From beitz@partnersprocessing.com Sat Sep 01 09:37:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRT9p-0007d4-2V for geopriv-archive@lists.ietf.org; Sat, 01 Sep 2007 09:37:01 -0400 Received: from [190.142.66.230] (helo=[190.142.66.230]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRT9o-0000e9-GN for geopriv-archive@lists.ietf.org; Sat, 01 Sep 2007 09:37:00 -0400 Received: by 10.66.63.26 with SMTP id MAkLdKCDwfrlI; Sat, 1 Sep 2007 09:37:15 -0400 (GMT) Received: by 192.168.20.20 with SMTP id IRoqpCHvJOrwUS.9646899916357; Sat, 1 Sep 2007 09:37:13 -0400 (GMT) Message-ID: <000901c7ec9d$32cced60$e6428ebe@microsoft> From: "Marcelino beitz" To: Subject: iekeist{ Date: Sat, 1 Sep 2007 09:37:10 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7EC7B.ABBB4D60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7EC7B.ABBB4D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.arratx.com/ News to beitz My peni$ grew 2=92=92 after 5 months of use Paavo Lodding ------=_NextPart_000_0003_01C7EC7B.ABBB4D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.arratx.com/
News to beitz
My peni$ grew 2=92=92 after 5 months of = use
Paavo Lodding
------=_NextPart_000_0003_01C7EC7B.ABBB4D60-- From Peeryiac@dedbrasil.org.br Sat Sep 01 20:58:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRdnG-0006dJ-DY for geopriv-archive@lists.ietf.org; Sat, 01 Sep 2007 20:58:26 -0400 Received: from 20151238134.user.veloxzone.com.br ([201.51.238.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRdn9-0002KR-UC for geopriv-archive@lists.ietf.org; Sat, 01 Sep 2007 20:58:26 -0400 Received: by 10.15.150.177 with SMTP id KCFATOlhlxgfN; Mon, 27 Aug 2007 21:57:22 -1200 (GMT) Received: by 192.168.34.68 with SMTP id DsKWJTLAthzSsQ.3590882337648; Mon, 27 Aug 2007 21:57:20 -1200 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2007 21:57:17 -1200 To: geopriv-archive@lists.ietf.org From: "Dynell Peery" Subject: seretff" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hello Dynell winner of the 2007 herbal gold medal kkk Momin http://asdcs.com/ From geopriv-bounces@ietf.org Sun Sep 02 09:42:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRph4-0003mb-Vp; Sun, 02 Sep 2007 09:40:50 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IRph3-0003mR-FV for geopriv-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 09:40:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRph3-0003mJ-44; Sun, 02 Sep 2007 09:40:49 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IRph2-0003y0-5B; Sun, 02 Sep 2007 09:40:49 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc346db1409; Sun, 02 Sep 2007 21:52:59 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1246d5de50; Thr, 30 Aug 2007 03:52:43 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 30 Aug 2007 03:52:43 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQT0h-0002b3-Bs; Wed, 29 Aug 2007 15:15:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQT0I-0002YO-N5; Wed, 29 Aug 2007 15:15:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQT0I-0005m1-8l; Wed, 29 Aug 2007 15:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1F2292AC6F; Wed, 29 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQT0H-0003xF-OG; Wed, 29 Aug 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 29 Aug 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: geopriv@ietf.org Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-radius-lo-16.txt X-BeenThere: geopriv@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org --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 : Carrying Location Objects in RADIUS and Diameter Author(s) : H. Tschofenig, et al. Filename : draft-ietf-geopriv-radius-lo-16.txt Pages : 63 Date : 2007-8-29 This document describes procedures for conveying access network ownership and location information based on a civic and geospatial location format in Remote Authentication Dial In User Service (RADIUS) and Diameter. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and addressed in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-radius-lo-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-geopriv-radius-lo-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-29145240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-geopriv-radius-lo-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-geopriv-radius-lo-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-29145240.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --NextPart-- From Steinlechnerscqt@multiple.tv Sun Sep 02 20:57:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS0Fb-0001sD-01 for geopriv-archive@lists.ietf.org; Sun, 02 Sep 2007 20:57:11 -0400 Received: from p578b6493.dip0.t-ipconnect.de ([87.139.100.147]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS0Fa-0000rH-FC for geopriv-archive@lists.ietf.org; Sun, 02 Sep 2007 20:57:10 -0400 Received: from pc-andreas ([191.110.191.168]:25344 "EHLO pc-andreas" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by p578b6493.dip0.t-ipconnect.de with ESMTP id S22DLWAXIUFCBQLD (ORCPT ); Mon, 3 Sep 2007 02:54:12 +0200 Message-ID: <000301c7edc4$df8f4570$93648b57@pcandreas> From: "tram Steinlechner" To: Subject: essatupe Date: Mon, 3 Sep 2007 02:53:42 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7EDD5.A3181570" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C7EDD5.A3181570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.elegeek.com/ Yo Steinlechner This stuff is selling like crazy, As seen on TV Caio STREET ------=_NextPart_000_0007_01C7EDD5.A3181570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.elegeek.com/
Yo Steinlechner
This stuff is selling like crazy, As seen on = TV
Caio STREET
------=_NextPart_000_0007_01C7EDD5.A3181570-- From min223@BUENOFOODS.COM Mon Sep 03 03:21:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS6FK-0001Da-K9 for geopriv-archive@lists.ietf.org; Mon, 03 Sep 2007 03:21:18 -0400 Received: from dwx236.internetdsl.tpnet.pl ([83.14.23.236] helo=xdsl-328.jgora.dialog.net.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS6FK-0008AG-2C for geopriv-archive@lists.ietf.org; Mon, 03 Sep 2007 03:21:18 -0400 Received: from dno-59ae48f273f ([109.184.4.150]:22705 "EHLO dno-59ae48f273f" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by xdsl-328.jgora.dialog.net.pl with ESMTP id S22NOTOVGASTDXCQ (ORCPT ); Mon, 3 Sep 2007 09:21:55 +0200 Message-ID: <000901c7edfb$04b8e9b0$4895a851@dno59ae48f273f> From: "min Kjemhus" To: Subject: tneregit Date: Mon, 3 Sep 2007 09:21:17 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7EE0B.C841B9B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C7EE0B.C841B9B0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable http://www.equiphi.com/ Good day geopriv-archive i am the most confident person around Karrie Driver ------=_NextPart_000_0005_01C7EE0B.C841B9B0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
http://www.equiphi.com/
Good day geopriv-archive
i am the most confident person = around
Karrie Driver
------=_NextPart_000_0005_01C7EE0B.C841B9B0-- From geopriv-bounces@ietf.org Mon Sep 03 19:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISLSr-0005ol-I3; Mon, 03 Sep 2007 19:36:17 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1ISLSq-0005ob-7Z for geopriv-confirm+ok@megatron.ietf.org; Mon, 03 Sep 2007 19:36:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISLSp-0005oT-Pn for geopriv@ietf.org; Mon, 03 Sep 2007 19:36:15 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISLSo-0001hy-9g for geopriv@ietf.org; Mon, 03 Sep 2007 19:36:15 -0400 X-SEF-Processed: 5_0_0_910__2007_09_03_18_45_25 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 03 Sep 2007 18:45:25 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Sep 2007 18:36:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] singh-geopriv-pdif-lo-dynamic difference betweenbearingand directionOfObject Date: Mon, 3 Sep 2007 18:36:09 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] singh-geopriv-pdif-lo-dynamic difference betweenbearingand directionOfObject Thread-Index: AcfbZ5nCu6c/+b6cQoqJDq8834AzfATGqCQw References: <46B87226.3050803@pernau.at> <20070808124500.76850@gmx.net><01b401c7d9d1$e8366660$6401a8c0@SusieandCarl> From: "Thomson, Martin" To: "Henning Schulzrinne" , "Carl Reed OGC Account" X-OriginalArrivalTime: 03 Sep 2007 23:36:11.0423 (UTC) FILETIME=[35CEF2F0:01C7EE83] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1351791234==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1351791234== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7EE83.35C86400" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EE83.35C86400 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KEp1c3QgY2F0Y2hpbmcgdXAgb24gZW1haWxzLikNCg0KIA0KDQpJIGJlbGlldmUgdGhhdCBJIHJh aXNlZCBhIHJlbGF0ZWQgcG9pbnQgZWFybGllci4gIFRoZSB1c2UgY2FzZSBpcyB0aGF0IG9mIGEg dG91cmlzdCBvbiBhIGJ1cy4gIFNheSB5b3UgYXJlIGRyaXZpbmcgcGFzdCBhIHN0cmFuZ2Ugb2Jq ZWN0LCB5b3UgcG9pbnQgeW91ciDigJxkZXZpY2XigJ0gYXQgaXQgYW5kIHByZXNzIHRoZSDigJx3 aGF0c2l04oCdIGJ1dHRvbi4gIFRoZSBzZXJ2aWNlIGlzIGludGVyZXN0ZWQgaW4gdGhlIGRpcmVj dGlvbiB5b3UgYXJlIHBvaW50aW5nIChiZWFyaW5nKSwgbm90IHRoZSBkaXJlY3Rpb24gdGhhdCB0 aGUgYnVzIGlzIHRyYXZlbGluZyBhdCB0aGF0IGluc3RhbnQgKGRpcmVjdGlvbk9mT2JqZWN0KS4g IE9uIHRoZSBvdGhlciBoYW5kLCBhIG5hdmlnYXRpb24gYXBwbGljYXRpb24gaXMgcHJvYmFibHkg Z29pbmcgdG8gYmUgbW9yZSBjb25jZXJuZWQgd2l0aCB0aGUgbW92ZW1lbnQgb2YgdGhlIGJ1cy4N Cg0KIA0KDQpUaGUgZXhhbXBsZSBiZWxvdyBvZiB0aGUgc3RlZXJpbmcgd2hlZWwgaXMgdHJpdmlh bCBhbmQgKEkgYWdyZWUpIHBvaW50bGVzcy4gIFRoZSBwcmVjaXNlIG9yaWVudGF0aW9uIGFnYWlu c3QgZ2VuZXJhbCBkaXJlY3Rpb24gb2YgdHJhdmVsIGlzIHByb2JhYmx5IHVuaW1wb3J0YW50LiAg SW4gdGhvc2UgY2FzZXMsIGRpcmVjdGlvbk9mT2JqZWN0IGlzIHByb2JhYmx5IHRoZSBvbmx5IG1l YXN1cmVtZW50IG9mIGludGVyZXN0Lg0KDQogDQoNCk1hcnRpbg0KDQogDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0 bzpoZ3NAY3MuY29sdW1iaWEuZWR1XSANClNlbnQ6IFNhdHVyZGF5LCAxMSBBdWd1c3QgMjAwNyAy OjAwIEFNDQpUbzogQ2FybCBSZWVkIE9HQyBBY2NvdW50DQpDYzogZ2VvcHJpdkBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtHZW9wcml2XSBzaW5naC1nZW9wcml2LXBkaWYtbG8tZHluYW1pYyBkaWZm ZXJlbmNlIGJldHdlZW5iZWFyaW5nYW5kIGRpcmVjdGlvbk9mT2JqZWN0DQoNCiANCg0KSSB0aGlu ayB0aGUgdGVybSB3YXMgYWRkZWQgYWZ0ZXIgdGhlIGluaXRpYWwgZGlzY3Vzc2lvbiBvZiB0aGUg ZG9jdW1lbnQsIGJ1dCBJIHN1c3BlY3QgdGhhdCBmdXJ0aGVyIGFuYWx5c2lzIG9mIHVzZSBjYXNl cyBpcyBuZWVkZWQuIE91ciBmb2N1cyBoYXMgYmVlbiBvbiByZXByZXNlbnRpbmcgcmVsYXRpdmVs eSBsYXJnZSBtb3Zpbmcgb2JqZWN0cywgc3VjaCBhcyBjYXJzIGFuZCBzaGlwcyB0aGF0IGhhdmUg Ym90aCBhbiBpbnN0YW50YW5lb3VzIG9yaWVudGF0aW9uIGFuZCBhIGdlbmVyYWwgZGlyZWN0aW9u IG9mIHRyYXZlbC4gVGhpcyB3b3VsZCBpbXBseSBhIGJlYXJpbmcgaW4gdGhlIGFlcm9uYXV0aWNh bCBzZW5zZS4gV2hhdCBJJ20gbm90IGNsZWFyIGFib3V0IGlzIHRoZSB0aW1lIHNjYWxlLiBEb2Vz IHRoaXMgY2hhbmdlIGVhY2ggaW5zdGFudCB0aGF0IEkgdHVybiB0aGUgc3RlZXJpbmcgd2hlZWwg YSBiaXQgdG8gY2hhbmdlIGxhbmVzIG9yIGlzIHRoaXMgYXZlcmFnZWQsIHNvIHRoYXQgaXQgc2F5 cyAiaGVhZGluZyB3ZXN0IiB3aGVuIEknbSBsZWF2aW5nIE5ZQyBvbiBJLTgwPw0KDQogDQoNCkhl bm5pbmcNCg0KIA0KDQpPbiBBdWcgOCwgMjAwNywgYXQgMTE6MzUgQU0sIENhcmwgUmVlZCBPR0Mg QWNjb3VudCB3cm90ZToNCg0KDQoNCg0KDQpKdXN0IGEgdGhvdWdodC4NCg0KIA0KDQpBIGJlYXJp bmcgdGVuZHMgdG8gYmUgdXNlZCBpbiBzdXJ2ZXlpbmcgdG8gZGVmaW5lIGFic29sdXRlIGxvY2F0 aW9uIGZyb20gYSBmaXhlZCBwb2ludCB0byBhIGdpdmVuIG9iamVjdCAoc3VjaCBhcyBmcm9tIGEg Z2VvZGV0aWMgbW9udW1lbnQgdG8gdGhlIGNvcm5lciBvZiBhIHByb3BlcnR5IG9yIHRvIGRlZmlu ZSBhIG5ldyBwb2ludCBsb2NhdGlvbiByZWxhdGl2ZSB0byBhIGtub3duIHBvaW50IGxvY2F0aW9u IChzdWNoIGFzIGZyb20gdGhlIGNvcm5lciBvZiBhIHByb3BlcnR5IHRvIHRoZSBuZXh0IHBvaW50 IGRlZmluaW5nIHRoZSBib3VuZGFyeSBvZiBhIHByb3BlcnR5LiBUaGlzIGNhc2UgaXMgYWx3YXlz IGRvbmUgYXMgYSBkaXN0YW5jZSBhbmQgYmVhcmluZykuIEluIGFlcm9uYXV0aWNzLCBhIGJlYXJp bmcgaXMgc2ltcGx5IHRoZSBkaXJlY3Rpb24gb2YgdHJhdmVsIHdpdGggbm8gdGFyZ2V0IGxvY2F0 aW9uIGJlaW5nIGRlZmluZWQuIFNvLCBpbiB0ZXJtcyBvZiBQSURGLUxPIGR5bmFtaWMsIGEgYmVh cmluZyBjb3VsZCBiZSB0aGUgc2ltcGxlIGNhc2Ugb2YgYSBkeW5hbWljIG9iamVjdCBtb3Zpbmcg YXQgYSBrbm93biBiZWFyaW5nIG9yIGEgYmVhcmluZyBmcm9tIGEga25vd24gbG9jYXRpb24gb2Zm IGludG8gaW5maW5pdHkuIE15IHJlYWRpbmcgb2YgdGhlIGRvY3VtZW50IGlzIHRoYXQgdGhlcmUg aXMgbm8gImRpc3RhbmNlIiBwcm9wZXJ0eSIgUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9u Zy4gSW4gYWxsIGNhc2VzLCB0aGVyZSBpcyBhIHN0cm9uZyBzdWdnZXN0aW9uIG9mICJzdGF0aWMi IGFzIG9wcG9zZWQgdG8gImR5bmFtaWMiIC0gZXZlbiBpZiBhIGJlYXJpbmcgaXMgdXNlZCB0byBk ZXNjcmliZSB0aGUgZGlyZWN0aW9uIGFuIG9iamVjdCBpcyBtb3ZpbmcuDQoNCiANCg0KTm93LCB3 aXRoIGEgc2xpZ2h0IGNoYW5nZSBvZiBkZWZpbml0aW9uIG9mIGRpcmVjdGlvbk9mT2JqZWN0LCB5 b3UgY291bGQgaGFuZGxlIGRlc2NyaWJpbmcgdGhlIGxvY2F0aW9uIGEgdHJ1bHkgZHluYW1pYyBv YmplY3QgaW4gNCBzcGFjZSAoeCx5LHosdCkuIFRoZSBjaGFuZ2Ugb2YgY29uY2VwdCB3b3VsZCBi ZSBmcm9tIGxvb2tpbmcgYXQgdGhpcyBlbGVtZW50IGFzIGEgcHJvcGVydHkgb2YgYW4gb2JqZWN0 IHRvIG9uZSBvZiBhIG1lYXN1cmVtZW50IHJlbGF0ZWQgdG8gdGhlIG9iamVjdC4gVGhlIE9HQyBo YXMgZG9uZSBjb25zaWRlcmFibGUgd29yayBpbiBkZWZpbmluZyBhIG1vZGVsIGFuZCByZWxhdGVk IHN0YW5kYXJkcyBmb3IgZGVzY3JpYmluZyBib3RoIHN0YXRpYyBhbmQgZHluYW1pYyBzeXN0ZW1z ICh0eXBpY2FsbHkgb25lIG9yIG1vcmUgc2Vuc29ycykuIEJlbG93IG15IHNpZ25hdHVyZSBpcyBh IHNob3J0IHBhcmFncmFwaCBvbiB0aGUgY29uY2VwdCBvZiBhICJtZWFzdXJlbWVudCIgaW4gT0dD L0lTTy9JRUVFIGxhbmQuIFRoaXMgcGFyYWdyYXBoIHdhcyBleHRyYWN0ZWQgZnJvbSB0aGUgcmVj ZW50bHkgYXBwcm92ZWQgT0dDIFN0YW5kYXJkIHRpdGxlZCBTZW5zb3JNTCAoU2Vuc29yIE1hcmt1 cCBMYW5ndWFnZSkuIE5vdGUgc2hvdWxkIGJlIGdpdmVuIHRoYXQgY29vcmRpbmF0ZSByZWZlcmVu Y2Ugc3lzdGVtcyBjYW4gYmVjb21lIHF1aXRlIGludGVyZXN0aW5nIHdoZW4gZGVhbGluZyB3aXRo IHNvbWUgc2Vuc29yIHN5c3RlbXMgOi0pDQoNCiANCg0KVGhlIHJlYXNvbiB0aGF0IEkgbWVudGlv biB0aGUgY29uY2VwdCBvZiBhIGR5bmFtaWMgb2JqZWN0IGlzIHRoYXQgbW9yZSBhbmQgbW9yZSBs b2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBnb2luZyB0byBiZSBtZWFzdXJlZCB1c2luZyBtb2JpbGUg YXNzZXRzLCBzdWNoIGFzIHRoZSBuZXh0IGdlbmVyYXRpb24gc2Vuc29yIGVuYWJsZSB2ZWhpY2xl IGFuZCB0aGUgbmF0aW9uYWwgcm9hZHNpZGUgc2Vuc29yIG5ldHdvcmsuIFRoZXJlIGFyZSBhIHZh cmlldHkgb2YgYXBwbGljYXRpb24gLSBhbmQgcGF5bG9hZCAtIGltcGxpY2F0aW9ucyByZWxhdGVk IHRvIHRoZSBhdmFpbGFiaWxpdHkgDQoNCiANCg0KRnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBJIHRo aW5rIHRoYXQgdGhlIHBpZGYtbG8tZHluYW1pYyBhY3Rpdml0eSBpcyBoaWdobHkgaW1wb3J0YW50 LiANCg0KIA0KDQpSZWdhcmRzDQoNCiANCg0KQ2FybA0KDQogDQoNCk1lYXN1cmVtZW50ICh2ZXJi KQ0KQW4gaW5zdGFuY2Ugb2YgYSBwcm9jZWR1cmUgdG8gZXN0aW1hdGUgdGhlIHZhbHVlIG9mIGEg bmF0dXJhbCBwaGVub21lbm9uLCB0eXBpY2FsbHkgaW52b2x2aW5nIGFuIGluc3RydW1lbnQgb3Ig c2Vuc29yLiBUaGlzIGlzIGltcGxlbWVudGVkIGFzIGEgZHluYW1pYyBmZWF0dXJlIHR5cGUsIHdo aWNoIGhhcyBhIHByb3BlcnR5IGNvbnRhaW5pbmcgdGhlIHJlc3VsdCBvZiB0aGUgbWVhc3VyZW1l bnQuIFRoZSBtZWFzdXJlbWVudCBmZWF0dXJlIGFsc28gaGFzIGEgbG9jYXRpb24sIHRpbWUsIGFu ZCByZWZlcmVuY2UgdG8gdGhlIG1ldGhvZCB1c2VkIHRvIGRldGVybWluZSB0aGUgdmFsdWUuIEEg bWVhc3VyZW1lbnQgZmVhdHVyZSBlZmZlY3RpdmVseSBiaW5kcyBhIHZhbHVlIHRvIGEgbG9jYXRp b24gYW5kIHRvIGEgbWV0aG9kIG9yIGluc3RydW1lbnQuDQoNCiANCg0KLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCg0KRnJvbTogIkhhbm5lcyBUc2Nob2ZlbmlnIiA8SGFubmVzLlRzY2hv ZmVuaWdAZ214Lm5ldD4NCg0KVG86ICJLbGF1cyBEYXJpbGlvbiIgPGtsYXVzLm1haWxpbmdsaXN0 c0BwZXJuYXUuYXQ+OyA8Z2VvcHJpdkBpZXRmLm9yZz4NCg0KU2VudDogV2VkbmVzZGF5LCBBdWd1 c3QgMDgsIDIwMDcgNjo0NSBBTQ0KDQpTdWJqZWN0OiBSZTogW0dlb3ByaXZdIHNpbmdoLWdlb3By aXYtcGRpZi1sby1keW5hbWljIGRpZmZlcmVuY2UgYmV0d2VlbiBiZWFyaW5nYW5kIGRpcmVjdGlv bk9mT2JqZWN0DQoNCiANCg0KPiBIaSBLbGF1cyANCj4gDQo+IEkgdG9vayBhIGxvb2sgYXQgdGhl IEdNTHYzIHNwZWNpZmljYXRpb24gYWdhaW4gYW5kIG5vdGljZWQgdGhhdCBJIGRpZCBub3QgZ2V0 IHRoZSB0ZXJtIGZyb20gdGhlcmUuIEdvb2QgcXVlc3Rpb24gd2hlcmUgaXQgY2FtZSBmcm9tIGdp dmVuIHRoYXQgaXQgd2FzIG5vdCBpbiB0aGUgLTAwIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LiAN Cj4gDQo+IEkgZ3Vlc3MgSSBuZWVkIHRvIGNoYXQgd2l0aCBteSBjby1hdXRob3JzLg0KPiANCj4g Q2lhbw0KPiBIYW5uZXMNCj4gDQo+IC0tLS0tLS0tIE9yaWdpbmFsLU5hY2hyaWNodCAtLS0tLS0t LQ0KPiBEYXR1bTogVHVlLCAwNyBBdWcgMjAwNyAxNToyMjo0NiArMDIwMA0KPiBWb246IEtsYXVz IERhcmlsaW9uIDxrbGF1cy5tYWlsaW5nbGlzdHNAcGVybmF1LmF0Pg0KPiBBbjogZ2VvcHJpdkBp ZXRmLm9yZw0KPiBCZXRyZWZmOiBbR2VvcHJpdl0gc2luZ2gtZ2VvcHJpdi1wZGlmLWxvLWR5bmFt aWMgZGlmZmVyZW5jZSBiZXR3ZWVuIGJlYXJpbmcgYW5kIGRpcmVjdGlvbk9mT2JqZWN0DQo+IA0K Pj4gSGkhDQo+PiANCj4+IENvdWxkIHNvbWVvbmUgcGxlYXNlIGRlc2NyaWJlIHRoZSBkaWZmZXJl bmNlIGJldHdlZW4gYmVhcmluZyBhbmQgDQo+PiBkaXJlY3Rpb25PZk9iamVjdD8NCj4+IA0KPj4g dGhhbmtzDQo+PiBLbGF1cw0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPj4gR2VvcHJp dkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2Vv cHJpdg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpHZW9wcml2IG1haWxpbmcg bGlzdA0KDQpHZW9wcml2QGlldGYub3JnDQoNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2dlb3ByaXYNCg0KIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9u bHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl IHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9y aWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRl ZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== ------_=_NextPart_001_01C7EE83.35C86400 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCg0KPG1ldGEgbmFtZT1HZW5lcmF0 b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9c Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHls ZT4NCjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpB cmlhbDsNCgljb2xvcjptYXJvb247DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQoNCjwv aGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9Ymx1ZSBzdHlsZT0nd29y ZC13cmFwOiBicmVhay13b3JkOy1raHRtbC1uYnNwLW1vZGU6IHNwYWNlOw0KLWtodG1sLWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlJz4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9v bic+KEp1c3QgY2F0Y2hpbmcgdXAgb24gZW1haWxzLik8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bWFyb29uJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bWFyb29u Jz5JIGJlbGlldmUgdGhhdCBJIHJhaXNlZCBhIHJlbGF0ZWQgcG9pbnQNCmVhcmxpZXIuwqAgVGhl IHVzZSBjYXNlIGlzIHRoYXQgb2YgYSB0b3VyaXN0IG9uIGEgYnVzLsKgIFNheSB5b3UgYXJlIGRy aXZpbmcgcGFzdA0KYSBzdHJhbmdlIG9iamVjdCwgeW91IHBvaW50IHlvdXIg4oCcZGV2aWNl4oCd IGF0IGl0IGFuZCBwcmVzcyB0aGUg4oCcd2hhdHNpdOKAnQ0KYnV0dG9uLsKgIFRoZSBzZXJ2aWNl IGlzIGludGVyZXN0ZWQgaW4gdGhlIGRpcmVjdGlvbiB5b3UgYXJlIHBvaW50aW5nIChiZWFyaW5n KSwNCm5vdCB0aGUgZGlyZWN0aW9uIHRoYXQgdGhlIGJ1cyBpcyB0cmF2ZWxpbmcgYXQgdGhhdCBp bnN0YW50DQooZGlyZWN0aW9uT2ZPYmplY3QpLsKgIE9uIHRoZSBvdGhlciBoYW5kLCBhIG5hdmln YXRpb24gYXBwbGljYXRpb24gaXMgcHJvYmFibHkNCmdvaW5nIHRvIGJlIG1vcmUgY29uY2VybmVk IHdpdGggdGhlIG1vdmVtZW50IG9mIHRoZSBidXMuPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOm1hcm9vbic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+ VGhlIGV4YW1wbGUgYmVsb3cgb2YgdGhlIHN0ZWVyaW5nIHdoZWVsDQppcyB0cml2aWFsIGFuZCAo SSBhZ3JlZSkgcG9pbnRsZXNzLsKgIFRoZSBwcmVjaXNlIG9yaWVudGF0aW9uIGFnYWluc3QgZ2Vu ZXJhbA0KZGlyZWN0aW9uIG9mIHRyYXZlbCBpcyBwcm9iYWJseSB1bmltcG9ydGFudC7CoCBJbiB0 aG9zZSBjYXNlcywgZGlyZWN0aW9uT2ZPYmplY3QNCmlzIHByb2JhYmx5IHRoZSBvbmx5IG1lYXN1 cmVtZW50IG9mIGludGVyZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bWFyb29uIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjptYXJvb24n PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9bWFyb29uIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjptYXJvb24nPk1hcnRpbjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9bWFyb29uIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjptYXJvb24nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYg Y2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxm b250IHNpemU9Mw0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEyLjBwdCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRl eD0tMT4NCg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxm b250IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9i Pjxmb250IHNpemU9Mg0KZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6VGFob21hJz4gSGVubmluZw0KU2NodWx6cmlubmUgW21haWx0bzpoZ3NAY3Mu Y29sdW1iaWEuZWR1XSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2Vu dDo8L3NwYW4+PC9iPiBTYXR1cmRheSwgMTEgQXVndXN0IDIwMDcNCjI6MDAgQU08YnI+DQo8Yj48 c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gQ2FybCBSZWVkIE9H QyBBY2NvdW50PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPkNjOjwvc3Bh bj48L2I+IGdlb3ByaXZAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6 Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0dlb3ByaXZdDQpzaW5naC1nZW9wcml2LXBk aWYtbG8tZHluYW1pYyBkaWZmZXJlbmNlIGJldHdlZW5iZWFyaW5nYW5kIGRpcmVjdGlvbk9mT2Jq ZWN0PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+SSB0aGluayB0aGUgdGVy bSB3YXMgYWRkZWQgYWZ0ZXIgdGhlIGluaXRpYWwgZGlzY3Vzc2lvbiBvZiB0aGUNCmRvY3VtZW50 LCBidXQgSSBzdXNwZWN0IHRoYXQgZnVydGhlciBhbmFseXNpcyBvZiB1c2UgY2FzZXMgaXMgbmVl ZGVkLiBPdXIgZm9jdXMNCmhhcyBiZWVuIG9uIHJlcHJlc2VudGluZyByZWxhdGl2ZWx5IGxhcmdl IG1vdmluZyBvYmplY3RzLCBzdWNoIGFzIGNhcnMgYW5kDQpzaGlwcyB0aGF0IGhhdmUgYm90aCBh biBpbnN0YW50YW5lb3VzIG9yaWVudGF0aW9uIGFuZCBhIGdlbmVyYWwgZGlyZWN0aW9uIG9mDQp0 cmF2ZWwuIFRoaXMgd291bGQgaW1wbHkgYSBiZWFyaW5nIGluIHRoZSBhZXJvbmF1dGljYWwgc2Vu c2UuIFdoYXQgSSdtIG5vdA0KY2xlYXIgYWJvdXQgaXMgdGhlIHRpbWUgc2NhbGUuIERvZXMgdGhp cyBjaGFuZ2UgZWFjaCBpbnN0YW50IHRoYXQgSSB0dXJuIHRoZQ0Kc3RlZXJpbmcgd2hlZWwgYSBi aXQgdG8gY2hhbmdlIGxhbmVzIG9yIGlzIHRoaXMgYXZlcmFnZWQsIHNvIHRoYXQgaXQgc2F5cw0K JnF1b3Q7aGVhZGluZyB3ZXN0JnF1b3Q7IHdoZW4gSSdtIGxlYXZpbmcgTllDIG9uIEktODA/PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPkhl bm5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5PbiBB dWcgOCwgMjAwNywgYXQgMTE6MzUgQU0sIENhcmwgUmVlZCBPR0MgQWNjb3VudCB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5KdXN0IGEgdGhvdWdodC48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+ QSBiZWFyaW5nIHRlbmRzIHRvIGJlIHVzZWQgaW4gc3VydmV5aW5nIHRvIGRlZmluZSBhYnNvbHV0 ZSBsb2NhdGlvbg0KZnJvbSBhIGZpeGVkIHBvaW50IHRvIGEgZ2l2ZW4gb2JqZWN0IChzdWNoIGFz IGZyb20gYSBnZW9kZXRpYyBtb251bWVudCB0byB0aGUNCmNvcm5lciBvZiBhIHByb3BlcnR5IG9y IHRvIGRlZmluZSBhIG5ldyBwb2ludCBsb2NhdGlvbiByZWxhdGl2ZSB0byBhIGtub3duDQpwb2lu dCBsb2NhdGlvbiAoc3VjaCBhcyBmcm9tIHRoZSBjb3JuZXIgb2YgYSBwcm9wZXJ0eSB0byB0aGUg bmV4dCBwb2ludA0KZGVmaW5pbmcgdGhlIGJvdW5kYXJ5IG9mIGEgcHJvcGVydHkuIFRoaXMgY2Fz ZSBpcyBhbHdheXMgZG9uZSBhcyBhIGRpc3RhbmNlIGFuZA0KYmVhcmluZykuIEluIGFlcm9uYXV0 aWNzLCBhIGJlYXJpbmcgaXMgc2ltcGx5IHRoZSBkaXJlY3Rpb24gb2YgdHJhdmVsIHdpdGggbm8N CnRhcmdldCBsb2NhdGlvbiBiZWluZyBkZWZpbmVkLiBTbywgaW4gdGVybXMgb2YgUElERi1MTyBk eW5hbWljLCBhIGJlYXJpbmcgY291bGQNCmJlIHRoZSBzaW1wbGUgY2FzZSBvZiBhIGR5bmFtaWMg b2JqZWN0IG1vdmluZyBhdCBhIGtub3duIGJlYXJpbmcgb3ImbmJzcDthIGJlYXJpbmcNCmZyb20g YSBrbm93biBsb2NhdGlvbiBvZmYgaW50byBpbmZpbml0eS4gTXkgcmVhZGluZyBvZiB0aGUgZG9j dW1lbnQgaXMgdGhhdA0KdGhlcmUgaXMgbm8gJnF1b3Q7ZGlzdGFuY2UmcXVvdDsgcHJvcGVydHkm cXVvdDsgUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbQ0Kd3JvbmcuIEluIGFsbCBjYXNlcywgdGhl cmUgaXMgYSBzdHJvbmcgc3VnZ2VzdGlvbiBvZiAmcXVvdDtzdGF0aWMmcXVvdDsgYXMNCm9wcG9z ZWQgdG8gJnF1b3Q7ZHluYW1pYyZxdW90OyAtIGV2ZW4gaWYgYSBiZWFyaW5nIGlzIHVzZWQgdG8g ZGVzY3JpYmUgdGhlDQpkaXJlY3Rpb24gYW4gb2JqZWN0IGlzIG1vdmluZy48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Tm93LCB3aXRoIGEg c2xpZ2h0IGNoYW5nZSBvZiBkZWZpbml0aW9uIG9mIGRpcmVjdGlvbk9mT2JqZWN0LCB5b3UgY291 bGQNCmhhbmRsZSBkZXNjcmliaW5nIHRoZSBsb2NhdGlvbiBhIHRydWx5IGR5bmFtaWMgb2JqZWN0 IGluIDQgc3BhY2UgKHgseSx6LHQpLiBUaGUNCmNoYW5nZSBvZiBjb25jZXB0IHdvdWxkIGJlIGZy b20gbG9va2luZyBhdCB0aGlzIGVsZW1lbnQgYXMgYSBwcm9wZXJ0eSBvZiBhbg0Kb2JqZWN0IHRv IG9uZSBvZiBhIG1lYXN1cmVtZW50IHJlbGF0ZWQgdG8gdGhlIG9iamVjdC4gVGhlIE9HQyBoYXMg ZG9uZQ0KY29uc2lkZXJhYmxlIHdvcmsgaW4gZGVmaW5pbmcgYSBtb2RlbCBhbmQgcmVsYXRlZCBz dGFuZGFyZHMgZm9yIGRlc2NyaWJpbmcgYm90aA0Kc3RhdGljIGFuZCBkeW5hbWljIHN5c3RlbXMg KHR5cGljYWxseSBvbmUgb3IgbW9yZSBzZW5zb3JzKS4gQmVsb3cgbXkgc2lnbmF0dXJlDQppcyBh IHNob3J0IHBhcmFncmFwaCBvbiB0aGUgY29uY2VwdCBvZiBhICZxdW90O21lYXN1cmVtZW50JnF1 b3Q7IGluDQpPR0MvSVNPL0lFRUUgbGFuZC4gVGhpcyBwYXJhZ3JhcGggd2FzIGV4dHJhY3RlZCBm cm9tIHRoZSByZWNlbnRseSBhcHByb3ZlZCBPR0MNClN0YW5kYXJkIHRpdGxlZCBTZW5zb3JNTCAo U2Vuc29yIE1hcmt1cCBMYW5ndWFnZSkuIE5vdGUgc2hvdWxkIGJlIGdpdmVuIHRoYXQNCmNvb3Jk aW5hdGUgcmVmZXJlbmNlIHN5c3RlbXMgY2FuIGJlY29tZSBxdWl0ZSBpbnRlcmVzdGluZyB3aGVu IGRlYWxpbmcgd2l0aA0Kc29tZSBzZW5zb3Igc3lzdGVtcyA6LSk8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox Mi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+VGhlIHJlYXNvbiB0aGF0IEkg bWVudGlvbiB0aGUgY29uY2VwdCBvZiBhIGR5bmFtaWMgb2JqZWN0IGlzIHRoYXQgbW9yZQ0KYW5k IG1vcmUgbG9jYXRpb24gaW5mb3JtYXRpb24gaXMgZ29pbmcgdG8gYmUgbWVhc3VyZWQgdXNpbmcg bW9iaWxlIGFzc2V0cywgc3VjaA0KYXMgdGhlIG5leHQgZ2VuZXJhdGlvbiBzZW5zb3IgZW5hYmxl IHZlaGljbGUgYW5kIHRoZSBuYXRpb25hbCByb2Fkc2lkZSBzZW5zb3INCm5ldHdvcmsuIFRoZXJl IGFyZSBhIHZhcmlldHkgb2YgYXBwbGljYXRpb24gLSBhbmQgcGF5bG9hZCAtIGltcGxpY2F0aW9u cw0KcmVsYXRlZCB0byB0aGUgYXZhaWxhYmlsaXR5IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5Gcm9tIHRoaXMgcGVyc3BlY3RpdmUsIEkg dGhpbmsgdGhhdCB0aGUgcGlkZi1sby1keW5hbWljIGFjdGl2aXR5IGlzDQpoaWdobHkgaW1wb3J0 YW50LiA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEy LjBwdCc+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz5DYXJsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMi4wcHQnPk1lYXN1cmVtZW50ICh2ZXJiKTxicj4NCkFuIGluc3RhbmNlIG9m IGEgcHJvY2VkdXJlIHRvIGVzdGltYXRlIHRoZSB2YWx1ZSBvZiBhIG5hdHVyYWwgcGhlbm9tZW5v biwNCnR5cGljYWxseSBpbnZvbHZpbmcgYW4gaW5zdHJ1bWVudCBvciBzZW5zb3IuIFRoaXMgaXMg aW1wbGVtZW50ZWQgYXMgYSBkeW5hbWljDQpmZWF0dXJlIHR5cGUsIHdoaWNoIGhhcyBhIHByb3Bl cnR5IGNvbnRhaW5pbmcgdGhlIHJlc3VsdCBvZiB0aGUgbWVhc3VyZW1lbnQuDQpUaGUgbWVhc3Vy ZW1lbnQgZmVhdHVyZSBhbHNvIGhhcyBhIGxvY2F0aW9uLCB0aW1lLCBhbmQgcmVmZXJlbmNlIHRv IHRoZSBtZXRob2QNCnVzZWQgdG8gZGV0ZXJtaW5lIHRoZSB2YWx1ZS4gQSBtZWFzdXJlbWVudCBm ZWF0dXJlIGVmZmVjdGl2ZWx5IGJpbmRzIGEgdmFsdWUgdG8NCmEgbG9jYXRpb24gYW5kIHRvIGEg bWV0aG9kIG9yIGluc3RydW1lbnQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMi4wcHQnPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMi4wcHQnPkZyb206ICZxdW90O0hhbm5lcyBUc2Nob2ZlbmlnJnF1b3Q7ICZsdDs8YQ0KaHJl Zj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQiPkhhbm5lcy5Uc2Nob2ZlbmlnQGdt eC5uZXQ8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+VG86ICZxdW90O0tsYXVzIERh cmlsaW9uJnF1b3Q7ICZsdDs8YQ0KaHJlZj0ibWFpbHRvOmtsYXVzLm1haWxpbmdsaXN0c0BwZXJu YXUuYXQiPmtsYXVzLm1haWxpbmdsaXN0c0BwZXJuYXUuYXQ8L2E+Jmd0OzsNCiZsdDs8YSBocmVm PSJtYWlsdG86Z2VvcHJpdkBpZXRmLm9yZyI+Z2VvcHJpdkBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOg0KMTIuMHB0Jz5TZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAwOCwgMjAwNyA2OjQ1 IEFNPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5TdWJqZWN0OiBSZTogW0dlb3ByaXZdIHNpbmdo LWdlb3ByaXYtcGRpZi1sby1keW5hbWljIGRpZmZlcmVuY2UgYmV0d2Vlbg0KYmVhcmluZ2FuZCBk aXJlY3Rpb25PZk9iamVjdDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCjEyLjBwdCc+Jmd0OyBIaSBLbGF1cyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0 b29rIGEgbG9vayBhdCB0aGUgR01MdjMgc3BlY2lmaWNhdGlvbiBhZ2FpbiBhbmQgbm90aWNlZCB0 aGF0IEkgZGlkIG5vdA0KZ2V0IHRoZSB0ZXJtIGZyb20gdGhlcmUuIEdvb2QgcXVlc3Rpb24gd2hl cmUgaXQgY2FtZSBmcm9tIGdpdmVuIHRoYXQgaXQgd2FzIG5vdA0KaW4gdGhlIC0wMCB2ZXJzaW9u IG9mIHRoZSBkb2N1bWVudC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZ3Vlc3MgSSBuZWVkIHRv IGNoYXQgd2l0aCBteSBjby1hdXRob3JzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBDaWFvPGJyPg0K Jmd0OyBIYW5uZXM8YnI+DQomZ3Q7Jm5ic3A7PGJyPg0KJmd0OyAtLS0tLS0tLSBPcmlnaW5hbC1O YWNocmljaHQgLS0tLS0tLS08YnI+DQomZ3Q7IERhdHVtOiBUdWUsIDA3IEF1ZyAyMDA3IDE1OjIy OjQ2ICswMjAwPGJyPg0KJmd0OyBWb246IEtsYXVzIERhcmlsaW9uICZsdDs8YSBocmVmPSJtYWls dG86a2xhdXMubWFpbGluZ2xpc3RzQHBlcm5hdS5hdCI+a2xhdXMubWFpbGluZ2xpc3RzQHBlcm5h dS5hdDwvYT4mZ3Q7PGJyPg0KJmd0OyBBbjogPGEgaHJlZj0ibWFpbHRvOmdlb3ByaXZAaWV0Zi5v cmciPmdlb3ByaXZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBCZXRyZWZmOiBbR2VvcHJpdl0gc2lu Z2gtZ2VvcHJpdi1wZGlmLWxvLWR5bmFtaWMgZGlmZmVyZW5jZSBiZXR3ZWVuDQpiZWFyaW5nIGFu ZCBkaXJlY3Rpb25PZk9iamVjdDxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgSGkhPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgQ291bGQgc29tZW9uZSBwbGVhc2UgZGVzY3JpYmUgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBiZWFyaW5nIGFuZCA8YnI+DQomZ3Q7Jmd0OyBkaXJlY3Rpb25PZk9i amVjdD88YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyB0aGFua3M8YnI+DQomZ3Q7Jmd0OyBL bGF1czxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgR2Vv cHJpdiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86R2VvcHJpdkBp ZXRmLm9yZyI+R2VvcHJpdkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2Ij5odHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2PC9hPjxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyBHZW9wcml2IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFp bHRvOkdlb3ByaXZAaWV0Zi5vcmciPkdlb3ByaXZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2Ij5odHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nZW9wcml2PC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIu MHB0Jz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+R2VvcHJpdiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMi4wcHQnPjxhIGhyZWY9Im1haWx0bzpHZW9wcml2QGlldGYub3JnIj5HZW9wcml2QGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdiI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZ2VvcHJpdjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxi cj48YnI+PHRhYmxlIGJnY29sb3I9d2hpdGUgc3R5bGU9ImNvbG9yOmJsYWNrIj48dHI+PHRkPjxi cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2lzJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7ZGVzaWduYXRlZCZuYnNwO3Jl Y2lwaWVudCZuYnNwO29ubHkmbmJzcDthbmQmbmJzcDttYXk8YnI+DQpjb250YWluJm5ic3A7cHJp dmlsZWdlZCwmbmJzcDtwcm9wcmlldGFyeSwmbmJzcDtvciZuYnNwO290aGVyd2lzZSZuYnNwO3By aXZhdGUmbmJzcDtpbmZvcm1hdGlvbi4mbmJzcDsmbmJzcDs8YnI+DQpJZiZuYnNwO3lvdSZuYnNw O2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO2l0Jm5ic3A7aW4mbmJzcDtlcnJvciwmbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtzZW5kZXI8YnI+DQppbW1lZGlhdGVseSZuYnNw O2FuZCZuYnNwO2RlbGV0ZSZuYnNwO3RoZSZuYnNwO29yaWdpbmFsLiZuYnNwOyZuYnNwO0FueSZu YnNwO3VuYXV0aG9yaXplZCZuYnNwO3VzZSZuYnNwO29mPGJyPg0KdGhpcyZuYnNwO2VtYWlsJm5i c3A7aXMmbmJzcDtwcm9oaWJpdGVkLjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxicj4NClttZjJdPC90ZD48L3RyPjwvdGFibGU+PC9ib2R5Pg0KDQo8L2h0bWw+ DQo= ------_=_NextPart_001_01C7EE83.35C86400-- --===============1351791234== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1351791234==-- From Pauliinabaladem@enablegroup.com Mon Sep 03 23:17:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISOv8-0008NS-Gp for geopriv-archive@lists.ietf.org; Mon, 03 Sep 2007 23:17:42 -0400 Received: from [189.24.86.138] (helo=18924189217.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISOv6-0001xi-G5 for geopriv-archive@lists.ietf.org; Mon, 03 Sep 2007 23:17:42 -0400 Received: from geologic-514cd5 ([178.172.28.60] helo=geologic-514cd5) by 18924189217.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1Brwxw-000ZIG-ym for geopriv-archive@lists.ietf.org; Tue, 4 Sep 2007 00:18:03 -0300 Message-ID: <000901c7eea2$276c4c70$d9bd18bd@geologic514cd5> From: "Pauliina baladem" To: Subject: depahsks Date: Tue, 4 Sep 2007 00:17:41 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7EE89.021F1470" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.6 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7EE89.021F1470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.mbvrt.com/ Wassup Pauliina ladies can sence a confident man, and they like it. Dahn larsson ------=_NextPart_000_0008_01C7EE89.021F1470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.mbvrt.com/
Wassup Pauliina
ladies can sence a confident man, and they = like it.
Dahn larsson
------=_NextPart_000_0008_01C7EE89.021F1470-- From nasser340@stachegmbh.de Tue Sep 04 09:49:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYmj-0005BT-RR for geopriv-archive@lists.ietf.org; Tue, 04 Sep 2007 09:49:41 -0400 Received: from cge145.neoplus.adsl.tpnet.pl ([83.30.232.145] helo=cfu236.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISYmi-0001Qp-RR for geopriv-archive@lists.ietf.org; Tue, 04 Sep 2007 09:49:41 -0400 Received: from 4add16a9556341e by stachegmbh.de with ASMTP id 765B4641 for ; Tue, 4 Sep 2007 15:49:57 +0200 Received: from 4add16a9556341e ([103.138.50.32]) by stachegmbh.de with ESMTP id 386EB3A1DCF2 for ; Tue, 4 Sep 2007 15:49:57 +0200 Message-ID: <000b01c7eefa$702e84c0$ecde1e53@4add16a9556341e> From: "nasser flock" To: Subject: fumatory Date: Tue, 4 Sep 2007 15:49:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7EF0B.33B754C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C7EF0B.33B754C0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.dicnay.com/ How it is going nasser With a larger manhood you penetrate more sensitive areas of the woman,, = WOW Brandis Nemec ------=_NextPart_000_0009_01C7EF0B.33B754C0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://www.dicnay.com/
How it is going nasser
With a larger manhood you penetrate more = sensitive areas=20 of the woman,, WOW
Brandis Nemec
------=_NextPart_000_0009_01C7EF0B.33B754C0-- From Fosterdlh@chowan.ces.state.nc.us Tue Sep 04 20:30:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISinG-0006JW-VQ for geopriv-archive@lists.ietf.org; Tue, 04 Sep 2007 20:30:54 -0400 Received: from host19-20-dynamic.6-87-r.retail.telecomitalia.it ([87.6.20.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISinE-0001YA-SE for geopriv-archive@lists.ietf.org; Tue, 04 Sep 2007 20:30:54 -0400 Received: from CCMGR ([155.118.93.190]:8626 "EHLO CCMGR" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host206-235-dynamic.7-87-r.retail.telecomitalia.it with ESMTP id S22AEVDWBRECHREG (ORCPT ); Tue, 4 Sep 2007 02:43:49 +0200 Message-ID: <000401c7ee8c$9394c0a0$ceeb0757@CCMGR> From: "jace Foster" To: Subject: reikyabi Date: Tue, 4 Sep 2007 02:43:14 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7EE9D.571D90A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000772-3, 04/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7EE9D.571D90A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://dicnay.com/ Good day Foster The guys get jealous now when they see me in the bathroom carbrey BRAGA ------=_NextPart_000_0003_01C7EE9D.571D90A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://dicnay.com/
Good day Foster
The guys get jealous now when they see me in = the bathroom
carbrey BRAGA
------=_NextPart_000_0003_01C7EE9D.571D90A0-- From khannazplt@JLFarmakis.com Wed Sep 05 05:12:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISqvp-0007iM-7I for geopriv-archive@lists.ietf.org; Wed, 05 Sep 2007 05:12:17 -0400 Received: from host133-28-dynamic.51-82-r.retail.telecomitalia.it ([82.51.28.133] helo=host245-135-dynamic.50-82-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISqvo-0006bm-Jo for geopriv-archive@lists.ietf.org; Wed, 05 Sep 2007 05:12:17 -0400 Received: by 10.66.231.85 with SMTP id kJluNlrvWqzgk; Wed, 5 Sep 2007 11:12:34 +0200 (GMT) Received: by 192.168.15.147 with SMTP id wpcomSTnBVuJXK.9634074374625; Wed, 5 Sep 2007 11:12:32 +0200 (GMT) Message-ID: <000901c7ef9c$e2803c60$f5873252@angelaa7509a42> From: "Iwona khanna" To: Subject: hjaltet Date: Wed, 5 Sep 2007 11:12:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7EFAD.A6090C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C7EFAD.A6090C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://dibres.com/ Hi bro geopriv-archive A girl once told me i was too small.. jeanette Nall ------=_NextPart_000_0003_01C7EFAD.A6090C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://dibres.com/
Hi bro geopriv-archive
A girl once told me i was too = small..
jeanette Nall
------=_NextPart_000_0003_01C7EFAD.A6090C60-- From pillaisrul@apyachts.com.au Thu Sep 06 03:14:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITBZA-0007WN-95 for geopriv-archive@lists.ietf.org; Thu, 06 Sep 2007 03:14:16 -0400 Received: from p2228-ipad02fukuhanazo.fukushima.ocn.ne.jp ([219.160.48.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITBZ9-0000Jq-8u for geopriv-archive@lists.ietf.org; Thu, 06 Sep 2007 03:14:15 -0400 Received: by 10.158.196.190 with SMTP id rEjcnURxDpZde; Thu, 6 Sep 2007 16:13:28 +0900 (GMT) Received: by 192.168.229.208 with SMTP id pPTFiDAlVkIsWs.0798434940027; Thu, 6 Sep 2007 16:13:26 +0900 (GMT) Message-ID: <000a01c7f055$695541f0$e430a0db@HP26144277938> From: "Mong pillai" To: Subject: namepol Date: Thu, 6 Sep 2007 16:13:23 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F0A0.D93CE9F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C7F0A0.D93CE9F0 Content-Type: text/plain; charset="shift_jis" Content-Transfer-Encoding: quoted-printable http://www.souitng.com/ Wazzup geopriv-archive if you are looking for penis enlargement, you are only a click away.. sheng schmeling ------=_NextPart_000_0006_01C7F0A0.D93CE9F0 Content-Type: text/html; charset="shift_jis" Content-Transfer-Encoding: quoted-printable
http://www.souitng.com/
Wazzup geopriv-archive
if you are looking for penis enlargement, you = are only a=20 click away..
sheng schmeling
------=_NextPart_000_0006_01C7F0A0.D93CE9F0-- From Gueco@williewill.com Thu Sep 06 19:32:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITQpW-0001xe-78 for geopriv-archive@lists.ietf.org; Thu, 06 Sep 2007 19:32:10 -0400 Received: from [211.173.158.78] (helo=[211.173.158.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITQpV-0003ee-Bi for geopriv-archive@lists.ietf.org; Thu, 06 Sep 2007 19:32:09 -0400 Received: by 10.161.30.238 with SMTP id pKRJLXYCeDLmI; Fri, 7 Sep 2007 08:31:45 +0900 (GMT) Received: by 192.168.227.68 with SMTP id iIcZozQtTZiWeW.9167757350440; Fri, 7 Sep 2007 08:31:43 +0900 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 7 Sep 2007 08:31:40 +0900 To: geopriv-archive@lists.ietf.org From: "Rashid Gueco" Subject: nakawata Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi bro geopriv-archive Get More Powerful erections - Develop 'rock hard' erections, each and every time no matter your age! kornel Reiman http://solvacom.com/ From Lincoln@trustydog.net Thu Sep 06 22:07:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITTFN-0007nE-Uv for geopriv-archive@lists.ietf.org; Thu, 06 Sep 2007 22:07:01 -0400 Received: from red-corp-201.143.41.222.telnor.net ([201.143.41.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITTFN-0007C6-Ez for geopriv-archive@lists.ietf.org; Thu, 06 Sep 2007 22:07:01 -0400 Received: by 10.98.126.204 with SMTP id ZJWZWxkeYNjgD; Thu, 6 Sep 2007 19:07:04 -0700 (GMT) Received: by 192.168.51.82 with SMTP id VurxnLbweSTXyX.5319170979095; Thu, 6 Sep 2007 19:07:02 -0700 (GMT) Message-ID: <000c01c7f0f3$c6346470$de298fc9@PC> From: "Lincoln Racette" To: Subject: wohbsgus Date: Thu, 6 Sep 2007 19:06:59 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F0B9.19D58C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.4 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0003_01C7F0B9.19D58C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://selenan.com/ Wassup Racette See my penis pictures as proof gyula Florez ------=_NextPart_000_0003_01C7F0B9.19D58C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://selenan.com/
Wassup Racette
See my penis pictures as proof
gyula Florez
------=_NextPart_000_0003_01C7F0B9.19D58C70-- From Degus@www.comunidadesol.org Fri Sep 07 17:39:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlY1-0005MB-AQ for geopriv-archive@lists.ietf.org; Fri, 07 Sep 2007 17:39:29 -0400 Received: from 8stb46.codetel.net.do ([64.32.104.8] helo=44stb45.codetel.net.do) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITlXz-00011z-9G for geopriv-archive@lists.ietf.org; Fri, 07 Sep 2007 17:39:29 -0400 Received: by 10.192.81.127 with SMTP id FwhTrUUymOMIi; Sat, 8 Sep 2007 05:39:28 -0300 (GMT) Received: by 192.168.235.188 with SMTP id uSTrjoDsTwgqur.9671802476224; Sat, 8 Sep 2007 05:39:26 -0300 (GMT) Message-ID: <000e01c7f1f3$c1a34c40$2c692040@josepc> From: "fadyan Degus" To: Subject: pe'anisa Date: Sat, 8 Sep 2007 05:39:23 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F1DA.9C561440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0008_01C7F1DA.9C561440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.hgwired.com/ Good day geopriv-archive We have been successfully helping men like you to enlarge their penises = since 1995 janean Peller ------=_NextPart_000_0008_01C7F1DA.9C561440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.hgwired.com/
Good day geopriv-archive
We have been successfully helping men like you = to=20 enlarge their penises since 1995
janean Peller
------=_NextPart_000_0008_01C7F1DA.9C561440-- From fu.dubay@flavorganics.com Fri Sep 07 23:07:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITqfI-00086x-8m for geopriv-archive@lists.ietf.org; Fri, 07 Sep 2007 23:07:20 -0400 Received: from [124.43.222.32] (helo=[124.43.222.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITqfG-0001HB-Ey for geopriv-archive@lists.ietf.org; Fri, 07 Sep 2007 23:07:20 -0400 Received: by 10.190.133.70 with SMTP id IUZUNXwdfVhnM; Sat, 8 Sep 2007 08:38:10 +0800 (GMT) Received: by 192.168.172.56 with SMTP id LbSJlIuCAsGdHT.7801559173220; Sat, 8 Sep 2007 08:38:08 +0800 (GMT) Message-ID: <000401c7f1b0$85108920$20de2b7c@pradeep> From: "fu dubay" To: Subject: ssargiab Date: Sat, 8 Sep 2007 08:38:05 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F1F3.9333C920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0008_01C7F1F3.9333C920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://hcougars.com/ How it is going dubay We have been successfully helping men like you to enlarge their penises = since 1995 Stela ebrahim ------=_NextPart_000_0008_01C7F1F3.9333C920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://hcougars.com/
How it is going dubay
We have been successfully helping men like you = to=20 enlarge their penises since 1995
Stela ebrahim
------=_NextPart_000_0008_01C7F1F3.9333C920-- From tchbpemdveq@bluesky-usa.com Sat Sep 08 05:00:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITwBH-0007I9-6R; Sat, 08 Sep 2007 05:00:43 -0400 Received: from dpi191.neoplus.adsl.tpnet.pl ([83.24.142.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITwBF-0003bG-Ky; Sat, 08 Sep 2007 05:00:43 -0400 Received: from [83.24.142.191] by mx3.megamailservers.com; Sat, 8 Sep 2007 10:00:53 +0100 Date: Sat, 8 Sep 2007 10:00:53 +0100 From: "Loren Guerrero" X-Mailer: The Bat! (v2.00.7) Educational Reply-To: tchbpemdveq@bluesky-usa.com X-Priority: 3 (Normal) Message-ID: <225767359.62491865340911@bluesky-usa.com> To: 6lowpan-request@lists.ietf.org Subject: Re:INPUT DEVICE MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Have you ever wanted a pricey Watch? We have the soulition for you! We have all the top quality for a very small precentage of the expense. www.oeiwjhhc.com From nary_Scheuer@khushe.org Sat Sep 08 10:10:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU111-0003H8-Sc for geopriv-archive@lists.ietf.org; Sat, 08 Sep 2007 10:10:27 -0400 Received: from 20158102233.user.veloxzone.com.br ([201.58.102.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IU10y-0001aB-Nr for geopriv-archive@lists.ietf.org; Sat, 08 Sep 2007 10:10:25 -0400 Received: from celeron ([129.140.30.0] helo=celeron) by 20158102233.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1VGpjW-000ZQC-pN for geopriv-archive@lists.ietf.org; Sat, 8 Sep 2007 11:10:49 -0300 Message-ID: <000a01c7f222$00b41440$e9663ac9@celeron> From: "nary Scheuer" To: Subject: ivukih{l Date: Sat, 8 Sep 2007 11:10:25 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F208.DB694D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C7F208.DB694D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.hongoi.com/ Hi bro Scheuer Men all over the world are going to love this product... NaiYee Polito ------=_NextPart_000_0006_01C7F208.DB694D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.hongoi.com/
Hi bro Scheuer
Men all over the world are going to love this = product...
NaiYee Polito
------=_NextPart_000_0006_01C7F208.DB694D40-- From KyleeMaliyevsky@PHBGROUP.com Sat Sep 08 11:41:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU2RO-0001ON-R7 for geopriv-archive@lists.ietf.org; Sat, 08 Sep 2007 11:41:46 -0400 Received: from host18-106-dynamic.7-87-r.retail.telecomitalia.it ([87.7.106.18] helo=host27-27-dynamic.10-87-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IU2RK-0007li-LU for geopriv-archive@lists.ietf.org; Sat, 08 Sep 2007 11:41:46 -0400 Received: by 10.57.161.142 with SMTP id FfwQTxJLNBzEh; Sat, 8 Sep 2007 17:41:43 +0200 (GMT) Received: by 192.168.171.68 with SMTP id nHYGgsRXFfohHx.1412605721648; Sat, 8 Sep 2007 17:41:41 +0200 (GMT) Message-ID: <000b01c7f22e$bee00bc0$1b1b0a57@personal6a0d50> From: "Kylee Maliyevsky" To: Subject: ekietuoh Date: Sat, 8 Sep 2007 17:41:38 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F23F.8268DBC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000773-2, 07/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.0 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C7F23F.8268DBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://hrunehq.com/ Hi bro Maliyevsky Men all over the world are going to love this product... Menh LaBree ------=_NextPart_000_0004_01C7F23F.8268DBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://hrunehq.com/
Hi bro Maliyevsky
Men all over the world are going to love this = product...
Menh LaBree
------=_NextPart_000_0004_01C7F23F.8268DBC0-- From Farah.ewing@anrasi.com Sat Sep 08 18:23:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU8hv-0002j8-J1 for geopriv-archive@lists.ietf.org; Sat, 08 Sep 2007 18:23:15 -0400 Received: from adsl-ull-253-36.49-151.net24.it ([151.49.36.253]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IU8hu-0001tM-VC for geopriv-archive@lists.ietf.org; Sat, 08 Sep 2007 18:23:15 -0400 Received: from octobot ([106.161.25.123] helo=octobot) by adsl-ull-253-36.49-151.net24.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1CTpwt-000YOX-Tt for geopriv-archive@lists.ietf.org; Sun, 9 Sep 2007 00:23:45 +0200 Message-ID: <000a01c7f266$db5a4260$fd243197@octobot> From: "Farah ewing" To: Subject: ieslaulu Date: Sun, 9 Sep 2007 00:23:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7F277.9EE31260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C7F277.9EE31260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://hoxxido.com/ How it is going Farah check out this website, limited offers (MEN ONLY) hamit Cheiko ------=_NextPart_000_0004_01C7F277.9EE31260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://hoxxido.com/
How it is going Farah
check out this website, limited offers (MEN = ONLY)
hamit Cheiko
------=_NextPart_000_0004_01C7F277.9EE31260-- From Firman810@marbleheadpta.org Sun Sep 09 10:53:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUOA2-0004Hv-I9 for geopriv-archive@lists.ietf.org; Sun, 09 Sep 2007 10:53:18 -0400 Received: from f051149190.adsl.alicedsl.de ([78.51.149.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUOA1-0004R2-WC for geopriv-archive@lists.ietf.org; Sun, 09 Sep 2007 10:53:18 -0400 Received: from Wohnzimmer ([184.100.111.53]:13509 "EHLO Wohnzimmer" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by f051149190.adsl.alicedsl.de with ESMTP id S22DWIMGJXCQTINA (ORCPT ); Sun, 9 Sep 2007 16:53:27 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 9 Sep 2007 16:53:08 +0200 To: geopriv-archive@lists.ietf.org From: "Firman Steadman" Subject: rednavel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea How it is going geopriv-archive ladies like em big, so i enlarged my cock just to please them.. Rigoberto Sheng http://www.sitesmit.com/ From Bejo@antipixel.org Sun Sep 09 16:23:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUTJe-0003wh-Vs for geopriv-archive@lists.ietf.org; Sun, 09 Sep 2007 16:23:35 -0400 Received: from adsl-ull-250-228.49-151.net24.it ([151.49.228.250] helo=adsl-ull-113-229.49-151.net24.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUTJe-0004Dv-9P for geopriv-archive@lists.ietf.org; Sun, 09 Sep 2007 16:23:34 -0400 Received: from nome-1m3b12i2gp ([105.170.191.199]:22797 "EHLO nome-1m3b12i2gp" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by adsl-ull-113-229.49-151.net24.it with ESMTP id S22FZOYKVZIBYNTI (ORCPT ); Sun, 9 Sep 2007 22:23:45 +0200 Message-ID: <2289D6F4.9FA962FE@antipixel.org> Date: Sun, 9 Sep 2007 22:23:20 +0200 From: "Bejo digness" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: geopriv-archive@lists.ietf.org Subject: suohtser Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.8 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi bro digness I started to notice that my penis had grown at least an inch thi dow http://smitana.com/ From LaBree@mailserver.studylight.org Mon Sep 10 01:36:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUbwW-0002UO-04 for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 01:36:16 -0400 Received: from 20132227252.user.veloxzone.com.br ([201.32.227.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUbwU-0000tX-2q for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 01:36:15 -0400 Received: from gleice ([108.174.91.75] helo=gleice) by 20132227252.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1QWWKh-000VCH-ux for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 02:36:14 -0300 Message-ID: <000601c7f36c$7814e000$fce320c9@gleice> From: "Rohit LaBree" To: Subject: polonsky Date: Mon, 10 Sep 2007 02:36:00 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F353.52C7A800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.6 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C7F353.52C7A800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.spaibncn.com/ Hi bro LaBree we=92re both so happy with his bigger penis. Nabih Flannery ------=_NextPart_000_0003_01C7F353.52C7A800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.spaibncn.com/
Hi bro LaBree
we=92re both so happy with his bigger = penis.
Nabih Flannery
------=_NextPart_000_0003_01C7F353.52C7A800-- From geopriv-bounces@ietf.org Mon Sep 10 03:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdam-0005ox-Ch; Mon, 10 Sep 2007 03:21:56 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUdal-0005op-KO for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 03:21:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdal-0005og-9Y for geopriv@ietf.org; Mon, 10 Sep 2007 03:21:55 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUdak-0003vY-T7 for geopriv@ietf.org; Mon, 10 Sep 2007 03:21:55 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_02_31_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 02:31:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 02:21:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Sep 2007 02:21:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7Lpmbg== From: "Thomson, Martin" To: X-OriginalArrivalTime: 10 Sep 2007 07:21:52.0365 (UTC) FILETIME=[4262D9D0:01C7F37B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Geopriv] responseTime reprise X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0894325261==" Errors-To: geopriv-bounces@ietf.org --===============0894325261== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIHByb2JhYmx5IGR1ZSB0byBzdGVwIGludG8gdGhlIHJpbmcgb24gdGhpcyB0b3BpYy4gIEkg YXBvbG9naXNlIGZvciBhbnl0aGluZyB0aGF0IGlzIHJlaGFzaGVkLCBJIGhhdmUgbm90IHJlYWQg dGhlIF9lbnRpcmVfIGFyY2hpdmUgb24gdGhpcyB0b3BpYy4NCg0KVGhlIG1haW4gcmVhc29uIHRo ZSByZXNwb25zZVRpbWUgcGFyYW1ldGVyIHdhcyBwcm9wb3NlZCB3YXMgb3VyIGNvbGxlY3RpdmUg ZXhwZXJpZW5jZSB3aXRoIGNlbGx1bGFyIHN5c3RlbXMuDQoNCjNHUFAgaGF2ZSBkZWZpbmVkIHR3 byB2YWx1ZXM6ICJsb3cgZGVsYXkiIGFuZCAiZGVsYXkgdG9sZXJhbnQiLCB3aGljaCByb3VnaGx5 IGNvcnJlc3BvbmQgdG8gd2hhdCBzb21lIGhhdmUgYmVlbiBhZHZvY2F0aW5nLiAgSG93ZXZlciwg d2hlcmUgbXVsdGlwbGUgbmV0d29yayBub2RlcyBhcmUgaW52b2x2ZWQgaW4gc2VydmluZyBhIHJl cXVlc3QgKGFuZCAzR1BQIHJlbGllcyBvbiBhYm91dCA2KSwgZW5naW5lZXJpbmcgaXMgcmVxdWly ZWQgdG8gZW5zdXJlIHNtb290aCBvcGVyYXRpb24uICBFYWNoIG5vZGUgaXMgY29uZmlndXJlZCB3 aXRoIGEgZGlmZmVyZW50IHRpbWVvdXQgc28gdGhhdCB0aGUgdGltZSB0aGF0IHRoZSBub2RlIGFk ZHMgdG8gdGhlIHRyYW5zYWN0aW9uIGRvZXNuJ3QgY2F1c2UgZmFpbHVyZXMuICBUaGlzIGVuZ2lu ZWVyaW5nIGVuc3VyZXMgdGhhdCBlYWNoIGxvY2F0aW9uIGNsaWVudCByZWNlaXZlcyBhIGNlcnRh aW4gbGV2ZWwgb2Ygc2VydmljZS4NCg0KT2YgY291cnNlLCBlYWNoIG5ldHdvcmsgaXMgZW5naW5l ZXJlZCBkaWZmZXJlbnRseS4gIEV2ZXJ5b25lIGhhcyBhIGRpZmZlcmVudCBpZGVhIG9mIHdoYXQg ImxvdyBkZWxheSIgYW5kICJkZWxheSB0b2xlcmFudCIgbWVhbi4gIEluIGEgY2xvc2VkIG5ldHdv cmsgdGhpcyBtb3JlIG9yIGxlc3Mgd29ya3M7IGFsdGhvdWdoIHRoaXMgaXNuJ3QgYXNzdXJlZCBm b3Igcm9hbWVycy4gIFdlIHdhbnRlZCB0byBhdm9pZCB0aGlzIHByb2JsZW0uICBJdCBtYWtlcyBz ZW5zZSB0byBhbGxvdyBkZXZvbHZlIHRoZSBwYXJhbWV0ZXI7IHJhdGhlciB0aGFuIHBsYWNlIGFu IGFyYml0cmFyeSB2YWx1ZSBvbiBzb21lIGFic3RyYWN0IGNvZGVzLCBhbGxvdyB0aGUgY2xpZW50 IHRvIGRlY2lkZS4NCg0KVG8gYWRkIHRvIHRoaXMsIGR1cmluZyBteSBicmVhaywgd2UgaGFkIGEg cmVxdWVzdCBmb3IgZnVydGhlciBjb250cm9sIG92ZXIgdGhlc2UgdmFsdWVzIG9uIG9uZSBvZiBv dXIgY2VsbHVsYXIgcHJvZHVjdHMuICBJbiB0aGlzIHJlcXVlc3QsIGRpZmZlcmVudCB0eXBlcyBv ZiBjbGllbnRzIHdvdWxkIGJlIGdpdmVuIHZhcnlpbmcgYW1vdW50cyBvZiB0aW1lLiAgVGh1cywg ZnJvbSBvdXIgcGVyc3BlY3RpdmUsIHdlIGhhdmUgYSBjbGVhciByZXF1aXJlbWVudCBmb3IgcmVz cG9uc2VUaW1lLg0KDQpUbyB0aG9zZSB3aG8gd2FudCBoYXJkIGxpbWl0czsgQkNQIGRvY3VtZW50 cyBhcmUgYSBnb29kIHBsYWNlIGZvciByZWNvbW1lbmRhdGlvbnMuICBZb3UgY2FuIGFkZCBuaWNl IHN0YXRlbWVudHMgbGlrZTogImlmIHJvdXRpbmcgZm9yIGVtZXJnZW5jeSBjYWxscywgc2V0IHJl c3BvbnNlVGltZSB0byB4IHNlY29uZHM7IGlmIHlvdSBkb24ndCBjYXJlLCBhbGxvdyB5IHNlY29u ZHMiLg0KDQpUYSwNCk1hcnRpbiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBh bmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJp dmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2lu YWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============0894325261== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0894325261==-- From geopriv-bounces@ietf.org Mon Sep 10 03:34:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdl6-00012i-SP; Mon, 10 Sep 2007 03:32:36 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUdl5-0000wq-Ez for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 03:32:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdl5-0000vd-3O for geopriv@ietf.org; Mon, 10 Sep 2007 03:32:35 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUdl4-00049F-E6 for geopriv@ietf.org; Mon, 10 Sep 2007 03:32:35 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_02_41_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 02:41:53 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 02:32:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] ResponseTime Date: Mon, 10 Sep 2007 02:32:30 -0500 Message-ID: In-Reply-To: <93C30F5E-361B-45EC-99CA-1ED5BCF90760@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] ResponseTime Thread-Index: AcfrD6RcFMbEXNd9RPKfrZKtkHpFWAIa8E9A References: <002c01c7e99b$aaa60c40$640fa8c0@cis.neustar.com><007201c7e9a6$46413530$640fa8c0@cis.neustar.com><00d801c7e9ab$f8f8c1c0$640fa8c0@cis.neustar.com><8C837214C95C864C9F34F3635C2A65750820FB43@SEA-EXCHVS-2.telecomsys.com><00f201c7e9ae$38ade410$640fa8c0@cis.neustar.com><018b01c7e9b5$70011520$640fa8c0@cis.neustar.com><01f001c7e9c4$54c61d00$640fa8c0@cis.neustar.com> <93C30F5E-361B-45EC-99CA-1ED5BCF90760@cs.columbia.edu> From: "Thomson, Martin" To: "Henning Schulzrinne" , "Stuard, Doug" X-OriginalArrivalTime: 10 Sep 2007 07:32:32.0239 (UTC) FILETIME=[BFC7DFF0:01C7F37C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122094385==" Errors-To: geopriv-bounces@ietf.org --===============2122094385== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlICJhY2N1cmFjeSIgZm9yIGEgdGVjaG5vbG9neSBpcyBvbmx5IGludGVyZXN0aW5nIHRvIHBl b3BsZSBsaWtlIHRoZSBGQ0MsIHB1cmNoYXNlcnMgb2YgbmV3IHRlY2hub2xvZ3kgYW5kIFImRCBm b2xrcy4gIE1vc3QtdGltZXMgd2UgYXJlIGludGVyZXN0ZWQgaW4gdGhlICJhY2N1cmFjeSIgb2Yg YW55IG9uZSBwb3NpdGlvbmluZyByZXN1bHQuDQoNCldoZW4gd2UgY2FsY3VsYXRlIGEgcG9zaXRp b24gYmFzZWQgb24gR1BTIG1lYXN1cmVtZW50cywgd2UgdGFrZSBhIG51bWJlciBvZiBmYWN0b3Jz IGFuZCBkZXRlcm1pbmUgYW4gdW5jZXJ0YWludHkgZm9yIHRoYXQgcG9pbnQuICBUaGlzIGlzIGRl dGVybWluZWQgYmFzZWQgb24gdGhlIHF1YWxpdHkgb2YgdGhlIG1lYXN1cmVtZW50cyAod2hpY2gg aXMgYWxzbyBtZWFzdXJlZCkgYW5kIGEgbnVtYmVyIG9mIG90aGVyIGZhY3RvcnMuICBCYXNlZCBv biBvdXIgdGVzdGluZywgYW5kIHRoZSBtYXRoZW1hdGljYWwgbW9kZWxzIHdlIGVtcGxveSwgd2Ug Y2FuIGJlIHJlYXNvbmFibHkgc3VyZSB0aGF0IHRoZSBhY3R1YWwgcG9pbnQgaXMgd2l0aGluIHRo ZSBhcmVhIG9mIHVuY2VydGFpbnR5IGF0IHRoZSBnaXZlbiBwZXJjZW50YWdlIG9mIGNvbmZpZGVu Y2UuICBUaGF0IGlzLCBpZiB3ZSBzYXkgd2l0aGluIHRoaXMgYXJlYSA5MCUgb2YgdGhlIHRpbWUs IDkwJSBvZiB0aGUgdGltZSB0aGF0IHdpbGwgYmUgcmlnaHQuDQoNCkZvciB0aGlzLCB5b3UgbmVl ZCBzdGF0aXN0aWNzIGFuZCBtYXRoZW1hdGljYWwgbW9kZWxzIHRoYXQgYXBwcm94aW1hdGUgeW91 ciByZXN1bHRzLiAgV2hldGhlciB0aGUgZXJyb3IgaXMgaW4gdGltaW5nLCBlbnZpcm9ubWVudCBv ciBhIGRhdGEgZW50cnkgc3R1ZmYtdXAsIGVycm9ycyBjYW4gYmUgYWNjb3VudGVkIGZvciBhbmQg dGhlc2UgYXJlIHJlZmxlY3RlZCBpbiB0aGUgZmluYWwgY29uZmlkZW5jZSB2YWx1ZS4NCg0KQW5k IHdoZW4geW91IHNheSB0aGUgcG9pbnQgaXMgIiphbHdheXMqIG91dHNpZGUgdGhlIGNpcmNsZSIs IHRoZXJlIGlzIG9ubHkgb25lIHBvaW50LCBidXQgaXQgaXMgb25seSBvdXRzaWRlIG9mIHRoZSA5 MCUgY2lyY2xlIDEwJSBvZiB0aGUgdGltZS4gIEhvdyBkbyB3ZSBrbm93PyAgU3RhdGlzdGljcy4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZW5uaW5nIFNjaHVsenJp bm5lIFttYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdV0NCj4gU2VudDogRnJpZGF5LCAzMSBBdWd1 c3QgMjAwNyAxMjoxMSBBTQ0KPiBUbzogU3R1YXJkLCBEb3VnDQo+IENjOiBHRU9QUklWIFdHDQo+ IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gUmVzcG9uc2VUaW1lDQo+IA0KPiBUaGUgcG9pbnQgaGFz IGJlZW4gbWFkZSBiZWZvcmUsIGJ1dCBpdCBwcm9iYWJseSBiZWFycyByZXBlYXRpbmcuDQo+IFRo ZXJlIGFyZSBhdCBsZWFzdCB0d28ga2luZHMgb2YgdW5jZXJ0YWludHkvYWNjdXJhY3kgc3BlY2lm aWNhdGlvbnMsDQo+IG5hbWVseSBmb3IgYSBwYXJ0aWN1bGFyIHRlY2hub2xvZ3kgYW5kIGZvciBh IHBhcnRpY3VsYXIgcG9pbnQuDQo+IA0KPiBUYWtlIGEgdGVjaG5vbG9neSB0aGF0IHByb2R1Y2Vz IGEgMTAwIG0gYWNjdXJhY3kgd2l0aCA5MCUgY29uZmlkZW5jZS4NCj4gVGFrZW4gbmFpdmVseSwg dGhpcyBpbXBsaWVzIHRoYXQgZXZlcnkgcG9pbnQgaXMgc29tZXdoZXJlIGluIGEgY2lyY2xlDQo+ IHdpdGggZGlhbWV0ZXIgMTAwIG0uDQo+IA0KPiBVbmZvcnR1bmF0ZWx5LCB0aGlzIGVycm9yIGlz IG5vdCB0aGUgc2FtZSBldmVyeXdoZXJlLiBTb21lIGxvY2F0aW9ucw0KPiB3aWxsIHByZXN1bWFi bHkgc2VlIGEgbXVjaCBsYXJnZXIgZXJyb3IsIHBvc3NpYmx5IHdpdGggbm9uLXplcm8gbWVhbg0K PiBlcnJvci4gRm9yIGV4YW1wbGUsIGlmIGEgdGltaW5nIGVycm9yIGlzIGFic29sdXRlICgrLy0g MSBucyksIGl0DQo+IGFmZmVjdHMgc2hvcnQgZGlzdGFuY2VzIG11Y2ggbW9yZSB0aGFuIGxvbmdl ciBvbmVzLiBPciBtdWx0aXBhdGgNCj4gbWFrZXMgYSBwYXJ0aWN1bGFyIGxvY2F0aW9uIGFsd2F5 cyBzZWVtIGZ1cnRoZXIgYXdheSB0aGFuIGl0IHJlYWxseSBpcy4NCj4gDQo+IFRodXMsIHlvdSBj b3VsZCBlYXNpbHkgZ2V0IGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBsb2NhdGlvbiBmb3IgYQ0KPiBw YXJ0aWN1bGFyIHBsYWNlIGlzICphbHdheXMqIG91dHNpZGUgdGhhdCBjaXJjbGUsIGV2ZW4gdGhv dWdoIHRoZQ0KPiB0ZWNobm9sb2d5LCBvbiBhdmVyYWdlLCBwZXJmb3JtcyBhcyBhZHZlcnRpc2Vk LiBJIGRvbid0IGtub3cgaWYNCj4gYW55Ym9keSBoYXMgc3R1ZGllZCB0aGlzIHByb2JsZW0gaW4g ZGV0YWlsIHRvIHNlZSBob3cgbXVjaCB0aGlzDQo+IG1hdHRlcnMgaW4gcHJhY3RpY2UuDQo+IA0K PiBodHRwOi8vd3d3LmNvbXNvYy5vcmcvcGNpL3ByaXZhdGUvMjAwMC9vY3QvYnVsdXN1Lmh0bWwg c2hvd3MgYW4NCj4gZXhhbXBsZSBvZiB0aGlzLiAoIlRoZSBsb2NhbGl6YXRpb24gZXJyb3IgaXMg bG93ZXN0IGF0IHRoZSBwb3NpdGlvbg0KPiBjb3JyZXNwb25kaW5nIHRvIHRoZSBjZW50cm9pZCBv ZiB0aGUgcmVnaW9uIGFuZCBpbmNyZWFzZXMgdG93YXJkIHRoZQ0KPiBlZGdlcyBvZiB0aGUgcmVn aW9uLiIpDQo+IA0KPiBodHRwOi8vd3d3LmdtYXQudW5zdy5lZHUuYXUvc25hcC9wdWJsaWNhdGlv bnMvbGliX2V0YWwyMDA1ZC5wZGYNCj4gaHR0cDovL3d3dy5pZWVlLWluZm9jb20ub3JnLzIwMDQv UGFwZXJzLzU1XzUuUERGDQo+IGFsc28gc2hvdyBiZWhhdmlvciBsaWtlIHRoYXQuDQo+IA0KPiBC dHcsIGh0dHA6Ly93d3cubG9jYXRlbW9kZWxjaXRpZXMub3JnL2RvY3VtZW50cy8NCj4gTE9DQVRF X0ZpbmFsX1JlcG9ydC5wZGYgaXMgb2Ygc29tZSByZWxldmFuY2UgaGVyZS4gSW4gcGFydGljdWxh ciwgaXQNCj4gY29udGFpbnMgZGVmaW5pdGlvbnMgZm9yIHRlcm1zLg0KPiANCj4gSGVubmluZw0K PiANCj4gT24gQXVnIDI5LCAyMDA3LCBhdCA5OjU3IEFNLCBTdHVhcmQsIERvdWcgd3JvdGU6DQo+ IA0KPiA+IEluIHByYWN0aWNlLCDigJx1bmNlcnRhaW50eeKAnSBpcyB1c3VhbGx5IHRha2VuIHRv IG1lYW4g4oCcYWNjdXJhY3nigJ0sDQo+ID4gYWx0aG91Z2gsIGFzIHBvaW50ZWQgb3V0LCBhY2N1 cmFjeSBpcyByZWFsbHkgYSBjb21iaW5hdGlvbiBvZg0KPiA+IHVuY2VydGFpbnR5IGFuZCBjb25m aWRlbmNlLiAgR2l2ZW4gdGhhdCBtb3N0IGZvbGtzIChhbmQgSeKAmW0gdGFsa2luZw0KPiA+IGFi b3V0IGNhbGwgdGFrZXJzLCBub3Qgc3lzdGVtIGFkbWluaXN0cmF0b3JzKSB0aGluayDigJxhY2N1 cmFjeeKAnSBhbmQNCj4gPiBub3QgdGhlIHVuY2VydGFpbnR5L2NvbmZpZGVuY2UgY29udGludXVt LCBjb25maWRlbmNlIGlzIHdvcnNlIHRoYW4NCj4gPiBvZiBubyB1c2UsIGl0IGlzIGNvbmZ1c2lu ZywgIHNvIGl0IGlzIGVpdGhlciBub3QgcHJvdmlkZWQgb3IgaXMNCj4gPiBzdXBwcmVzc2VkLiAg TmV2ZXJ0aGVsZXNzLCB0aGUgcmVwb3J0ZWQg4oCcYWNjdXJhY3nigJ0gKHVuY2VydGFpbnR5KQ0K PiA+IHNob3VsZCBiZSBiYXNlZCBvbiBhbiB1bmRlcmx5aW5nIGNvbW1vbiBjb25maWRlbmNlIHZh bHVlIChldmVuIGlmDQo+ID4gaXQgaXMgbm90IGRpc3BsYXllZCBvciBvdGhlcndpc2UgdXNlZCku DQo+ID4NCj4gPg0KPiA+DQo+ID4gV2hpbGUgaXQgbWF5IGJlIHRydWUgdGhhdCBhY2N1cmFjeS91 bmNlcnRhaW50eSBpcyBub3QgdXNlZCBUT0RBWSBieQ0KPiA+IGluZGl2aWR1YWwgc2VydmljZSBw cm92aWRlcnMsIGRvIHdlIHdhbnQgdG8gZW5zdXJlIHRoYXQgaXQgY2FuDQo+ID4gTkVWRVIgYmUg dXNlZD8/PyAgQXMgZmFtaWxpYXJpdHkgd2l0aCBnZW9sb2NhdGlvbiBjb25jZXB0cyBncm93cywN Cj4gPiBhbmQgYXMgbW9yZSBhdXRvbWF0ZWQgc3lzdGVtcyBhcmUgZGVwbG95ZWQgKGkuZS4sIHRo b3NlIHRoYXQNCj4gPiB1bmRlcnN0YW5kIHRoZSBjb25maWRlbmNlL3VuY2VydGFpbnR5IHRyYWRl b2ZmIGFuZCBwbG90IGJpZyAob3INCj4gPiBsaXR0bGUpIGNpcmNsZXMgb24gbWFwcyksIGdyZWF0 ZXIgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjYW4gYmUNCj4gPiBleHBlY3RlZC4NCj4gPg0KPiA+ DQo+ID4NCj4gPiBPciBtYXliZSBub3QuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIHBvaW50IEni gJltIHRyeWluZyB0byBtYWtlIChhbmQgdG8gZ2V0IGJhY2sgdG8gdGhlIG9yaWdpbmFsDQo+ID4g c3ViamVjdCkgaXMgdGhhdCBieSBwcm92aWRpbmcgb3B0aW9uYWwgdGltZSBhbmQg4oCcYWNjdXJh Y3nigJ0gdmFsdWVzDQo+ID4gKGFjdHVhbGx5LCB1bmNlcnRhaW50eSBhdCBzb21lIGEgY29tbW9u bHkgYWdyZWVkIHRvIGNvbmZpZGVuY2UNCj4gPiBsZXZlbCksIHdpdGggZGVmaW5lZCBtZWFuaW5n cyBzaW1pbGFyIHRvIHRob3NlIEkgc3VnZ2VzdGVkIGVhcmxpZXIsDQo+ID4gdGhlIGZsZXhpYmls aXR5IHRvIGFkYXB0IHRvIGEgd2lkZSByYW5nZSBvZiBhcHBsaWNhdGlvbnMgKGVtZXJnZW5jeQ0K PiA+IGFuZCBvdGhlcndpc2UpIGFuZCB0ZWNobm9sb2dpY2FsIGFkdmFuY2VzIGNhbiBiZSBhY2Nv bW1vZGF0ZWQgZ29pbmcNCj4gPiBmb3J3YXJkLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEFsbCB3ZSBu ZWVkIGlzIGFuIGFncmVlbWVudCBhcyB0byB3aGF0IHRoZSBjb25maWRlbmNlIGxldmVsIHNob3Vs ZA0KPiA+IGJlIChvaCwgYW5kIHdvcmxkIHBlYWNlLCB0b28pLg0KPiA+DQo+ID4NCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBHZW9w cml2IG1haWxpbmcgbGlzdA0KPiBHZW9wcml2QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lw aWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90 aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRl IHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHBy b2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd DQo= --===============2122094385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============2122094385==-- From kellieArra@arpalink.com Mon Sep 10 07:54:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUhq8-0002RQ-Cr for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 07:54:04 -0400 Received: from [151.72.90.3] (helo=[151.72.90.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUhq7-0002so-0I for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 07:54:04 -0400 Received: from acer-eec2e0702c by arpalink.com with ASMTP id 0361BAA3 for ; Tue, 11 Sep 2007 13:56:15 +0200 Received: from acer-eec2e0702c ([114.191.171.88]) by arpalink.com with ESMTP id EDFC080C1F88 for ; Tue, 11 Sep 2007 13:56:15 +0200 Message-ID: <000801c7f46a$b0535330$035a4897@acereec2e0702c> From: "kellie Arra" To: Subject: gaest Date: Tue, 11 Sep 2007 13:55:46 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F47B.73DC2330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000774-0, 10/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.2 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0003_01C7F47B.73DC2330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://smonter.com/ Good day Arra If you feel insecure about your penis size then it affects how you act = and behave Tawatchai Kaisch ------=_NextPart_000_0003_01C7F47B.73DC2330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://smonter.com/
Good day Arra
If you feel insecure about your penis size = then it=20 affects how you act and behave
Tawatchai Kaisch
------=_NextPart_000_0003_01C7F47B.73DC2330-- From Lukenbttf@advantage-promotions.com Mon Sep 10 08:48:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUih1-0005g6-Tt for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 08:48:43 -0400 Received: from host118-6-dynamic.60-82-r.retail.telecomitalia.it ([82.60.6.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUigy-0003zA-AM for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 08:48:43 -0400 Received: from paolo-rrh09f9p9 ([186.118.119.118]:26137 "EHLO paolo-rrh09f9p9" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host118-6-dynamic.60-82-r.retail.telecomitalia.it with ESMTP id S22STWAYKAYMOPPE (ORCPT ); Mon, 10 Sep 2007 14:48:59 +0200 Message-ID: Date: Mon, 10 Sep 2007 14:48:43 +0200 From: "Edgars Luken" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: geopriv-archive@lists.ietf.org Subject: eetacoll Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-0, 10/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good day Luken Penis size is one of the main concerns of modern men, with many feeling that they don't measure up. Fox Goss http://slimsbbq.com/ From geopriv-bounces@ietf.org Mon Sep 10 09:27:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjGg-0005Sk-4S; Mon, 10 Sep 2007 09:25:34 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUjGc-0005Et-Bc for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 09:25:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjGa-0005By-RP for geopriv@ietf.org; Mon, 10 Sep 2007 09:25:29 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUjGa-0005rN-9A for geopriv@ietf.org; Mon, 10 Sep 2007 09:25:28 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUjGQ-0000no-6d; Mon, 10 Sep 2007 08:25:18 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , References: Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 09:25:22 -0400 Message-ID: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uw In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I was working in updates to phonebcp and framework and here is the spec I want to have: ED-25/AN-14 It is RECOMMENDED that location determination not take longer than 250 ms to obtain routing location and systems SHOULD be designed such that the typical response is under 100ms. However, as much as 3 seconds to obtain routing location MAY be tolerated if location accuracy can be substantially improved over what can be obtained in 250 ms. How would you express that with your parameter? The equivalent for dispatch location is: Generally, the PSAP can wait for an accurate location for dispatch. However, there is no fixed time known in advance which is the limit; it depends on the nature of the emergency. At some point the PSAP must dispatch. In a subscription environment, the PSAP could update the parameters in the filter (immediate response required). In a HELD dereference, there is no way to cancel and the PSAP will have to choose a ResponseTime that it will wait for even if it wants to dispatch sooner than that. We then get to a complication. It may be the case in some jurisdictions that there are regulations that govern this. In those cases, we may need a way to say "I need the regulation-imposed values for emergency call route", or the equivalent for dispatch. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Monday, September 10, 2007 3:22 AM > To: geopriv@ietf.org > Subject: [Geopriv] responseTime reprise > > I'm probably due to step into the ring on this topic. I apologise for > anything that is rehashed, I have not read the _entire_ archive on this > topic. > > The main reason the responseTime parameter was proposed was our collective > experience with cellular systems. > > 3GPP have defined two values: "low delay" and "delay tolerant", which > roughly correspond to what some have been advocating. However, where > multiple network nodes are involved in serving a request (and 3GPP relies > on about 6), engineering is required to ensure smooth operation. Each > node is configured with a different timeout so that the time that the node > adds to the transaction doesn't cause failures. This engineering ensures > that each location client receives a certain level of service. > > Of course, each network is engineered differently. Everyone has a > different idea of what "low delay" and "delay tolerant" mean. In a closed > network this more or less works; although this isn't assured for roamers. > We wanted to avoid this problem. It makes sense to allow devolve the > parameter; rather than place an arbitrary value on some abstract codes, > allow the client to decide. > > To add to this, during my break, we had a request for further control over > these values on one of our cellular products. In this request, different > types of clients would be given varying amounts of time. Thus, from our > perspective, we have a clear requirement for responseTime. > > To those who want hard limits; BCP documents are a good place for > recommendations. You can add nice statements like: "if routing for > emergency calls, set responseTime to x seconds; if you don't care, allow y > seconds". > > Ta, > Martin > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 10:27:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkDH-0007pw-US; Mon, 10 Sep 2007 10:26:07 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUkDH-0007pO-Ji for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 10:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkDH-0007pC-9r for geopriv@ietf.org; Mon, 10 Sep 2007 10:26:07 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkDF-000782-RW for geopriv@ietf.org; Mon, 10 Sep 2007 10:26:07 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_09_35_26 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 09:35:26 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 09:26:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 09:26:09 -0500 Message-ID: In-Reply-To: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqA= References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Thomson, Martin" , X-OriginalArrivalTime: 10 Sep 2007 14:26:05.0294 (UTC) FILETIME=[858398E0:01C7F3B6] X-Spam-Score: 1.8 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org You put three seconds in as the response time. If a more accurate=0D=0Aloca= tion can be provided in 3 seconds, it will take that long, if not it=0D=0Aw= ill respond even faster.=0D=0A=0D=0AWhat's more, if the next application ru= nning on the device can actually=0D=0Await 20 seconds, it can state "20 sec= onds" and may actually subsequently=0D=0Aget a more accurate location which= may take anywhere from 3 to 20=0D=0Aseconds to return.=0D=0A=0D=0ASimple.=0D= =0A=0D=0AIf you really think that there is a need for a "please give me loc= ation=0D=0Ain the time mandated by the jurisdiction in which I am currently=0D= =0Aoperating" semantic then please send text. Nobody has suggested that is=0D= =0Awhat response time satisfies - and you have not proposed anything that=0D= =0Asatisfies it either. Such a mechanism is not mutually exclusive to an=0D= =0Aoptional response time parameter.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.= net]=20=0D=0ASent: Monday, 10 September 2007 11:25 PM=0D=0ATo: Thomson, Mar= tin; geopriv@ietf.org=0D=0ASubject: RE: [Geopriv] responseTime reprise=0D=0A=0D= =0AI was working in updates to phonebcp and framework and here is the spec=0D= =0AI=0D=0Awant to have:=0D=0A=0D=0AED-25/AN-14 It is RECOMMENDED that locat= ion determination not take=0D=0Alonger=0D=0Athan 250 ms to obtain routing l= ocation and systems SHOULD be designed=0D=0Asuch=0D=0Athat the typical resp= onse is under 100ms. However, as much as 3 seconds=0D=0Ato=0D=0Aobtain rout= ing location MAY be tolerated if location accuracy can be=0D=0Asubstantiall= y improved over what can be obtained in 250 ms.=0D=0A=0D=0AHow would you ex= press that with your parameter=3F=0D=0A=0D=0AThe equivalent for dispatch lo= cation is:=0D=0AGenerally, the PSAP can wait for an accurate location for d= ispatch.=0D=0AHowever, there is no fixed time known in advance which is the= limit; it=0D=0Adepends on the nature of the emergency. At some point the = PSAP must=0D=0Adispatch. In a subscription environment, the PSAP could upd= ate the=0D=0Aparameters in the filter (immediate response required). In a = HELD=0D=0Adereference, there is no way to cancel and the PSAP will have to = choose=0D=0Aa=0D=0AResponseTime that it will wait for even if it wants to d= ispatch sooner=0D=0Athan=0D=0Athat. =0D=0A=0D=0AWe then get to a complication. It may be the case = in some jurisdictions=0D=0Athat there are regulations that govern this. In= those cases, we may=0D=0Aneed a=0D=0Away to say "I need the regulation-imp= osed values for emergency call=0D=0Aroute",=0D=0Aor the equivalent for disp= atch.=0D=0A=0D=0ABrian=0D=0A=0D=0A> -----Original Message-----=0D=0A> From:= Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A> Sent: Monday, Se= ptember 10, 2007 3:22 AM=0D=0A> To: geopriv@ietf.org=0D=0A> Subject: [Geopr= iv] responseTime reprise=0D=0A>=20=0D=0A> I'm probably due to step into the= ring on this topic. I apologise for=0D=0A> anything that is rehashed, I h= ave not read the _entire_ archive on=0D=0Athis=0D=0A> topic.=0D=0A>=20=0D=0A= > The main reason the responseTime parameter was proposed was our=0D=0Acoll= ective=0D=0A> experience with cellular systems.=0D=0A>=20=0D=0A> 3GPP have = defined two values: "low delay" and "delay tolerant", which=0D=0A> roughly = correspond to what some have been advocating. However, where=0D=0A> multip= le network nodes are involved in serving a request (and 3GPP=0D=0Arelies=0D= =0A> on about 6), engineering is required to ensure smooth operation. Each=0D= =0A> node is configured with a different timeout so that the time that the=0D= =0Anode=0D=0A> adds to the transaction doesn't cause failures. This engine= ering=0D=0Aensures=0D=0A> that each location client receives a certain leve= l of service.=0D=0A>=20=0D=0A> Of course, each network is engineered differ= ently. Everyone has a=0D=0A> different idea of what "low delay" and "delay= tolerant" mean. In a=0D=0Aclosed=0D=0A> network this more or less works; = although this isn't assured for=0D=0Aroamers.=0D=0A> We wanted to avoid thi= s problem. It makes sense to allow devolve the=0D=0A> parameter; rather th= an place an arbitrary value on some abstract=0D=0Acodes,=0D=0A> allow the c= lient to decide.=0D=0A>=20=0D=0A> To add to this, during my break, we had a= request for further control=0D=0Aover=0D=0A> these values on one of our ce= llular products. In this request,=0D=0Adifferent=0D=0A> types of clients w= ould be given varying amounts of time. Thus, from=0D=0Aour=0D=0A> perspect= ive, we have a clear requirement for responseTime.=0D=0A>=20=0D=0A> To thos= e who want hard limits; BCP documents are a good place for=0D=0A> recommend= ations. You can add nice statements like: "if routing for=0D=0A> emergency= calls, set responseTime to x seconds; if you don't care,=0D=0Aallow y=0D=0A= > seconds".=0D=0A>=20=0D=0A> Ta,=0D=0A> Martin=0D=0A>=0D=0A----------------= --------------------------------------------------------=0D=0A--=0D=0A> ---= -------------------=0D=0A> This message is for the designated recipient onl= y and may=0D=0A> contain privileged, proprietary, or otherwise private info= rmation.=0D=0A> If you have received it in error, please notify the sender=0D= =0A> immediately and delete the original. Any unauthorized use of=0D=0A> t= his email is prohibited.=0D=0A>=0D=0A--------------------------------------= ----------------------------------=0D=0A--=0D=0A> ----------------------=0D= =0A> [mf2]=0D=0A=0D=0A=0D=0A=0D=0A_________________________________________= ______=0D=0AGeopriv mailing list=0D=0AGeopriv@ietf.org=0D=0Ahttps://www1.ie= tf.org/mailman/listinfo/geopriv=0D=0A=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0AThis = message is for the designated recipient only and may=0D=0Acontain privilege= d, proprietary, or otherwise private information. =20=0D=0AIf you have rece= ived it in error, please notify the sender=0D=0Aimmediately and delete the = original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----= ---------------------------------------------------------------------------= -----------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From anupa66shirley@SAFemail.net Mon Sep 10 10:51:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkc7-0001bR-Uu for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 10:51:47 -0400 Received: from abqo244.neoplus.adsl.tpnet.pl ([83.8.82.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUkc3-0000hk-0x for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 10:51:47 -0400 Received: from [83.8.82.244] by gmphjk.SAFemail.net; Mon, 10 Sep 2007 14:51:42 +0000 Message-ID: <000501c7f3ba$01681ecd$f6d86aae@hjkle> From: "Elbert Gaines" To: "Polly Bowers" Subject: Thanks, we are accepting your company loan request Date: Mon, 10 Sep 2007 13:04:20 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C7F3BA.0167BA2F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C7F3BA.0167BA2F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you have your own business and require IMMEDIATE ready money to spend = ANY way you like or want Extra money to give your company a boost or = wish A low interest loan - NO STRINGS ATTACHED, here is the deal we can = offer you NOW (hurry, this deal will expire TONIGHT):   $61,000+ loan   Hurry, when best deal is gone, it is gone. Simply Call Us Free on=20 877-503-8916 ------=_NextPart_000_0002_01C7F3BA.0167BA2F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you have your own business and = require IMMEDIATE ready money to spend ANY way you like or want Extra = money to give your company a boost or wish A low interest loan - NO = STRINGS ATTACHED, here is the deal we can offer you NOW (hurry, this = deal will expire TONIGHT):
=20
 
$61,000+ loan
 
Hurry, when best deal is gone, it is = gone. Simply Call Us Free on 877-503-8916
------=_NextPart_000_0002_01C7F3BA.0167BA2F-- From geopriv-bounces@ietf.org Mon Sep 10 11:11:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUktx-0002ug-P0; Mon, 10 Sep 2007 11:10:13 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUktw-0002sP-JI for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 11:10:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUktw-0002s4-7D for geopriv@ietf.org; Mon, 10 Sep 2007 11:10:12 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUktv-0001Hs-7X for geopriv@ietf.org; Mon, 10 Sep 2007 11:10:12 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUktm-00054a-3x; Mon, 10 Sep 2007 10:10:02 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 11:10:07 -0400 Message-ID: <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoA== In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I don't think so. Someone needs to judge "substantial improvement". It could be the server if it knew that is what you want. It could be the client if it knew what the server could do. Just putting the time parameter doesn't have a way to express anything other than the simplistic "wait 3 seconds" if anything can be done in those 3 seconds. You might get, say, 30% improvement from .25 sec to 3 sec. If that was the case, your mechanism would wait 3 seconds. I would not want that to happen. I want someone to judge when it's not worth waiting more for. That might be 1 second, or 2 seconds. Depends on the shape of the curve. Whatever parameters are decided upon, we may need two distinguished values that are "use locally mandated limits for emergency call routing" and the same for dispatch. If we're stuck with ResponseTime alone: In some jurisdictions, there are regulations which govern the time and/or accuracy required for emergency calls. When processing an emergency call location is used in two circumstances: routing a call to the most appropriate PSAP, and later, dispatching responders to help the caller. Regulations may govern one or both of these circumstances and the regulation may specify the accuracy without specifying time, time without specifying accuracy, or both time and accuracy. The protocol supports this possibility. There are two distinguished values for ResponseTime which are used for emergency calls, where there is a locally mandated time/accuracy requirements for routing or dispatch. The two values are: * EmergencyCallRoute: Used to signal that the locally required values for emergency call routing are needed. If there are no local mandates, and this parameter is used, the server should assume <1KM uncertainty with 95% confidence in <250 ms unless the accuracy can be substantially improved by waiting as much as 3 seconds. If the measurement mechanism can make substantial improvement by waiting, the wait time should be judged by the server to minimize the time the call is held while getting most of the gain in accuracy. If most of the improved uncertainty is achieved in 2 seconds, do not wait the entire 3 seconds. * EmergencyCallDispatch: Used to signal that the locally required values for emergency call dispatch are needed. If there are no local mandates, and this parameter is used, the server should assume <100M uncertainty with 95% confidence in <30 sec. As HELD is a text language, perhaps these strings can be used. If we need to assign integer values to them, then we'll pick something. > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Monday, September 10, 2007 10:26 AM > To: Brian Rosen; Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > You put three seconds in as the response time. If a more accurate > location can be provided in 3 seconds, it will take that long, if not it > will respond even faster. > > What's more, if the next application running on the device can actually > wait 20 seconds, it can state "20 seconds" and may actually subsequently > get a more accurate location which may take anywhere from 3 to 20 > seconds to return. > > Simple. > > If you really think that there is a need for a "please give me location > in the time mandated by the jurisdiction in which I am currently > operating" semantic then please send text. Nobody has suggested that is > what response time satisfies - and you have not proposed anything that > satisfies it either. Such a mechanism is not mutually exclusive to an > optional response time parameter. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, 10 September 2007 11:25 PM > To: Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > I was working in updates to phonebcp and framework and here is the spec > I > want to have: > > ED-25/AN-14 It is RECOMMENDED that location determination not take > longer > than 250 ms to obtain routing location and systems SHOULD be designed > such > that the typical response is under 100ms. However, as much as 3 seconds > to > obtain routing location MAY be tolerated if location accuracy can be > substantially improved over what can be obtained in 250 ms. > > How would you express that with your parameter? > > The equivalent for dispatch location is: > Generally, the PSAP can wait for an accurate location for dispatch. > However, there is no fixed time known in advance which is the limit; it > depends on the nature of the emergency. At some point the PSAP must > dispatch. In a subscription environment, the PSAP could update the > parameters in the filter (immediate response required). In a HELD > dereference, there is no way to cancel and the PSAP will have to choose > a > ResponseTime that it will wait for even if it wants to dispatch sooner > than > that. > > We then get to a complication. It may be the case in some jurisdictions > that there are regulations that govern this. In those cases, we may > need a > way to say "I need the regulation-imposed values for emergency call > route", > or the equivalent for dispatch. > > Brian > > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: Monday, September 10, 2007 3:22 AM > > To: geopriv@ietf.org > > Subject: [Geopriv] responseTime reprise > > > > I'm probably due to step into the ring on this topic. I apologise for > > anything that is rehashed, I have not read the _entire_ archive on > this > > topic. > > > > The main reason the responseTime parameter was proposed was our > collective > > experience with cellular systems. > > > > 3GPP have defined two values: "low delay" and "delay tolerant", which > > roughly correspond to what some have been advocating. However, where > > multiple network nodes are involved in serving a request (and 3GPP > relies > > on about 6), engineering is required to ensure smooth operation. Each > > node is configured with a different timeout so that the time that the > node > > adds to the transaction doesn't cause failures. This engineering > ensures > > that each location client receives a certain level of service. > > > > Of course, each network is engineered differently. Everyone has a > > different idea of what "low delay" and "delay tolerant" mean. In a > closed > > network this more or less works; although this isn't assured for > roamers. > > We wanted to avoid this problem. It makes sense to allow devolve the > > parameter; rather than place an arbitrary value on some abstract > codes, > > allow the client to decide. > > > > To add to this, during my break, we had a request for further control > over > > these values on one of our cellular products. In this request, > different > > types of clients would be given varying amounts of time. Thus, from > our > > perspective, we have a clear requirement for responseTime. > > > > To those who want hard limits; BCP documents are a good place for > > recommendations. You can add nice statements like: "if routing for > > emergency calls, set responseTime to x seconds; if you don't care, > allow y > > seconds". > > > > Ta, > > Martin > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 16:35:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpx4-00007y-6B; Mon, 10 Sep 2007 16:33:46 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUpx3-00007t-95 for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 16:33:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpx2-00007l-Ve for geopriv@ietf.org; Mon, 10 Sep 2007 16:33:44 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUpx1-0003kQ-7W for geopriv@ietf.org; Mon, 10 Sep 2007 16:33:44 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_15_43_02 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 15:43:02 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 15:33:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 15:33:37 -0500 Message-ID: In-Reply-To: <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEg References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 10 Sep 2007 20:33:40.0167 (UTC) FILETIME=[DF3E2570:01C7F3E9] X-Spam-Score: 1.8 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Brian,=0D=0A=0D=0AAs has been pointed out more times than I can count now.=0D= =0AThe shape of the curve CANNOT be quantified ahead of time.=0D=0A=0D=0AYo= u state below "In some jurisdictions, there are regulations which=0D=0Agove= rn the time and/or accuracy required for emergency calls."=20=0D=0ACan you = explain what happens if the accuracy cannot be met in any place,=0D=0Adoes = the PSAP get no location at all=3F I am prepared to bet you a beer at=0D=0A= the next IETF that they get something, and that it is the probably the=0D=0A= best location that the network can provide before the ALI transaction=0D=0A= times out.=0D=0A=0D=0AUntil recently you said that you only had two require= ment AGAP and ASAP,=0D=0AresponseTime will give you that, and it will give = us what we want.=0D=0AWin-win, and 'best-basis'.=0D=0A=0D=0AIf you want som= ething more than repsonseTime, as you indicate below,=0D=0Athen that can be= an extension and I challenge you to write a draft that=0D=0Acan do this.=0D= =0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> F= rom: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Tuesday, 11 Septem= ber 2007 1:10 AM=0D=0A> To: Dawson, Martin; Thomson, Martin; geopriv@ietf.o= rg=0D=0A> Subject: RE: [Geopriv] responseTime reprise=0D=0A>=20=0D=0A> I do= n't think so. Someone needs to judge "substantial improvement".=0D=0AIt=0D= =0A> could be the server if it knew that is what you want. It could be the=0D= =0A> client if it knew what the server could do. Just putting the time=0D=0A= > parameter=0D=0A> doesn't have a way to express anything other than the si= mplistic "wait=0D=0A3=0D=0A> seconds" if anything can be done in those 3 se= conds. You might get,=0D=0Asay,=0D=0A> 30% improvement from .25 sec to 3 s= ec. If that was the case, your=0D=0A> mechanism=0D=0A> would wait 3 second= s. I would not want that to happen. I want=0D=0Asomeone to=0D=0A> judge w= hen it's not worth waiting more for. That might be 1 second,=0D=0Aor 2=0D=0A= > seconds. Depends on the shape of the curve.=0D=0A>=20=0D=0A> Whatever pa= rameters are decided upon, we may need two distinguished=0D=0Avalues=0D=0A>= that are "use locally mandated limits for emergency call routing" and=0D=0A= the=0D=0A> same for dispatch. If we're stuck with ResponseTime alone:=0D=0A= >=20=0D=0A> In some jurisdictions, there are regulations which govern the t= ime=0D=0Aand/or=0D=0A> accuracy required for emergency calls. When process= ing an emergency=0D=0Acall=0D=0A> location is used in two circumstances: ro= uting a call to the most=0D=0A> appropriate PSAP, and later, dispatching re= sponders to help the=0D=0Acaller.=0D=0A> Regulations may govern one or both= of these circumstances and the=0D=0A> regulation=0D=0A> may specify the ac= curacy without specifying time, time without=0D=0Aspecifying=0D=0A> accurac= y, or both time and accuracy. The protocol supports this=0D=0A> possibilit= y. There are two distinguished values for ResponseTime=0D=0Awhich=0D=0A> a= re=0D=0A> used for emergency calls, where there is a locally mandated=0D=0A= time/accuracy=0D=0A> requirements for routing or dispatch. The two values = are:=0D=0A>=20=0D=0A> * EmergencyCallRoute: Used to signal that the locally= required values=0D=0Afor=0D=0A> emergency call routing are needed. If the= re are no local mandates,=0D=0Aand=0D=0A> this=0D=0A> parameter is used, th= e server should assume <1KM uncertainty with 95%=0D=0A> confidence in <250 = ms unless the accuracy can be substantially=0D=0Aimproved by=0D=0A> waiting= as much as 3 seconds. If the measurement mechanism can make=0D=0A> substa= ntial improvement by waiting, the wait time should be judged by=0D=0Athe=0D= =0A> server to minimize the time the call is held while getting most of the=0D= =0A> gain=0D=0A> in accuracy. If most of the improved uncertainty is achie= ved in 2=0D=0A> seconds,=0D=0A> do not wait the entire 3 seconds.=0D=0A> =0D= =0A> * EmergencyCallDispatch: Used to signal that the locally required=0D=0A= values=0D=0A> for=0D=0A> emergency call dispatch are needed. If there are = no local mandates,=0D=0Aand=0D=0A> this parameter is used, the server shoul= d assume <100M uncertainty=0D=0Awith=0D=0A> 95%=0D=0A> confidence in <30 se= c.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> As HELD is a text language, perhaps= these strings can be used. If we=0D=0Aneed=0D=0A> to assign integer value= s to them, then we'll pick something.=0D=0A>=20=0D=0A>=20=0D=0A> > -----Ori= ginal Message-----=0D=0A> > From: Dawson, Martin [mailto:Martin.Dawson@andr= ew.com]=0D=0A> > Sent: Monday, September 10, 2007 10:26 AM=0D=0A> > To: Bri= an Rosen; Thomson, Martin; geopriv@ietf.org=0D=0A> > Subject: RE: [Geopriv]= responseTime reprise=0D=0A> >=0D=0A> > You put three seconds in as the res= ponse time. If a more accurate=0D=0A> > location can be provided in 3 secon= ds, it will take that long, if=0D=0Anot it=0D=0A> > will respond even faste= r.=0D=0A> >=0D=0A> > What's more, if the next application running on the de= vice can=0D=0Aactually=0D=0A> > wait 20 seconds, it can state "20 seconds" = and may actually=0D=0Asubsequently=0D=0A> > get a more accurate location wh= ich may take anywhere from 3 to 20=0D=0A> > seconds to return.=0D=0A> >=0D=0A= > > Simple.=0D=0A> >=0D=0A> > If you really think that there is a need for = a "please give me=0D=0Alocation=0D=0A> > in the time mandated by the jurisd= iction in which I am currently=0D=0A> > operating" semantic then please sen= d text. Nobody has suggested that=0D=0Ais=0D=0A> > what response time satis= fies - and you have not proposed anything=0D=0Athat=0D=0A> > satisfies it e= ither. Such a mechanism is not mutually exclusive to=0D=0Aan=0D=0A> > optio= nal response time parameter.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A= > >=0D=0A> > -----Original Message-----=0D=0A> > From: Brian Rosen [mailto:= br@brianrosen.net]=0D=0A> > Sent: Monday, 10 September 2007 11:25 PM=0D=0A>= > To: Thomson, Martin; geopriv@ietf.org=0D=0A> > Subject: RE: [Geopriv] re= sponseTime reprise=0D=0A> >=0D=0A> > I was working in updates to phonebcp a= nd framework and here is the=0D=0Aspec=0D=0A> > I=0D=0A> > want to have:=0D= =0A> >=0D=0A> > ED-25/AN-14 It is RECOMMENDED that location determination n= ot take=0D=0A> > longer=0D=0A> > than 250 ms to obtain routing location and= systems SHOULD be=0D=0Adesigned=0D=0A> > such=0D=0A> > that the typical re= sponse is under 100ms. However, as much as 3=0D=0Aseconds=0D=0A> > to=0D=0A= > > obtain routing location MAY be tolerated if location accuracy can be=0D= =0A> > substantially improved over what can be obtained in 250 ms.=0D=0A> >=0D= =0A> > How would you express that with your parameter=3F=0D=0A> >=0D=0A> > = The equivalent for dispatch location is:=0D=0A> > Generally, the PSAP can w= ait for an accurate location for dispatch.=0D=0A> > However, there is no fi= xed time known in advance which is the limit;=0D=0Ait=0D=0A> > depends on t= he nature of the emergency. At some point the PSAP must=0D=0A> > dispatch.= In a subscription environment, the PSAP could update the=0D=0A> > paramet= ers in the filter (immediate response required). In a HELD=0D=0A> > derefe= rence, there is no way to cancel and the PSAP will have to=0D=0Achoose=0D=0A= > > a=0D=0A> > ResponseTime that it will wait for even if it wants to dispa= tch=0D=0Asooner=0D=0A> > than=0D=0A> > that. =0D=0A> >=0D=0A> > We then get to a complication. It = may be the case in some=0D=0Ajurisdictions=0D=0A> > that there are regulati= ons that govern this. In those cases, we may=0D=0A> > need a=0D=0A> > way = to say "I need the regulation-imposed values for emergency call=0D=0A> > ro= ute",=0D=0A> > or the equivalent for dispatch.=0D=0A> >=0D=0A> > Brian=0D=0A= > >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Thomson, Martin = [mailto:Martin.Thomson@andrew.com]=0D=0A> > > Sent: Monday, September 10, 2= 007 3:22 AM=0D=0A> > > To: geopriv@ietf.org=0D=0A> > > Subject: [Geopriv] r= esponseTime reprise=0D=0A> > >=0D=0A> > > I'm probably due to step into the= ring on this topic. I apologise=0D=0Afor=0D=0A> > > anything that is reha= shed, I have not read the _entire_ archive on=0D=0A> > this=0D=0A> > > topi= c.=0D=0A> > >=0D=0A> > > The main reason the responseTime parameter was pro= posed was our=0D=0A> > collective=0D=0A> > > experience with cellular syste= ms.=0D=0A> > >=0D=0A> > > 3GPP have defined two values: "low delay" and "de= lay tolerant",=0D=0Awhich=0D=0A> > > roughly correspond to what some have b= een advocating. However,=0D=0Awhere=0D=0A> > > multiple network nodes are = involved in serving a request (and 3GPP=0D=0A> > relies=0D=0A> > > on about= 6), engineering is required to ensure smooth operation.=0D=0AEach=0D=0A> >= > node is configured with a different timeout so that the time that=0D=0At= he=0D=0A> > node=0D=0A> > > adds to the transaction doesn't cause failures.= This engineering=0D=0A> > ensures=0D=0A> > > that each location client re= ceives a certain level of service.=0D=0A> > >=0D=0A> > > Of course, each ne= twork is engineered differently. Everyone has a=0D=0A> > > different idea = of what "low delay" and "delay tolerant" mean. In=0D=0Aa=0D=0A> > closed=0D= =0A> > > network this more or less works; although this isn't assured for=0D= =0A> > roamers.=0D=0A> > > We wanted to avoid this problem. It makes sense= to allow devolve=0D=0Athe=0D=0A> > > parameter; rather than place an arbit= rary value on some abstract=0D=0A> > codes,=0D=0A> > > allow the client to = decide.=0D=0A> > >=0D=0A> > > To add to this, during my break, we had a req= uest for further=0D=0Acontrol=0D=0A> > over=0D=0A> > > these values on one = of our cellular products. In this request,=0D=0A> > different=0D=0A> > > t= ypes of clients would be given varying amounts of time. Thus,=0D=0Afrom=0D= =0A> > our=0D=0A> > > perspective, we have a clear requirement for response= Time.=0D=0A> > >=0D=0A> > > To those who want hard limits; BCP documents ar= e a good place for=0D=0A> > > recommendations. You can add nice statements= like: "if routing=0D=0Afor=0D=0A> > > emergency calls, set responseTime to= x seconds; if you don't care,=0D=0A> > allow y=0D=0A> > > seconds".=0D=0A>= > >=0D=0A> > > Ta,=0D=0A> > > Martin=0D=0A> > >=0D=0A> >=0D=0A------------= ------------------------------------------------------------=0D=0A> > --=0D= =0A> > > ----------------------=0D=0A> > > This message is for the designat= ed recipient only and may=0D=0A> > > contain privileged, proprietary, or ot= herwise private information.=0D=0A> > > If you have received it in error, p= lease notify the sender=0D=0A> > > immediately and delete the original. An= y unauthorized use of=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A= > >=0D=0A------------------------------------------------------------------= ------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A> > > [mf2]=0D=0A= > >=0D=0A> >=0D=0A> >=0D=0A> > ____________________________________________= ___=0D=0A> > Geopriv mailing list=0D=0A> > Geopriv@ietf.org=0D=0A> > https:= //www1.ietf.org/mailman/listinfo/geopriv=0D=0A> >=0D=0A> >=0D=0A-----------= -------------------------------------------------------------=0D=0A> --=0D=0A= > > ----------------------=0D=0A> > This message is for the designated reci= pient only and may=0D=0A> > contain privileged, proprietary, or otherwise p= rivate information.=0D=0A> > If you have received it in error, please notif= y the sender=0D=0A> > immediately and delete the original. Any unauthorize= d use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A-----------------= -------------------------------------------------------=0D=0A> --=0D=0A> > = ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> = _______________________________________________=0D=0A> Geopriv mailing list=0D= =0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 17:21:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqfp-0006iE-Si; Mon, 10 Sep 2007 17:20:01 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUqfo-0006hi-O2 for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 17:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqfo-0006hW-EI for geopriv@ietf.org; Mon, 10 Sep 2007 17:20:00 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUqfn-00055Y-1F for geopriv@ietf.org; Mon, 10 Sep 2007 17:20:00 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUqfZ-0003bH-Tk; Mon, 10 Sep 2007 16:19:46 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Dawson, Martin'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 17:19:55 -0400 Message-ID: <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUA= In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James In the past, I thought a generalized "roughly now, whatever accuracy you can give me" and "roughly as accurate as you can get, in a reasonable, but longish time frame" was acceptable. It was pointed out to me that where there is actual regulation, what I asked for may not be one of the above. To my knowledge, there are no other uses where there is, or might be, regulation. So, I'm proposing that there be something that alerts the LIS that the request is one of those that have to conform to such regulation if there is any. I think what happens when the network cannot deliver what the regulation says is that they get some answer. The authorities also get some statistics that shows them whether the regulation is being met within the confidence requirement. After all, confidence is never 100%. Addressing what they do about it when the result doesn't meet the regulation is beyond scope no matter how you define it. I thought I made a pretty reasonable proposal, with text, as asked. I think I have provided a pretty decent motivation. I fail to see why this should be an extension, since this is one of (not the only) driving use cases. You can assail me for not recognizing sooner that there may have to be something that gets a predefined accuracy/time trade-off for the emergency case, but I think that, having recognized it, defined it, made a specific text proposal, and defended it, that perhaps you need to show me where I am wrong. In North America, at present, there is an accuracy requirement for emergency dispatch on mobile handsets. For handset driven systems like GPS, it's <100m 95% of the time. That may or may not conform to some LIS' notion of AGAP. On the other hand, if you tell it that you need dispatch location for an emergency call, and it's in the U.S., it knows EXACTLY what it needs to do. There is no setting of a generalized ResponseTime with or without AGAP/ASAP which would indicate <100M with 95% confidence. You will note that the regulation states accuracy without stating response time. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, September 10, 2007 4:34 PM > To: Brian Rosen; Dawson, Martin; Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > Brian, > > As has been pointed out more times than I can count now. > The shape of the curve CANNOT be quantified ahead of time. > > You state below "In some jurisdictions, there are regulations which > govern the time and/or accuracy required for emergency calls." > Can you explain what happens if the accuracy cannot be met in any place, > does the PSAP get no location at all? I am prepared to bet you a beer at > the next IETF that they get something, and that it is the probably the > best location that the network can provide before the ALI transaction > times out. > > Until recently you said that you only had two requirement AGAP and ASAP, > responseTime will give you that, and it will give us what we want. > Win-win, and 'best-basis'. > > If you want something more than repsonseTime, as you indicate below, > then that can be an extension and I challenge you to write a draft that > can do this. > > Cheers > James > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 11 September 2007 1:10 AM > > To: Dawson, Martin; Thomson, Martin; geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > I don't think so. Someone needs to judge "substantial improvement". > It > > could be the server if it knew that is what you want. It could be the > > client if it knew what the server could do. Just putting the time > > parameter > > doesn't have a way to express anything other than the simplistic "wait > 3 > > seconds" if anything can be done in those 3 seconds. You might get, > say, > > 30% improvement from .25 sec to 3 sec. If that was the case, your > > mechanism > > would wait 3 seconds. I would not want that to happen. I want > someone to > > judge when it's not worth waiting more for. That might be 1 second, > or 2 > > seconds. Depends on the shape of the curve. > > > > Whatever parameters are decided upon, we may need two distinguished > values > > that are "use locally mandated limits for emergency call routing" and > the > > same for dispatch. If we're stuck with ResponseTime alone: > > > > In some jurisdictions, there are regulations which govern the time > and/or > > accuracy required for emergency calls. When processing an emergency > call > > location is used in two circumstances: routing a call to the most > > appropriate PSAP, and later, dispatching responders to help the > caller. > > Regulations may govern one or both of these circumstances and the > > regulation > > may specify the accuracy without specifying time, time without > specifying > > accuracy, or both time and accuracy. The protocol supports this > > possibility. There are two distinguished values for ResponseTime > which > > are > > used for emergency calls, where there is a locally mandated > time/accuracy > > requirements for routing or dispatch. The two values are: > > > > * EmergencyCallRoute: Used to signal that the locally required values > for > > emergency call routing are needed. If there are no local mandates, > and > > this > > parameter is used, the server should assume <1KM uncertainty with 95% > > confidence in <250 ms unless the accuracy can be substantially > improved by > > waiting as much as 3 seconds. If the measurement mechanism can make > > substantial improvement by waiting, the wait time should be judged by > the > > server to minimize the time the call is held while getting most of the > > gain > > in accuracy. If most of the improved uncertainty is achieved in 2 > > seconds, > > do not wait the entire 3 seconds. > > > > * EmergencyCallDispatch: Used to signal that the locally required > values > > for > > emergency call dispatch are needed. If there are no local mandates, > and > > this parameter is used, the server should assume <100M uncertainty > with > > 95% > > confidence in <30 sec. > > > > > > > > As HELD is a text language, perhaps these strings can be used. If we > need > > to assign integer values to them, then we'll pick something. > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Monday, September 10, 2007 10:26 AM > > > To: Brian Rosen; Thomson, Martin; geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > You put three seconds in as the response time. If a more accurate > > > location can be provided in 3 seconds, it will take that long, if > not it > > > will respond even faster. > > > > > > What's more, if the next application running on the device can > actually > > > wait 20 seconds, it can state "20 seconds" and may actually > subsequently > > > get a more accurate location which may take anywhere from 3 to 20 > > > seconds to return. > > > > > > Simple. > > > > > > If you really think that there is a need for a "please give me > location > > > in the time mandated by the jurisdiction in which I am currently > > > operating" semantic then please send text. Nobody has suggested that > is > > > what response time satisfies - and you have not proposed anything > that > > > satisfies it either. Such a mechanism is not mutually exclusive to > an > > > optional response time parameter. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Monday, 10 September 2007 11:25 PM > > > To: Thomson, Martin; geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > I was working in updates to phonebcp and framework and here is the > spec > > > I > > > want to have: > > > > > > ED-25/AN-14 It is RECOMMENDED that location determination not take > > > longer > > > than 250 ms to obtain routing location and systems SHOULD be > designed > > > such > > > that the typical response is under 100ms. However, as much as 3 > seconds > > > to > > > obtain routing location MAY be tolerated if location accuracy can be > > > substantially improved over what can be obtained in 250 ms. > > > > > > How would you express that with your parameter? > > > > > > The equivalent for dispatch location is: > > > Generally, the PSAP can wait for an accurate location for dispatch. > > > However, there is no fixed time known in advance which is the limit; > it > > > depends on the nature of the emergency. At some point the PSAP must > > > dispatch. In a subscription environment, the PSAP could update the > > > parameters in the filter (immediate response required). In a HELD > > > dereference, there is no way to cancel and the PSAP will have to > choose > > > a > > > ResponseTime that it will wait for even if it wants to dispatch > sooner > > > than > > > that. > > > > > > We then get to a complication. It may be the case in some > jurisdictions > > > that there are regulations that govern this. In those cases, we may > > > need a > > > way to say "I need the regulation-imposed values for emergency call > > > route", > > > or the equivalent for dispatch. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > > Sent: Monday, September 10, 2007 3:22 AM > > > > To: geopriv@ietf.org > > > > Subject: [Geopriv] responseTime reprise > > > > > > > > I'm probably due to step into the ring on this topic. I apologise > for > > > > anything that is rehashed, I have not read the _entire_ archive on > > > this > > > > topic. > > > > > > > > The main reason the responseTime parameter was proposed was our > > > collective > > > > experience with cellular systems. > > > > > > > > 3GPP have defined two values: "low delay" and "delay tolerant", > which > > > > roughly correspond to what some have been advocating. However, > where > > > > multiple network nodes are involved in serving a request (and 3GPP > > > relies > > > > on about 6), engineering is required to ensure smooth operation. > Each > > > > node is configured with a different timeout so that the time that > the > > > node > > > > adds to the transaction doesn't cause failures. This engineering > > > ensures > > > > that each location client receives a certain level of service. > > > > > > > > Of course, each network is engineered differently. Everyone has a > > > > different idea of what "low delay" and "delay tolerant" mean. In > a > > > closed > > > > network this more or less works; although this isn't assured for > > > roamers. > > > > We wanted to avoid this problem. It makes sense to allow devolve > the > > > > parameter; rather than place an arbitrary value on some abstract > > > codes, > > > > allow the client to decide. > > > > > > > > To add to this, during my break, we had a request for further > control > > > over > > > > these values on one of our cellular products. In this request, > > > different > > > > types of clients would be given varying amounts of time. Thus, > from > > > our > > > > perspective, we have a clear requirement for responseTime. > > > > > > > > To those who want hard limits; BCP documents are a good place for > > > > recommendations. You can add nice statements like: "if routing > for > > > > emergency calls, set responseTime to x seconds; if you don't care, > > > allow y > > > > seconds". > > > > > > > > Ta, > > > > Martin > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 17:32:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqpq-0007zY-Qu; Mon, 10 Sep 2007 17:30:22 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUqpp-0007yw-Kv for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 17:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqpp-0007yo-Ax for geopriv@ietf.org; Mon, 10 Sep 2007 17:30:21 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUqpo-0005JK-1H for geopriv@ietf.org; Mon, 10 Sep 2007 17:30:21 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_16_39_41 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 16:39:41 -0500 Received: from acvaexch2k3.andrew.com ([10.142.20.230]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 16:30:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 17:30:17 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAJ9elA= References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com><023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> From: "Stuard, Doug" To: "Winterbottom, James" , "Brian Rosen" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 10 Sep 2007 21:30:19.0196 (UTC) FILETIME=[C938CFC0:01C7F3F1] X-Spam-Score: 1.8 (+) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Perhaps it's worthwhile dragging this one out of the archives:=0D=0A=0D=0AO= n August 14th I posted:=0D=0A=0D=0ARECOMMENDATION: What this boils down to = is to include both an (optional)=0D=0AResponseTime parameter specifying the= maximum time permitted for a=0D=0Aresponse, as well as an (also optional) = desired accuracy parameter=0D=0A(uncertainty value at a "standard" confiden= ce). =20=0D=0A=0D=0AThe inclusion of accuracy and/or time parameters in a c= lient request=0D=0Awould then result in the following response types:=0D=0A=0D= =0A1) No stated requirement - Best achievable accuracy, no time limit=0D=0A= (Open ended - Response provided at convergence or on receipt of "that's=0D=0A= enough!" command).=0D=0A=20=0D=0A2) Time limit only - Best achievable accur= acy within specified time=0D=0Alimit.=20=0D=0A=0D=0A3) Accuracy requirement= only - Provide response when specified=0D=0Aaccuracy reached, no time limi= t.=0D=0A=0D=0A4) Both time and accuracy - Provide response when specified=0D= =0Aaccuracy is reached or time limit expires, whichever comes first.=0D=0A =0D= =0AIn all cases, an accuracy estimate should be included in the response,=0D= =0Aand would be at a standard.=0D=0AThis will allow the client to decide if= further requests are necessary=0D=0Abased on the situation/application. =0D= =0A=0D=0AIn implementation, case 4 would be "first on wins". You either ac= hieve=0D=0Ayour required accuracy within the time limit specified in the cl= ient=0D=0Arequest, or you take the best that the server can provide when th= e clock=0D=0Aruns out. If you then need additional time, you can re-issue = the=0D=0Arequest, either without the time parameter or with a longer time w= indow.=0D=0A=0D=0AAs James pointed out this meets the full range of require= ments and is=0D=0A"best basis".=0D=0A=0D=0ADoug=0D=0A=0D=0A=0D=0A=0D=0A> --= ---Original Message-----=0D=0A> From: Winterbottom, James [mailto:James.Win= terbottom@andrew.com]=0D=0A> Sent: Monday, September 10, 2007 4:34 PM=0D=0A= > To: Brian Rosen; Dawson, Martin; Thomson, Martin; geopriv@ietf.org=0D=0A>= Subject: RE: [Geopriv] responseTime reprise=0D=0A>=20=0D=0A> Brian,=0D=0A>= =20=0D=0A> As has been pointed out more times than I can count now.=0D=0A> = The shape of the curve CANNOT be quantified ahead of time.=0D=0A>=20=0D=0A>= You state below "In some jurisdictions, there are regulations which=0D=0A>= govern the time and/or accuracy required for emergency calls."=0D=0A> Can = you explain what happens if the accuracy cannot be met in any=0D=0A> place,=0D= =0A> does the PSAP get no location at all=3F I am prepared to bet you a bee= r=0D=0A> at=0D=0A> the next IETF that they get something, and that it is th= e probably the=0D=0A> best location that the network can provide before the= ALI transaction=0D=0A> times out.=0D=0A>=20=0D=0A> Until recently you said= that you only had two requirement AGAP and=0D=0A> ASAP,=0D=0A> responseTim= e will give you that, and it will give us what we want.=0D=0A> Win-win, and= 'best-basis'.=0D=0A>=20=0D=0A> If you want something more than repsonseTim= e, as you indicate below,=0D=0A> then that can be an extension and I challe= nge you to write a draft=0D=0Athat=0D=0A> can do this.=0D=0A>=20=0D=0A> Che= ers=0D=0A> James=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > Fro= m: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > Sent: Tuesday, 11 Septem= ber 2007 1:10 AM=0D=0A> > To: Dawson, Martin; Thomson, Martin; geopriv@ietf= =2Eorg=0D=0A> > Subject: RE: [Geopriv] responseTime reprise=0D=0A> >=0D=0A>= > I don't think so. Someone needs to judge "substantial improvement".=0D=0A= > It=0D=0A> > could be the server if it knew that is what you want. It cou= ld be=0D=0A> the=0D=0A> > client if it knew what the server could do. Just= putting the time=0D=0A> > parameter=0D=0A> > doesn't have a way to express= anything other than the simplistic=0D=0A> "wait=0D=0A> 3=0D=0A> > seconds"= if anything can be done in those 3 seconds. You might get,=0D=0A> say,=0D= =0A> > 30% improvement from .25 sec to 3 sec. If that was the case, your=0D= =0A> > mechanism=0D=0A> > would wait 3 seconds. I would not want that to h= appen. I want=0D=0A> someone to=0D=0A> > judge when it's not worth waiting= more for. That might be 1 second,=0D=0A> or 2=0D=0A> > seconds. Depends = on the shape of the curve.=0D=0A> >=0D=0A> > Whatever parameters are decide= d upon, we may need two distinguished=0D=0A> values=0D=0A> > that are "use = locally mandated limits for emergency call routing"=0D=0Aand=0D=0A> the=0D=0A= > > same for dispatch. If we're stuck with ResponseTime alone:=0D=0A> >=0D= =0A> > In some jurisdictions, there are regulations which govern the time=0D= =0A> and/or=0D=0A> > accuracy required for emergency calls. When processin= g an emergency=0D=0A> call=0D=0A> > location is used in two circumstances: = routing a call to the most=0D=0A> > appropriate PSAP, and later, dispatchin= g responders to help the=0D=0A> caller.=0D=0A> > Regulations may govern one= or both of these circumstances and the=0D=0A> > regulation=0D=0A> > may sp= ecify the accuracy without specifying time, time without=0D=0A> specifying=0D= =0A> > accuracy, or both time and accuracy. The protocol supports this=0D=0A= > > possibility. There are two distinguished values for ResponseTime=0D=0A= > which=0D=0A> > are=0D=0A> > used for emergency calls, where there is a lo= cally mandated=0D=0A> time/accuracy=0D=0A> > requirements for routing or di= spatch. The two values are:=0D=0A> >=0D=0A> > * EmergencyCallRoute: Used t= o signal that the locally required=0D=0Avalues=0D=0A> for=0D=0A> > emergenc= y call routing are needed. If there are no local mandates,=0D=0A> and=0D=0A= > > this=0D=0A> > parameter is used, the server should assume <1KM uncertai= nty with=0D=0A95%=0D=0A> > confidence in <250 ms unless the accuracy can be= substantially=0D=0A> improved by=0D=0A> > waiting as much as 3 seconds. I= f the measurement mechanism can make=0D=0A> > substantial improvement by wa= iting, the wait time should be judged=0D=0Aby=0D=0A> the=0D=0A> > server to= minimize the time the call is held while getting most of=0D=0A> the=0D=0A>= > gain=0D=0A> > in accuracy. If most of the improved uncertainty is achie= ved in 2=0D=0A> > seconds,=0D=0A> > do not wait the entire 3 seconds.=0D=0A= > >=0D=0A> > * EmergencyCallDispatch: Used to signal that the locally requi= red=0D=0A> values=0D=0A> > for=0D=0A> > emergency call dispatch are needed.= If there are no local mandates,=0D=0A> and=0D=0A> > this parameter is use= d, the server should assume <100M uncertainty=0D=0A> with=0D=0A> > 95%=0D=0A= > > confidence in <30 sec.=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > As HELD is a= text language, perhaps these strings can be used. If=0D=0Awe=0D=0A> need=0D= =0A> > to assign integer values to them, then we'll pick something.=0D=0A> = >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Dawson, M= artin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > Sent: Monday, September = 10, 2007 10:26 AM=0D=0A> > > To: Brian Rosen; Thomson, Martin; geopriv@ietf= =2Eorg=0D=0A> > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D= =0A> > > You put three seconds in as the response time. If a more accurate=0D= =0A> > > location can be provided in 3 seconds, it will take that long, if=0D= =0A> not it=0D=0A> > > will respond even faster.=0D=0A> > >=0D=0A> > > What= 's more, if the next application running on the device can=0D=0A> actually=0D= =0A> > > wait 20 seconds, it can state "20 seconds" and may actually=0D=0A>= subsequently=0D=0A> > > get a more accurate location which may take anywhe= re from 3 to 20=0D=0A> > > seconds to return.=0D=0A> > >=0D=0A> > > Simple.=0D= =0A> > >=0D=0A> > > If you really think that there is a need for a "please = give me=0D=0A> location=0D=0A> > > in the time mandated by the jurisdiction= in which I am currently=0D=0A> > > operating" semantic then please send te= xt. Nobody has suggested=0D=0A> that=0D=0A> is=0D=0A> > > what response tim= e satisfies - and you have not proposed anything=0D=0A> that=0D=0A> > > sat= isfies it either. Such a mechanism is not mutually exclusive to=0D=0A> an=0D= =0A> > > optional response time parameter.=0D=0A> > >=0D=0A> > > Cheers,=0D= =0A> > > Martin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > >= From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Monday, 10 S= eptember 2007 11:25 PM=0D=0A> > > To: Thomson, Martin; geopriv@ietf.org=0D=0A= > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D=0A> > > I w= as working in updates to phonebcp and framework and here is the=0D=0A> spec=0D= =0A> > > I=0D=0A> > > want to have:=0D=0A> > >=0D=0A> > > ED-25/AN-14 It is= RECOMMENDED that location determination not take=0D=0A> > > longer=0D=0A> = > > than 250 ms to obtain routing location and systems SHOULD be=0D=0A> des= igned=0D=0A> > > such=0D=0A> > > that the typical response is under 100ms. = However, as much as 3=0D=0A> seconds=0D=0A> > > to=0D=0A> > > obtain routin= g location MAY be tolerated if location accuracy can=0D=0A> be=0D=0A> > > s= ubstantially improved over what can be obtained in 250 ms.=0D=0A> > >=0D=0A= > > > How would you express that with your parameter=3F=0D=0A> > >=0D=0A> >= > The equivalent for dispatch location is:=0D=0A> > > Generally, the PSAP = can wait for an accurate location for=0D=0Adispatch.=0D=0A> > > However, th= ere is no fixed time known in advance which is the=0D=0A> limit;=0D=0A> it=0D= =0A> > > depends on the nature of the emergency. At some point the PSAP=0D= =0A> must=0D=0A> > > dispatch. In a subscription environment, the PSAP cou= ld update=0D=0Athe=0D=0A> > > parameters in the filter (immediate response = required). In a HELD=0D=0A> > > dereference, there is no way to cancel and= the PSAP will have to=0D=0A> choose=0D=0A> > > a=0D=0A> > > ResponseTime t= hat it will wait for even if it wants to dispatch=0D=0A> sooner=0D=0A> > > = than=0D=0A> > > that. =0D= =0A> > >=0D=0A> > > We then get to a complication. It may be the case in s= ome=0D=0A> jurisdictions=0D=0A> > > that there are regulations that govern = this. In those cases, we=0D=0A> may=0D=0A> > > need a=0D=0A> > > way to sa= y "I need the regulation-imposed values for emergency=0D=0Acall=0D=0A> > > = route",=0D=0A> > > or the equivalent for dispatch.=0D=0A> > >=0D=0A> > > Br= ian=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: T= homson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A> > > > Sent: Monday= , September 10, 2007 3:22 AM=0D=0A> > > > To: geopriv@ietf.org=0D=0A> > > >= Subject: [Geopriv] responseTime reprise=0D=0A> > > >=0D=0A> > > > I'm prob= ably due to step into the ring on this topic. I=0D=0A> apologise=0D=0A> fo= r=0D=0A> > > > anything that is rehashed, I have not read the _entire_ arch= ive=0D=0A> on=0D=0A> > > this=0D=0A> > > > topic.=0D=0A> > > >=0D=0A> > > >= The main reason the responseTime parameter was proposed was our=0D=0A> > >= collective=0D=0A> > > > experience with cellular systems.=0D=0A> > > >=0D=0A= > > > > 3GPP have defined two values: "low delay" and "delay tolerant",=0D=0A= > which=0D=0A> > > > roughly correspond to what some have been advocating. = However,=0D=0A> where=0D=0A> > > > multiple network nodes are involved in = serving a request (and=0D=0A> 3GPP=0D=0A> > > relies=0D=0A> > > > on about = 6), engineering is required to ensure smooth operation.=0D=0A> Each=0D=0A> = > > > node is configured with a different timeout so that the time=0D=0Atha= t=0D=0A> the=0D=0A> > > node=0D=0A> > > > adds to the transaction doesn't c= ause failures. This=0D=0Aengineering=0D=0A> > > ensures=0D=0A> > > > that = each location client receives a certain level of service.=0D=0A> > > >=0D=0A= > > > > Of course, each network is engineered differently. Everyone has=0D= =0A> a=0D=0A> > > > different idea of what "low delay" and "delay tolerant"= mean.=0D=0AIn=0D=0A> a=0D=0A> > > closed=0D=0A> > > > network this more or= less works; although this isn't assured for=0D=0A> > > roamers.=0D=0A> > >= > We wanted to avoid this problem. It makes sense to allow=0D=0Adevolve=0D= =0A> the=0D=0A> > > > parameter; rather than place an arbitrary value on so= me abstract=0D=0A> > > codes,=0D=0A> > > > allow the client to decide.=0D=0A= > > > >=0D=0A> > > > To add to this, during my break, we had a request for = further=0D=0A> control=0D=0A> > > over=0D=0A> > > > these values on one of = our cellular products. In this request,=0D=0A> > > different=0D=0A> > > > = types of clients would be given varying amounts of time. Thus,=0D=0A> from=0D= =0A> > > our=0D=0A> > > > perspective, we have a clear requirement for resp= onseTime.=0D=0A> > > >=0D=0A> > > > To those who want hard limits; BCP docu= ments are a good place=0D=0Afor=0D=0A> > > > recommendations. You can add = nice statements like: "if routing=0D=0A> for=0D=0A> > > > emergency calls, = set responseTime to x seconds; if you don't=0D=0A> care,=0D=0A> > > allow y=0D= =0A> > > > seconds".=0D=0A> > > >=0D=0A> > > > Ta,=0D=0A> > > > Martin=0D=0A= > > > >=0D=0A> > >=0D=0A>=0D=0A--------------------------------------------= ---------------------------=0D=0A> -=0D=0A> > > --=0D=0A> > > > -----------= -----------=0D=0A> > > > This message is for the designated recipient only = and may=0D=0A> > > > contain privileged, proprietary, or otherwise private=0D= =0A> information.=0D=0A> > > > If you have received it in error, please not= ify the sender=0D=0A> > > > immediately and delete the original. Any unaut= horized use of=0D=0A> > > > this email is prohibited.=0D=0A> > > >=0D=0A> >= >=0D=0A>=0D=0A------------------------------------------------------------= -----------=0D=0A> -=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A= > > > > [mf2]=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > _________________= ______________________________=0D=0A> > > Geopriv mailing list=0D=0A> > > G= eopriv@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A> > >=0D=0A> > >=0D=0A>=0D=0A-------------------------------------------= ----------------------------=0D=0A> -=0D=0A> > --=0D=0A> > > --------------= --------=0D=0A> > > This message is for the designated recipient only and m= ay=0D=0A> > > contain privileged, proprietary, or otherwise private informa= tion.=0D=0A> > > If you have received it in error, please notify the sender=0D= =0A> > > immediately and delete the original. Any unauthorized use of=0D=0A= > > > this email is prohibited.=0D=0A> > >=0D=0A>=0D=0A--------------------= ---------------------------------------------------=0D=0A> -=0D=0A> > --=0D= =0A> > > ----------------------=0D=0A> > > [mf2]=0D=0A> >=0D=0A> >=0D=0A> >=0D= =0A> > _______________________________________________=0D=0A> > Geopriv mai= ling list=0D=0A> > Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/= listinfo/geopriv=0D=0A>=20=0D=0A>=0D=0A------------------------------------= -----------------------------------=0D=0A> -------------------------=0D=0A>= This message is for the designated recipient only and may=0D=0A> contain p= rivileged, proprietary, or otherwise private information.=0D=0A> If you hav= e received it in error, please notify the sender=0D=0A> immediately and del= ete the original. Any unauthorized use of=0D=0A> this email is prohibited.=0D= =0A>=0D=0A-----------------------------------------------------------------= ------=0D=0A> -------------------------=0D=0A> [mf2]=0D=0A>=20=0D=0A>=20=0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Geopr= iv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailma= n/listinfo/geopriv=0D=0A=0D=0A---------------------------------------------= ---------------------------------------------------=0D=0AThis message is fo= r the designated recipient only and may=0D=0Acontain privileged, proprietar= y, or otherwise private information. =20=0D=0AIf you have received it in er= ror, please notify the sender=0D=0Aimmediately and delete the original. An= y unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------------= ---------------------------------------------------------------------------= ----=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 17:45:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUr2b-0005Uf-A7; Mon, 10 Sep 2007 17:43:33 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUr2Z-0005Py-Qw for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 17:43:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUr2Z-0005PC-Gs for geopriv@ietf.org; Mon, 10 Sep 2007 17:43:31 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUr2Y-0005cM-36 for geopriv@ietf.org; Mon, 10 Sep 2007 17:43:31 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_16_52_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 16:52:51 -0500 Received: from acvaexch2k3.andrew.com ([10.142.20.230]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 16:43:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 17:43:27 -0400 Message-ID: In-Reply-To: <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAAT+OgA== References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com><023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> From: "Stuard, Doug" To: "Brian Rosen" , "Winterbottom, James" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 10 Sep 2007 21:43:29.0251 (UTC) FILETIME=[A021A330:01C7F3F3] X-Spam-Score: -0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The accuracy requirements in North America do NOT apply to individual=0D=0A= locations, but to overall system performance. 100 m uncertainty at 95%=0D=0A= confidence for a given geolocation is neither compliant or=0D=0Anon-complia= nt, it is just one data point in overall accuracy evaluation=0D=0A(obviousl= y if all locations came it with these results, the overall=0D=0Asystem woul= d in fact be compliant). =20=0D=0A=0D=0AAGAP for a given call instance is = just that - AGAP for THAT CALL. If=0D=0Ayou need dispatch location for an = emergency call in the US, you need=0D=0AAGAP within your dispatch time wind= ow (generally taken to be 30 seconds=0D=0Aor less). Whether it is within t= he 100m uncertainty at whatever=0D=0Aconfidence is irrelevant for any given= call. Those factors are for the=0D=0Aanalysts to evaluate after the fact = on a statistical sampling of calls=0D=0Ain the defined service are to deter= mine whether the accuracy standards=0D=0Ahave been met.=0D=0A=0D=0ADoug=0D=0A=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@b= rianrosen.net]=0D=0A> Sent: Monday, September 10, 2007 5:20 PM=0D=0A> To: W= interbottom, James; Dawson, Martin; Thomson, Martin;=0D=0A> geopriv@ietf.or= g=0D=0A> Subject: RE: [Geopriv] responseTime reprise=0D=0A>=20=0D=0A>=0D= =0A>=20=0D=0A> In North America, at present, there is an accuracy requireme= nt for=0D=0A> emergency=0D=0A> dispatch on mobile handsets. For handset dr= iven systems like GPS,=0D=0Ait's=0D=0A> <100m 95% of the time. That may or= may not conform to some LIS'=0D=0Anotion=0D=0A> of=0D=0A> AGAP. On the ot= her hand, if you tell it that you need dispatch=0D=0A> location for=0D=0A> = an emergency call, and it's in the U.S., it knows EXACTLY what it=0D=0Aneed= s=0D=0A> to=0D=0A> do. There is no setting of a generalized ResponseTime w= ith or without=0D=0A> AGAP/ASAP which would indicate <100M with 95% confide= nce. You will=0D=0A> note=0D=0A> that the regulation states accuracy witho= ut stating response time.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A>= > -----Original Message-----=0D=0A> > From: Winterbottom, James [mailto:Ja= mes.Winterbottom@andrew.com]=0D=0A> > Sent: Monday, September 10, 2007 4:34= PM=0D=0A> > To: Brian Rosen; Dawson, Martin; Thomson, Martin; geopriv@ietf= =2Eorg=0D=0A> > Subject: RE: [Geopriv] responseTime reprise=0D=0A> >=0D=0A>= > Brian,=0D=0A> >=0D=0A> > As has been pointed out more times than I can c= ount now.=0D=0A> > The shape of the curve CANNOT be quantified ahead of tim= e.=0D=0A> >=0D=0A> > You state below "In some jurisdictions, there are regu= lations which=0D=0A> > govern the time and/or accuracy required for emergen= cy calls."=0D=0A> > Can you explain what happens if the accuracy cannot be = met in any=0D=0A> place,=0D=0A> > does the PSAP get no location at all=3F I= am prepared to bet you a=0D=0Abeer=0D=0A> at=0D=0A> > the next IETF that t= hey get something, and that it is the probably=0D=0A> the=0D=0A> > best loc= ation that the network can provide before the ALI=0D=0Atransaction=0D=0A> >= times out.=0D=0A> >=0D=0A> > Until recently you said that you only had two= requirement AGAP and=0D=0A> ASAP,=0D=0A> > responseTime will give you that= , and it will give us what we want.=0D=0A> > Win-win, and 'best-basis'.=0D=0A= > >=0D=0A> > If you want something more than repsonseTime, as you indicate = below,=0D=0A> > then that can be an extension and I challenge you to write = a draft=0D=0A> that=0D=0A> > can do this.=0D=0A> >=0D=0A> > Cheers=0D=0A> >= James=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Bria= n Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Tuesday, 11 September 2= 007 1:10 AM=0D=0A> > > To: Dawson, Martin; Thomson, Martin; geopriv@ietf.or= g=0D=0A> > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D=0A> = > > I don't think so. Someone needs to judge "substantial=0D=0A> improveme= nt".=0D=0A> > It=0D=0A> > > could be the server if it knew that is what you= want. It could be=0D=0A> the=0D=0A> > > client if it knew what the server= could do. Just putting the time=0D=0A> > > parameter=0D=0A> > > doesn't h= ave a way to express anything other than the simplistic=0D=0A> "wait=0D=0A>= > 3=0D=0A> > > seconds" if anything can be done in those 3 seconds. You m= ight=0D=0A> get,=0D=0A> > say,=0D=0A> > > 30% improvement from .25 sec to 3= sec. If that was the case, your=0D=0A> > > mechanism=0D=0A> > > would wai= t 3 seconds. I would not want that to happen. I want=0D=0A> > someone to=0D= =0A> > > judge when it's not worth waiting more for. That might be 1=0D=0A= > second,=0D=0A> > or 2=0D=0A> > > seconds. Depends on the shape of the cu= rve.=0D=0A> > >=0D=0A> > > Whatever parameters are decided upon, we may nee= d two=0D=0Adistinguished=0D=0A> > values=0D=0A> > > that are "use locally m= andated limits for emergency call routing"=0D=0A> and=0D=0A> > the=0D=0A> >= > same for dispatch. If we're stuck with ResponseTime alone:=0D=0A> > >=0D= =0A> > > In some jurisdictions, there are regulations which govern the time=0D= =0A> > and/or=0D=0A> > > accuracy required for emergency calls. When proce= ssing an=0D=0A> emergency=0D=0A> > call=0D=0A> > > location is used in two = circumstances: routing a call to the most=0D=0A> > > appropriate PSAP, and = later, dispatching responders to help the=0D=0A> > caller.=0D=0A> > > Regul= ations may govern one or both of these circumstances and the=0D=0A> > > reg= ulation=0D=0A> > > may specify the accuracy without specifying time, time w= ithout=0D=0A> > specifying=0D=0A> > > accuracy, or both time and accuracy. = The protocol supports this=0D=0A> > > possibility. There are two distingu= ished values for ResponseTime=0D=0A> > which=0D=0A> > > are=0D=0A> > > used= for emergency calls, where there is a locally mandated=0D=0A> > time/accur= acy=0D=0A> > > requirements for routing or dispatch. The two values are:=0D= =0A> > >=0D=0A> > > * EmergencyCallRoute: Used to signal that the locally r= equired=0D=0A> values=0D=0A> > for=0D=0A> > > emergency call routing are ne= eded. If there are no local=0D=0Amandates,=0D=0A> > and=0D=0A> > > this=0D= =0A> > > parameter is used, the server should assume <1KM uncertainty with=0D= =0A> 95%=0D=0A> > > confidence in <250 ms unless the accuracy can be substa= ntially=0D=0A> > improved by=0D=0A> > > waiting as much as 3 seconds. If t= he measurement mechanism can=0D=0A> make=0D=0A> > > substantial improvement= by waiting, the wait time should be judged=0D=0A> by=0D=0A> > the=0D=0A> >= > server to minimize the time the call is held while getting most of=0D=0A= > the=0D=0A> > > gain=0D=0A> > > in accuracy. If most of the improved unce= rtainty is achieved in 2=0D=0A> > > seconds,=0D=0A> > > do not wait the ent= ire 3 seconds.=0D=0A> > >=0D=0A> > > * EmergencyCallDispatch: Used to signa= l that the locally required=0D=0A> > values=0D=0A> > > for=0D=0A> > > emerg= ency call dispatch are needed. If there are no local=0D=0A> mandates,=0D=0A= > > and=0D=0A> > > this parameter is used, the server should assume <100M u= ncertainty=0D=0A> > with=0D=0A> > > 95%=0D=0A> > > confidence in <30 sec.=0D= =0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > As HELD is a text language, perha= ps these strings can be used. If=0D=0A> we=0D=0A> > need=0D=0A> > > to ass= ign integer values to them, then we'll pick something.=0D=0A> > >=0D=0A> > = >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: Dawson, Martin= [mailto:Martin.Dawson@andrew.com]=0D=0A> > > > Sent: Monday, September 10,= 2007 10:26 AM=0D=0A> > > > To: Brian Rosen; Thomson, Martin; geopriv@ietf.= org=0D=0A> > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > >=0D= =0A> > > > You put three seconds in as the response time. If a more=0D=0Aac= curate=0D=0A> > > > location can be provided in 3 seconds, it will take tha= t long,=0D=0Aif=0D=0A> > not it=0D=0A> > > > will respond even faster.=0D=0A= > > > >=0D=0A> > > > What's more, if the next application running on the de= vice can=0D=0A> > actually=0D=0A> > > > wait 20 seconds, it can state "20 s= econds" and may actually=0D=0A> > subsequently=0D=0A> > > > get a more accu= rate location which may take anywhere from 3 to=0D=0A20=0D=0A> > > > second= s to return.=0D=0A> > > >=0D=0A> > > > Simple.=0D=0A> > > >=0D=0A> > > > If= you really think that there is a need for a "please give me=0D=0A> > locat= ion=0D=0A> > > > in the time mandated by the jurisdiction in which I am cur= rently=0D=0A> > > > operating" semantic then please send text. Nobody has s= uggested=0D=0A> that=0D=0A> > is=0D=0A> > > > what response time satisfies = - and you have not proposed=0D=0Aanything=0D=0A> > that=0D=0A> > > > satisf= ies it either. Such a mechanism is not mutually exclusive=0D=0A> to=0D=0A> = > an=0D=0A> > > > optional response time parameter.=0D=0A> > > >=0D=0A> > >= > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > > > -----Original Mess= age-----=0D=0A> > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> >= > > Sent: Monday, 10 September 2007 11:25 PM=0D=0A> > > > To: Thomson, Mar= tin; geopriv@ietf.org=0D=0A> > > > Subject: RE: [Geopriv] responseTime repr= ise=0D=0A> > > >=0D=0A> > > > I was working in updates to phonebcp and fram= ework and here is=0D=0A> the=0D=0A> > spec=0D=0A> > > > I=0D=0A> > > > want= to have:=0D=0A> > > >=0D=0A> > > > ED-25/AN-14 It is RECOMMENDED that loca= tion determination not=0D=0A> take=0D=0A> > > > longer=0D=0A> > > > than 25= 0 ms to obtain routing location and systems SHOULD be=0D=0A> > designed=0D=0A= > > > > such=0D=0A> > > > that the typical response is under 100ms. However= , as much as 3=0D=0A> > seconds=0D=0A> > > > to=0D=0A> > > > obtain routing= location MAY be tolerated if location accuracy=0D=0Acan=0D=0A> be=0D=0A> >= > > substantially improved over what can be obtained in 250 ms.=0D=0A> > >= >=0D=0A> > > > How would you express that with your parameter=3F=0D=0A> > = > >=0D=0A> > > > The equivalent for dispatch location is:=0D=0A> > > > Gene= rally, the PSAP can wait for an accurate location for=0D=0A> dispatch.=0D=0A= > > > > However, there is no fixed time known in advance which is the=0D=0A= > limit;=0D=0A> > it=0D=0A> > > > depends on the nature of the emergency. = At some point the PSAP=0D=0A> must=0D=0A> > > > dispatch. In a subscriptio= n environment, the PSAP could update=0D=0A> the=0D=0A> > > > parameters in = the filter (immediate response required). In a=0D=0A> HELD=0D=0A> > > > de= reference, there is no way to cancel and the PSAP will have to=0D=0A> > cho= ose=0D=0A> > > > a=0D=0A> > > > ResponseTime that it will wait for even if = it wants to dispatch=0D=0A> > sooner=0D=0A> > > > than=0D=0A> > > > that. = =0D=0A> > > >=0D=0A> > > = > We then get to a complication. It may be the case in some=0D=0A> > juris= dictions=0D=0A> > > > that there are regulations that govern this. In thos= e cases, we=0D=0A> may=0D=0A> > > > need a=0D=0A> > > > way to say "I need = the regulation-imposed values for emergency=0D=0A> call=0D=0A> > > > route"= ,=0D=0A> > > > or the equivalent for dispatch.=0D=0A> > > >=0D=0A> > > > Br= ian=0D=0A> > > >=0D=0A> > > > > -----Original Message-----=0D=0A> > > > > F= rom: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A> > > > > Sent= : Monday, September 10, 2007 3:22 AM=0D=0A> > > > > To: geopriv@ietf.org=0D= =0A> > > > > Subject: [Geopriv] responseTime reprise=0D=0A> > > > >=0D=0A> = > > > > I'm probably due to step into the ring on this topic. I=0D=0A> apo= logise=0D=0A> > for=0D=0A> > > > > anything that is rehashed, I have not re= ad the _entire_=0D=0Aarchive=0D=0A> on=0D=0A> > > > this=0D=0A> > > > > top= ic.=0D=0A> > > > >=0D=0A> > > > > The main reason the responseTime paramete= r was proposed was=0D=0Aour=0D=0A> > > > collective=0D=0A> > > > > experien= ce with cellular systems.=0D=0A> > > > >=0D=0A> > > > > 3GPP have defined t= wo values: "low delay" and "delay=0D=0Atolerant",=0D=0A> > which=0D=0A> > >= > > roughly correspond to what some have been advocating.=0D=0AHowever,=0D= =0A> > where=0D=0A> > > > > multiple network nodes are involved in serving = a request (and=0D=0A> 3GPP=0D=0A> > > > relies=0D=0A> > > > > on about 6), = engineering is required to ensure smooth=0D=0A> operation.=0D=0A> > Each=0D= =0A> > > > > node is configured with a different timeout so that the time=0D= =0A> that=0D=0A> > the=0D=0A> > > > node=0D=0A> > > > > adds to the transac= tion doesn't cause failures. This=0D=0A> engineering=0D=0A> > > > ensures=0D= =0A> > > > > that each location client receives a certain level of service.=0D= =0A> > > > >=0D=0A> > > > > Of course, each network is engineered different= ly. Everyone=0D=0A> has a=0D=0A> > > > > different idea of what "low delay= " and "delay tolerant" mean.=0D=0A> In=0D=0A> > a=0D=0A> > > > closed=0D=0A= > > > > > network this more or less works; although this isn't assured=0D=0A= > for=0D=0A> > > > roamers.=0D=0A> > > > > We wanted to avoid this problem.= It makes sense to allow=0D=0A> devolve=0D=0A> > the=0D=0A> > > > > parame= ter; rather than place an arbitrary value on some=0D=0A> abstract=0D=0A> > = > > codes,=0D=0A> > > > > allow the client to decide.=0D=0A> > > > >=0D=0A>= > > > > To add to this, during my break, we had a request for further=0D=0A= > > control=0D=0A> > > > over=0D=0A> > > > > these values on one of our cel= lular products. In this=0D=0Arequest,=0D=0A> > > > different=0D=0A> > > > = > types of clients would be given varying amounts of time.=0D=0AThus,=0D=0A= > > from=0D=0A> > > > our=0D=0A> > > > > perspective, we have a clear requi= rement for responseTime.=0D=0A> > > > >=0D=0A> > > > > To those who want ha= rd limits; BCP documents are a good place=0D=0A> for=0D=0A> > > > > recomme= ndations. You can add nice statements like: "if=0D=0Arouting=0D=0A> > for=0D= =0A> > > > > emergency calls, set responseTime to x seconds; if you don't=0D= =0A> care,=0D=0A> > > > allow y=0D=0A> > > > > seconds".=0D=0A> > > > >=0D=0A= > > > > > Ta,=0D=0A> > > > > Martin=0D=0A> > > > >=0D=0A> > > >=0D=0A> >=0D= =0A---------------------------------------------------------------------=0D= =0A> ---=0D=0A> > > > --=0D=0A> > > > > ----------------------=0D=0A> > > >= > This message is for the designated recipient only and may=0D=0A> > > > >= contain privileged, proprietary, or otherwise private=0D=0A> information.=0D= =0A> > > > > If you have received it in error, please notify the sender=0D=0A= > > > > > immediately and delete the original. Any unauthorized use of=0D=0A= > > > > > this email is prohibited.=0D=0A> > > > >=0D=0A> > > >=0D=0A> >=0D= =0A---------------------------------------------------------------------=0D= =0A> ---=0D=0A> > > > --=0D=0A> > > > > ----------------------=0D=0A> > > >= > [mf2]=0D=0A> > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > ______________= _________________________________=0D=0A> > > > Geopriv mailing list=0D=0A> = > > > Geopriv@ietf.org=0D=0A> > > > https://www1.ietf.org/mailman/listinfo/= geopriv=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D=0A---------------------------= ------------------------------------------=0D=0A> ---=0D=0A> > > --=0D=0A> = > > > ----------------------=0D=0A> > > > This message is for the designate= d recipient only and may=0D=0A> > > > contain privileged, proprietary, or o= therwise private=0D=0A> information.=0D=0A> > > > If you have received it i= n error, please notify the sender=0D=0A> > > > immediately and delete the o= riginal. Any unauthorized use of=0D=0A> > > > this email is prohibited.=0D= =0A> > > >=0D=0A> >=0D=0A--------------------------------------------------= -------------------=0D=0A> ---=0D=0A> > > --=0D=0A> > > > -----------------= -----=0D=0A> > > > [mf2]=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > ______= _________________________________________=0D=0A> > > Geopriv mailing list=0D= =0A> > > Geopriv@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo= /geopriv=0D=0A> >=0D=0A> >=0D=0A-------------------------------------------= --------------------------=0D=0A> -----=0D=0A> > ----------------------=0D=0A= > > This message is for the designated recipient only and may=0D=0A> > cont= ain privileged, proprietary, or otherwise private information.=0D=0A> > If = you have received it in error, please notify the sender=0D=0A> > immediatel= y and delete the original. Any unauthorized use of=0D=0A> > this email is = prohibited.=0D=0A> >=0D=0A-------------------------------------------------= --------------------=0D=0A> -----=0D=0A> > ----------------------=0D=0A> > = [mf2]=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> ________________________________= _______________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> = https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-----------------= ---------------------------------------------------------------------------= ----=0D=0AThis message is for the designated recipient only and may=0D=0Aco= ntain privileged, proprietary, or otherwise private information. =20=0D=0AI= f you have received it in error, please notify the sender=0D=0Aimmediately = and delete the original. Any unauthorized use of=0D=0Athis email is prohib= ited.=0D=0A----------------------------------------------------------------= --------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 17:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUr6S-0001AO-KG; Mon, 10 Sep 2007 17:47:32 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUr6S-0001A1-0N for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 17:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUr6R-00019n-JL for geopriv@ietf.org; Mon, 10 Sep 2007 17:47:31 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUr6P-0005ja-JW for geopriv@ietf.org; Mon, 10 Sep 2007 17:47:31 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_16_56_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 16:56:50 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 16:47:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 16:47:25 -0500 Message-ID: In-Reply-To: <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYA== References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 10 Sep 2007 21:47:29.0025 (UTC) FILETIME=[2F0C3F10:01C7F3F4] X-Spam-Score: -0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Brian,=0D=0A=0D=0AI think that the first part is actually totally achievabl= e with the=0D=0AresponseTime parameter, and you can certainly check the sta= ts later.=0D=0AThis further stresses my point that applications almost alwa= ys know=0D=0Awhether the accuracy is good enough to do something with. But = I think=0D=0Awhat I am hearing from you is that you see a need for a servic= e=0D=0Aindicator to the LIS saying, I need this for emergency purposes plea= se.=0D=0A=0D=0APerhaps I missed what your proposed text was then, the only = solutions I=0D=0Arecall seeing were ones that required network URI profilin= g ahead of=0D=0Atime and I know that that can't be done. So would you pleas= e repeat your=0D=0Aproposal=3F=0D=0A=0D=0AOn the last point, the legislatio= n might not provide a time constraint,=0D=0Abut we all know that there is o= ne. If it were to take an hour or even 5=0D=0Aminutes to get a location tha= t that would be totally unacceptable in=0D=0Athis use case. I have describe= d mobile concierge applications that only=0D=0Ahave a time constraint and n= ot really an accuracy one, because they can=0D=0Awork with either geodetic = or civic locations.=0D=0A=0D=0AI am not discounting the use case you propos= e, I just don't believe that=0D=0Aany proposed solution I have describes ho= w:=0D=0A=0D=0A1) It can apply to civic and geo location information=0D=0A2)= If I can't meet it, what is the semantic=0D=0A3) If I request a civic and = geo in the same location request, which=0D=0Atakes precedence, time or accu= racy and why=3F=0D=0A4) How it interacts with other attributes that are alr= eady agreed upon=0D=0A=0D=0ABasically any proposed solution needs to addres= s at least all of those=0D=0Aand in an unambiguous way, otherwise I don't s= ee it as doing much more=0D=0Athan throwing a spanner(wrench) in the works.=0D= =0A=0D=0ACheers=0D=0AJames=20=0D=0A=0D=0A> -----Original Message-----=0D=0A= > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Tuesday, 11 Sep= tember 2007 7:20 AM=0D=0A> To: Winterbottom, James; Dawson, Martin; Thomson= , Martin;=0D=0Ageopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] responseTime = reprise=0D=0A>=20=0D=0A> James=0D=0A>=20=0D=0A> In the past, I thought a ge= neralized "roughly now, whatever accuracy=0D=0Ayou=0D=0A> can=0D=0A> give m= e" and "roughly as accurate as you can get, in a reasonable, but=0D=0A> lon= gish time frame" was acceptable. It was pointed out to me that=0D=0Awhere=0D= =0A> there is actual regulation, what I asked for may not be one of the=0D=0A= above.=0D=0A> To my knowledge, there are no other uses where there is, or m= ight be,=0D=0A> regulation. So, I'm proposing that there be something that= alerts the=0D=0ALIS=0D=0A> that the request is one of those that have to c= onform to such=0D=0Aregulation=0D=0A> if=0D=0A> there is any.=0D=0A>=20=0D=0A= > I think what happens when the network cannot deliver what the=0D=0Aregula= tion=0D=0A> says is that they get some answer. The authorities also get som= e=0D=0A> statistics=0D=0A> that shows them whether the regulation is being = met within the=0D=0Aconfidence=0D=0A> requirement. After all, confidence i= s never 100%. Addressing what=0D=0Athey=0D=0A> do=0D=0A> about it when the= result doesn't meet the regulation is beyond scope=0D=0Ano=0D=0A> matter h= ow you define it.=0D=0A>=20=0D=0A> I thought I made a pretty reasonable pro= posal, with text, as asked. I=0D=0A> think=0D=0A> I have provided a pretty= decent motivation. I fail to see why this=0D=0Ashould=0D=0A> be an extens= ion, since this is one of (not the only) driving use=0D=0Acases.=0D=0A> You=0D= =0A> can assail me for not recognizing sooner that there may have to be=0D=0A= > something=0D=0A> that gets a predefined accuracy/time trade-off for the e= mergency case,=0D=0Abut=0D=0A> I=0D=0A> think that, having recognized it, d= efined it, made a specific text=0D=0A> proposal,=0D=0A> and defended it, th= at perhaps you need to show me where I am wrong.=0D=0A>=20=0D=0A> In North = America, at present, there is an accuracy requirement for=0D=0A> emergency=0D= =0A> dispatch on mobile handsets. For handset driven systems like GPS,=0D=0A= it's=0D=0A> <100m 95% of the time. That may or may not conform to some LIS= '=0D=0Anotion of=0D=0A> AGAP. On the other hand, if you tell it that you n= eed dispatch=0D=0Alocation=0D=0A> for=0D=0A> an emergency call, and it's in= the U.S., it knows EXACTLY what it=0D=0Aneeds to=0D=0A> do. There is no s= etting of a generalized ResponseTime with or without=0D=0A> AGAP/ASAP which= would indicate <100M with 95% confidence. You will=0D=0Anote=0D=0A> that = the regulation states accuracy without stating response time.=0D=0A>=20=0D=0A= > Brian=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > Fr= om: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A> > Sen= t: Monday, September 10, 2007 4:34 PM=0D=0A> > To: Brian Rosen; Dawson, Mar= tin; Thomson, Martin; geopriv@ietf.org=0D=0A> > Subject: RE: [Geopriv] resp= onseTime reprise=0D=0A> >=0D=0A> > Brian,=0D=0A> >=0D=0A> > As has been poi= nted out more times than I can count now.=0D=0A> > The shape of the curve C= ANNOT be quantified ahead of time.=0D=0A> >=0D=0A> > You state below "In so= me jurisdictions, there are regulations which=0D=0A> > govern the time and/= or accuracy required for emergency calls."=0D=0A> > Can you explain what ha= ppens if the accuracy cannot be met in any=0D=0Aplace,=0D=0A> > does the PS= AP get no location at all=3F I am prepared to bet you a=0D=0Abeer at=0D=0A>= > the next IETF that they get something, and that it is the probably=0D=0A= the=0D=0A> > best location that the network can provide before the ALI=0D=0A= transaction=0D=0A> > times out.=0D=0A> >=0D=0A> > Until recently you said t= hat you only had two requirement AGAP and=0D=0AASAP,=0D=0A> > responseTime = will give you that, and it will give us what we want.=0D=0A> > Win-win, and= 'best-basis'.=0D=0A> >=0D=0A> > If you want something more than repsonseTi= me, as you indicate below,=0D=0A> > then that can be an extension and I cha= llenge you to write a draft=0D=0Athat=0D=0A> > can do this.=0D=0A> >=0D=0A>= > Cheers=0D=0A> > James=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A= > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Tuesday= , 11 September 2007 1:10 AM=0D=0A> > > To: Dawson, Martin; Thomson, Martin;= geopriv@ietf.org=0D=0A> > > Subject: RE: [Geopriv] responseTime reprise=0D= =0A> > >=0D=0A> > > I don't think so. Someone needs to judge "substantial=0D= =0Aimprovement".=0D=0A> > It=0D=0A> > > could be the server if it knew that= is what you want. It could be=0D=0Athe=0D=0A> > > client if it knew what = the server could do. Just putting the time=0D=0A> > > parameter=0D=0A> > >= doesn't have a way to express anything other than the simplistic=0D=0A"wai= t=0D=0A> > 3=0D=0A> > > seconds" if anything can be done in those 3 seconds= =2E You might=0D=0Aget,=0D=0A> > say,=0D=0A> > > 30% improvement from .25 = sec to 3 sec. If that was the case, your=0D=0A> > > mechanism=0D=0A> > > w= ould wait 3 seconds. I would not want that to happen. I want=0D=0A> > som= eone to=0D=0A> > > judge when it's not worth waiting more for. That might = be 1=0D=0Asecond,=0D=0A> > or 2=0D=0A> > > seconds. Depends on the shape o= f the curve.=0D=0A> > >=0D=0A> > > Whatever parameters are decided upon, we= may need two=0D=0Adistinguished=0D=0A> > values=0D=0A> > > that are "use l= ocally mandated limits for emergency call routing"=0D=0Aand=0D=0A> > the=0D= =0A> > > same for dispatch. If we're stuck with ResponseTime alone:=0D=0A>= > >=0D=0A> > > In some jurisdictions, there are regulations which govern t= he time=0D=0A> > and/or=0D=0A> > > accuracy required for emergency calls. = When processing an=0D=0Aemergency=0D=0A> > call=0D=0A> > > location is used= in two circumstances: routing a call to the most=0D=0A> > > appropriate PS= AP, and later, dispatching responders to help the=0D=0A> > caller.=0D=0A> >= > Regulations may govern one or both of these circumstances and the=0D=0A>= > > regulation=0D=0A> > > may specify the accuracy without specifying time= , time without=0D=0A> > specifying=0D=0A> > > accuracy, or both time and ac= curacy. The protocol supports this=0D=0A> > > possibility. There are two = distinguished values for ResponseTime=0D=0A> > which=0D=0A> > > are=0D=0A> = > > used for emergency calls, where there is a locally mandated=0D=0A> > ti= me/accuracy=0D=0A> > > requirements for routing or dispatch. The two value= s are:=0D=0A> > >=0D=0A> > > * EmergencyCallRoute: Used to signal that the = locally required=0D=0Avalues=0D=0A> > for=0D=0A> > > emergency call routing= are needed. If there are no local=0D=0Amandates,=0D=0A> > and=0D=0A> > > = this=0D=0A> > > parameter is used, the server should assume <1KM uncertaint= y with=0D=0A95%=0D=0A> > > confidence in <250 ms unless the accuracy can be= substantially=0D=0A> > improved by=0D=0A> > > waiting as much as 3 seconds= =2E If the measurement mechanism can=0D=0Amake=0D=0A> > > substantial impr= ovement by waiting, the wait time should be judged=0D=0Aby=0D=0A> > the=0D=0A= > > > server to minimize the time the call is held while getting most of=0D= =0Athe=0D=0A> > > gain=0D=0A> > > in accuracy. If most of the improved unc= ertainty is achieved in 2=0D=0A> > > seconds,=0D=0A> > > do not wait the en= tire 3 seconds.=0D=0A> > >=0D=0A> > > * EmergencyCallDispatch: Used to sign= al that the locally required=0D=0A> > values=0D=0A> > > for=0D=0A> > > emer= gency call dispatch are needed. If there are no local=0D=0Amandates,=0D=0A= > > and=0D=0A> > > this parameter is used, the server should assume <100M u= ncertainty=0D=0A> > with=0D=0A> > > 95%=0D=0A> > > confidence in <30 sec.=0D= =0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > As HELD is a text language, perha= ps these strings can be used. If=0D=0Awe=0D=0A> > need=0D=0A> > > to assig= n integer values to them, then we'll pick something.=0D=0A> > >=0D=0A> > >=0D= =0A> > > > -----Original Message-----=0D=0A> > > > From: Dawson, Martin [ma= ilto:Martin.Dawson@andrew.com]=0D=0A> > > > Sent: Monday, September 10, 200= 7 10:26 AM=0D=0A> > > > To: Brian Rosen; Thomson, Martin; geopriv@ietf.org=0D= =0A> > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > >=0D=0A> = > > > You put three seconds in as the response time. If a more=0D=0Aaccurat= e=0D=0A> > > > location can be provided in 3 seconds, it will take that lon= g,=0D=0Aif=0D=0A> > not it=0D=0A> > > > will respond even faster.=0D=0A> > = > >=0D=0A> > > > What's more, if the next application running on the device= can=0D=0A> > actually=0D=0A> > > > wait 20 seconds, it can state "20 secon= ds" and may actually=0D=0A> > subsequently=0D=0A> > > > get a more accurate= location which may take anywhere from 3 to=0D=0A20=0D=0A> > > > seconds to= return.=0D=0A> > > >=0D=0A> > > > Simple.=0D=0A> > > >=0D=0A> > > > If you= really think that there is a need for a "please give me=0D=0A> > location=0D= =0A> > > > in the time mandated by the jurisdiction in which I am currently=0D= =0A> > > > operating" semantic then please send text. Nobody has suggested=0D= =0Athat=0D=0A> > is=0D=0A> > > > what response time satisfies - and you hav= e not proposed=0D=0Aanything=0D=0A> > that=0D=0A> > > > satisfies it either= =2E Such a mechanism is not mutually exclusive=0D=0Ato=0D=0A> > an=0D=0A> >= > > optional response time parameter.=0D=0A> > > >=0D=0A> > > > Cheers,=0D= =0A> > > > Martin=0D=0A> > > >=0D=0A> > > > -----Original Message-----=0D=0A= > > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > Sent: Mon= day, 10 September 2007 11:25 PM=0D=0A> > > > To: Thomson, Martin; geopriv@i= etf.org=0D=0A> > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >= >=0D=0A> > > > I was working in updates to phonebcp and framework and here= is=0D=0Athe=0D=0A> > spec=0D=0A> > > > I=0D=0A> > > > want to have:=0D=0A>= > > >=0D=0A> > > > ED-25/AN-14 It is RECOMMENDED that location determinati= on not=0D=0Atake=0D=0A> > > > longer=0D=0A> > > > than 250 ms to obtain rou= ting location and systems SHOULD be=0D=0A> > designed=0D=0A> > > > such=0D=0A= > > > > that the typical response is under 100ms. However, as much as 3=0D=0A= > > seconds=0D=0A> > > > to=0D=0A> > > > obtain routing location MAY be tol= erated if location accuracy=0D=0Acan be=0D=0A> > > > substantially improved= over what can be obtained in 250 ms.=0D=0A> > > >=0D=0A> > > > How would y= ou express that with your parameter=3F=0D=0A> > > >=0D=0A> > > > The equiva= lent for dispatch location is:=0D=0A> > > > Generally, the PSAP can wait fo= r an accurate location for=0D=0Adispatch.=0D=0A> > > > However, there is no= fixed time known in advance which is the=0D=0Alimit;=0D=0A> > it=0D=0A> > = > > depends on the nature of the emergency. At some point the PSAP=0D=0Amu= st=0D=0A> > > > dispatch. In a subscription environment, the PSAP could up= date=0D=0Athe=0D=0A> > > > parameters in the filter (immediate response req= uired). In a=0D=0AHELD=0D=0A> > > > dereference, there is no way to cancel= and the PSAP will have to=0D=0A> > choose=0D=0A> > > > a=0D=0A> > > > Resp= onseTime that it will wait for even if it wants to dispatch=0D=0A> > sooner=0D= =0A> > > > than=0D=0A> > > > that. =0D=0A> > > >=0D=0A> > > > We then get to a complication. It ma= y be the case in some=0D=0A> > jurisdictions=0D=0A> > > > that there are re= gulations that govern this. In those cases, we=0D=0Amay=0D=0A> > > > need = a=0D=0A> > > > way to say "I need the regulation-imposed values for emergen= cy=0D=0Acall=0D=0A> > > > route",=0D=0A> > > > or the equivalent for dispat= ch.=0D=0A> > > >=0D=0A> > > > Brian=0D=0A> > > >=0D=0A> > > > > -----Origin= al Message-----=0D=0A> > > > > From: Thomson, Martin [mailto:Martin.Thomson= @andrew.com]=0D=0A> > > > > Sent: Monday, September 10, 2007 3:22 AM=0D=0A>= > > > > To: geopriv@ietf.org=0D=0A> > > > > Subject: [Geopriv] responseTim= e reprise=0D=0A> > > > >=0D=0A> > > > > I'm probably due to step into the r= ing on this topic. I=0D=0Aapologise=0D=0A> > for=0D=0A> > > > > anything t= hat is rehashed, I have not read the _entire_=0D=0Aarchive on=0D=0A> > > > = this=0D=0A> > > > > topic.=0D=0A> > > > >=0D=0A> > > > > The main reason th= e responseTime parameter was proposed was=0D=0Aour=0D=0A> > > > collective=0D= =0A> > > > > experience with cellular systems.=0D=0A> > > > >=0D=0A> > > > = > 3GPP have defined two values: "low delay" and "delay=0D=0Atolerant",=0D=0A= > > which=0D=0A> > > > > roughly correspond to what some have been advocati= ng.=0D=0AHowever,=0D=0A> > where=0D=0A> > > > > multiple network nodes are = involved in serving a request (and=0D=0A3GPP=0D=0A> > > > relies=0D=0A> > >= > > on about 6), engineering is required to ensure smooth=0D=0Aoperation.=0D= =0A> > Each=0D=0A> > > > > node is configured with a different timeout so t= hat the time=0D=0Athat=0D=0A> > the=0D=0A> > > > node=0D=0A> > > > > adds t= o the transaction doesn't cause failures. This=0D=0Aengineering=0D=0A> > >= > ensures=0D=0A> > > > > that each location client receives a certain leve= l of service.=0D=0A> > > > >=0D=0A> > > > > Of course, each network is engi= neered differently. Everyone=0D=0Ahas a=0D=0A> > > > > different idea of w= hat "low delay" and "delay tolerant" mean.=0D=0AIn=0D=0A> > a=0D=0A> > > > = closed=0D=0A> > > > > network this more or less works; although this isn't = assured=0D=0Afor=0D=0A> > > > roamers.=0D=0A> > > > > We wanted to avoid th= is problem. It makes sense to allow=0D=0Adevolve=0D=0A> > the=0D=0A> > > >= > parameter; rather than place an arbitrary value on some=0D=0Aabstract=0D= =0A> > > > codes,=0D=0A> > > > > allow the client to decide.=0D=0A> > > > >=0D= =0A> > > > > To add to this, during my break, we had a request for further=0D= =0A> > control=0D=0A> > > > over=0D=0A> > > > > these values on one of our = cellular products. In this=0D=0Arequest,=0D=0A> > > > different=0D=0A> > >= > > types of clients would be given varying amounts of time.=0D=0AThus,=0D= =0A> > from=0D=0A> > > > our=0D=0A> > > > > perspective, we have a clear re= quirement for responseTime.=0D=0A> > > > >=0D=0A> > > > > To those who want= hard limits; BCP documents are a good place=0D=0Afor=0D=0A> > > > > recomm= endations. You can add nice statements like: "if=0D=0Arouting=0D=0A> > for=0D= =0A> > > > > emergency calls, set responseTime to x seconds; if you don't=0D= =0Acare,=0D=0A> > > > allow y=0D=0A> > > > > seconds".=0D=0A> > > > >=0D=0A= > > > > > Ta,=0D=0A> > > > > Martin=0D=0A> > > > >=0D=0A> > > >=0D=0A> >=0D= =0A------------------------------------------------------------------------=0D= =0A> > > > --=0D=0A> > > > > ----------------------=0D=0A> > > > > This mes= sage is for the designated recipient only and may=0D=0A> > > > > contain pr= ivileged, proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > > > = > If you have received it in error, please notify the sender=0D=0A> > > > >= immediately and delete the original. Any unauthorized use of=0D=0A> > > >= > this email is prohibited.=0D=0A> > > > >=0D=0A> > > >=0D=0A> >=0D=0A----= --------------------------------------------------------------------=0D=0A>= > > > --=0D=0A> > > > > ----------------------=0D=0A> > > > > [mf2]=0D=0A>= > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > _____________________________= __________________=0D=0A> > > > Geopriv mailing list=0D=0A> > > > Geopriv@i= etf.org=0D=0A> > > > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A> = > > >=0D=0A> > > >=0D=0A> >=0D=0A------------------------------------------= ------------------------------=0D=0A> > > --=0D=0A> > > > -----------------= -----=0D=0A> > > > This message is for the designated recipient only and ma= y=0D=0A> > > > contain privileged, proprietary, or otherwise private=0D=0Ai= nformation.=0D=0A> > > > If you have received it in error, please notify th= e sender=0D=0A> > > > immediately and delete the original. Any unauthorize= d use of=0D=0A> > > > this email is prohibited.=0D=0A> > > >=0D=0A> >=0D=0A= ------------------------------------------------------------------------=0D= =0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > [mf2]=0D=0A> >= >=0D=0A> > >=0D=0A> > >=0D=0A> > > _______________________________________= ________=0D=0A> > > Geopriv mailing list=0D=0A> > > Geopriv@ietf.org=0D=0A>= > > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A> >=0D=0A> >=0D=0A= ------------------------------------------------------------------------=0D= =0A> --=0D=0A> > ----------------------=0D=0A> > This message is for the de= signated recipient only and may=0D=0A> > contain privileged, proprietary, o= r otherwise private information.=0D=0A> > If you have received it in error,= please notify the sender=0D=0A> > immediately and delete the original. An= y unauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A----= --------------------------------------------------------------------=0D=0A>= --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A---= ---------------------------------------------------------------------------= ------------------=0D=0AThis message is for the designated recipient only a= nd may=0D=0Acontain privileged, proprietary, or otherwise private informati= on. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 18:19:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUrZP-0006oM-Ts; Mon, 10 Sep 2007 18:17:27 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUrZO-0006o8-OG for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 18:17:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUrZO-0006np-EA for geopriv@ietf.org; Mon, 10 Sep 2007 18:17:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUrZN-0006el-2C for geopriv@ietf.org; Mon, 10 Sep 2007 18:17:26 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUrZ9-0003iT-7T; Mon, 10 Sep 2007 17:17:11 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Dawson, Martin'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 18:17:21 -0400 Message-ID: <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSw In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The proposed text was in the message. Here it is again: In some jurisdictions, there are regulations which govern the time and/or accuracy required for emergency calls. When processing an emergency call location is used in two circumstances: routing a call to the most appropriate PSAP, and later, dispatching responders to help the caller. Regulations may govern one or both of these circumstances and the regulation may specify the accuracy without specifying time, time without specifying accuracy, or both time and accuracy. The protocol supports this possibility. There are two distinguished values for ResponseTime which are used for emergency calls, where there is a locally mandated time/accuracy requirements for routing or dispatch. The two values are: * EmergencyCallRoute: Used to signal that the locally required values for emergency call routing are needed. If there are no local mandates, and this parameter is used, the server should assume <1KM uncertainty with 95% confidence in <250 ms unless the accuracy can be substantially improved by waiting as much as 3 seconds. If the measurement mechanism can make substantial improvement by waiting, the wait time should be judged by the server to minimize the time the call is held while getting most of the gain in accuracy. If most of the improved uncertainty is achieved in 2 seconds, do not wait the entire 3 seconds. * EmergencyCallDispatch: Used to signal that the locally required values for emergency call dispatch are needed. If there are no local mandates, and this parameter is used, the server should assume <100M uncertainty with 95% confidence in <30 sec. It would apply to civic as well as geo, although I don't think any LIS that reports civic has any response time (unless it converts and it should not convert). If the LIS can't meet the regulation, it returns the best it can. You can request a civic and a geo in the same message. I don't want to say that you could not have an implementation which could give you an accurate civic and an accurate geo by two different mechanisms and thus the request might make sense. I think that will be rare. As long as you don't convert, I'm okay with asking for both. If you do that, and the implementation can do both, then you get both. I'm not sure what interactions are issues. It's really just a distinguished value for ResponseTime (and/or accuracy if we go with Doug's proposal, which I like better than just time). Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, September 10, 2007 5:47 PM > To: Brian Rosen; Dawson, Martin; Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > Brian, > > I think that the first part is actually totally achievable with the > responseTime parameter, and you can certainly check the stats later. > This further stresses my point that applications almost always know > whether the accuracy is good enough to do something with. But I think > what I am hearing from you is that you see a need for a service > indicator to the LIS saying, I need this for emergency purposes please. > > Perhaps I missed what your proposed text was then, the only solutions I > recall seeing were ones that required network URI profiling ahead of > time and I know that that can't be done. So would you please repeat your > proposal? > > On the last point, the legislation might not provide a time constraint, > but we all know that there is one. If it were to take an hour or even 5 > minutes to get a location that that would be totally unacceptable in > this use case. I have described mobile concierge applications that only > have a time constraint and not really an accuracy one, because they can > work with either geodetic or civic locations. > > I am not discounting the use case you propose, I just don't believe that > any proposed solution I have describes how: > > 1) It can apply to civic and geo location information > 2) If I can't meet it, what is the semantic > 3) If I request a civic and geo in the same location request, which > takes precedence, time or accuracy and why? > 4) How it interacts with other attributes that are already agreed upon > > Basically any proposed solution needs to address at least all of those > and in an unambiguous way, otherwise I don't see it as doing much more > than throwing a spanner(wrench) in the works. > > Cheers > James > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 11 September 2007 7:20 AM > > To: Winterbottom, James; Dawson, Martin; Thomson, Martin; > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > James > > > > In the past, I thought a generalized "roughly now, whatever accuracy > you > > can > > give me" and "roughly as accurate as you can get, in a reasonable, but > > longish time frame" was acceptable. It was pointed out to me that > where > > there is actual regulation, what I asked for may not be one of the > above. > > To my knowledge, there are no other uses where there is, or might be, > > regulation. So, I'm proposing that there be something that alerts the > LIS > > that the request is one of those that have to conform to such > regulation > > if > > there is any. > > > > I think what happens when the network cannot deliver what the > regulation > > says is that they get some answer. The authorities also get some > > statistics > > that shows them whether the regulation is being met within the > confidence > > requirement. After all, confidence is never 100%. Addressing what > they > > do > > about it when the result doesn't meet the regulation is beyond scope > no > > matter how you define it. > > > > I thought I made a pretty reasonable proposal, with text, as asked. I > > think > > I have provided a pretty decent motivation. I fail to see why this > should > > be an extension, since this is one of (not the only) driving use > cases. > > You > > can assail me for not recognizing sooner that there may have to be > > something > > that gets a predefined accuracy/time trade-off for the emergency case, > but > > I > > think that, having recognized it, defined it, made a specific text > > proposal, > > and defended it, that perhaps you need to show me where I am wrong. > > > > In North America, at present, there is an accuracy requirement for > > emergency > > dispatch on mobile handsets. For handset driven systems like GPS, > it's > > <100m 95% of the time. That may or may not conform to some LIS' > notion of > > AGAP. On the other hand, if you tell it that you need dispatch > location > > for > > an emergency call, and it's in the U.S., it knows EXACTLY what it > needs to > > do. There is no setting of a generalized ResponseTime with or without > > AGAP/ASAP which would indicate <100M with 95% confidence. You will > note > > that the regulation states accuracy without stating response time. > > > > Brian > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Monday, September 10, 2007 4:34 PM > > > To: Brian Rosen; Dawson, Martin; Thomson, Martin; geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > Brian, > > > > > > As has been pointed out more times than I can count now. > > > The shape of the curve CANNOT be quantified ahead of time. > > > > > > You state below "In some jurisdictions, there are regulations which > > > govern the time and/or accuracy required for emergency calls." > > > Can you explain what happens if the accuracy cannot be met in any > place, > > > does the PSAP get no location at all? I am prepared to bet you a > beer at > > > the next IETF that they get something, and that it is the probably > the > > > best location that the network can provide before the ALI > transaction > > > times out. > > > > > > Until recently you said that you only had two requirement AGAP and > ASAP, > > > responseTime will give you that, and it will give us what we want. > > > Win-win, and 'best-basis'. > > > > > > If you want something more than repsonseTime, as you indicate below, > > > then that can be an extension and I challenge you to write a draft > that > > > can do this. > > > > > > Cheers > > > James > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, 11 September 2007 1:10 AM > > > > To: Dawson, Martin; Thomson, Martin; geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > I don't think so. Someone needs to judge "substantial > improvement". > > > It > > > > could be the server if it knew that is what you want. It could be > the > > > > client if it knew what the server could do. Just putting the time > > > > parameter > > > > doesn't have a way to express anything other than the simplistic > "wait > > > 3 > > > > seconds" if anything can be done in those 3 seconds. You might > get, > > > say, > > > > 30% improvement from .25 sec to 3 sec. If that was the case, your > > > > mechanism > > > > would wait 3 seconds. I would not want that to happen. I want > > > someone to > > > > judge when it's not worth waiting more for. That might be 1 > second, > > > or 2 > > > > seconds. Depends on the shape of the curve. > > > > > > > > Whatever parameters are decided upon, we may need two > distinguished > > > values > > > > that are "use locally mandated limits for emergency call routing" > and > > > the > > > > same for dispatch. If we're stuck with ResponseTime alone: > > > > > > > > In some jurisdictions, there are regulations which govern the time > > > and/or > > > > accuracy required for emergency calls. When processing an > emergency > > > call > > > > location is used in two circumstances: routing a call to the most > > > > appropriate PSAP, and later, dispatching responders to help the > > > caller. > > > > Regulations may govern one or both of these circumstances and the > > > > regulation > > > > may specify the accuracy without specifying time, time without > > > specifying > > > > accuracy, or both time and accuracy. The protocol supports this > > > > possibility. There are two distinguished values for ResponseTime > > > which > > > > are > > > > used for emergency calls, where there is a locally mandated > > > time/accuracy > > > > requirements for routing or dispatch. The two values are: > > > > > > > > * EmergencyCallRoute: Used to signal that the locally required > values > > > for > > > > emergency call routing are needed. If there are no local > mandates, > > > and > > > > this > > > > parameter is used, the server should assume <1KM uncertainty with > 95% > > > > confidence in <250 ms unless the accuracy can be substantially > > > improved by > > > > waiting as much as 3 seconds. If the measurement mechanism can > make > > > > substantial improvement by waiting, the wait time should be judged > by > > > the > > > > server to minimize the time the call is held while getting most of > the > > > > gain > > > > in accuracy. If most of the improved uncertainty is achieved in 2 > > > > seconds, > > > > do not wait the entire 3 seconds. > > > > > > > > * EmergencyCallDispatch: Used to signal that the locally required > > > values > > > > for > > > > emergency call dispatch are needed. If there are no local > mandates, > > > and > > > > this parameter is used, the server should assume <100M uncertainty > > > with > > > > 95% > > > > confidence in <30 sec. > > > > > > > > > > > > > > > > As HELD is a text language, perhaps these strings can be used. If > we > > > need > > > > to assign integer values to them, then we'll pick something. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > Sent: Monday, September 10, 2007 10:26 AM > > > > > To: Brian Rosen; Thomson, Martin; geopriv@ietf.org > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > You put three seconds in as the response time. If a more > accurate > > > > > location can be provided in 3 seconds, it will take that long, > if > > > not it > > > > > will respond even faster. > > > > > > > > > > What's more, if the next application running on the device can > > > actually > > > > > wait 20 seconds, it can state "20 seconds" and may actually > > > subsequently > > > > > get a more accurate location which may take anywhere from 3 to > 20 > > > > > seconds to return. > > > > > > > > > > Simple. > > > > > > > > > > If you really think that there is a need for a "please give me > > > location > > > > > in the time mandated by the jurisdiction in which I am currently > > > > > operating" semantic then please send text. Nobody has suggested > that > > > is > > > > > what response time satisfies - and you have not proposed > anything > > > that > > > > > satisfies it either. Such a mechanism is not mutually exclusive > to > > > an > > > > > optional response time parameter. > > > > > > > > > > Cheers, > > > > > Martin > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Monday, 10 September 2007 11:25 PM > > > > > To: Thomson, Martin; geopriv@ietf.org > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > I was working in updates to phonebcp and framework and here is > the > > > spec > > > > > I > > > > > want to have: > > > > > > > > > > ED-25/AN-14 It is RECOMMENDED that location determination not > take > > > > > longer > > > > > than 250 ms to obtain routing location and systems SHOULD be > > > designed > > > > > such > > > > > that the typical response is under 100ms. However, as much as 3 > > > seconds > > > > > to > > > > > obtain routing location MAY be tolerated if location accuracy > can be > > > > > substantially improved over what can be obtained in 250 ms. > > > > > > > > > > How would you express that with your parameter? > > > > > > > > > > The equivalent for dispatch location is: > > > > > Generally, the PSAP can wait for an accurate location for > dispatch. > > > > > However, there is no fixed time known in advance which is the > limit; > > > it > > > > > depends on the nature of the emergency. At some point the PSAP > must > > > > > dispatch. In a subscription environment, the PSAP could update > the > > > > > parameters in the filter (immediate response required). In a > HELD > > > > > dereference, there is no way to cancel and the PSAP will have to > > > choose > > > > > a > > > > > ResponseTime that it will wait for even if it wants to dispatch > > > sooner > > > > > than > > > > > that. > > > > > > > > > > We then get to a complication. It may be the case in some > > > jurisdictions > > > > > that there are regulations that govern this. In those cases, we > may > > > > > need a > > > > > way to say "I need the regulation-imposed values for emergency > call > > > > > route", > > > > > or the equivalent for dispatch. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > > > > Sent: Monday, September 10, 2007 3:22 AM > > > > > > To: geopriv@ietf.org > > > > > > Subject: [Geopriv] responseTime reprise > > > > > > > > > > > > I'm probably due to step into the ring on this topic. I > apologise > > > for > > > > > > anything that is rehashed, I have not read the _entire_ > archive on > > > > > this > > > > > > topic. > > > > > > > > > > > > The main reason the responseTime parameter was proposed was > our > > > > > collective > > > > > > experience with cellular systems. > > > > > > > > > > > > 3GPP have defined two values: "low delay" and "delay > tolerant", > > > which > > > > > > roughly correspond to what some have been advocating. > However, > > > where > > > > > > multiple network nodes are involved in serving a request (and > 3GPP > > > > > relies > > > > > > on about 6), engineering is required to ensure smooth > operation. > > > Each > > > > > > node is configured with a different timeout so that the time > that > > > the > > > > > node > > > > > > adds to the transaction doesn't cause failures. This > engineering > > > > > ensures > > > > > > that each location client receives a certain level of service. > > > > > > > > > > > > Of course, each network is engineered differently. Everyone > has a > > > > > > different idea of what "low delay" and "delay tolerant" mean. > In > > > a > > > > > closed > > > > > > network this more or less works; although this isn't assured > for > > > > > roamers. > > > > > > We wanted to avoid this problem. It makes sense to allow > devolve > > > the > > > > > > parameter; rather than place an arbitrary value on some > abstract > > > > > codes, > > > > > > allow the client to decide. > > > > > > > > > > > > To add to this, during my break, we had a request for further > > > control > > > > > over > > > > > > these values on one of our cellular products. In this > request, > > > > > different > > > > > > types of clients would be given varying amounts of time. > Thus, > > > from > > > > > our > > > > > > perspective, we have a clear requirement for responseTime. > > > > > > > > > > > > To those who want hard limits; BCP documents are a good place > for > > > > > > recommendations. You can add nice statements like: "if > routing > > > for > > > > > > emergency calls, set responseTime to x seconds; if you don't > care, > > > > > allow y > > > > > > seconds". > > > > > > > > > > > > Ta, > > > > > > Martin > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > -- > > > > > > ---------------------- > > > > > > This message is for the designated recipient only and may > > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > > If you have received it in error, please notify the sender > > > > > > immediately and delete the original. Any unauthorized use of > > > > > > this email is prohibited. > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > -- > > > > > > ---------------------- > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 18:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUroA-0002Ry-Vp; Mon, 10 Sep 2007 18:32:42 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUro9-0002Rr-5v for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 18:32:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUro8-0002Rj-PQ for geopriv@ietf.org; Mon, 10 Sep 2007 18:32:40 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUro7-0007kl-4f for geopriv@ietf.org; Mon, 10 Sep 2007 18:32:40 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_17_41_55 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 17:41:55 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 17:32:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 17:32:30 -0500 Message-ID: In-Reply-To: <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAAqTLMA== References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Winterbottom, James" , "Thomson, Martin" , X-OriginalArrivalTime: 10 Sep 2007 22:32:33.0578 (UTC) FILETIME=[7B1648A0:01C7F3FA] X-Spam-Score: 1.8 (+) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Brian,=0D=0A=0D=0AI think what you have actually done is taken the first st= ep to=0D=0Aacknowledging that different applications have different time=0D= =0Arequirements. What your proposal does, is provide an *application=0D=0As= pecific* flag that then translates to a specific hard-coded response=0D=0At= ime (best fit) for an emergency application. You now need to take the=0D=0A= next step and recognize that you've just covered one possible=0D=0Aapplicat= ion - and you've chosen one that the LIS may be in the best=0D=0Aplace to a= scribe the response time for. Now you need to recognize that=0D=0Athere are= applications that the client wants to ascribe the response=0D=0Atimes for.=0D= =0A=0D=0A" To my knowledge, there are no other uses where there is, or migh= t be,=0D=0Aregulation." - this I find to be a strange statement. It seems t= o=0D=0Asuggest that response time is only relevant if there's a regulatory=0D= =0Aimperative to have it. Friend finders, fleet and asset tracking,=0D=0Apr= esence registration, hot desk location registration, navigation,=0D=0Alocat= ion concierge,... all these applications can and do have their own=0D=0Aopt= imal response times.=0D=0A=0D=0ANow - I'm happy to support your suggestion = of what is effectively an=0D=0A"emergency request" indicator flag in the ba= se request semantics. Let=0D=0Athe LIS apply local policy as to what is the= standard response time for=0D=0Athat request in that jurisdiction - good i= dea. As I think you note, you=0D=0Amay want "emergency route", and "emergen= cy dispatch" flags. Frankly, I=0D=0Athink the emergency dispatch request is= likely to originate from the=0D=0APSAP and it will know what response time= applies and could just use the=0D=0Aresponse time parameter; then PSAPs co= uld apply their own requirements=0D=0Aand not assume a one size fits all by= jurisdiction. This flag can=0D=0Aco-exist with the response time parameter= so there's no reason to block=0D=0Aeither on the basis of the other in the= spec unless you just want to be=0D=0Adifficult.=0D=0A=0D=0AI don't think y= ou've provided any useful text on a "LIS profiling" set=0D=0Aof semantics. = It is going to have to be quite involved - including the=0D=0Asecond phase = aspect of how the client identifies which of the profile=0D=0Apoints it wan= ts to invoke as the actual request. I certainly haven't=0D=0Aseen a compreh= ensive and coherent proposal for this. Since I neither=0D=0Afeel the need f= or the mechanism, nor see any practical way to implement=0D=0Ait given the = state of the art, I have no inclination to spend time=0D=0Adeveloping that = proposal. That ball is in your court. Hopefully we can=0D=0Aboth agree that= it can comfortably live in extension land. BTW - any LIS=0D=0Athat decided= to take an order of magnitude longer for a location=0D=0Atechnology that g= enerally only provided a miniscule or generally=0D=0Anegligible improvement= in accuracy would be a poor LIS. Your point is=0D=0Avalid in theory; your = profiling technology addresses it in theory. I=0D=0Adon't think that either= have any practical basis.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----O= riginal Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D= =0ASent: Tuesday, 11 September 2007 7:20 AM=0D=0ATo: Winterbottom, James; D= awson, Martin; Thomson, Martin;=0D=0Ageopriv@ietf.org=0D=0ASubject: RE: [Ge= opriv] responseTime reprise=0D=0A=0D=0AJames=0D=0A=0D=0AIn the past, I thou= ght a generalized "roughly now, whatever accuracy you=0D=0Acan=0D=0Agive me= " and "roughly as accurate as you can get, in a reasonable, but=0D=0Alongis= h time frame" was acceptable. It was pointed out to me that where=0D=0Athe= re is actual regulation, what I asked for may not be one of the=0D=0Aabove.=0D= =0ATo my knowledge, there are no other uses where there is, or might be,=0D= =0Aregulation. So, I'm proposing that there be something that alerts the=0D= =0ALIS=0D=0Athat the request is one of those that have to conform to such r= egulation=0D=0Aif=0D=0Athere is any.=0D=0A=0D=0AI think what happens when t= he network cannot deliver what the regulation=0D=0Asays is that they get so= me answer. The authorities also get some=0D=0Astatistics=0D=0Athat shows th= em whether the regulation is being met within the=0D=0Aconfidence=0D=0Arequ= irement. After all, confidence is never 100%. Addressing what they=0D=0Ad= o=0D=0Aabout it when the result doesn't meet the regulation is beyond scope= no=0D=0Amatter how you define it.=0D=0A=0D=0AI thought I made a pretty rea= sonable proposal, with text, as asked. I=0D=0Athink=0D=0AI have provided a= pretty decent motivation. I fail to see why this=0D=0Ashould=0D=0Abe an e= xtension, since this is one of (not the only) driving use cases.=0D=0AYou=0D= =0Acan assail me for not recognizing sooner that there may have to be=0D=0A= something=0D=0Athat gets a predefined accuracy/time trade-off for the emerg= ency case,=0D=0Abut I=0D=0Athink that, having recognized it, defined it, ma= de a specific text=0D=0Aproposal,=0D=0Aand defended it, that perhaps you ne= ed to show me where I am wrong.=0D=0A=0D=0AIn North America, at present, th= ere is an accuracy requirement for=0D=0Aemergency=0D=0Adispatch on mobile h= andsets. For handset driven systems like GPS, it's=0D=0A<100m 95% of the t= ime. That may or may not conform to some LIS' notion=0D=0Aof=0D=0AAGAP. O= n the other hand, if you tell it that you need dispatch location=0D=0Afor=0D= =0Aan emergency call, and it's in the U.S., it knows EXACTLY what it needs=0D= =0Ato=0D=0Ado. There is no setting of a generalized ResponseTime with or w= ithout=0D=0AAGAP/ASAP which would indicate <100M with 95% confidence. You = will note=0D=0Athat the regulation states accuracy without stating response= time. =20=0D=0A=0D=0ABrian=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A= > Sent: Monday, September 10, 2007 4:34 PM=0D=0A> To: Brian Rosen; Dawson, = Martin; Thomson, Martin; geopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] res= ponseTime reprise=0D=0A>=20=0D=0A> Brian,=0D=0A>=20=0D=0A> As has been poin= ted out more times than I can count now.=0D=0A> The shape of the curve CANN= OT be quantified ahead of time.=0D=0A>=20=0D=0A> You state below "In some j= urisdictions, there are regulations which=0D=0A> govern the time and/or acc= uracy required for emergency calls."=0D=0A> Can you explain what happens if= the accuracy cannot be met in any=0D=0Aplace,=0D=0A> does the PSAP get no = location at all=3F I am prepared to bet you a beer=0D=0Aat=0D=0A> the next = IETF that they get something, and that it is the probably the=0D=0A> best l= ocation that the network can provide before the ALI transaction=0D=0A> time= s out.=0D=0A>=20=0D=0A> Until recently you said that you only had two requi= rement AGAP and=0D=0AASAP,=0D=0A> responseTime will give you that, and it w= ill give us what we want.=0D=0A> Win-win, and 'best-basis'.=0D=0A>=20=0D=0A= > If you want something more than repsonseTime, as you indicate below,=0D=0A= > then that can be an extension and I challenge you to write a draft=0D=0At= hat=0D=0A> can do this.=0D=0A>=20=0D=0A> Cheers=0D=0A> James=0D=0A>=20=0D=0A= > > -----Original Message-----=0D=0A> > From: Brian Rosen [mailto:br@brianr= osen.net]=0D=0A> > Sent: Tuesday, 11 September 2007 1:10 AM=0D=0A> > To: Da= wson, Martin; Thomson, Martin; geopriv@ietf.org=0D=0A> > Subject: RE: [Geop= riv] responseTime reprise=0D=0A> >=0D=0A> > I don't think so. Someone need= s to judge "substantial improvement".=0D=0A> It=0D=0A> > could be the serve= r if it knew that is what you want. It could be=0D=0Athe=0D=0A> > client i= f it knew what the server could do. Just putting the time=0D=0A> > paramet= er=0D=0A> > doesn't have a way to express anything other than the simplisti= c=0D=0A"wait=0D=0A> 3=0D=0A> > seconds" if anything can be done in those 3 = seconds. You might get,=0D=0A> say,=0D=0A> > 30% improvement from .25 sec = to 3 sec. If that was the case, your=0D=0A> > mechanism=0D=0A> > would wai= t 3 seconds. I would not want that to happen. I want=0D=0A> someone to=0D= =0A> > judge when it's not worth waiting more for. That might be 1 second,=0D= =0A> or 2=0D=0A> > seconds. Depends on the shape of the curve.=0D=0A> >=0D= =0A> > Whatever parameters are decided upon, we may need two distinguished=0D= =0A> values=0D=0A> > that are "use locally mandated limits for emergency ca= ll routing"=0D=0Aand=0D=0A> the=0D=0A> > same for dispatch. If we're stuck= with ResponseTime alone:=0D=0A> >=0D=0A> > In some jurisdictions, there ar= e regulations which govern the time=0D=0A> and/or=0D=0A> > accuracy require= d for emergency calls. When processing an emergency=0D=0A> call=0D=0A> > l= ocation is used in two circumstances: routing a call to the most=0D=0A> > a= ppropriate PSAP, and later, dispatching responders to help the=0D=0A> calle= r.=0D=0A> > Regulations may govern one or both of these circumstances and t= he=0D=0A> > regulation=0D=0A> > may specify the accuracy without specifying= time, time without=0D=0A> specifying=0D=0A> > accuracy, or both time and a= ccuracy. The protocol supports this=0D=0A> > possibility. There are two d= istinguished values for ResponseTime=0D=0A> which=0D=0A> > are=0D=0A> > use= d for emergency calls, where there is a locally mandated=0D=0A> time/accura= cy=0D=0A> > requirements for routing or dispatch. The two values are:=0D=0A= > >=0D=0A> > * EmergencyCallRoute: Used to signal that the locally required=0D= =0Avalues=0D=0A> for=0D=0A> > emergency call routing are needed. If there = are no local mandates,=0D=0A> and=0D=0A> > this=0D=0A> > parameter is used,= the server should assume <1KM uncertainty with=0D=0A95%=0D=0A> > confidenc= e in <250 ms unless the accuracy can be substantially=0D=0A> improved by=0D= =0A> > waiting as much as 3 seconds. If the measurement mechanism can make=0D= =0A> > substantial improvement by waiting, the wait time should be judged=0D= =0Aby=0D=0A> the=0D=0A> > server to minimize the time the call is held whil= e getting most of=0D=0Athe=0D=0A> > gain=0D=0A> > in accuracy. If most of = the improved uncertainty is achieved in 2=0D=0A> > seconds,=0D=0A> > do not= wait the entire 3 seconds.=0D=0A> >=0D=0A> > * EmergencyCallDispatch: Used= to signal that the locally required=0D=0A> values=0D=0A> > for=0D=0A> > em= ergency call dispatch are needed. If there are no local mandates,=0D=0A> a= nd=0D=0A> > this parameter is used, the server should assume <100M uncertai= nty=0D=0A> with=0D=0A> > 95%=0D=0A> > confidence in <30 sec.=0D=0A> >=0D=0A= > >=0D=0A> >=0D=0A> > As HELD is a text language, perhaps these strings can= be used. If=0D=0Awe=0D=0A> need=0D=0A> > to assign integer values to them= , then we'll pick something.=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Mes= sage-----=0D=0A> > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D= =0A> > > Sent: Monday, September 10, 2007 10:26 AM=0D=0A> > > To: Brian Ros= en; Thomson, Martin; geopriv@ietf.org=0D=0A> > > Subject: RE: [Geopriv] res= ponseTime reprise=0D=0A> > >=0D=0A> > > You put three seconds in as the res= ponse time. If a more accurate=0D=0A> > > location can be provided in 3 sec= onds, it will take that long, if=0D=0A> not it=0D=0A> > > will respond even= faster.=0D=0A> > >=0D=0A> > > What's more, if the next application running= on the device can=0D=0A> actually=0D=0A> > > wait 20 seconds, it can state= "20 seconds" and may actually=0D=0A> subsequently=0D=0A> > > get a more ac= curate location which may take anywhere from 3 to 20=0D=0A> > > seconds to = return.=0D=0A> > >=0D=0A> > > Simple.=0D=0A> > >=0D=0A> > > If you really t= hink that there is a need for a "please give me=0D=0A> location=0D=0A> > > = in the time mandated by the jurisdiction in which I am currently=0D=0A> > >= operating" semantic then please send text. Nobody has suggested=0D=0Athat=0D= =0A> is=0D=0A> > > what response time satisfies - and you have not proposed= anything=0D=0A> that=0D=0A> > > satisfies it either. Such a mechanism is n= ot mutually exclusive to=0D=0A> an=0D=0A> > > optional response time parame= ter.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> > > Martin=0D=0A> > >=0D=0A> > > = -----Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianros= en.net]=0D=0A> > > Sent: Monday, 10 September 2007 11:25 PM=0D=0A> > > To: = Thomson, Martin; geopriv@ietf.org=0D=0A> > > Subject: RE: [Geopriv] respons= eTime reprise=0D=0A> > >=0D=0A> > > I was working in updates to phonebcp an= d framework and here is the=0D=0A> spec=0D=0A> > > I=0D=0A> > > want to hav= e:=0D=0A> > >=0D=0A> > > ED-25/AN-14 It is RECOMMENDED that location determ= ination not take=0D=0A> > > longer=0D=0A> > > than 250 ms to obtain routing= location and systems SHOULD be=0D=0A> designed=0D=0A> > > such=0D=0A> > > = that the typical response is under 100ms. However, as much as 3=0D=0A> seco= nds=0D=0A> > > to=0D=0A> > > obtain routing location MAY be tolerated if lo= cation accuracy can=0D=0Abe=0D=0A> > > substantially improved over what can= be obtained in 250 ms.=0D=0A> > >=0D=0A> > > How would you express that wi= th your parameter=3F=0D=0A> > >=0D=0A> > > The equivalent for dispatch loca= tion is:=0D=0A> > > Generally, the PSAP can wait for an accurate location f= or=0D=0Adispatch.=0D=0A> > > However, there is no fixed time known in advan= ce which is the=0D=0Alimit;=0D=0A> it=0D=0A> > > depends on the nature of t= he emergency. At some point the PSAP=0D=0Amust=0D=0A> > > dispatch. In a = subscription environment, the PSAP could update=0D=0Athe=0D=0A> > > paramet= ers in the filter (immediate response required). In a HELD=0D=0A> > > dere= ference, there is no way to cancel and the PSAP will have to=0D=0A> choose=0D= =0A> > > a=0D=0A> > > ResponseTime that it will wait for even if it wants t= o dispatch=0D=0A> sooner=0D=0A> > > than=0D=0A> > > that. =0D=0A> > >=0D=0A> > > We then get to a c= omplication. It may be the case in some=0D=0A> jurisdictions=0D=0A> > > th= at there are regulations that govern this. In those cases, we=0D=0Amay=0D=0A= > > > need a=0D=0A> > > way to say "I need the regulation-imposed values fo= r emergency=0D=0Acall=0D=0A> > > route",=0D=0A> > > or the equivalent for d= ispatch.=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Original = Message-----=0D=0A> > > > From: Thomson, Martin [mailto:Martin.Thomson@andr= ew.com]=0D=0A> > > > Sent: Monday, September 10, 2007 3:22 AM=0D=0A> > > > = To: geopriv@ietf.org=0D=0A> > > > Subject: [Geopriv] responseTime reprise=0D= =0A> > > >=0D=0A> > > > I'm probably due to step into the ring on this topi= c. I=0D=0Aapologise=0D=0A> for=0D=0A> > > > anything that is rehashed, I h= ave not read the _entire_ archive=0D=0Aon=0D=0A> > > this=0D=0A> > > > topi= c.=0D=0A> > > >=0D=0A> > > > The main reason the responseTime parameter was= proposed was our=0D=0A> > > collective=0D=0A> > > > experience with cellul= ar systems.=0D=0A> > > >=0D=0A> > > > 3GPP have defined two values: "low de= lay" and "delay tolerant",=0D=0A> which=0D=0A> > > > roughly correspond to = what some have been advocating. However,=0D=0A> where=0D=0A> > > > multipl= e network nodes are involved in serving a request (and=0D=0A3GPP=0D=0A> > >= relies=0D=0A> > > > on about 6), engineering is required to ensure smooth = operation.=0D=0A> Each=0D=0A> > > > node is configured with a different tim= eout so that the time=0D=0Athat=0D=0A> the=0D=0A> > > node=0D=0A> > > > add= s to the transaction doesn't cause failures. This=0D=0Aengineering=0D=0A> = > > ensures=0D=0A> > > > that each location client receives a certain level= of service.=0D=0A> > > >=0D=0A> > > > Of course, each network is engineere= d differently. Everyone has=0D=0Aa=0D=0A> > > > different idea of what "lo= w delay" and "delay tolerant" mean.=0D=0AIn=0D=0A> a=0D=0A> > > closed=0D=0A= > > > > network this more or less works; although this isn't assured for=0D= =0A> > > roamers.=0D=0A> > > > We wanted to avoid this problem. It makes s= ense to allow=0D=0Adevolve=0D=0A> the=0D=0A> > > > parameter; rather than p= lace an arbitrary value on some abstract=0D=0A> > > codes,=0D=0A> > > > all= ow the client to decide.=0D=0A> > > >=0D=0A> > > > To add to this, during m= y break, we had a request for further=0D=0A> control=0D=0A> > > over=0D=0A>= > > > these values on one of our cellular products. In this request,=0D=0A= > > > different=0D=0A> > > > types of clients would be given varying amount= s of time. Thus,=0D=0A> from=0D=0A> > > our=0D=0A> > > > perspective, we h= ave a clear requirement for responseTime.=0D=0A> > > >=0D=0A> > > > To thos= e who want hard limits; BCP documents are a good place=0D=0Afor=0D=0A> > > = > recommendations. You can add nice statements like: "if routing=0D=0A> fo= r=0D=0A> > > > emergency calls, set responseTime to x seconds; if you don't=0D= =0Acare,=0D=0A> > > allow y=0D=0A> > > > seconds".=0D=0A> > > >=0D=0A> > > = > Ta,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > >=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A> > > --=0D= =0A> > > > ----------------------=0D=0A> > > > This message is for the desi= gnated recipient only and may=0D=0A> > > > contain privileged, proprietary,= or otherwise private=0D=0Ainformation.=0D=0A> > > > If you have received i= t in error, please notify the sender=0D=0A> > > > immediately and delete th= e original. Any unauthorized use of=0D=0A> > > > this email is prohibited.=0D= =0A> > > >=0D=0A> > >=0D=0A>=0D=0A-----------------------------------------= -------------------------------=0D=0A> > > --=0D=0A> > > > ----------------= ------=0D=0A> > > > [mf2]=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > _____= __________________________________________=0D=0A> > > Geopriv mailing list=0D= =0A> > > Geopriv@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo= /geopriv=0D=0A> > >=0D=0A> > >=0D=0A>=0D=0A--------------------------------= ----------------------------------------=0D=0A> > --=0D=0A> > > -----------= -----------=0D=0A> > > This message is for the designated recipient only an= d may=0D=0A> > > contain privileged, proprietary, or otherwise private info= rmation.=0D=0A> > > If you have received it in error, please notify the sen= der=0D=0A> > > immediately and delete the original. Any unauthorized use o= f=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A> > --=0D=0A= > > > ----------------------=0D=0A> > > [mf2]=0D=0A> >=0D=0A> >=0D=0A> >=0D= =0A> > _______________________________________________=0D=0A> > Geopriv mai= ling list=0D=0A> > Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/= listinfo/geopriv=0D=0A>=20=0D=0A>=0D=0A------------------------------------= ------------------------------------=0D=0A--=0D=0A> ----------------------=0D= =0A> This message is for the designated recipient only and may=0D=0A> conta= in privileged, proprietary, or otherwise private information.=0D=0A> If you= have received it in error, please notify the sender=0D=0A> immediately and= delete the original. Any unauthorized use of=0D=0A> this email is prohibi= ted.=0D=0A>=0D=0A----------------------------------------------------------= --------------=0D=0A--=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 18:42:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUrvs-0005Vg-If; Mon, 10 Sep 2007 18:40:40 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUrvq-0005VZ-Fu for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 18:40:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUrvq-0005VP-1k for geopriv@ietf.org; Mon, 10 Sep 2007 18:40:38 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUrvo-0007C9-F0 for geopriv@ietf.org; Mon, 10 Sep 2007 18:40:38 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_17_49_58 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 17:49:57 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 17:40:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 17:40:30 -0500 Message-ID: In-Reply-To: <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LA= References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Winterbottom, James" , "Thomson, Martin" , X-OriginalArrivalTime: 10 Sep 2007 22:40:35.0970 (UTC) FILETIME=[9A9D7620:01C7F3FB] X-Spam-Score: -0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think the text you have below is suitable for inclusion in, say, the=0D=0A= ECRIT BCP. We need text for the HELD spec - which I don't think should=0D=0A= be quantifying anything. I gather you'd like an optional parameter in=0D=0A= the HELD request that is binary and used to indicate that the purpose of=0D= =0Athe location is for emergency route/dispatch=3F=0D=0A=0D=0ACheers,=0D=0A= Martin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto= :br@brianrosen.net]=20=0D=0ASent: Tuesday, 11 September 2007 8:17 AM=0D=0AT= o: Winterbottom, James; Dawson, Martin; Thomson, Martin;=0D=0Ageopriv@ietf.= org=0D=0ASubject: RE: [Geopriv] responseTime reprise=0D=0A=0D=0AThe propose= d text was in the message. Here it is again:=0D=0AIn some jurisdictions, t= here are regulations which govern the time=0D=0Aand/or=0D=0Aaccuracy requir= ed for emergency calls. When processing an emergency=0D=0Acall=0D=0Alocati= on is used in two circumstances: routing a call to the most=0D=0Aappropriat= e PSAP, and later, dispatching responders to help the caller.=0D=0ARegulati= ons may govern one or both of these circumstances and the=0D=0Aregulation=0D= =0Amay specify the accuracy without specifying time, time without=0D=0Aspec= ifying=0D=0Aaccuracy, or both time and accuracy. The protocol supports thi= s=0D=0Apossibility. There are two distinguished values for ResponseTime wh= ich=0D=0Aare=0D=0Aused for emergency calls, where there is a locally mandat= ed=0D=0Atime/accuracy=0D=0Arequirements for routing or dispatch. The two v= alues are:=0D=0A=0D=0A* EmergencyCallRoute: Used to signal that the locally= required values=0D=0Afor=0D=0Aemergency call routing are needed. If there= are no local mandates, and=0D=0Athis=0D=0Aparameter is used, the server sh= ould assume <1KM uncertainty with 95%=0D=0Aconfidence in <250 ms unless the= accuracy can be substantially improved=0D=0Aby=0D=0Awaiting as much as 3 s= econds. If the measurement mechanism can make=0D=0Asubstantial improvement= by waiting, the wait time should be judged by=0D=0Athe=0D=0Aserver to mini= mize the time the call is held while getting most of the=0D=0Again=0D=0Ain = accuracy. If most of the improved uncertainty is achieved in 2=0D=0Asecond= s,=0D=0Ado not wait the entire 3 seconds.=0D=0A=0D=0A* EmergencyCallDispatc= h: Used to signal that the locally required values=0D=0Afor=0D=0Aemergency = call dispatch are needed. If there are no local mandates, and=0D=0Athis pa= rameter is used, the server should assume <100M uncertainty with=0D=0A95%=0D= =0Aconfidence in <30 sec. =20=0D=0A=0D=0A=0D=0A=0D=0AIt would apply to civi= c as well as geo, although I don't think any LIS=0D=0Athat=0D=0Areports civ= ic has any response time (unless it converts and it should=0D=0Anot=0D=0Aco= nvert).=0D=0A=0D=0AIf the LIS can't meet the regulation, it returns the bes= t it can.=0D=0A=0D=0AYou can request a civic and a geo in the same message.= I don't want to=0D=0Asay=0D=0Athat you could not have an implementation w= hich could give you an=0D=0Aaccurate=0D=0Acivic and an accurate geo by two = different mechanisms and thus the=0D=0Arequest=0D=0Amight make sense. I th= ink that will be rare. As long as you don't=0D=0Aconvert,=0D=0AI'm okay wi= th asking for both. If you do that, and the implementation=0D=0Acan=0D=0Ad= o both, then you get both.=0D=0A=0D=0AI'm not sure what interactions are is= sues. It's really just a=0D=0Adistinguished=0D=0Avalue for ResponseTime (a= nd/or accuracy if we go with Doug's proposal,=0D=0Awhich=0D=0AI like better= than just time).=0D=0A=0D=0ABrian=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A= > Sent: Monday, September 10, 2007 5:47 PM=0D=0A> To: Brian Rosen; Dawson, = Martin; Thomson, Martin; geopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] res= ponseTime reprise=0D=0A>=20=0D=0A> Brian,=0D=0A>=20=0D=0A> I think that the= first part is actually totally achievable with the=0D=0A> responseTime par= ameter, and you can certainly check the stats later.=0D=0A> This further st= resses my point that applications almost always know=0D=0A> whether the acc= uracy is good enough to do something with. But I think=0D=0A> what I am hea= ring from you is that you see a need for a service=0D=0A> indicator to the = LIS saying, I need this for emergency purposes=0D=0Aplease.=0D=0A>=20=0D=0A= > Perhaps I missed what your proposed text was then, the only solutions=0D=0A= I=0D=0A> recall seeing were ones that required network URI profiling ahead = of=0D=0A> time and I know that that can't be done. So would you please repe= at=0D=0Ayour=0D=0A> proposal=3F=0D=0A>=20=0D=0A> On the last point, the leg= islation might not provide a time=0D=0Aconstraint,=0D=0A> but we all know t= hat there is one. If it were to take an hour or even=0D=0A5=0D=0A> minutes = to get a location that that would be totally unacceptable in=0D=0A> this us= e case. I have described mobile concierge applications that=0D=0Aonly=0D=0A= > have a time constraint and not really an accuracy one, because they=0D=0A= can=0D=0A> work with either geodetic or civic locations.=0D=0A>=20=0D=0A> I= am not discounting the use case you propose, I just don't believe=0D=0Atha= t=0D=0A> any proposed solution I have describes how:=0D=0A>=20=0D=0A> 1) It= can apply to civic and geo location information=0D=0A> 2) If I can't meet = it, what is the semantic=0D=0A> 3) If I request a civic and geo in the same= location request, which=0D=0A> takes precedence, time or accuracy and why=3F=0D= =0A> 4) How it interacts with other attributes that are already agreed upon=0D= =0A>=20=0D=0A> Basically any proposed solution needs to address at least al= l of those=0D=0A> and in an unambiguous way, otherwise I don't see it as do= ing much more=0D=0A> than throwing a spanner(wrench) in the works.=0D=0A> =0D= =0A> Cheers=0D=0A> James=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A= > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > Sent: Tuesday, 11= September 2007 7:20 AM=0D=0A> > To: Winterbottom, James; Dawson, Martin; T= homson, Martin;=0D=0A> geopriv@ietf.org=0D=0A> > Subject: RE: [Geopriv] res= ponseTime reprise=0D=0A> >=0D=0A> > James=0D=0A> >=0D=0A> > In the past, I = thought a generalized "roughly now, whatever accuracy=0D=0A> you=0D=0A> > c= an=0D=0A> > give me" and "roughly as accurate as you can get, in a reasonab= le,=0D=0Abut=0D=0A> > longish time frame" was acceptable. It was pointed o= ut to me that=0D=0A> where=0D=0A> > there is actual regulation, what I aske= d for may not be one of the=0D=0A> above.=0D=0A> > To my knowledge, there a= re no other uses where there is, or might=0D=0Abe,=0D=0A> > regulation. So= , I'm proposing that there be something that alerts=0D=0Athe=0D=0A> LIS=0D=0A= > > that the request is one of those that have to conform to such=0D=0A> re= gulation=0D=0A> > if=0D=0A> > there is any.=0D=0A> >=0D=0A> > I think what = happens when the network cannot deliver what the=0D=0A> regulation=0D=0A> >= says is that they get some answer. The authorities also get some=0D=0A> > = statistics=0D=0A> > that shows them whether the regulation is being met wit= hin the=0D=0A> confidence=0D=0A> > requirement. After all, confidence is n= ever 100%. Addressing what=0D=0A> they=0D=0A> > do=0D=0A> > about it when = the result doesn't meet the regulation is beyond scope=0D=0A> no=0D=0A> > m= atter how you define it.=0D=0A> >=0D=0A> > I thought I made a pretty reason= able proposal, with text, as asked.=0D=0AI=0D=0A> > think=0D=0A> > I have p= rovided a pretty decent motivation. I fail to see why this=0D=0A> should=0D= =0A> > be an extension, since this is one of (not the only) driving use=0D=0A= > cases.=0D=0A> > You=0D=0A> > can assail me for not recognizing sooner tha= t there may have to be=0D=0A> > something=0D=0A> > that gets a predefined a= ccuracy/time trade-off for the emergency=0D=0Acase,=0D=0A> but=0D=0A> > I=0D= =0A> > think that, having recognized it, defined it, made a specific text=0D= =0A> > proposal,=0D=0A> > and defended it, that perhaps you need to show me= where I am wrong.=0D=0A> >=0D=0A> > In North America, at present, there is= an accuracy requirement for=0D=0A> > emergency=0D=0A> > dispatch on mobile= handsets. For handset driven systems like GPS,=0D=0A> it's=0D=0A> > <100m= 95% of the time. That may or may not conform to some LIS'=0D=0A> notion o= f=0D=0A> > AGAP. On the other hand, if you tell it that you need dispatch=0D= =0A> location=0D=0A> > for=0D=0A> > an emergency call, and it's in the U.S.= , it knows EXACTLY what it=0D=0A> needs to=0D=0A> > do. There is no settin= g of a generalized ResponseTime with or=0D=0Awithout=0D=0A> > AGAP/ASAP whi= ch would indicate <100M with 95% confidence. You will=0D=0A> note=0D=0A> >= that the regulation states accuracy without stating response time.=0D=0A> = >=0D=0A> > Brian=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Message-----=0D= =0A> > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D= =0A> > > Sent: Monday, September 10, 2007 4:34 PM=0D=0A> > > To: Brian Rose= n; Dawson, Martin; Thomson, Martin; geopriv@ietf.org=0D=0A> > > Subject: RE= : [Geopriv] responseTime reprise=0D=0A> > >=0D=0A> > > Brian,=0D=0A> > >=0D= =0A> > > As has been pointed out more times than I can count now.=0D=0A> > = > The shape of the curve CANNOT be quantified ahead of time.=0D=0A> > >=0D=0A= > > > You state below "In some jurisdictions, there are regulations=0D=0Awh= ich=0D=0A> > > govern the time and/or accuracy required for emergency calls= =2E"=0D=0A> > > Can you explain what happens if the accuracy cannot be met = in any=0D=0A> place,=0D=0A> > > does the PSAP get no location at all=3F I a= m prepared to bet you a=0D=0A> beer at=0D=0A> > > the next IETF that they g= et something, and that it is the probably=0D=0A> the=0D=0A> > > best locati= on that the network can provide before the ALI=0D=0A> transaction=0D=0A> > = > times out.=0D=0A> > >=0D=0A> > > Until recently you said that you only ha= d two requirement AGAP and=0D=0A> ASAP,=0D=0A> > > responseTime will give y= ou that, and it will give us what we want.=0D=0A> > > Win-win, and 'best-ba= sis'.=0D=0A> > >=0D=0A> > > If you want something more than repsonseTime, a= s you indicate=0D=0Abelow,=0D=0A> > > then that can be an extension and I c= hallenge you to write a draft=0D=0A> that=0D=0A> > > can do this.=0D=0A> > = >=0D=0A> > > Cheers=0D=0A> > > James=0D=0A> > >=0D=0A> > > > -----Original = Message-----=0D=0A> > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A= > > > > Sent: Tuesday, 11 September 2007 1:10 AM=0D=0A> > > > To: Dawson, M= artin; Thomson, Martin; geopriv@ietf.org=0D=0A> > > > Subject: RE: [Geopriv= ] responseTime reprise=0D=0A> > > >=0D=0A> > > > I don't think so. Someone= needs to judge "substantial=0D=0A> improvement".=0D=0A> > > It=0D=0A> > > = > could be the server if it knew that is what you want. It could=0D=0Abe=0D= =0A> the=0D=0A> > > > client if it knew what the server could do. Just put= ting the=0D=0Atime=0D=0A> > > > parameter=0D=0A> > > > doesn't have a way t= o express anything other than the simplistic=0D=0A> "wait=0D=0A> > > 3=0D=0A= > > > > seconds" if anything can be done in those 3 seconds. You might=0D=0A= > get,=0D=0A> > > say,=0D=0A> > > > 30% improvement from .25 sec to 3 sec. = If that was the case,=0D=0Ayour=0D=0A> > > > mechanism=0D=0A> > > > would = wait 3 seconds. I would not want that to happen. I want=0D=0A> > > someon= e to=0D=0A> > > > judge when it's not worth waiting more for. That might b= e 1=0D=0A> second,=0D=0A> > > or 2=0D=0A> > > > seconds. Depends on the sh= ape of the curve.=0D=0A> > > >=0D=0A> > > > Whatever parameters are decided= upon, we may need two=0D=0A> distinguished=0D=0A> > > values=0D=0A> > > > = that are "use locally mandated limits for emergency call=0D=0Arouting"=0D=0A= > and=0D=0A> > > the=0D=0A> > > > same for dispatch. If we're stuck with R= esponseTime alone:=0D=0A> > > >=0D=0A> > > > In some jurisdictions, there a= re regulations which govern the=0D=0Atime=0D=0A> > > and/or=0D=0A> > > > ac= curacy required for emergency calls. When processing an=0D=0A> emergency=0D= =0A> > > call=0D=0A> > > > location is used in two circumstances: routing a= call to the=0D=0Amost=0D=0A> > > > appropriate PSAP, and later, dispatchin= g responders to help the=0D=0A> > > caller.=0D=0A> > > > Regulations may go= vern one or both of these circumstances and=0D=0Athe=0D=0A> > > > regulatio= n=0D=0A> > > > may specify the accuracy without specifying time, time witho= ut=0D=0A> > > specifying=0D=0A> > > > accuracy, or both time and accuracy. = The protocol supports this=0D=0A> > > > possibility. There are two distin= guished values for=0D=0AResponseTime=0D=0A> > > which=0D=0A> > > > are=0D=0A= > > > > used for emergency calls, where there is a locally mandated=0D=0A> = > > time/accuracy=0D=0A> > > > requirements for routing or dispatch. The t= wo values are:=0D=0A> > > >=0D=0A> > > > * EmergencyCallRoute: Used to sign= al that the locally required=0D=0A> values=0D=0A> > > for=0D=0A> > > > emer= gency call routing are needed. If there are no local=0D=0A> mandates,=0D=0A= > > > and=0D=0A> > > > this=0D=0A> > > > parameter is used, the server shou= ld assume <1KM uncertainty=0D=0Awith=0D=0A> 95%=0D=0A> > > > confidence in = <250 ms unless the accuracy can be substantially=0D=0A> > > improved by=0D=0A= > > > > waiting as much as 3 seconds. If the measurement mechanism can=0D=0A= > make=0D=0A> > > > substantial improvement by waiting, the wait time shoul= d be=0D=0Ajudged=0D=0A> by=0D=0A> > > the=0D=0A> > > > server to minimize t= he time the call is held while getting most=0D=0Aof=0D=0A> the=0D=0A> > > >= gain=0D=0A> > > > in accuracy. If most of the improved uncertainty is ach= ieved in=0D=0A2=0D=0A> > > > seconds,=0D=0A> > > > do not wait the entire 3= seconds.=0D=0A> > > >=0D=0A> > > > * EmergencyCallDispatch: Used to signal= that the locally=0D=0Arequired=0D=0A> > > values=0D=0A> > > > for=0D=0A> >= > > emergency call dispatch are needed. If there are no local=0D=0A> mand= ates,=0D=0A> > > and=0D=0A> > > > this parameter is used, the server should= assume <100M=0D=0Auncertainty=0D=0A> > > with=0D=0A> > > > 95%=0D=0A> > > = > confidence in <30 sec.=0D=0A> > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> > > = > As HELD is a text language, perhaps these strings can be used.=0D=0AIf=0D= =0A> we=0D=0A> > > need=0D=0A> > > > to assign integer values to them, then= we'll pick something.=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > > -----Origin= al Message-----=0D=0A> > > > > From: Dawson, Martin [mailto:Martin.Dawson@a= ndrew.com]=0D=0A> > > > > Sent: Monday, September 10, 2007 10:26 AM=0D=0A> = > > > > To: Brian Rosen; Thomson, Martin; geopriv@ietf.org=0D=0A> > > > > S= ubject: RE: [Geopriv] responseTime reprise=0D=0A> > > > >=0D=0A> > > > > Yo= u put three seconds in as the response time. If a more=0D=0A> accurate=0D=0A= > > > > > location can be provided in 3 seconds, it will take that long,=0D= =0A> if=0D=0A> > > not it=0D=0A> > > > > will respond even faster.=0D=0A> >= > > >=0D=0A> > > > > What's more, if the next application running on the d= evice can=0D=0A> > > actually=0D=0A> > > > > wait 20 seconds, it can state = "20 seconds" and may actually=0D=0A> > > subsequently=0D=0A> > > > > get a = more accurate location which may take anywhere from 3 to=0D=0A> 20=0D=0A> >= > > > seconds to return.=0D=0A> > > > >=0D=0A> > > > > Simple.=0D=0A> > > = > >=0D=0A> > > > > If you really think that there is a need for a "please g= ive me=0D=0A> > > location=0D=0A> > > > > in the time mandated by the juris= diction in which I am=0D=0Acurrently=0D=0A> > > > > operating" semantic the= n please send text. Nobody has=0D=0Asuggested=0D=0A> that=0D=0A> > > is=0D=0A= > > > > > what response time satisfies - and you have not proposed=0D=0A> a= nything=0D=0A> > > that=0D=0A> > > > > satisfies it either. Such a mechanis= m is not mutually=0D=0Aexclusive=0D=0A> to=0D=0A> > > an=0D=0A> > > > > opt= ional response time parameter.=0D=0A> > > > >=0D=0A> > > > > Cheers,=0D=0A>= > > > > Martin=0D=0A> > > > >=0D=0A> > > > > -----Original Message-----=0D= =0A> > > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > Se= nt: Monday, 10 September 2007 11:25 PM=0D=0A> > > > > To: Thomson, Martin; = geopriv@ietf.org=0D=0A> > > > > Subject: RE: [Geopriv] responseTime reprise=0D= =0A> > > > >=0D=0A> > > > > I was working in updates to phonebcp and framew= ork and here is=0D=0A> the=0D=0A> > > spec=0D=0A> > > > > I=0D=0A> > > > > = want to have:=0D=0A> > > > >=0D=0A> > > > > ED-25/AN-14 It is RECOMMENDED t= hat location determination not=0D=0A> take=0D=0A> > > > > longer=0D=0A> > >= > > than 250 ms to obtain routing location and systems SHOULD be=0D=0A> > = > designed=0D=0A> > > > > such=0D=0A> > > > > that the typical response is = under 100ms. However, as much as=0D=0A3=0D=0A> > > seconds=0D=0A> > > > > t= o=0D=0A> > > > > obtain routing location MAY be tolerated if location accur= acy=0D=0A> can be=0D=0A> > > > > substantially improved over what can be ob= tained in 250 ms.=0D=0A> > > > >=0D=0A> > > > > How would you express that = with your parameter=3F=0D=0A> > > > >=0D=0A> > > > > The equivalent for dis= patch location is:=0D=0A> > > > > Generally, the PSAP can wait for an accur= ate location for=0D=0A> dispatch.=0D=0A> > > > > However, there is no fixed= time known in advance which is the=0D=0A> limit;=0D=0A> > > it=0D=0A> > > = > > depends on the nature of the emergency. At some point the=0D=0APSAP=0D= =0A> must=0D=0A> > > > > dispatch. In a subscription environment, the PSAP= could=0D=0Aupdate=0D=0A> the=0D=0A> > > > > parameters in the filter (imme= diate response required). In a=0D=0A> HELD=0D=0A> > > > > dereference, the= re is no way to cancel and the PSAP will have=0D=0Ato=0D=0A> > > choose=0D=0A= > > > > > a=0D=0A> > > > > ResponseTime that it will wait for even if it wa= nts to=0D=0Adispatch=0D=0A> > > sooner=0D=0A> > > > > than=0D=0A> > > > > t= hat. =0D=0A> > > > >=0D=0A= > > > > > We then get to a complication. It may be the case in some=0D=0A>= > > jurisdictions=0D=0A> > > > > that there are regulations that govern th= is. In those cases,=0D=0Awe=0D=0A> may=0D=0A> > > > > need a=0D=0A> > > > = > way to say "I need the regulation-imposed values for emergency=0D=0A> cal= l=0D=0A> > > > > route",=0D=0A> > > > > or the equivalent for dispatch.=0D=0A= > > > > >=0D=0A> > > > > Brian=0D=0A> > > > >=0D=0A> > > > > > -----Origina= l Message-----=0D=0A> > > > > > From: Thomson, Martin [mailto:Martin.Thomso= n@andrew.com]=0D=0A> > > > > > Sent: Monday, September 10, 2007 3:22 AM=0D=0A= > > > > > > To: geopriv@ietf.org=0D=0A> > > > > > Subject: [Geopriv] respon= seTime reprise=0D=0A> > > > > >=0D=0A> > > > > > I'm probably due to step i= nto the ring on this topic. I=0D=0A> apologise=0D=0A> > > for=0D=0A> > > >= > > anything that is rehashed, I have not read the _entire_=0D=0A> archive= on=0D=0A> > > > > this=0D=0A> > > > > > topic.=0D=0A> > > > > >=0D=0A> > >= > > > The main reason the responseTime parameter was proposed was=0D=0A> o= ur=0D=0A> > > > > collective=0D=0A> > > > > > experience with cellular syst= ems.=0D=0A> > > > > >=0D=0A> > > > > > 3GPP have defined two values: "low d= elay" and "delay=0D=0A> tolerant",=0D=0A> > > which=0D=0A> > > > > > roughl= y correspond to what some have been advocating.=0D=0A> However,=0D=0A> > > = where=0D=0A> > > > > > multiple network nodes are involved in serving a req= uest=0D=0A(and=0D=0A> 3GPP=0D=0A> > > > > relies=0D=0A> > > > > > on about = 6), engineering is required to ensure smooth=0D=0A> operation.=0D=0A> > > E= ach=0D=0A> > > > > > node is configured with a different timeout so that th= e time=0D=0A> that=0D=0A> > > the=0D=0A> > > > > node=0D=0A> > > > > > adds= to the transaction doesn't cause failures. This=0D=0A> engineering=0D=0A>= > > > > ensures=0D=0A> > > > > > that each location client receives a cert= ain level of=0D=0Aservice.=0D=0A> > > > > >=0D=0A> > > > > > Of course, eac= h network is engineered differently. Everyone=0D=0A> has a=0D=0A> > > > > = > different idea of what "low delay" and "delay tolerant"=0D=0Amean.=0D=0A>= In=0D=0A> > > a=0D=0A> > > > > closed=0D=0A> > > > > > network this more o= r less works; although this isn't assured=0D=0A> for=0D=0A> > > > > roamers= =2E=0D=0A> > > > > > We wanted to avoid this problem. It makes sense to al= low=0D=0A> devolve=0D=0A> > > the=0D=0A> > > > > > parameter; rather than p= lace an arbitrary value on some=0D=0A> abstract=0D=0A> > > > > codes,=0D=0A= > > > > > > allow the client to decide.=0D=0A> > > > > >=0D=0A> > > > > > T= o add to this, during my break, we had a request for=0D=0Afurther=0D=0A> > = > control=0D=0A> > > > > over=0D=0A> > > > > > these values on one of our c= ellular products. In this=0D=0A> request,=0D=0A> > > > > different=0D=0A> = > > > > > types of clients would be given varying amounts of time.=0D=0A> T= hus,=0D=0A> > > from=0D=0A> > > > > our=0D=0A> > > > > > perspective, we ha= ve a clear requirement for responseTime.=0D=0A> > > > > >=0D=0A> > > > > > = To those who want hard limits; BCP documents are a good=0D=0Aplace=0D=0A> f= or=0D=0A> > > > > > recommendations. You can add nice statements like: "if=0D= =0A> routing=0D=0A> > > for=0D=0A> > > > > > emergency calls, set responseT= ime to x seconds; if you don't=0D=0A> care,=0D=0A> > > > > allow y=0D=0A> >= > > > > seconds".=0D=0A> > > > > >=0D=0A> > > > > > Ta,=0D=0A> > > > > > M= artin=0D=0A> > > > > >=0D=0A> > > > >=0D=0A> > >=0D=0A>=0D=0A--------------= ----------------------------------------------------------=0D=0A> > > > > -= -=0D=0A> > > > > > ----------------------=0D=0A> > > > > > This message is = for the designated recipient only and may=0D=0A> > > > > > contain privileg= ed, proprietary, or otherwise private=0D=0A> information.=0D=0A> > > > > > = If you have received it in error, please notify the sender=0D=0A> > > > > >= immediately and delete the original. Any unauthorized use=0D=0Aof=0D=0A> = > > > > > this email is prohibited.=0D=0A> > > > > >=0D=0A> > > > >=0D=0A> = > >=0D=0A>=0D=0A-----------------------------------------------------------= -------------=0D=0A> > > > > --=0D=0A> > > > > > ----------------------=0D=0A= > > > > > > [mf2]=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > >= > _______________________________________________=0D=0A> > > > > Geopriv m= ailing list=0D=0A> > > > > Geopriv@ietf.org=0D=0A> > > > > https://www1.iet= f.org/mailman/listinfo/geopriv=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > >=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A> > > > --=0D=0A> > > > > ----------------------=0D=0A> > > > > T= his message is for the designated recipient only and may=0D=0A> > > > > con= tain privileged, proprietary, or otherwise private=0D=0A> information.=0D=0A= > > > > > If you have received it in error, please notify the sender=0D=0A>= > > > > immediately and delete the original. Any unauthorized use of=0D=0A= > > > > > this email is prohibited.=0D=0A> > > > >=0D=0A> > >=0D=0A>=0D=0A-= -----------------------------------------------------------------------=0D=0A= > > > > --=0D=0A> > > > > ----------------------=0D=0A> > > > > [mf2]=0D=0A= > > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > ____________________________= ___________________=0D=0A> > > > Geopriv mailing list=0D=0A> > > > Geopriv@= ietf.org=0D=0A> > > > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>= > >=0D=0A> > >=0D=0A>=0D=0A-----------------------------------------------= -------------------------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A= > > > This message is for the designated recipient only and may=0D=0A> > > = contain privileged, proprietary, or otherwise private information.=0D=0A> >= > If you have received it in error, please notify the sender=0D=0A> > > im= mediately and delete the original. Any unauthorized use of=0D=0A> > > this= email is prohibited.=0D=0A> > >=0D=0A>=0D=0A------------------------------= ------------------------------------------=0D=0A> > --=0D=0A> > > ---------= -------------=0D=0A> > > [mf2]=0D=0A> >=0D=0A>=20=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A--=0D=0A> = ----------------------=0D=0A> This message is for the designated recipient = only and may=0D=0A> contain privileged, proprietary, or otherwise private i= nformation.=0D=0A> If you have received it in error, please notify the send= er=0D=0A> immediately and delete the original. Any unauthorized use of=0D=0A= > this email is prohibited.=0D=0A>=0D=0A-----------------------------------= -------------------------------------=0D=0A--=0D=0A> ----------------------=0D= =0A> [mf2]=0D=0A=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From azze@sinaloa.com.mx Mon Sep 10 20:21:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUtVh-0002Y3-Lk for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 20:21:45 -0400 Received: from [195.205.124.68] (helo=avp10.internetdsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUtVh-0001wF-5P for geopriv-archive@lists.ietf.org; Mon, 10 Sep 2007 20:21:45 -0400 Received: from sikora-i0e9wllc ([184.164.16.62] helo=sikora-i0e9wllc) by avp10.internetdsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1ZHtpY-000RFM-om for geopriv-archive@lists.ietf.org; Tue, 11 Sep 2007 02:22:43 +0200 Message-ID: <000d01c7f409$c8669ec0$0a291253@sikorai0e9wllc> From: "azze jorn" To: Subject: etstuhtn Date: Tue, 11 Sep 2007 02:22:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F41A.8BEF6EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7F41A.8BEF6EC0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://www.luisio.com/ How it is going jorn bigger than average, thats what i am now am Gruzdas ------=_NextPart_000_0008_01C7F41A.8BEF6EC0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://www.luisio.com/
How it is going jorn
bigger than average, thats what i am = now
am Gruzdas
------=_NextPart_000_0008_01C7F41A.8BEF6EC0-- From geopriv-bounces@ietf.org Mon Sep 10 22:28:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUvT8-0003vj-PE; Mon, 10 Sep 2007 22:27:14 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUvT7-0003ve-Om for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 22:27:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUvT7-0003vW-Ax for geopriv@ietf.org; Mon, 10 Sep 2007 22:27:13 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUvT5-0004ko-7N for geopriv@ietf.org; Mon, 10 Sep 2007 22:27:13 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUvT1-0007fM-5J; Mon, 10 Sep 2007 21:27:08 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Winterbottom, James'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 22:27:04 -0400 Message-ID: <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQA== In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I want a distinguished value in the ResponseTime field if that is all there is. > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Monday, September 10, 2007 6:41 PM > To: Brian Rosen; Winterbottom, James; Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > I think the text you have below is suitable for inclusion in, say, the > ECRIT BCP. We need text for the HELD spec - which I don't think should > be quantifying anything. I gather you'd like an optional parameter in > the HELD request that is binary and used to indicate that the purpose of > the location is for emergency route/dispatch? > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, 11 September 2007 8:17 AM > To: Winterbottom, James; Dawson, Martin; Thomson, Martin; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > The proposed text was in the message. Here it is again: > In some jurisdictions, there are regulations which govern the time > and/or > accuracy required for emergency calls. When processing an emergency > call > location is used in two circumstances: routing a call to the most > appropriate PSAP, and later, dispatching responders to help the caller. > Regulations may govern one or both of these circumstances and the > regulation > may specify the accuracy without specifying time, time without > specifying > accuracy, or both time and accuracy. The protocol supports this > possibility. There are two distinguished values for ResponseTime which > are > used for emergency calls, where there is a locally mandated > time/accuracy > requirements for routing or dispatch. The two values are: > > * EmergencyCallRoute: Used to signal that the locally required values > for > emergency call routing are needed. If there are no local mandates, and > this > parameter is used, the server should assume <1KM uncertainty with 95% > confidence in <250 ms unless the accuracy can be substantially improved > by > waiting as much as 3 seconds. If the measurement mechanism can make > substantial improvement by waiting, the wait time should be judged by > the > server to minimize the time the call is held while getting most of the > gain > in accuracy. If most of the improved uncertainty is achieved in 2 > seconds, > do not wait the entire 3 seconds. > > * EmergencyCallDispatch: Used to signal that the locally required values > for > emergency call dispatch are needed. If there are no local mandates, and > this parameter is used, the server should assume <100M uncertainty with > 95% > confidence in <30 sec. > > > > It would apply to civic as well as geo, although I don't think any LIS > that > reports civic has any response time (unless it converts and it should > not > convert). > > If the LIS can't meet the regulation, it returns the best it can. > > You can request a civic and a geo in the same message. I don't want to > say > that you could not have an implementation which could give you an > accurate > civic and an accurate geo by two different mechanisms and thus the > request > might make sense. I think that will be rare. As long as you don't > convert, > I'm okay with asking for both. If you do that, and the implementation > can > do both, then you get both. > > I'm not sure what interactions are issues. It's really just a > distinguished > value for ResponseTime (and/or accuracy if we go with Doug's proposal, > which > I like better than just time). > > Brian > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, September 10, 2007 5:47 PM > > To: Brian Rosen; Dawson, Martin; Thomson, Martin; geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > Brian, > > > > I think that the first part is actually totally achievable with the > > responseTime parameter, and you can certainly check the stats later. > > This further stresses my point that applications almost always know > > whether the accuracy is good enough to do something with. But I think > > what I am hearing from you is that you see a need for a service > > indicator to the LIS saying, I need this for emergency purposes > please. > > > > Perhaps I missed what your proposed text was then, the only solutions > I > > recall seeing were ones that required network URI profiling ahead of > > time and I know that that can't be done. So would you please repeat > your > > proposal? > > > > On the last point, the legislation might not provide a time > constraint, > > but we all know that there is one. If it were to take an hour or even > 5 > > minutes to get a location that that would be totally unacceptable in > > this use case. I have described mobile concierge applications that > only > > have a time constraint and not really an accuracy one, because they > can > > work with either geodetic or civic locations. > > > > I am not discounting the use case you propose, I just don't believe > that > > any proposed solution I have describes how: > > > > 1) It can apply to civic and geo location information > > 2) If I can't meet it, what is the semantic > > 3) If I request a civic and geo in the same location request, which > > takes precedence, time or accuracy and why? > > 4) How it interacts with other attributes that are already agreed upon > > > > Basically any proposed solution needs to address at least all of those > > and in an unambiguous way, otherwise I don't see it as doing much more > > than throwing a spanner(wrench) in the works. > > > > Cheers > > James > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, 11 September 2007 7:20 AM > > > To: Winterbottom, James; Dawson, Martin; Thomson, Martin; > > geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > James > > > > > > In the past, I thought a generalized "roughly now, whatever accuracy > > you > > > can > > > give me" and "roughly as accurate as you can get, in a reasonable, > but > > > longish time frame" was acceptable. It was pointed out to me that > > where > > > there is actual regulation, what I asked for may not be one of the > > above. > > > To my knowledge, there are no other uses where there is, or might > be, > > > regulation. So, I'm proposing that there be something that alerts > the > > LIS > > > that the request is one of those that have to conform to such > > regulation > > > if > > > there is any. > > > > > > I think what happens when the network cannot deliver what the > > regulation > > > says is that they get some answer. The authorities also get some > > > statistics > > > that shows them whether the regulation is being met within the > > confidence > > > requirement. After all, confidence is never 100%. Addressing what > > they > > > do > > > about it when the result doesn't meet the regulation is beyond scope > > no > > > matter how you define it. > > > > > > I thought I made a pretty reasonable proposal, with text, as asked. > I > > > think > > > I have provided a pretty decent motivation. I fail to see why this > > should > > > be an extension, since this is one of (not the only) driving use > > cases. > > > You > > > can assail me for not recognizing sooner that there may have to be > > > something > > > that gets a predefined accuracy/time trade-off for the emergency > case, > > but > > > I > > > think that, having recognized it, defined it, made a specific text > > > proposal, > > > and defended it, that perhaps you need to show me where I am wrong. > > > > > > In North America, at present, there is an accuracy requirement for > > > emergency > > > dispatch on mobile handsets. For handset driven systems like GPS, > > it's > > > <100m 95% of the time. That may or may not conform to some LIS' > > notion of > > > AGAP. On the other hand, if you tell it that you need dispatch > > location > > > for > > > an emergency call, and it's in the U.S., it knows EXACTLY what it > > needs to > > > do. There is no setting of a generalized ResponseTime with or > without > > > AGAP/ASAP which would indicate <100M with 95% confidence. You will > > note > > > that the regulation states accuracy without stating response time. > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Monday, September 10, 2007 4:34 PM > > > > To: Brian Rosen; Dawson, Martin; Thomson, Martin; geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > Brian, > > > > > > > > As has been pointed out more times than I can count now. > > > > The shape of the curve CANNOT be quantified ahead of time. > > > > > > > > You state below "In some jurisdictions, there are regulations > which > > > > govern the time and/or accuracy required for emergency calls." > > > > Can you explain what happens if the accuracy cannot be met in any > > place, > > > > does the PSAP get no location at all? I am prepared to bet you a > > beer at > > > > the next IETF that they get something, and that it is the probably > > the > > > > best location that the network can provide before the ALI > > transaction > > > > times out. > > > > > > > > Until recently you said that you only had two requirement AGAP and > > ASAP, > > > > responseTime will give you that, and it will give us what we want. > > > > Win-win, and 'best-basis'. > > > > > > > > If you want something more than repsonseTime, as you indicate > below, > > > > then that can be an extension and I challenge you to write a draft > > that > > > > can do this. > > > > > > > > Cheers > > > > James > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Tuesday, 11 September 2007 1:10 AM > > > > > To: Dawson, Martin; Thomson, Martin; geopriv@ietf.org > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > I don't think so. Someone needs to judge "substantial > > improvement". > > > > It > > > > > could be the server if it knew that is what you want. It could > be > > the > > > > > client if it knew what the server could do. Just putting the > time > > > > > parameter > > > > > doesn't have a way to express anything other than the simplistic > > "wait > > > > 3 > > > > > seconds" if anything can be done in those 3 seconds. You might > > get, > > > > say, > > > > > 30% improvement from .25 sec to 3 sec. If that was the case, > your > > > > > mechanism > > > > > would wait 3 seconds. I would not want that to happen. I want > > > > someone to > > > > > judge when it's not worth waiting more for. That might be 1 > > second, > > > > or 2 > > > > > seconds. Depends on the shape of the curve. > > > > > > > > > > Whatever parameters are decided upon, we may need two > > distinguished > > > > values > > > > > that are "use locally mandated limits for emergency call > routing" > > and > > > > the > > > > > same for dispatch. If we're stuck with ResponseTime alone: > > > > > > > > > > In some jurisdictions, there are regulations which govern the > time > > > > and/or > > > > > accuracy required for emergency calls. When processing an > > emergency > > > > call > > > > > location is used in two circumstances: routing a call to the > most > > > > > appropriate PSAP, and later, dispatching responders to help the > > > > caller. > > > > > Regulations may govern one or both of these circumstances and > the > > > > > regulation > > > > > may specify the accuracy without specifying time, time without > > > > specifying > > > > > accuracy, or both time and accuracy. The protocol supports this > > > > > possibility. There are two distinguished values for > ResponseTime > > > > which > > > > > are > > > > > used for emergency calls, where there is a locally mandated > > > > time/accuracy > > > > > requirements for routing or dispatch. The two values are: > > > > > > > > > > * EmergencyCallRoute: Used to signal that the locally required > > values > > > > for > > > > > emergency call routing are needed. If there are no local > > mandates, > > > > and > > > > > this > > > > > parameter is used, the server should assume <1KM uncertainty > with > > 95% > > > > > confidence in <250 ms unless the accuracy can be substantially > > > > improved by > > > > > waiting as much as 3 seconds. If the measurement mechanism can > > make > > > > > substantial improvement by waiting, the wait time should be > judged > > by > > > > the > > > > > server to minimize the time the call is held while getting most > of > > the > > > > > gain > > > > > in accuracy. If most of the improved uncertainty is achieved in > 2 > > > > > seconds, > > > > > do not wait the entire 3 seconds. > > > > > > > > > > * EmergencyCallDispatch: Used to signal that the locally > required > > > > values > > > > > for > > > > > emergency call dispatch are needed. If there are no local > > mandates, > > > > and > > > > > this parameter is used, the server should assume <100M > uncertainty > > > > with > > > > > 95% > > > > > confidence in <30 sec. > > > > > > > > > > > > > > > > > > > > As HELD is a text language, perhaps these strings can be used. > If > > we > > > > need > > > > > to assign integer values to them, then we'll pick something. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > Sent: Monday, September 10, 2007 10:26 AM > > > > > > To: Brian Rosen; Thomson, Martin; geopriv@ietf.org > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > You put three seconds in as the response time. If a more > > accurate > > > > > > location can be provided in 3 seconds, it will take that long, > > if > > > > not it > > > > > > will respond even faster. > > > > > > > > > > > > What's more, if the next application running on the device can > > > > actually > > > > > > wait 20 seconds, it can state "20 seconds" and may actually > > > > subsequently > > > > > > get a more accurate location which may take anywhere from 3 to > > 20 > > > > > > seconds to return. > > > > > > > > > > > > Simple. > > > > > > > > > > > > If you really think that there is a need for a "please give me > > > > location > > > > > > in the time mandated by the jurisdiction in which I am > currently > > > > > > operating" semantic then please send text. Nobody has > suggested > > that > > > > is > > > > > > what response time satisfies - and you have not proposed > > anything > > > > that > > > > > > satisfies it either. Such a mechanism is not mutually > exclusive > > to > > > > an > > > > > > optional response time parameter. > > > > > > > > > > > > Cheers, > > > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Monday, 10 September 2007 11:25 PM > > > > > > To: Thomson, Martin; geopriv@ietf.org > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > I was working in updates to phonebcp and framework and here is > > the > > > > spec > > > > > > I > > > > > > want to have: > > > > > > > > > > > > ED-25/AN-14 It is RECOMMENDED that location determination not > > take > > > > > > longer > > > > > > than 250 ms to obtain routing location and systems SHOULD be > > > > designed > > > > > > such > > > > > > that the typical response is under 100ms. However, as much as > 3 > > > > seconds > > > > > > to > > > > > > obtain routing location MAY be tolerated if location accuracy > > can be > > > > > > substantially improved over what can be obtained in 250 ms. > > > > > > > > > > > > How would you express that with your parameter? > > > > > > > > > > > > The equivalent for dispatch location is: > > > > > > Generally, the PSAP can wait for an accurate location for > > dispatch. > > > > > > However, there is no fixed time known in advance which is the > > limit; > > > > it > > > > > > depends on the nature of the emergency. At some point the > PSAP > > must > > > > > > dispatch. In a subscription environment, the PSAP could > update > > the > > > > > > parameters in the filter (immediate response required). In a > > HELD > > > > > > dereference, there is no way to cancel and the PSAP will have > to > > > > choose > > > > > > a > > > > > > ResponseTime that it will wait for even if it wants to > dispatch > > > > sooner > > > > > > than > > > > > > that. > > > > > > > > > > > > We then get to a complication. It may be the case in some > > > > jurisdictions > > > > > > that there are regulations that govern this. In those cases, > we > > may > > > > > > need a > > > > > > way to say "I need the regulation-imposed values for emergency > > call > > > > > > route", > > > > > > or the equivalent for dispatch. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > > > > > Sent: Monday, September 10, 2007 3:22 AM > > > > > > > To: geopriv@ietf.org > > > > > > > Subject: [Geopriv] responseTime reprise > > > > > > > > > > > > > > I'm probably due to step into the ring on this topic. I > > apologise > > > > for > > > > > > > anything that is rehashed, I have not read the _entire_ > > archive on > > > > > > this > > > > > > > topic. > > > > > > > > > > > > > > The main reason the responseTime parameter was proposed was > > our > > > > > > collective > > > > > > > experience with cellular systems. > > > > > > > > > > > > > > 3GPP have defined two values: "low delay" and "delay > > tolerant", > > > > which > > > > > > > roughly correspond to what some have been advocating. > > However, > > > > where > > > > > > > multiple network nodes are involved in serving a request > (and > > 3GPP > > > > > > relies > > > > > > > on about 6), engineering is required to ensure smooth > > operation. > > > > Each > > > > > > > node is configured with a different timeout so that the time > > that > > > > the > > > > > > node > > > > > > > adds to the transaction doesn't cause failures. This > > engineering > > > > > > ensures > > > > > > > that each location client receives a certain level of > service. > > > > > > > > > > > > > > Of course, each network is engineered differently. Everyone > > has a > > > > > > > different idea of what "low delay" and "delay tolerant" > mean. > > In > > > > a > > > > > > closed > > > > > > > network this more or less works; although this isn't assured > > for > > > > > > roamers. > > > > > > > We wanted to avoid this problem. It makes sense to allow > > devolve > > > > the > > > > > > > parameter; rather than place an arbitrary value on some > > abstract > > > > > > codes, > > > > > > > allow the client to decide. > > > > > > > > > > > > > > To add to this, during my break, we had a request for > further > > > > control > > > > > > over > > > > > > > these values on one of our cellular products. In this > > request, > > > > > > different > > > > > > > types of clients would be given varying amounts of time. > > Thus, > > > > from > > > > > > our > > > > > > > perspective, we have a clear requirement for responseTime. > > > > > > > > > > > > > > To those who want hard limits; BCP documents are a good > place > > for > > > > > > > recommendations. You can add nice statements like: "if > > routing > > > > for > > > > > > > emergency calls, set responseTime to x seconds; if you don't > > care, > > > > > > allow y > > > > > > > seconds". > > > > > > > > > > > > > > Ta, > > > > > > > Martin > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > > > > > ---------------------- > > > > > > > This message is for the designated recipient only and may > > > > > > > contain privileged, proprietary, or otherwise private > > information. > > > > > > > If you have received it in error, please notify the sender > > > > > > > immediately and delete the original. Any unauthorized use > of > > > > > > > this email is prohibited. > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > > > > > ---------------------- > > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Geopriv mailing list > > > > > > Geopriv@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > -- > > > > > > ---------------------- > > > > > > This message is for the designated recipient only and may > > > > > > contain privileged, proprietary, or otherwise private > > information. > > > > > > If you have received it in error, please notify the sender > > > > > > immediately and delete the original. Any unauthorized use of > > > > > > this email is prohibited. > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > -- > > > > > > ---------------------- > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 22:37:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUvbc-0003qg-PC; Mon, 10 Sep 2007 22:36:00 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUvbb-0003qX-Vn for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 22:35:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUvbb-0003qG-It for geopriv@ietf.org; Mon, 10 Sep 2007 22:35:59 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUvbZ-0004xw-DE for geopriv@ietf.org; Mon, 10 Sep 2007 22:35:59 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_21_45_16 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 21:45:16 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 21:35:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 21:35:49 -0500 Message-ID: In-Reply-To: <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+w References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Winterbottom, James" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 02:35:54.0507 (UTC) FILETIME=[79EB3DB0:01C7F41C] X-Spam-Score: 1.8 (+) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org OK - we can do that.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Origina= l Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASe= nt: Tuesday, 11 September 2007 12:27 PM=0D=0ATo: Dawson, Martin; Winterbott= om, James; Thomson, Martin;=0D=0Ageopriv@ietf.org=0D=0ASubject: RE: [Geopri= v] responseTime reprise=0D=0A=0D=0AI want a distinguished value in the Resp= onseTime field if that is all=0D=0Athere=0D=0Ais.=0D=0A=0D=0A=0D=0A=0D=0A> = -----Original Message-----=0D=0A> From: Dawson, Martin [mailto:Martin.Dawso= n@andrew.com]=0D=0A> Sent: Monday, September 10, 2007 6:41 PM=0D=0A> To: Br= ian Rosen; Winterbottom, James; Thomson, Martin;=0D=0Ageopriv@ietf.org=0D=0A= > Subject: RE: [Geopriv] responseTime reprise=0D=0A>=20=0D=0A> I think the = text you have below is suitable for inclusion in, say, the=0D=0A> ECRIT BCP= =2E We need text for the HELD spec - which I don't think should=0D=0A> be q= uantifying anything. I gather you'd like an optional parameter in=0D=0A> th= e HELD request that is binary and used to indicate that the purpose=0D=0Aof=0D= =0A> the location is for emergency route/dispatch=3F=0D=0A>=20=0D=0A> Cheer= s,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: B= rian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Tuesday, 11 September 20= 07 8:17 AM=0D=0A> To: Winterbottom, James; Dawson, Martin; Thomson, Martin;=0D= =0A> geopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] responseTime reprise=0D= =0A>=20=0D=0A> The proposed text was in the message. Here it is again:=0D=0A= > In some jurisdictions, there are regulations which govern the time=0D=0A>= and/or=0D=0A> accuracy required for emergency calls. When processing an e= mergency=0D=0A> call=0D=0A> location is used in two circumstances: routing = a call to the most=0D=0A> appropriate PSAP, and later, dispatching responde= rs to help the=0D=0Acaller.=0D=0A> Regulations may govern one or both of th= ese circumstances and the=0D=0A> regulation=0D=0A> may specify the accuracy= without specifying time, time without=0D=0A> specifying=0D=0A> accuracy, o= r both time and accuracy. The protocol supports this=0D=0A> possibility. = There are two distinguished values for ResponseTime=0D=0Awhich=0D=0A> are=0D= =0A> used for emergency calls, where there is a locally mandated=0D=0A> tim= e/accuracy=0D=0A> requirements for routing or dispatch. The two values are= :=0D=0A>=20=0D=0A> * EmergencyCallRoute: Used to signal that the locally re= quired values=0D=0A> for=0D=0A> emergency call routing are needed. If ther= e are no local mandates,=0D=0Aand=0D=0A> this=0D=0A> parameter is used, the= server should assume <1KM uncertainty with 95%=0D=0A> confidence in <250 m= s unless the accuracy can be substantially=0D=0Aimproved=0D=0A> by=0D=0A> w= aiting as much as 3 seconds. If the measurement mechanism can make=0D=0A> = substantial improvement by waiting, the wait time should be judged by=0D=0A= > the=0D=0A> server to minimize the time the call is held while getting mos= t of the=0D=0A> gain=0D=0A> in accuracy. If most of the improved uncertain= ty is achieved in 2=0D=0A> seconds,=0D=0A> do not wait the entire 3 seconds= =2E=0D=0A>=20=0D=0A> * EmergencyCallDispatch: Used to signal that the local= ly required=0D=0Avalues=0D=0A> for=0D=0A> emergency call dispatch are neede= d. If there are no local mandates,=0D=0Aand=0D=0A> this parameter is used,= the server should assume <100M uncertainty=0D=0Awith=0D=0A> 95%=0D=0A> con= fidence in <30 sec.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> It would apply to = civic as well as geo, although I don't think any LIS=0D=0A> that=0D=0A> rep= orts civic has any response time (unless it converts and it should=0D=0A> n= ot=0D=0A> convert).=0D=0A>=20=0D=0A> If the LIS can't meet the regulation, = it returns the best it can.=0D=0A>=20=0D=0A> You can request a civic and a = geo in the same message. I don't want=0D=0Ato=0D=0A> say=0D=0A> that you c= ould not have an implementation which could give you an=0D=0A> accurate=0D=0A= > civic and an accurate geo by two different mechanisms and thus the=0D=0A>= request=0D=0A> might make sense. I think that will be rare. As long as y= ou don't=0D=0A> convert,=0D=0A> I'm okay with asking for both. If you do t= hat, and the implementation=0D=0A> can=0D=0A> do both, then you get both.=0D= =0A>=20=0D=0A> I'm not sure what interactions are issues. It's really just= a=0D=0A> distinguished=0D=0A> value for ResponseTime (and/or accuracy if w= e go with Doug's proposal,=0D=0A> which=0D=0A> I like better than just time= ).=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A= > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A>= > Sent: Monday, September 10, 2007 5:47 PM=0D=0A> > To: Brian Rosen; Dawso= n, Martin; Thomson, Martin; geopriv@ietf.org=0D=0A> > Subject: RE: [Geopriv= ] responseTime reprise=0D=0A> >=0D=0A> > Brian,=0D=0A> >=0D=0A> > I think t= hat the first part is actually totally achievable with the=0D=0A> > respons= eTime parameter, and you can certainly check the stats later.=0D=0A> > This= further stresses my point that applications almost always know=0D=0A> > wh= ether the accuracy is good enough to do something with. But I=0D=0Athink=0D= =0A> > what I am hearing from you is that you see a need for a service=0D=0A= > > indicator to the LIS saying, I need this for emergency purposes=0D=0A> = please.=0D=0A> >=0D=0A> > Perhaps I missed what your proposed text was then= , the only=0D=0Asolutions=0D=0A> I=0D=0A> > recall seeing were ones that re= quired network URI profiling ahead of=0D=0A> > time and I know that that ca= n't be done. So would you please repeat=0D=0A> your=0D=0A> > proposal=3F=0D= =0A> >=0D=0A> > On the last point, the legislation might not provide a time=0D= =0A> constraint,=0D=0A> > but we all know that there is one. If it were to = take an hour or=0D=0Aeven=0D=0A> 5=0D=0A> > minutes to get a location that = that would be totally unacceptable in=0D=0A> > this use case. I have descri= bed mobile concierge applications that=0D=0A> only=0D=0A> > have a time con= straint and not really an accuracy one, because they=0D=0A> can=0D=0A> > wo= rk with either geodetic or civic locations.=0D=0A> >=0D=0A> > I am not disc= ounting the use case you propose, I just don't believe=0D=0A> that=0D=0A> >= any proposed solution I have describes how:=0D=0A> >=0D=0A> > 1) It can ap= ply to civic and geo location information=0D=0A> > 2) If I can't meet it, w= hat is the semantic=0D=0A> > 3) If I request a civic and geo in the same lo= cation request, which=0D=0A> > takes precedence, time or accuracy and why=3F=0D= =0A> > 4) How it interacts with other attributes that are already agreed=0D= =0Aupon=0D=0A> >=0D=0A> > Basically any proposed solution needs to address = at least all of=0D=0Athose=0D=0A> > and in an unambiguous way, otherwise I = don't see it as doing much=0D=0Amore=0D=0A> > than throwing a spanner(wrenc= h) in the works.=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> > = > -----Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianr= osen.net]=0D=0A> > > Sent: Tuesday, 11 September 2007 7:20 AM=0D=0A> > > To= : Winterbottom, James; Dawson, Martin; Thomson, Martin;=0D=0A> > geopriv@ie= tf.org=0D=0A> > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D= =0A> > > James=0D=0A> > >=0D=0A> > > In the past, I thought a generalized "= roughly now, whatever=0D=0Aaccuracy=0D=0A> > you=0D=0A> > > can=0D=0A> > > = give me" and "roughly as accurate as you can get, in a reasonable,=0D=0A> b= ut=0D=0A> > > longish time frame" was acceptable. It was pointed out to me= that=0D=0A> > where=0D=0A> > > there is actual regulation, what I asked fo= r may not be one of the=0D=0A> > above.=0D=0A> > > To my knowledge, there a= re no other uses where there is, or might=0D=0A> be,=0D=0A> > > regulation.= So, I'm proposing that there be something that alerts=0D=0A> the=0D=0A> >= LIS=0D=0A> > > that the request is one of those that have to conform to su= ch=0D=0A> > regulation=0D=0A> > > if=0D=0A> > > there is any.=0D=0A> > >=0D= =0A> > > I think what happens when the network cannot deliver what the=0D=0A= > > regulation=0D=0A> > > says is that they get some answer. The authoritie= s also get some=0D=0A> > > statistics=0D=0A> > > that shows them whether th= e regulation is being met within the=0D=0A> > confidence=0D=0A> > > require= ment. After all, confidence is never 100%. Addressing=0D=0Awhat=0D=0A> > = they=0D=0A> > > do=0D=0A> > > about it when the result doesn't meet the reg= ulation is beyond=0D=0Ascope=0D=0A> > no=0D=0A> > > matter how you define i= t.=0D=0A> > >=0D=0A> > > I thought I made a pretty reasonable proposal, wit= h text, as=0D=0Aasked.=0D=0A> I=0D=0A> > > think=0D=0A> > > I have provided= a pretty decent motivation. I fail to see why=0D=0Athis=0D=0A> > should=0D= =0A> > > be an extension, since this is one of (not the only) driving use=0D= =0A> > cases.=0D=0A> > > You=0D=0A> > > can assail me for not recognizing s= ooner that there may have to be=0D=0A> > > something=0D=0A> > > that gets a= predefined accuracy/time trade-off for the emergency=0D=0A> case,=0D=0A> >= but=0D=0A> > > I=0D=0A> > > think that, having recognized it, defined it, = made a specific text=0D=0A> > > proposal,=0D=0A> > > and defended it, that = perhaps you need to show me where I am=0D=0Awrong.=0D=0A> > >=0D=0A> > > In= North America, at present, there is an accuracy requirement for=0D=0A> > >= emergency=0D=0A> > > dispatch on mobile handsets. For handset driven syst= ems like GPS,=0D=0A> > it's=0D=0A> > > <100m 95% of the time. That may or = may not conform to some LIS'=0D=0A> > notion of=0D=0A> > > AGAP. On the ot= her hand, if you tell it that you need dispatch=0D=0A> > location=0D=0A> > = > for=0D=0A> > > an emergency call, and it's in the U.S., it knows EXACTLY = what it=0D=0A> > needs to=0D=0A> > > do. There is no setting of a generali= zed ResponseTime with or=0D=0A> without=0D=0A> > > AGAP/ASAP which would in= dicate <100M with 95% confidence. You=0D=0Awill=0D=0A> > note=0D=0A> > > t= hat the regulation states accuracy without stating response time.=0D=0A> > = >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > >=0D=0A> > > > -----Original Message= -----=0D=0A> > > > From: Winterbottom, James [mailto:James.Winterbottom@and= rew.com]=0D=0A> > > > Sent: Monday, September 10, 2007 4:34 PM=0D=0A> > > >= To: Brian Rosen; Dawson, Martin; Thomson, Martin;=0D=0Ageopriv@ietf.org=0D= =0A> > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > >=0D=0A> = > > > Brian,=0D=0A> > > >=0D=0A> > > > As has been pointed out more times t= han I can count now.=0D=0A> > > > The shape of the curve CANNOT be quantifi= ed ahead of time.=0D=0A> > > >=0D=0A> > > > You state below "In some jurisd= ictions, there are regulations=0D=0A> which=0D=0A> > > > govern the time an= d/or accuracy required for emergency calls."=0D=0A> > > > Can you explain w= hat happens if the accuracy cannot be met in=0D=0Aany=0D=0A> > place,=0D=0A= > > > > does the PSAP get no location at all=3F I am prepared to bet you a=0D= =0A> > beer at=0D=0A> > > > the next IETF that they get something, and that= it is the=0D=0Aprobably=0D=0A> > the=0D=0A> > > > best location that the n= etwork can provide before the ALI=0D=0A> > transaction=0D=0A> > > > times o= ut.=0D=0A> > > >=0D=0A> > > > Until recently you said that you only had two= requirement AGAP=0D=0Aand=0D=0A> > ASAP,=0D=0A> > > > responseTime will gi= ve you that, and it will give us what we=0D=0Awant.=0D=0A> > > > Win-win, a= nd 'best-basis'.=0D=0A> > > >=0D=0A> > > > If you want something more than = repsonseTime, as you indicate=0D=0A> below,=0D=0A> > > > then that can be a= n extension and I challenge you to write a=0D=0Adraft=0D=0A> > that=0D=0A> = > > > can do this.=0D=0A> > > >=0D=0A> > > > Cheers=0D=0A> > > > James=0D=0A= > > > >=0D=0A> > > > > -----Original Message-----=0D=0A> > > > > From: Bria= n Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > Sent: Tuesday, 11 Septemb= er 2007 1:10 AM=0D=0A> > > > > To: Dawson, Martin; Thomson, Martin; geopriv= @ietf.org=0D=0A> > > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A>= > > > >=0D=0A> > > > > I don't think so. Someone needs to judge "substant= ial=0D=0A> > improvement".=0D=0A> > > > It=0D=0A> > > > > could be the serv= er if it knew that is what you want. It=0D=0Acould=0D=0A> be=0D=0A> > the=0D= =0A> > > > > client if it knew what the server could do. Just putting the=0D= =0A> time=0D=0A> > > > > parameter=0D=0A> > > > > doesn't have a way to exp= ress anything other than the=0D=0Asimplistic=0D=0A> > "wait=0D=0A> > > > 3=0D= =0A> > > > > seconds" if anything can be done in those 3 seconds. You=0D=0A= might=0D=0A> > get,=0D=0A> > > > say,=0D=0A> > > > > 30% improvement from .= 25 sec to 3 sec. If that was the case,=0D=0A> your=0D=0A> > > > > mechanis= m=0D=0A> > > > > would wait 3 seconds. I would not want that to happen. I=0D= =0Awant=0D=0A> > > > someone to=0D=0A> > > > > judge when it's not worth wa= iting more for. That might be 1=0D=0A> > second,=0D=0A> > > > or 2=0D=0A> = > > > > seconds. Depends on the shape of the curve.=0D=0A> > > > >=0D=0A> = > > > > Whatever parameters are decided upon, we may need two=0D=0A> > dist= inguished=0D=0A> > > > values=0D=0A> > > > > that are "use locally mandated= limits for emergency call=0D=0A> routing"=0D=0A> > and=0D=0A> > > > the=0D= =0A> > > > > same for dispatch. If we're stuck with ResponseTime alone:=0D= =0A> > > > >=0D=0A> > > > > In some jurisdictions, there are regulations wh= ich govern the=0D=0A> time=0D=0A> > > > and/or=0D=0A> > > > > accuracy requ= ired for emergency calls. When processing an=0D=0A> > emergency=0D=0A> > >= > call=0D=0A> > > > > location is used in two circumstances: routing a cal= l to the=0D=0A> most=0D=0A> > > > > appropriate PSAP, and later, dispatchin= g responders to help=0D=0Athe=0D=0A> > > > caller.=0D=0A> > > > > Regulatio= ns may govern one or both of these circumstances and=0D=0A> the=0D=0A> > > = > > regulation=0D=0A> > > > > may specify the accuracy without specifying t= ime, time without=0D=0A> > > > specifying=0D=0A> > > > > accuracy, or both = time and accuracy. The protocol supports=0D=0Athis=0D=0A> > > > > possibil= ity. There are two distinguished values for=0D=0A> ResponseTime=0D=0A> > >= > which=0D=0A> > > > > are=0D=0A> > > > > used for emergency calls, where = there is a locally mandated=0D=0A> > > > time/accuracy=0D=0A> > > > > requi= rements for routing or dispatch. The two values are:=0D=0A> > > > >=0D=0A>= > > > > * EmergencyCallRoute: Used to signal that the locally required=0D=0A= > > values=0D=0A> > > > for=0D=0A> > > > > emergency call routing are neede= d. If there are no local=0D=0A> > mandates,=0D=0A> > > > and=0D=0A> > > > = > this=0D=0A> > > > > parameter is used, the server should assume <1KM unce= rtainty=0D=0A> with=0D=0A> > 95%=0D=0A> > > > > confidence in <250 ms unles= s the accuracy can be substantially=0D=0A> > > > improved by=0D=0A> > > > >= waiting as much as 3 seconds. If the measurement mechanism=0D=0Acan=0D=0A= > > make=0D=0A> > > > > substantial improvement by waiting, the wait time s= hould be=0D=0A> judged=0D=0A> > by=0D=0A> > > > the=0D=0A> > > > > server t= o minimize the time the call is held while getting=0D=0Amost=0D=0A> of=0D=0A= > > the=0D=0A> > > > > gain=0D=0A> > > > > in accuracy. If most of the imp= roved uncertainty is achieved=0D=0Ain=0D=0A> 2=0D=0A> > > > > seconds,=0D=0A= > > > > > do not wait the entire 3 seconds.=0D=0A> > > > >=0D=0A> > > > > *= EmergencyCallDispatch: Used to signal that the locally=0D=0A> required=0D=0A= > > > > values=0D=0A> > > > > for=0D=0A> > > > > emergency call dispatch ar= e needed. If there are no local=0D=0A> > mandates,=0D=0A> > > > and=0D=0A>= > > > > this parameter is used, the server should assume <100M=0D=0A> unce= rtainty=0D=0A> > > > with=0D=0A> > > > > 95%=0D=0A> > > > > confidence in <= 30 sec.=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > > As HELD= is a text language, perhaps these strings can be used.=0D=0A> If=0D=0A> > = we=0D=0A> > > > need=0D=0A> > > > > to assign integer values to them, then = we'll pick something.=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > > > -----O= riginal Message-----=0D=0A> > > > > > From: Dawson, Martin [mailto:Martin.D= awson@andrew.com]=0D=0A> > > > > > Sent: Monday, September 10, 2007 10:26 A= M=0D=0A> > > > > > To: Brian Rosen; Thomson, Martin; geopriv@ietf.org=0D=0A= > > > > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > > > >=0D= =0A> > > > > > You put three seconds in as the response time. If a more=0D=0A= > > accurate=0D=0A> > > > > > location can be provided in 3 seconds, it wil= l take that=0D=0Along,=0D=0A> > if=0D=0A> > > > not it=0D=0A> > > > > > wil= l respond even faster.=0D=0A> > > > > >=0D=0A> > > > > > What's more, if th= e next application running on the device=0D=0Acan=0D=0A> > > > actually=0D=0A= > > > > > > wait 20 seconds, it can state "20 seconds" and may actually=0D=0A= > > > > subsequently=0D=0A> > > > > > get a more accurate location which ma= y take anywhere from 3=0D=0Ato=0D=0A> > 20=0D=0A> > > > > > seconds to retu= rn.=0D=0A> > > > > >=0D=0A> > > > > > Simple.=0D=0A> > > > > >=0D=0A> > > >= > > If you really think that there is a need for a "please give=0D=0Ame=0D= =0A> > > > location=0D=0A> > > > > > in the time mandated by the jurisdicti= on in which I am=0D=0A> currently=0D=0A> > > > > > operating" semantic then= please send text. Nobody has=0D=0A> suggested=0D=0A> > that=0D=0A> > > > i= s=0D=0A> > > > > > what response time satisfies - and you have not proposed=0D= =0A> > anything=0D=0A> > > > that=0D=0A> > > > > > satisfies it either. Suc= h a mechanism is not mutually=0D=0A> exclusive=0D=0A> > to=0D=0A> > > > an=0D= =0A> > > > > > optional response time parameter.=0D=0A> > > > > >=0D=0A> > = > > > > Cheers,=0D=0A> > > > > > Martin=0D=0A> > > > > >=0D=0A> > > > > > -= ----Original Message-----=0D=0A> > > > > > From: Brian Rosen [mailto:br@bri= anrosen.net]=0D=0A> > > > > > Sent: Monday, 10 September 2007 11:25 PM=0D=0A= > > > > > > To: Thomson, Martin; geopriv@ietf.org=0D=0A> > > > > > Subject:= RE: [Geopriv] responseTime reprise=0D=0A> > > > > >=0D=0A> > > > > > I was= working in updates to phonebcp and framework and here=0D=0Ais=0D=0A> > the=0D= =0A> > > > spec=0D=0A> > > > > > I=0D=0A> > > > > > want to have:=0D=0A> > = > > > >=0D=0A> > > > > > ED-25/AN-14 It is RECOMMENDED that location determ= ination=0D=0Anot=0D=0A> > take=0D=0A> > > > > > longer=0D=0A> > > > > > tha= n 250 ms to obtain routing location and systems SHOULD be=0D=0A> > > > desi= gned=0D=0A> > > > > > such=0D=0A> > > > > > that the typical response is un= der 100ms. However, as much=0D=0Aas=0D=0A> 3=0D=0A> > > > seconds=0D=0A> > = > > > > to=0D=0A> > > > > > obtain routing location MAY be tolerated if loc= ation=0D=0Aaccuracy=0D=0A> > can be=0D=0A> > > > > > substantially improved= over what can be obtained in 250 ms.=0D=0A> > > > > >=0D=0A> > > > > > How= would you express that with your parameter=3F=0D=0A> > > > > >=0D=0A> > > = > > > The equivalent for dispatch location is:=0D=0A> > > > > > Generally, = the PSAP can wait for an accurate location for=0D=0A> > dispatch.=0D=0A> > = > > > > However, there is no fixed time known in advance which is=0D=0Athe=0D= =0A> > limit;=0D=0A> > > > it=0D=0A> > > > > > depends on the nature of the= emergency. At some point the=0D=0A> PSAP=0D=0A> > must=0D=0A> > > > > > d= ispatch. In a subscription environment, the PSAP could=0D=0A> update=0D=0A= > > the=0D=0A> > > > > > parameters in the filter (immediate response requi= red). In=0D=0Aa=0D=0A> > HELD=0D=0A> > > > > > dereference, there is no wa= y to cancel and the PSAP will=0D=0Ahave=0D=0A> to=0D=0A> > > > choose=0D=0A= > > > > > > a=0D=0A> > > > > > ResponseTime that it will wait for even if i= t wants to=0D=0A> dispatch=0D=0A> > > > sooner=0D=0A> > > > > > than=0D=0A>= > > > > > that. =0D=0A>= > > > > >=0D=0A> > > > > > We then get to a complication. It may be the c= ase in some=0D=0A> > > > jurisdictions=0D=0A> > > > > > that there are regu= lations that govern this. In those=0D=0Acases,=0D=0A> we=0D=0A> > may=0D=0A= > > > > > > need a=0D=0A> > > > > > way to say "I need the regulation-impos= ed values for=0D=0Aemergency=0D=0A> > call=0D=0A> > > > > > route",=0D=0A> = > > > > > or the equivalent for dispatch.=0D=0A> > > > > >=0D=0A> > > > > >= Brian=0D=0A> > > > > >=0D=0A> > > > > > > -----Original Message-----=0D=0A= > > > > > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A= > > > > > > > Sent: Monday, September 10, 2007 3:22 AM=0D=0A> > > > > > > T= o: geopriv@ietf.org=0D=0A> > > > > > > Subject: [Geopriv] responseTime repr= ise=0D=0A> > > > > > >=0D=0A> > > > > > > I'm probably due to step into the= ring on this topic. I=0D=0A> > apologise=0D=0A> > > > for=0D=0A> > > > > = > > anything that is rehashed, I have not read the _entire_=0D=0A> > archiv= e on=0D=0A> > > > > > this=0D=0A> > > > > > > topic.=0D=0A> > > > > > >=0D=0A= > > > > > > > The main reason the responseTime parameter was proposed=0D=0A= was=0D=0A> > our=0D=0A> > > > > > collective=0D=0A> > > > > > > experience = with cellular systems.=0D=0A> > > > > > >=0D=0A> > > > > > > 3GPP have defi= ned two values: "low delay" and "delay=0D=0A> > tolerant",=0D=0A> > > > whi= ch=0D=0A> > > > > > > roughly correspond to what some have been advocating.=0D= =0A> > However,=0D=0A> > > > where=0D=0A> > > > > > > multiple network node= s are involved in serving a request=0D=0A> (and=0D=0A> > 3GPP=0D=0A> > > > = > > relies=0D=0A> > > > > > > on about 6), engineering is required to ensur= e smooth=0D=0A> > operation.=0D=0A> > > > Each=0D=0A> > > > > > > node is c= onfigured with a different timeout so that the=0D=0Atime=0D=0A> > that=0D=0A= > > > > the=0D=0A> > > > > > node=0D=0A> > > > > > > adds to the transactio= n doesn't cause failures. This=0D=0A> > engineering=0D=0A> > > > > > ensur= es=0D=0A> > > > > > > that each location client receives a certain level of=0D= =0A> service.=0D=0A> > > > > > >=0D=0A> > > > > > > Of course, each network= is engineered differently.=0D=0AEveryone=0D=0A> > has a=0D=0A> > > > > > >= different idea of what "low delay" and "delay tolerant"=0D=0A> mean.=0D=0A= > > In=0D=0A> > > > a=0D=0A> > > > > > closed=0D=0A> > > > > > > network th= is more or less works; although this isn't=0D=0Aassured=0D=0A> > for=0D=0A>= > > > > > roamers.=0D=0A> > > > > > > We wanted to avoid this problem. It= makes sense to allow=0D=0A> > devolve=0D=0A> > > > the=0D=0A> > > > > > > = parameter; rather than place an arbitrary value on some=0D=0A> > abstract=0D= =0A> > > > > > codes,=0D=0A> > > > > > > allow the client to decide.=0D=0A>= > > > > > >=0D=0A> > > > > > > To add to this, during my break, we had a r= equest for=0D=0A> further=0D=0A> > > > control=0D=0A> > > > > > over=0D=0A>= > > > > > > these values on one of our cellular products. In this=0D=0A> = > request,=0D=0A> > > > > > different=0D=0A> > > > > > > types of clients w= ould be given varying amounts of time.=0D=0A> > Thus,=0D=0A> > > > from=0D=0A= > > > > > > our=0D=0A> > > > > > > perspective, we have a clear requirement= for responseTime.=0D=0A> > > > > > >=0D=0A> > > > > > > To those who want = hard limits; BCP documents are a good=0D=0A> place=0D=0A> > for=0D=0A> > > = > > > > recommendations. You can add nice statements like: "if=0D=0A> > ro= uting=0D=0A> > > > for=0D=0A> > > > > > > emergency calls, set responseTime= to x seconds; if you=0D=0Adon't=0D=0A> > care,=0D=0A> > > > > > allow y=0D= =0A> > > > > > > seconds".=0D=0A> > > > > > >=0D=0A> > > > > > > Ta,=0D=0A>= > > > > > > Martin=0D=0A> > > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A>= >=0D=0A>=0D=0A------------------------------------------------------------= ------------=0D=0A> > > > > > --=0D=0A> > > > > > > ----------------------=0D= =0A> > > > > > > This message is for the designated recipient only and may=0D= =0A> > > > > > > contain privileged, proprietary, or otherwise private=0D=0A= > > information.=0D=0A> > > > > > > If you have received it in error, pleas= e notify the sender=0D=0A> > > > > > > immediately and delete the original.= Any unauthorized use=0D=0A> of=0D=0A> > > > > > > this email is prohibite= d.=0D=0A> > > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A>=0D=0A--= ----------------------------------------------------------------------=0D=0A= > > > > > > --=0D=0A> > > > > > > ----------------------=0D=0A> > > > > > >= [mf2]=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > > > = _______________________________________________=0D=0A> > > > > > Geopriv ma= iling list=0D=0A> > > > > > Geopriv@ietf.org=0D=0A> > > > > > https://www1.= ietf.org/mailman/listinfo/geopriv=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> = > > >=0D=0A> >=0D=0A>=0D=0A------------------------------------------------= ------------------------=0D=0A> > > > > --=0D=0A> > > > > > ---------------= -------=0D=0A> > > > > > This message is for the designated recipient only = and may=0D=0A> > > > > > contain privileged, proprietary, or otherwise priv= ate=0D=0A> > information.=0D=0A> > > > > > If you have received it in error= , please notify the sender=0D=0A> > > > > > immediately and delete the orig= inal. Any unauthorized use=0D=0Aof=0D=0A> > > > > > this email is prohibit= ed.=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A>=0D=0A--------------------= ----------------------------------------------------=0D=0A> > > > > --=0D=0A= > > > > > > ----------------------=0D=0A> > > > > > [mf2]=0D=0A> > > > >=0D= =0A> > > > >=0D=0A> > > > >=0D=0A> > > > > ________________________________= _______________=0D=0A> > > > > Geopriv mailing list=0D=0A> > > > > Geopriv@= ietf.org=0D=0A> > > > > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A= > > > >=0D=0A> > > >=0D=0A> >=0D=0A>=0D=0A---------------------------------= ---------------------------------------=0D=0A> > > --=0D=0A> > > > --------= --------------=0D=0A> > > > This message is for the designated recipient on= ly and may=0D=0A> > > > contain privileged, proprietary, or otherwise priva= te=0D=0Ainformation.=0D=0A> > > > If you have received it in error, please = notify the sender=0D=0A> > > > immediately and delete the original. Any un= authorized use of=0D=0A> > > > this email is prohibited.=0D=0A> > > >=0D=0A= > >=0D=0A>=0D=0A-----------------------------------------------------------= -------------=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > = > [mf2]=0D=0A> > >=0D=0A> >=0D=0A> >=0D=0A>=0D=0A--------------------------= ----------------------------------------------=0D=0A> --=0D=0A> > ---------= -------------=0D=0A> > This message is for the designated recipient only an= d may=0D=0A> > contain privileged, proprietary, or otherwise private inform= ation.=0D=0A> > If you have received it in error, please notify the sender=0D= =0A> > immediately and delete the original. Any unauthorized use of=0D=0A>= > this email is prohibited.=0D=0A> >=0D=0A>=0D=0A-------------------------= -----------------------------------------------=0D=0A> --=0D=0A> > --------= --------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A>=20=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A--=0D=0A> = ----------------------=0D=0A> This message is for the designated recipient = only and may=0D=0A> contain privileged, proprietary, or otherwise private i= nformation.=0D=0A> If you have received it in error, please notify the send= er=0D=0A> immediately and delete the original. Any unauthorized use of=0D=0A= > this email is prohibited.=0D=0A>=0D=0A-----------------------------------= -------------------------------------=0D=0A--=0D=0A> ----------------------=0D= =0A> [mf2]=0D=0A=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 10 22:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUveo-0007Iz-Jx; Mon, 10 Sep 2007 22:39:18 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUven-0007Hx-Kl for geopriv-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 22:39:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUven-0007Hp-80 for geopriv@ietf.org; Mon, 10 Sep 2007 22:39:17 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUvel-000522-BY for geopriv@ietf.org; Mon, 10 Sep 2007 22:39:17 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUvek-0005cj-6i; Mon, 10 Sep 2007 21:39:14 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Winterbottom, James'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 22:39:11 -0400 Message-ID: <038f01c7f41c$f130b030$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAAqTLMAAI84zA In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b6435b1bfa5977f2eb96dc7e52434b6d Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I suggested that there may be regulation that defines what the LIS must do, and asked for a way for the client to signal the server that it needed to follow the regulation. I don't think we should extend this to another application that did not have a regulatory or other fixed, and known to the LIS requirement. I used the actual requirement, which has no time value and only has an accuracy value, albeit that there are generally accepted time values. The requirement is stated as an accuracy requirement. There is no way for the PSAP to signal that it requires <100M accuracy with 95% confidence. It could only signal <30 sec. That is most decidedly NOT the same thing. The distinguished value in ResponseTime is specifically to get around the limitation you want to have that only time can be specified. It's much more specific than ASAP/AGAP, and it has to be. I WANT something that allows me to specify accuracy as well as time. I WANT a way to find out what a reasonable request of the server is. I can compromise through those things. On the other hand I NEED (as in hard requirement), a way to tell the LIS to meet the regulation. I don't think I can compromise there. I don't need to use my suggested mechanism, but I need a way to signal that the LIS must meet the regulation, if any. I don't think ASAP/AGAP does that. I know just having a scalar in ResponseTime can't do that. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Monday, September 10, 2007 6:33 PM > To: Brian Rosen; Winterbottom, James; Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > Brian, > > I think what you have actually done is taken the first step to > acknowledging that different applications have different time > requirements. What your proposal does, is provide an *application > specific* flag that then translates to a specific hard-coded response > time (best fit) for an emergency application. You now need to take the > next step and recognize that you've just covered one possible > application - and you've chosen one that the LIS may be in the best > place to ascribe the response time for. Now you need to recognize that > there are applications that the client wants to ascribe the response > times for. > > " To my knowledge, there are no other uses where there is, or might be, > regulation." - this I find to be a strange statement. It seems to > suggest that response time is only relevant if there's a regulatory > imperative to have it. Friend finders, fleet and asset tracking, > presence registration, hot desk location registration, navigation, > location concierge,... all these applications can and do have their own > optimal response times. > > Now - I'm happy to support your suggestion of what is effectively an > "emergency request" indicator flag in the base request semantics. Let > the LIS apply local policy as to what is the standard response time for > that request in that jurisdiction - good idea. As I think you note, you > may want "emergency route", and "emergency dispatch" flags. Frankly, I > think the emergency dispatch request is likely to originate from the > PSAP and it will know what response time applies and could just use the > response time parameter; then PSAPs could apply their own requirements > and not assume a one size fits all by jurisdiction. This flag can > co-exist with the response time parameter so there's no reason to block > either on the basis of the other in the spec unless you just want to be > difficult. > > I don't think you've provided any useful text on a "LIS profiling" set > of semantics. It is going to have to be quite involved - including the > second phase aspect of how the client identifies which of the profile > points it wants to invoke as the actual request. I certainly haven't > seen a comprehensive and coherent proposal for this. Since I neither > feel the need for the mechanism, nor see any practical way to implement > it given the state of the art, I have no inclination to spend time > developing that proposal. That ball is in your court. Hopefully we can > both agree that it can comfortably live in extension land. BTW - any LIS > that decided to take an order of magnitude longer for a location > technology that generally only provided a miniscule or generally > negligible improvement in accuracy would be a poor LIS. Your point is > valid in theory; your profiling technology addresses it in theory. I > don't think that either have any practical basis. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, 11 September 2007 7:20 AM > To: Winterbottom, James; Dawson, Martin; Thomson, Martin; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > James > > In the past, I thought a generalized "roughly now, whatever accuracy you > can > give me" and "roughly as accurate as you can get, in a reasonable, but > longish time frame" was acceptable. It was pointed out to me that where > there is actual regulation, what I asked for may not be one of the > above. > To my knowledge, there are no other uses where there is, or might be, > regulation. So, I'm proposing that there be something that alerts the > LIS > that the request is one of those that have to conform to such regulation > if > there is any. > > I think what happens when the network cannot deliver what the regulation > says is that they get some answer. The authorities also get some > statistics > that shows them whether the regulation is being met within the > confidence > requirement. After all, confidence is never 100%. Addressing what they > do > about it when the result doesn't meet the regulation is beyond scope no > matter how you define it. > > I thought I made a pretty reasonable proposal, with text, as asked. I > think > I have provided a pretty decent motivation. I fail to see why this > should > be an extension, since this is one of (not the only) driving use cases. > You > can assail me for not recognizing sooner that there may have to be > something > that gets a predefined accuracy/time trade-off for the emergency case, > but I > think that, having recognized it, defined it, made a specific text > proposal, > and defended it, that perhaps you need to show me where I am wrong. > > In North America, at present, there is an accuracy requirement for > emergency > dispatch on mobile handsets. For handset driven systems like GPS, it's > <100m 95% of the time. That may or may not conform to some LIS' notion > of > AGAP. On the other hand, if you tell it that you need dispatch location > for > an emergency call, and it's in the U.S., it knows EXACTLY what it needs > to > do. There is no setting of a generalized ResponseTime with or without > AGAP/ASAP which would indicate <100M with 95% confidence. You will note > that the regulation states accuracy without stating response time. > > Brian > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, September 10, 2007 4:34 PM > > To: Brian Rosen; Dawson, Martin; Thomson, Martin; geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > Brian, > > > > As has been pointed out more times than I can count now. > > The shape of the curve CANNOT be quantified ahead of time. > > > > You state below "In some jurisdictions, there are regulations which > > govern the time and/or accuracy required for emergency calls." > > Can you explain what happens if the accuracy cannot be met in any > place, > > does the PSAP get no location at all? I am prepared to bet you a beer > at > > the next IETF that they get something, and that it is the probably the > > best location that the network can provide before the ALI transaction > > times out. > > > > Until recently you said that you only had two requirement AGAP and > ASAP, > > responseTime will give you that, and it will give us what we want. > > Win-win, and 'best-basis'. > > > > If you want something more than repsonseTime, as you indicate below, > > then that can be an extension and I challenge you to write a draft > that > > can do this. > > > > Cheers > > James > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, 11 September 2007 1:10 AM > > > To: Dawson, Martin; Thomson, Martin; geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > I don't think so. Someone needs to judge "substantial improvement". > > It > > > could be the server if it knew that is what you want. It could be > the > > > client if it knew what the server could do. Just putting the time > > > parameter > > > doesn't have a way to express anything other than the simplistic > "wait > > 3 > > > seconds" if anything can be done in those 3 seconds. You might get, > > say, > > > 30% improvement from .25 sec to 3 sec. If that was the case, your > > > mechanism > > > would wait 3 seconds. I would not want that to happen. I want > > someone to > > > judge when it's not worth waiting more for. That might be 1 second, > > or 2 > > > seconds. Depends on the shape of the curve. > > > > > > Whatever parameters are decided upon, we may need two distinguished > > values > > > that are "use locally mandated limits for emergency call routing" > and > > the > > > same for dispatch. If we're stuck with ResponseTime alone: > > > > > > In some jurisdictions, there are regulations which govern the time > > and/or > > > accuracy required for emergency calls. When processing an emergency > > call > > > location is used in two circumstances: routing a call to the most > > > appropriate PSAP, and later, dispatching responders to help the > > caller. > > > Regulations may govern one or both of these circumstances and the > > > regulation > > > may specify the accuracy without specifying time, time without > > specifying > > > accuracy, or both time and accuracy. The protocol supports this > > > possibility. There are two distinguished values for ResponseTime > > which > > > are > > > used for emergency calls, where there is a locally mandated > > time/accuracy > > > requirements for routing or dispatch. The two values are: > > > > > > * EmergencyCallRoute: Used to signal that the locally required > values > > for > > > emergency call routing are needed. If there are no local mandates, > > and > > > this > > > parameter is used, the server should assume <1KM uncertainty with > 95% > > > confidence in <250 ms unless the accuracy can be substantially > > improved by > > > waiting as much as 3 seconds. If the measurement mechanism can make > > > substantial improvement by waiting, the wait time should be judged > by > > the > > > server to minimize the time the call is held while getting most of > the > > > gain > > > in accuracy. If most of the improved uncertainty is achieved in 2 > > > seconds, > > > do not wait the entire 3 seconds. > > > > > > * EmergencyCallDispatch: Used to signal that the locally required > > values > > > for > > > emergency call dispatch are needed. If there are no local mandates, > > and > > > this parameter is used, the server should assume <100M uncertainty > > with > > > 95% > > > confidence in <30 sec. > > > > > > > > > > > > As HELD is a text language, perhaps these strings can be used. If > we > > need > > > to assign integer values to them, then we'll pick something. > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Monday, September 10, 2007 10:26 AM > > > > To: Brian Rosen; Thomson, Martin; geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > You put three seconds in as the response time. If a more accurate > > > > location can be provided in 3 seconds, it will take that long, if > > not it > > > > will respond even faster. > > > > > > > > What's more, if the next application running on the device can > > actually > > > > wait 20 seconds, it can state "20 seconds" and may actually > > subsequently > > > > get a more accurate location which may take anywhere from 3 to 20 > > > > seconds to return. > > > > > > > > Simple. > > > > > > > > If you really think that there is a need for a "please give me > > location > > > > in the time mandated by the jurisdiction in which I am currently > > > > operating" semantic then please send text. Nobody has suggested > that > > is > > > > what response time satisfies - and you have not proposed anything > > that > > > > satisfies it either. Such a mechanism is not mutually exclusive to > > an > > > > optional response time parameter. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Monday, 10 September 2007 11:25 PM > > > > To: Thomson, Martin; geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > I was working in updates to phonebcp and framework and here is the > > spec > > > > I > > > > want to have: > > > > > > > > ED-25/AN-14 It is RECOMMENDED that location determination not take > > > > longer > > > > than 250 ms to obtain routing location and systems SHOULD be > > designed > > > > such > > > > that the typical response is under 100ms. However, as much as 3 > > seconds > > > > to > > > > obtain routing location MAY be tolerated if location accuracy can > be > > > > substantially improved over what can be obtained in 250 ms. > > > > > > > > How would you express that with your parameter? > > > > > > > > The equivalent for dispatch location is: > > > > Generally, the PSAP can wait for an accurate location for > dispatch. > > > > However, there is no fixed time known in advance which is the > limit; > > it > > > > depends on the nature of the emergency. At some point the PSAP > must > > > > dispatch. In a subscription environment, the PSAP could update > the > > > > parameters in the filter (immediate response required). In a HELD > > > > dereference, there is no way to cancel and the PSAP will have to > > choose > > > > a > > > > ResponseTime that it will wait for even if it wants to dispatch > > sooner > > > > than > > > > that. > > > > > > > > We then get to a complication. It may be the case in some > > jurisdictions > > > > that there are regulations that govern this. In those cases, we > may > > > > need a > > > > way to say "I need the regulation-imposed values for emergency > call > > > > route", > > > > or the equivalent for dispatch. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > > > Sent: Monday, September 10, 2007 3:22 AM > > > > > To: geopriv@ietf.org > > > > > Subject: [Geopriv] responseTime reprise > > > > > > > > > > I'm probably due to step into the ring on this topic. I > apologise > > for > > > > > anything that is rehashed, I have not read the _entire_ archive > on > > > > this > > > > > topic. > > > > > > > > > > The main reason the responseTime parameter was proposed was our > > > > collective > > > > > experience with cellular systems. > > > > > > > > > > 3GPP have defined two values: "low delay" and "delay tolerant", > > which > > > > > roughly correspond to what some have been advocating. However, > > where > > > > > multiple network nodes are involved in serving a request (and > 3GPP > > > > relies > > > > > on about 6), engineering is required to ensure smooth operation. > > Each > > > > > node is configured with a different timeout so that the time > that > > the > > > > node > > > > > adds to the transaction doesn't cause failures. This > engineering > > > > ensures > > > > > that each location client receives a certain level of service. > > > > > > > > > > Of course, each network is engineered differently. Everyone has > a > > > > > different idea of what "low delay" and "delay tolerant" mean. > In > > a > > > > closed > > > > > network this more or less works; although this isn't assured for > > > > roamers. > > > > > We wanted to avoid this problem. It makes sense to allow > devolve > > the > > > > > parameter; rather than place an arbitrary value on some abstract > > > > codes, > > > > > allow the client to decide. > > > > > > > > > > To add to this, during my break, we had a request for further > > control > > > > over > > > > > these values on one of our cellular products. In this request, > > > > different > > > > > types of clients would be given varying amounts of time. Thus, > > from > > > > our > > > > > perspective, we have a clear requirement for responseTime. > > > > > > > > > > To those who want hard limits; BCP documents are a good place > for > > > > > recommendations. You can add nice statements like: "if routing > > for > > > > > emergency calls, set responseTime to x seconds; if you don't > care, > > > > allow y > > > > > seconds". > > > > > > > > > > Ta, > > > > > Martin > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 00:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUwwC-0007Rw-S1; Tue, 11 Sep 2007 00:01:20 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IUwwB-0007Rq-O0 for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 00:01:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUwwB-0007Ri-EQ for geopriv@ietf.org; Tue, 11 Sep 2007 00:01:19 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUwwA-0005Wf-2j for geopriv@ietf.org; Tue, 11 Sep 2007 00:01:19 -0400 X-SEF-Processed: 5_0_0_910__2007_09_10_23_10_35 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 10 Sep 2007 23:10:35 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Sep 2007 23:01:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Mon, 10 Sep 2007 23:01:11 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZA= References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Dawson, Martin" , "Brian Rosen" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 04:01:13.0366 (UTC) FILETIME=[64FF2360:01C7F428] X-Spam-Score: 1.8 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org So here is my proposal.=0D=0A=0D=0A=0D=0A=09=0D=0A=09=09civic=0D=0A=09=09ge= odetic=0D=0A=09=09locationURI=0D=0A=09=0D=0A=0D=0A=0D=0AThis request says give me location for routing an emergency c= all within=0D=0A3 seconds please. Where svc is a new attribute specifying w= hat you want=0D=0Ait for. This could be an IANA registry item if we wanted = to go that far.=0D=0A=0D=0ASimilarly if you want location for dispatch:=0D=0A=0D= =0A=0D=0A=09= =0D=0A=09=09civic=0D=0A=09=09geodetic=0D=0A=09=0D= =0A=0D=0A=0D=0AYou could even ditch the 30 seconds if the= thing making the request=0D=0Adoesn't care how long it takes.=0D=0A=0D=0AB= rian, can you live with this=3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Dawson, Martin=0D=0A> Sent: Tu= esday, 11 September 2007 12:36 PM=0D=0A> To: Brian Rosen; Winterbottom, Jam= es; Thomson, Martin;=0D=0Ageopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] re= sponseTime reprise=0D=0A>=20=0D=0A> OK - we can do that.=0D=0A>=20=0D=0A> C= heers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> Fro= m: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Tuesday, 11 Septembe= r 2007 12:27 PM=0D=0A> To: Dawson, Martin; Winterbottom, James; Thomson, Ma= rtin;=0D=0Ageopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] responseTime repr= ise=0D=0A>=20=0D=0A> I want a distinguished value in the ResponseTime field= if that is all=0D=0A> there=0D=0A> is.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A= > > -----Original Message-----=0D=0A> > From: Dawson, Martin [mailto:Martin= =2EDawson@andrew.com]=0D=0A> > Sent: Monday, September 10, 2007 6:41 PM=0D=0A= > > To: Brian Rosen; Winterbottom, James; Thomson, Martin;=0D=0Ageopriv@iet= f.org=0D=0A> > Subject: RE: [Geopriv] responseTime reprise=0D=0A> >=0D=0A> = > I think the text you have below is suitable for inclusion in, say,=0D=0At= he=0D=0A> > ECRIT BCP. We need text for the HELD spec - which I don't think=0D= =0Ashould=0D=0A> > be quantifying anything. I gather you'd like an optional= parameter=0D=0Ain=0D=0A> > the HELD request that is binary and used to ind= icate that the=0D=0Apurpose of=0D=0A> > the location is for emergency route= /dispatch=3F=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > --= ---Original Message-----=0D=0A=0D=0A---------------------------------------= ---------------------------------------------------------=0D=0AThis message= is for the designated recipient only and may=0D=0Acontain privileged, prop= rietary, or otherwise private information. =20=0D=0AIf you have received it= in error, please notify the sender=0D=0Aimmediately and delete the origina= l. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------= ---------------------------------------------------------------------------= ----------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Phon.oi@arroyoinsurance.com Tue Sep 11 04:53:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1UR-0003zU-WF for geopriv-archive@lists.ietf.org; Tue, 11 Sep 2007 04:53:00 -0400 Received: from 0x573244af.hgnxx2.adsl-dhcp.tele.dk ([87.50.68.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV1TW-0003MB-5o for geopriv-archive@lists.ietf.org; Tue, 11 Sep 2007 04:52:59 -0400 Received: from p9kjtkc2rs2c1kf ([183.147.134.124] helo=p9kjtkc2rs2c1kf) by 0x573244af.hgnxx2.adsl-dhcp.tele.dk ( sendmail 8.13.3/8.13.1) with esmtpa id 1xbDww-000CLT-nR for geopriv-archive@lists.ietf.org; Tue, 11 Sep 2007 10:52:30 +0200 Message-ID: <000501c7f451$0670c2d0$af443257@p9kjtkc2rs2c1kf> From: "Phon oi" To: Subject: denwot Date: Tue, 11 Sep 2007 10:52:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7F461.C9F992D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C7F461.C9F992D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.mathun.net/ Wazzup geopriv-archive i am the most confident person around mantaj soo ------=_NextPart_000_0006_01C7F461.C9F992D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.mathun.net/
Wazzup geopriv-archive
i am the most confident person = around
mantaj soo
------=_NextPart_000_0006_01C7F461.C9F992D0-- From geopriv-bounces@ietf.org Tue Sep 11 08:26:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4nH-0000M5-7q; Tue, 11 Sep 2007 08:24:39 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IV4nG-0000Lg-E2 for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 08:24:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4nG-0000LX-2f for geopriv@ietf.org; Tue, 11 Sep 2007 08:24:38 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV4nF-0002aZ-J2 for geopriv@ietf.org; Tue, 11 Sep 2007 08:24:37 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IV4n6-0000ib-KP; Tue, 11 Sep 2007 07:24:28 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Dawson, Martin'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 08:24:32 -0400 Message-ID: <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgA== In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Can I live with it? Yes. I think defining two tokens that can go in ResponseTime is easier. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, September 11, 2007 12:01 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > So here is my proposal. > > > > civic > geodetic > locationURI > > > > This request says give me location for routing an emergency call within > 3 seconds please. Where svc is a new attribute specifying what you want > it for. This could be an IANA registry item if we wanted to go that far. > > Similarly if you want location for dispatch: > > > > civic > geodetic > > > > You could even ditch the 30 seconds if the thing making the request > doesn't care how long it takes. > > Brian, can you live with this? > > Cheers > James > > > > -----Original Message----- > > From: Dawson, Martin > > Sent: Tuesday, 11 September 2007 12:36 PM > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > OK - we can do that. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 11 September 2007 12:27 PM > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin; > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > I want a distinguished value in the ResponseTime field if that is all > > there > > is. > > > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Monday, September 10, 2007 6:41 PM > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > I think the text you have below is suitable for inclusion in, say, > the > > > ECRIT BCP. We need text for the HELD spec - which I don't think > should > > > be quantifying anything. I gather you'd like an optional parameter > in > > > the HELD request that is binary and used to indicate that the > purpose of > > > the location is for emergency route/dispatch? > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 14:43:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVAgU-0005gR-AY; Tue, 11 Sep 2007 14:42:02 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVAgS-0005gB-Hr for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 14:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVAgS-0005g1-8I for geopriv@ietf.org; Tue, 11 Sep 2007 14:42:00 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVAgR-0003Pb-15 for geopriv@ietf.org; Tue, 11 Sep 2007 14:42:00 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8BIdb523503; Tue, 11 Sep 2007 18:39:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 13:41:44 -0500 Message-ID: In-Reply-To: <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGg References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> From: "Mary Barnes" To: "Brian Rosen" , "Winterbottom, James" , "Dawson, Martin" , "Thomson, Martin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org First, thanks to Martin Thomson for restarting this discussion. I've been following this ping pong match and trying to figure out how we could get consensus and it seems there is a proposal on the table with which both camps A and camps B agree. I know there was a camp C that didn't see the need at all for a responseTime, but I'm hoping that this compromise is agreeable at this point in time.=20 Are others that had not been so entrenched in camps A, B or C okay with this approach? It seems similar to several of the other past compromise proposals in allowing specification of two elements to meet everyone's requirements. In the case that folks are agreeable to the general approach, do we have any other opinions on whether the "svc" is part of the responseTime rather than a separate element. I would actually prefer the approach of having two tokens in responseTime, as Brian suggested, since it would then restrict the "svc" as a qualifer associated with the time. And, in this case, I think an IANA registry would be unnecessary. So, I'm hoping folks are now in the mode to debate and comment on this detail rather than the general approach.=20 Regards, Mary - HELD editor=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, September 11, 2007 7:25 AM To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin'; geopriv@ietf.org Subject: RE: [Geopriv] responseTime reprise Can I live with it? Yes. I think defining two tokens that can go in ResponseTime is easier. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, September 11, 2007 12:01 AM > To: Dawson, Martin; Brian Rosen; Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise >=20 > So here is my proposal. >=20 > > > civic > geodetic > locationURI > > >=20 > This request says give me location for routing an emergency call=20 > within > 3 seconds please. Where svc is a new attribute specifying what you=20 > want it for. This could be an IANA registry item if we wanted to go that far. >=20 > Similarly if you want location for dispatch: >=20 > > > civic > geodetic > > >=20 > You could even ditch the 30 seconds if the thing making the request=20 > doesn't care how long it takes. >=20 > Brian, can you live with this? >=20 > Cheers > James >=20 >=20 > > -----Original Message----- > > From: Dawson, Martin > > Sent: Tuesday, 11 September 2007 12:36 PM > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > OK - we can do that. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 11 September 2007 12:27 PM > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin; > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > I want a distinguished value in the ResponseTime field if that is=20 > > all there is. > > > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Monday, September 10, 2007 6:41 PM > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > I think the text you have below is suitable for inclusion in, say, > the > > > ECRIT BCP. We need text for the HELD spec - which I don't think > should > > > be quantifying anything. I gather you'd like an optional parameter > in > > > the HELD request that is binary and used to indicate that the > purpose of > > > the location is for emergency route/dispatch? > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- >=20 > ---------------------------------------------------------------------- > ---- > ---------------------- > This message is for the designated recipient only and may contain=20 > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is=20 > prohibited. > ---------------------------------------------------------------------- > ---- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 15:00:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVAwL-0003en-2k; Tue, 11 Sep 2007 14:58:25 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVAwK-0003eM-8I for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 14:58:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVAwJ-0003eA-Si for geopriv@ietf.org; Tue, 11 Sep 2007 14:58:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVAwJ-0006DM-4b for geopriv@ietf.org; Tue, 11 Sep 2007 14:58:23 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_14_07_45 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 14:07:45 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 13:58:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 13:58:22 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAARIrCA= References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Mary Barnes" , "Brian Rosen" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 18:58:22.0911 (UTC) FILETIME=[B9E7DCF0:01C7F4A5] X-Spam-Score: 1.8 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The only reason that I suggested svc as a separate attribute was that it=0D= =0Amakes adding other "special cases" easier later. If this isn't a concern=0D= =0Athen I have no objection to Brian's approach.=0D=0A=0D=0AI would point o= ut one further thing, and that is if you specify=0D=0AemergencyRouting or e= mergencyDispatch, then also providing a=0D=0AlocationType is moot as the LI= S MUST provide location in the form=0D=0Asuitable for those services.=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: M= ary Barnes [mailto:mary.barnes@nortel.com]=0D=0A> Sent: Wednesday, 12 Septe= mber 2007 4:42 AM=0D=0A> To: Brian Rosen; Winterbottom, James; Dawson, Mart= in; Thomson, Martin;=0D=0A> geopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] = responseTime reprise=0D=0A>=20=0D=0A> First, thanks to Martin Thomson for r= estarting this discussion.=0D=0A>=20=0D=0A> I've been following this ping p= ong match and trying to figure out how=0D=0Awe=0D=0A> could get consensus a= nd it seems there is a proposal on the table with=0D=0A> which both camps A= and camps B agree. I know there was a camp C that=0D=0A> didn't see the = need at all for a responseTime, but I'm hoping that=0D=0Athis=0D=0A> compro= mise is agreeable at this point in time.=0D=0A>=20=0D=0A> Are others that h= ad not been so entrenched in camps A, B or C okay=0D=0Awith=0D=0A> this app= roach=3F It seems similar to several of the other past=0D=0Acompromise=0D=0A= > proposals in allowing specification of two elements to meet everyone's=0D= =0A> requirements.=0D=0A>=20=0D=0A> In the case that folks are agreeable to= the general approach, do we=0D=0Ahave=0D=0A> any other opinions on whether= the "svc" is part of the responseTime=0D=0A> rather than a separate elemen= t. I would actually prefer the approach=0D=0Aof=0D=0A> having two tokens in= responseTime, as Brian suggested, since it would=0D=0A> then restrict the = "svc" as a qualifer associated with the time. And,=0D=0Ain=0D=0A> this case= , I think an IANA registry would be unnecessary. So, I'm=0D=0A> hoping fol= ks are now in the mode to debate and comment on this detail=0D=0A> rather t= han the general approach.=0D=0A>=20=0D=0A> Regards,=0D=0A> Mary=0D=0A> - HE= LD editor=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: Brian Ro= sen [mailto:br@brianrosen.net]=0D=0A> Sent: Tuesday, September 11, 2007 7:2= 5 AM=0D=0A> To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin';=0D= =0A> geopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] responseTime reprise=0D= =0A>=20=0D=0A> Can I live with it=3F Yes.=0D=0A> I think defining two toke= ns that can go in ResponseTime is easier.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D= =0A> > -----Original Message-----=0D=0A> > From: Winterbottom, James [mailt= o:James.Winterbottom@andrew.com]=0D=0A> > Sent: Tuesday, September 11, 2007= 12:01 AM=0D=0A> > To: Dawson, Martin; Brian Rosen; Thomson, Martin; geopri= v@ietf.org=0D=0A> > Subject: RE: [Geopriv] responseTime reprise=0D=0A> >=0D= =0A> > So here is my proposal.=0D=0A> >=0D=0A> > =0D=0A> > =09=0D=0A> > =09= =09civic=0D=0A> > =09=09geodetic=0D=0A> > =09=09locationURI=0D=0A> > =09=0D=0A> > =0D=0A> >=0D=0A> > This request say= s give me location for routing an emergency call=0D=0A> > within=0D=0A> > 3= seconds please. Where svc is a new attribute specifying what you=0D=0A> > = want it for. This could be an IANA registry item if we wanted to go=0D=0A> = that far.=0D=0A> >=0D=0A> > Similarly if you want location for dispatch:=0D= =0A> >=0D=0A> > =0D=0A> > =09=0D=0A> > =09=09civic=0D=0A> > =09=09geodeti= c=0D=0A> > =09=0D=0A> > =0D=0A> >=0D=0A> >= You could even ditch the 30 seconds if the thing making the request=0D=0A>= > doesn't care how long it takes.=0D=0A> >=0D=0A> > Brian, can you live wi= th this=3F=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A>= > > -----Original Message-----=0D=0A> > > From: Dawson, Martin=0D=0A> > > = Sent: Tuesday, 11 September 2007 12:36 PM=0D=0A> > > To: Brian Rosen; Winte= rbottom, James; Thomson, Martin;=0D=0A> > geopriv@ietf.org=0D=0A> > > Subje= ct: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D=0A> > > OK - we can do= that.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> > > Martin=0D=0A> > >=0D=0A> > = > -----Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianr= osen.net]=0D=0A> > > Sent: Tuesday, 11 September 2007 12:27 PM=0D=0A> > > T= o: Dawson, Martin; Winterbottom, James; Thomson, Martin;=0D=0A> > geopriv@i= etf.org=0D=0A> > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D= =0A> > > I want a distinguished value in the ResponseTime field if that is=0D= =0A> > > all there is.=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > > -----O= riginal Message-----=0D=0A> > > > From: Dawson, Martin [mailto:Martin.Dawso= n@andrew.com]=0D=0A> > > > Sent: Monday, September 10, 2007 6:41 PM=0D=0A> = > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin;=0D=0A> > geopr= iv@ietf.org=0D=0A> > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A>= > > >=0D=0A> > > > I think the text you have below is suitable for inclusi= on in,=0D=0Asay,=0D=0A> > the=0D=0A> > > > ECRIT BCP. We need text for the = HELD spec - which I don't think=0D=0A> > should=0D=0A> > > > be quantifying= anything. I gather you'd like an optional=0D=0Aparameter=0D=0A> > in=0D=0A= > > > > the HELD request that is binary and used to indicate that the=0D=0A= > > purpose of=0D=0A> > > > the location is for emergency route/dispatch=3F=0D= =0A> > > >=0D=0A> > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > >= > -----Original Message-----=0D=0A> >=0D=0A> >=0D=0A----------------------= ------------------------------------------------=0D=0A> > ----=0D=0A> > ---= -------------------=0D=0A> > This message is for the designated recipient o= nly and may contain=0D=0A> > privileged, proprietary, or otherwise private = information.=0D=0A> > If you have received it in error, please notify the s= ender=0D=0Aimmediately=0D=0A>=20=0D=0A> > and delete the original. Any una= uthorized use of this email is=0D=0A> > prohibited.=0D=0A> >=0D=0A---------= -------------------------------------------------------------=0D=0A> > ----=0D= =0A> > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D= =0A> _______________________________________________=0D=0A> Geopriv mailing= list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo= /geopriv=0D=0A=0D=0A-------------------------------------------------------= -----------------------------------------=0D=0AThis message is for the desi= gnated recipient only and may=0D=0Acontain privileged, proprietary, or othe= rwise private information. =20=0D=0AIf you have received it in error, pleas= e notify the sender=0D=0Aimmediately and delete the original. Any unauthor= ized use of=0D=0Athis email is prohibited.=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= [mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 15:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVB3b-00037q-Oh; Tue, 11 Sep 2007 15:05:55 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVB3a-00037l-TU for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:05:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVB3a-00037b-Jp for geopriv@ietf.org; Tue, 11 Sep 2007 15:05:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVB3Z-00041D-9T for geopriv@ietf.org; Tue, 11 Sep 2007 15:05:54 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IVB3N-0007Zi-PX; Tue, 11 Sep 2007 14:05:42 -0500 From: "Brian Rosen" To: "'Mary Barnes'" , "'Winterbottom, James'" , "'Dawson, Martin'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 15:05:49 -0400 Message-ID: <04b701c7f4a6$c607b1d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAASP1BA= In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think there are two, somewhat separable issues here: 1. Do we need something beyond time in the basic protocol? Doug Stuard had a specific proposal 2. Do we need something that indicates a requirement to conform to local regulations for emergency calls? The latest set of messages is on the latter question, and you know where I stand - I prefer two distinguished values. The former question is still open. I think something along the lines of what Doug proposed could be the basis of something workable. I would like some way for the server to tell the client what kinds of values it could reasonably handle. I'm willing to make that an extension if we need to in order to make progress. Brian > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, September 11, 2007 2:42 PM > To: Brian Rosen; Winterbottom, James; Dawson, Martin; Thomson, Martin; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > First, thanks to Martin Thomson for restarting this discussion. > > I've been following this ping pong match and trying to figure out how we > could get consensus and it seems there is a proposal on the table with > which both camps A and camps B agree. I know there was a camp C that > didn't see the need at all for a responseTime, but I'm hoping that this > compromise is agreeable at this point in time. > > Are others that had not been so entrenched in camps A, B or C okay with > this approach? It seems similar to several of the other past compromise > proposals in allowing specification of two elements to meet everyone's > requirements. > > In the case that folks are agreeable to the general approach, do we have > any other opinions on whether the "svc" is part of the responseTime > rather than a separate element. I would actually prefer the approach of > having two tokens in responseTime, as Brian suggested, since it would > then restrict the "svc" as a qualifer associated with the time. And, in > this case, I think an IANA registry would be unnecessary. So, I'm > hoping folks are now in the mode to debate and comment on this detail > rather than the general approach. > > Regards, > Mary > - HELD editor > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, September 11, 2007 7:25 AM > To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin'; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > Can I live with it? Yes. > I think defining two tokens that can go in ResponseTime is easier. > > Brian > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Tuesday, September 11, 2007 12:01 AM > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > So here is my proposal. > > > > > > > > civic > > geodetic > > locationURI > > > > > > > > This request says give me location for routing an emergency call > > within > > 3 seconds please. Where svc is a new attribute specifying what you > > want it for. This could be an IANA registry item if we wanted to go > that far. > > > > Similarly if you want location for dispatch: > > > > > > > > civic > > geodetic > > > > > > > > You could even ditch the 30 seconds if the thing making the request > > doesn't care how long it takes. > > > > Brian, can you live with this? > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Dawson, Martin > > > Sent: Tuesday, 11 September 2007 12:36 PM > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > OK - we can do that. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, 11 September 2007 12:27 PM > > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin; > > geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > I want a distinguished value in the ResponseTime field if that is > > > all there is. > > > > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Monday, September 10, 2007 6:41 PM > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > I think the text you have below is suitable for inclusion in, say, > > the > > > > ECRIT BCP. We need text for the HELD spec - which I don't think > > should > > > > be quantifying anything. I gather you'd like an optional parameter > > in > > > > the HELD request that is binary and used to indicate that the > > purpose of > > > > the location is for emergency route/dispatch? > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > ---------------------------------------------------------------------- > > ---- > > ---------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender immediately > > > and delete the original. Any unauthorized use of this email is > > prohibited. > > ---------------------------------------------------------------------- > > ---- > > ---------------------- > > [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 15:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBB2-0002Dz-Np; Tue, 11 Sep 2007 15:13:36 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVBB1-0002Dn-G4 for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:13:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBB1-0002De-3P for geopriv@ietf.org; Tue, 11 Sep 2007 15:13:35 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVBB0-0006jm-Ad for geopriv@ietf.org; Tue, 11 Sep 2007 15:13:35 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_14_22_56 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 14:22:56 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 14:13:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 14:13:35 -0500 Message-ID: In-Reply-To: <04b701c7f4a6$c607b1d0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAASP1BAAAFfGsA== References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b701c7f4a6$c607b1d0$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 19:13:33.0809 (UTC) FILETIME=[D8D7DE10:01C7F4A7] X-Spam-Score: 1.8 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Thankyou Brian.=0D=0A=0D=0AI would prefer accuracy request to be an extensi= on to be developed as=0D=0Arequired.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A= > -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen= =2Enet]=0D=0A> Sent: Wednesday, 12 September 2007 5:06 AM=0D=0A> To: 'Mary = Barnes'; Winterbottom, James; Dawson, Martin; Thomson,=0D=0AMartin;=0D=0A> = geopriv@ietf.org=0D=0A> Subject: RE: [Geopriv] responseTime reprise=0D=0A> =0D= =0A> I think there are two, somewhat separable issues here:=0D=0A> 1. Do we= need something beyond time in the basic protocol=3F Doug=0D=0AStuard=0D=0A= > had=0D=0A> a specific proposal=0D=0A> 2. Do we need something that indica= tes a requirement to conform to=0D=0Alocal=0D=0A> regulations for emergency= calls=3F=0D=0A>=20=0D=0A> The latest set of messages is on the latter ques= tion, and you know=0D=0Awhere I=0D=0A> stand - I prefer two distinguished v= alues.=0D=0A>=20=0D=0A> The former question is still open. I think somethi= ng along the lines=0D=0Aof=0D=0A> what Doug proposed could be the basis of = something workable. I would=0D=0Alike=0D=0A> some way for the server to te= ll the client what kinds of values it=0D=0Acould=0D=0A> reasonably handle. = I'm willing to make that an extension if we need=0D=0Ato in=0D=0A> order t= o make progress.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Me= ssage-----=0D=0A> > From: Mary Barnes [mailto:mary.barnes@nortel.com]=0D=0A= > > Sent: Tuesday, September 11, 2007 2:42 PM=0D=0A> > To: Brian Rosen; Win= terbottom, James; Dawson, Martin; Thomson,=0D=0AMartin;=0D=0A> > geopriv@ie= tf.org=0D=0A> > Subject: RE: [Geopriv] responseTime reprise=0D=0A> >=0D=0A>= > First, thanks to Martin Thomson for restarting this discussion.=0D=0A> >=0D= =0A> > I've been following this ping pong match and trying to figure out=0D= =0Ahow we=0D=0A> > could get consensus and it seems there is a proposal on = the table=0D=0Awith=0D=0A> > which both camps A and camps B agree. I know= there was a camp C=0D=0Athat=0D=0A> > didn't see the need at all for a res= ponseTime, but I'm hoping that=0D=0Athis=0D=0A> > compromise is agreeable a= t this point in time.=0D=0A> >=0D=0A> > Are others that had not been so ent= renched in camps A, B or C okay=0D=0Awith=0D=0A> > this approach=3F It see= ms similar to several of the other past=0D=0Acompromise=0D=0A> > proposals = in allowing specification of two elements to meet=0D=0Aeveryone's=0D=0A> > = requirements.=0D=0A> >=0D=0A> > In the case that folks are agreeable to the= general approach, do we=0D=0Ahave=0D=0A> > any other opinions on whether t= he "svc" is part of the responseTime=0D=0A> > rather than a separate elemen= t. I would actually prefer the approach=0D=0Aof=0D=0A> > having two tokens = in responseTime, as Brian suggested, since it=0D=0Awould=0D=0A> > then rest= rict the "svc" as a qualifer associated with the time. And,=0D=0Ain=0D=0A> = > this case, I think an IANA registry would be unnecessary. So, I'm=0D=0A>= > hoping folks are now in the mode to debate and comment on this=0D=0Adeta= il=0D=0A> > rather than the general approach.=0D=0A> >=0D=0A> > Regards,=0D= =0A> > Mary=0D=0A> > - HELD editor=0D=0A> >=0D=0A> > -----Original Message-= ----=0D=0A> > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > Sent: T= uesday, September 11, 2007 7:25 AM=0D=0A> > To: 'Winterbottom, James'; 'Daw= son, Martin'; 'Thomson, Martin';=0D=0A> > geopriv@ietf.org=0D=0A> > Subject= : RE: [Geopriv] responseTime reprise=0D=0A> >=0D=0A> > Can I live with it=3F= Yes.=0D=0A> > I think defining two tokens that can go in ResponseTime is = easier.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> > > -----Original Message--= ---=0D=0A> > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.= com]=0D=0A> > > Sent: Tuesday, September 11, 2007 12:01 AM=0D=0A> > > To: D= awson, Martin; Brian Rosen; Thomson, Martin; geopriv@ietf.org=0D=0A> > > Su= bject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D=0A> > > So here is = my proposal.=0D=0A> > >=0D=0A> > > =0D=0A> > > =09=0D=0A> > > =09=09civic=0D= =0A> > > =09=09geodetic=0D=0A> > > =09=09locationURI=0D=0A> > > =09=0D=0A> > > =0D=0A> > >=0D=0A> > > This request sa= ys give me location for routing an emergency call=0D=0A> > > within=0D=0A> = > > 3 seconds please. Where svc is a new attribute specifying what you=0D=0A= > > > want it for. This could be an IANA registry item if we wanted to=0D=0A= go=0D=0A> > that far.=0D=0A> > >=0D=0A> > > Similarly if you want location = for dispatch:=0D=0A> > >=0D=0A> > > =0D=0A> > > =09=0D=0A> > > =09=09civi= c=0D=0A> > > =09=09geodetic=0D=0A> > > =09=0D=0A> > > =0D=0A> > >=0D=0A> > > You could even ditch the 30 seconds if t= he thing making the=0D=0Arequest=0D=0A> > > doesn't care how long it takes.=0D= =0A> > >=0D=0A> > > Brian, can you live with this=3F=0D=0A> > >=0D=0A> > > = Cheers=0D=0A> > > James=0D=0A> > >=0D=0A> > >=0D=0A> > > > -----Original Me= ssage-----=0D=0A> > > > From: Dawson, Martin=0D=0A> > > > Sent: Tuesday, 11= September 2007 12:36 PM=0D=0A> > > > To: Brian Rosen; Winterbottom, James;= Thomson, Martin;=0D=0A> > > geopriv@ietf.org=0D=0A> > > > Subject: RE: [Ge= opriv] responseTime reprise=0D=0A> > > >=0D=0A> > > > OK - we can do that.=0D= =0A> > > >=0D=0A> > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > >= > -----Original Message-----=0D=0A> > > > From: Brian Rosen [mailto:br@bri= anrosen.net]=0D=0A> > > > Sent: Tuesday, 11 September 2007 12:27 PM=0D=0A> = > > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin;=0D=0A> > > = geopriv@ietf.org=0D=0A> > > > Subject: RE: [Geopriv] responseTime reprise=0D= =0A> > > >=0D=0A> > > > I want a distinguished value in the ResponseTime fi= eld if that=0D=0Ais=0D=0A> > > > all there is.=0D=0A> > > >=0D=0A> > > >=0D= =0A> > > >=0D=0A> > > > > -----Original Message-----=0D=0A> > > > > From: D= awson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > > > Sent: Monday= , September 10, 2007 6:41 PM=0D=0A> > > > > To: Brian Rosen; Winterbottom, = James; Thomson, Martin;=0D=0A> > > geopriv@ietf.org=0D=0A> > > > > Subject:= RE: [Geopriv] responseTime reprise=0D=0A> > > > >=0D=0A> > > > > I think t= he text you have below is suitable for inclusion in,=0D=0Asay,=0D=0A> > > t= he=0D=0A> > > > > ECRIT BCP. We need text for the HELD spec - which I don't=0D= =0Athink=0D=0A> > > should=0D=0A> > > > > be quantifying anything. I gather= you'd like an optional=0D=0Aparameter=0D=0A> > > in=0D=0A> > > > > the HEL= D request that is binary and used to indicate that the=0D=0A> > > purpose o= f=0D=0A> > > > > the location is for emergency route/dispatch=3F=0D=0A> > >= > >=0D=0A> > > > > Cheers,=0D=0A> > > > > Martin=0D=0A> > > > >=0D=0A> > >= > > -----Original Message-----=0D=0A> > >=0D=0A> > >=0D=0A----------------= ------------------------------------------------------=0D=0A> > > ----=0D=0A= > > > ----------------------=0D=0A> > > This message is for the designated = recipient only and may contain=0D=0A> > > privileged, proprietary, or other= wise private information.=0D=0A> > > If you have received it in error, plea= se notify the sender=0D=0Aimmediately=0D=0A> >=0D=0A> > > and delete the or= iginal. Any unauthorized use of this email is=0D=0A> > > prohibited.=0D=0A= > > >=0D=0A----------------------------------------------------------------= ------=0D=0A> > > ----=0D=0A> > > ----------------------=0D=0A> > > [mf2]=0D= =0A> >=0D=0A> >=0D=0A> >=0D=0A> > _________________________________________= ______=0D=0A> > Geopriv mailing list=0D=0A> > Geopriv@ietf.org=0D=0A> > htt= ps://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 15:17:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBD2-0004gj-Vd; Tue, 11 Sep 2007 15:15:40 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVBD1-0004gU-Sp for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:15:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBD1-0004gM-G4 for geopriv@ietf.org; Tue, 11 Sep 2007 15:15:39 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVBD0-0006me-J1 for geopriv@ietf.org; Tue, 11 Sep 2007 15:15:39 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IVBCp-0006NM-1u; Tue, 11 Sep 2007 14:15:27 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Mary Barnes'" , "'Dawson, Martin'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 15:15:35 -0400 Message-ID: <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAARIrCAAAHuGUA== In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I don't understand that. Let's first see if we agree on basic principals: 1. Conversion should never be done implicitly. It could be explict if you want. 2. Conversion on emergency calls must not be done. 3. A LIS may have multiple determination mechanisms. It's possible, albeit unlikely, that one could determine a civic and another determine a geo. Despite the fact that I don't think it will happen very often, I'd rather not prohibit that. 4. It may be even more unlikely that a LIS would have multiple determination mechanisms one or more of which resulted in civic and one or more that resulted in geo AND that at least one civic and at least one geo meet the local regulatory requirements, but again, I wouldn't want to prohibit it. That means that locationType still matters, right? Unlikely perhaps, but possible. I don't think we need extra text for this. I don't think we imply any locationType with the distinguished values. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, September 11, 2007 2:58 PM > To: Mary Barnes; Brian Rosen; Dawson, Martin; Thomson, Martin; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > The only reason that I suggested svc as a separate attribute was that it > makes adding other "special cases" easier later. If this isn't a concern > then I have no objection to Brian's approach. > > I would point out one further thing, and that is if you specify > emergencyRouting or emergencyDispatch, then also providing a > locationType is moot as the LIS MUST provide location in the form > suitable for those services. > > Cheers > James > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Wednesday, 12 September 2007 4:42 AM > > To: Brian Rosen; Winterbottom, James; Dawson, Martin; Thomson, Martin; > > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > First, thanks to Martin Thomson for restarting this discussion. > > > > I've been following this ping pong match and trying to figure out how > we > > could get consensus and it seems there is a proposal on the table with > > which both camps A and camps B agree. I know there was a camp C that > > didn't see the need at all for a responseTime, but I'm hoping that > this > > compromise is agreeable at this point in time. > > > > Are others that had not been so entrenched in camps A, B or C okay > with > > this approach? It seems similar to several of the other past > compromise > > proposals in allowing specification of two elements to meet everyone's > > requirements. > > > > In the case that folks are agreeable to the general approach, do we > have > > any other opinions on whether the "svc" is part of the responseTime > > rather than a separate element. I would actually prefer the approach > of > > having two tokens in responseTime, as Brian suggested, since it would > > then restrict the "svc" as a qualifer associated with the time. And, > in > > this case, I think an IANA registry would be unnecessary. So, I'm > > hoping folks are now in the mode to debate and comment on this detail > > rather than the general approach. > > > > Regards, > > Mary > > - HELD editor > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, September 11, 2007 7:25 AM > > To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin'; > > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > Can I live with it? Yes. > > I think defining two tokens that can go in ResponseTime is easier. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Tuesday, September 11, 2007 12:01 AM > > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > So here is my proposal. > > > > > > > > > > > > civic > > > geodetic > > > locationURI > > > > > > > > > > > > This request says give me location for routing an emergency call > > > within > > > 3 seconds please. Where svc is a new attribute specifying what you > > > want it for. This could be an IANA registry item if we wanted to go > > that far. > > > > > > Similarly if you want location for dispatch: > > > > > > > > > > > > civic > > > geodetic > > > > > > > > > > > > You could even ditch the 30 seconds if the thing making the request > > > doesn't care how long it takes. > > > > > > Brian, can you live with this? > > > > > > Cheers > > > James > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin > > > > Sent: Tuesday, 11 September 2007 12:36 PM > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > > geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > OK - we can do that. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, 11 September 2007 12:27 PM > > > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin; > > > geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > I want a distinguished value in the ResponseTime field if that is > > > > all there is. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > Sent: Monday, September 10, 2007 6:41 PM > > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > > geopriv@ietf.org > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > I think the text you have below is suitable for inclusion in, > say, > > > the > > > > > ECRIT BCP. We need text for the HELD spec - which I don't think > > > should > > > > > be quantifying anything. I gather you'd like an optional > parameter > > > in > > > > > the HELD request that is binary and used to indicate that the > > > purpose of > > > > > the location is for emergency route/dispatch? > > > > > > > > > > Cheers, > > > > > Martin > > > > > > > > > > -----Original Message----- > > > > > > > ---------------------------------------------------------------------- > > > ---- > > > ---------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > immediately > > > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > > ---------------------------------------------------------------------- > > > ---- > > > ---------------------- > > > [mf2] > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 15:18:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBDg-0005BV-1a; Tue, 11 Sep 2007 15:16:20 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVBDe-0005BO-QX for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBDe-0005BB-GU for geopriv@ietf.org; Tue, 11 Sep 2007 15:16:18 -0400 Received: from mail1.911.org ([65.67.130.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBDc-0004LA-PL for geopriv@ietf.org; Tue, 11 Sep 2007 15:16:18 -0400 Received: from ghcmail [192.168.6.230] by mail1.911.org - SurfControl E-mail Filter (5.5.0); Tue, 11 Sep 2007 14:13:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 14:16:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAASP1BAAAFfGsAAAMH6w References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com><023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com><036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com><037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com><038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com><040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com><04b701c7f4a6$c607b1d0$640fa8c0@cis.neustar.com> From: "Marc Berryman" To: "Winterbottom, James" , "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , X-SEF-Processed: 5_5_0_191__2007_09_11_14_13_35 X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org That sounds like a great plan - Marc Marc Berryman, ENP Geographic Information Systems Greater Harris County 9-1-1 Emergency Network Houston, Texas (713) 407-2254 mberryman@911.org -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Tuesday, September 11, 2007 2:14 PM To: Brian Rosen; Mary Barnes; Dawson, Martin; Thomson, Martin; geopriv@ietf.org Subject: RE: [Geopriv] responseTime reprise Thankyou Brian. I would prefer accuracy request to be an extension to be developed as required. Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 12 September 2007 5:06 AM > To: 'Mary Barnes'; Winterbottom, James; Dawson, Martin; Thomson, Martin; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise >=20 > I think there are two, somewhat separable issues here: > 1. Do we need something beyond time in the basic protocol? Doug Stuard > had > a specific proposal > 2. Do we need something that indicates a requirement to conform to local > regulations for emergency calls? >=20 > The latest set of messages is on the latter question, and you know where I > stand - I prefer two distinguished values. >=20 > The former question is still open. I think something along the lines of > what Doug proposed could be the basis of something workable. I would like > some way for the server to tell the client what kinds of values it could > reasonably handle. I'm willing to make that an extension if we need to in > order to make progress. >=20 > Brian >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Tuesday, September 11, 2007 2:42 PM > > To: Brian Rosen; Winterbottom, James; Dawson, Martin; Thomson, Martin; > > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > First, thanks to Martin Thomson for restarting this discussion. > > > > I've been following this ping pong match and trying to figure out how we > > could get consensus and it seems there is a proposal on the table with > > which both camps A and camps B agree. I know there was a camp C that > > didn't see the need at all for a responseTime, but I'm hoping that this > > compromise is agreeable at this point in time. > > > > Are others that had not been so entrenched in camps A, B or C okay with > > this approach? It seems similar to several of the other past compromise > > proposals in allowing specification of two elements to meet everyone's > > requirements. > > > > In the case that folks are agreeable to the general approach, do we have > > any other opinions on whether the "svc" is part of the responseTime > > rather than a separate element. I would actually prefer the approach of > > having two tokens in responseTime, as Brian suggested, since it would > > then restrict the "svc" as a qualifer associated with the time. And, in > > this case, I think an IANA registry would be unnecessary. So, I'm > > hoping folks are now in the mode to debate and comment on this detail > > rather than the general approach. > > > > Regards, > > Mary > > - HELD editor > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, September 11, 2007 7:25 AM > > To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin'; > > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > Can I live with it? Yes. > > I think defining two tokens that can go in ResponseTime is easier. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Tuesday, September 11, 2007 12:01 AM > > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > So here is my proposal. > > > > > > > > > > > > civic > > > geodetic > > > locationURI > > > > > > > > > > > > This request says give me location for routing an emergency call > > > within > > > 3 seconds please. Where svc is a new attribute specifying what you > > > want it for. This could be an IANA registry item if we wanted to go > > that far. > > > > > > Similarly if you want location for dispatch: > > > > > > > > > > > > civic > > > geodetic > > > > > > > > > > > > You could even ditch the 30 seconds if the thing making the request > > > doesn't care how long it takes. > > > > > > Brian, can you live with this? > > > > > > Cheers > > > James > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin > > > > Sent: Tuesday, 11 September 2007 12:36 PM > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > > geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > OK - we can do that. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, 11 September 2007 12:27 PM > > > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin; > > > geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > I want a distinguished value in the ResponseTime field if that is > > > > all there is. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > Sent: Monday, September 10, 2007 6:41 PM > > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > > geopriv@ietf.org > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > I think the text you have below is suitable for inclusion in, say, > > > the > > > > > ECRIT BCP. We need text for the HELD spec - which I don't think > > > should > > > > > be quantifying anything. I gather you'd like an optional parameter > > > in > > > > > the HELD request that is binary and used to indicate that the > > > purpose of > > > > > the location is for emergency route/dispatch? > > > > > > > > > > Cheers, > > > > > Martin > > > > > > > > > > -----Original Message----- > > > > > > ---------------------------------------------------------------------- > > > ---- > > > ---------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender immediately > > > > > and delete the original. Any unauthorized use of this email is > > > prohibited. > > > ---------------------------------------------------------------------- > > > ---- > > > ---------------------- > > > [mf2] > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 15:23:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBJN-00044u-1u; Tue, 11 Sep 2007 15:22:13 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVBJM-00044f-4o for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBJL-00044K-0c for geopriv@ietf.org; Tue, 11 Sep 2007 15:22:11 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBJH-0004ZY-Jq for geopriv@ietf.org; Tue, 11 Sep 2007 15:22:10 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_14_31_27 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 14:31:27 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 14:22:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 14:22:04 -0500 Message-ID: In-Reply-To: <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAARIrCAAAHuGUAAAbXGA References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 19:22:04.0971 (UTC) FILETIME=[0984FFB0:01C7F4A9] X-Spam-Score: 1.8 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Yes, let's just add extra text.=0D=0A=0D=0A> -----Original Message-----=0D=0A= > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Wednesday, 12 S= eptember 2007 5:16 AM=0D=0A> To: Winterbottom, James; 'Mary Barnes'; Dawson= , Martin; Thomson,=0D=0AMartin;=0D=0A> geopriv@ietf.org=0D=0A> Subject: RE:= [Geopriv] responseTime reprise=0D=0A>=20=0D=0A> I don't understand that.=0D= =0A>=20=0D=0A> Let's first see if we agree on basic principals:=0D=0A> 1. C= onversion should never be done implicitly. It could be explict if=0D=0Ayou=0D= =0A> want.=0D=0A> 2. Conversion on emergency calls must not be done.=0D=0A>= 3. A LIS may have multiple determination mechanisms. It's possible,=0D=0A= > albeit=0D=0A> unlikely, that one could determine a civic and another dete= rmine a=0D=0Ageo.=0D=0A> Despite the fact that I don't think it will happen= very often, I'd=0D=0Arather=0D=0A> not prohibit that.=0D=0A> 4. It may be = even more unlikely that a LIS would have multiple=0D=0A> determination=0D=0A= > mechanisms one or more of which resulted in civic and one or more that=0D= =0A> resulted in geo AND that at least one civic and at least one geo meet=0D= =0Athe=0D=0A> local regulatory requirements, but again, I wouldn't want to = prohibit=0D=0Ait.=0D=0A>=20=0D=0A> That means that locationType still matte= rs, right=3F Unlikely perhaps,=0D=0Abut=0D=0A> possible. I don't think we= need extra text for this. I don't think=0D=0Awe=0D=0A> imply any location= Type with the distinguished values.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>= > -----Original Message-----=0D=0A> > From: Winterbottom, James [mailto:Ja= mes.Winterbottom@andrew.com]=0D=0A> > Sent: Tuesday, September 11, 2007 2:5= 8 PM=0D=0A> > To: Mary Barnes; Brian Rosen; Dawson, Martin; Thomson, Martin= ;=0D=0A> > geopriv@ietf.org=0D=0A> > Subject: RE: [Geopriv] responseTime re= prise=0D=0A> >=0D=0A> > The only reason that I suggested svc as a separate = attribute was=0D=0Athat it=0D=0A> > makes adding other "special cases" easi= er later. If this isn't a=0D=0Aconcern=0D=0A> > then I have no objection to= Brian's approach.=0D=0A> >=0D=0A> > I would point out one further thing, a= nd that is if you specify=0D=0A> > emergencyRouting or emergencyDispatch, t= hen also providing a=0D=0A> > locationType is moot as the LIS MUST provide = location in the form=0D=0A> > suitable for those services.=0D=0A> >=0D=0A> = > Cheers=0D=0A> > James=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A= > > > From: Mary Barnes [mailto:mary.barnes@nortel.com]=0D=0A> > > Sent: We= dnesday, 12 September 2007 4:42 AM=0D=0A> > > To: Brian Rosen; Winterbottom= , James; Dawson, Martin; Thomson,=0D=0AMartin;=0D=0A> > > geopriv@ietf.org=0D= =0A> > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D=0A> > > = First, thanks to Martin Thomson for restarting this discussion.=0D=0A> > >=0D= =0A> > > I've been following this ping pong match and trying to figure out=0D= =0Ahow=0D=0A> > we=0D=0A> > > could get consensus and it seems there is a p= roposal on the table=0D=0Awith=0D=0A> > > which both camps A and camps B ag= ree. I know there was a camp C=0D=0Athat=0D=0A> > > didn't see the need a= t all for a responseTime, but I'm hoping that=0D=0A> > this=0D=0A> > > comp= romise is agreeable at this point in time.=0D=0A> > >=0D=0A> > > Are others= that had not been so entrenched in camps A, B or C okay=0D=0A> > with=0D=0A= > > > this approach=3F It seems similar to several of the other past=0D=0A= > > compromise=0D=0A> > > proposals in allowing specification of two elemen= ts to meet=0D=0Aeveryone's=0D=0A> > > requirements.=0D=0A> > >=0D=0A> > > I= n the case that folks are agreeable to the general approach, do=0D=0Awe=0D=0A= > > have=0D=0A> > > any other opinions on whether the "svc" is part of the=0D= =0AresponseTime=0D=0A> > > rather than a separate element. I would actually= prefer the=0D=0Aapproach=0D=0A> > of=0D=0A> > > having two tokens in respo= nseTime, as Brian suggested, since it=0D=0Awould=0D=0A> > > then restrict t= he "svc" as a qualifer associated with the time.=0D=0AAnd,=0D=0A> > in=0D=0A= > > > this case, I think an IANA registry would be unnecessary. So, I'm=0D= =0A> > > hoping folks are now in the mode to debate and comment on this=0D=0A= detail=0D=0A> > > rather than the general approach.=0D=0A> > >=0D=0A> > > R= egards,=0D=0A> > > Mary=0D=0A> > > - HELD editor=0D=0A> > >=0D=0A> > > ----= -Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianrosen.n= et]=0D=0A> > > Sent: Tuesday, September 11, 2007 7:25 AM=0D=0A> > > To: 'Wi= nterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin';=0D=0A> > > geopriv= @ietf.org=0D=0A> > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D= =0A> > > Can I live with it=3F Yes.=0D=0A> > > I think defining two tokens= that can go in ResponseTime is easier.=0D=0A> > >=0D=0A> > > Brian=0D=0A> = > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: Winterbottom= , James [mailto:James.Winterbottom@andrew.com]=0D=0A> > > > Sent: Tuesday, = September 11, 2007 12:01 AM=0D=0A> > > > To: Dawson, Martin; Brian Rosen; T= homson, Martin;=0D=0Ageopriv@ietf.org=0D=0A> > > > Subject: RE: [Geopriv] r= esponseTime reprise=0D=0A> > > >=0D=0A> > > > So here is my proposal.=0D=0A= > > > >=0D=0A> > > > =0D=0A> > > > =09=0D=0A> > > > =09=09civic=0D=0A> > > = > =09=09geodetic=0D=0A> > > > =09=09locationURI=0D=0A> > > > =09=0D=0A> > > > =0D=0A> > > >=0D=0A> > > > This request= says give me location for routing an emergency call=0D=0A> > > > within=0D= =0A> > > > 3 seconds please. Where svc is a new attribute specifying what=0D= =0Ayou=0D=0A> > > > want it for. This could be an IANA registry item if we = wanted to=0D=0Ago=0D=0A> > > that far.=0D=0A> > > >=0D=0A> > > > Similarly = if you want location for dispatch:=0D=0A> > > >=0D=0A> > > > =0D=0A> > > > =09=0D=0A> > > > =09=09civic=0D=0A> > > > =09=09geodetic=0D=0A> > > > =09= =0D=0A> > > > =0D=0A> > > >=0D=0A> > > > Y= ou could even ditch the 30 seconds if the thing making the=0D=0Arequest=0D=0A= > > > > doesn't care how long it takes.=0D=0A> > > >=0D=0A> > > > Brian, ca= n you live with this=3F=0D=0A> > > >=0D=0A> > > > Cheers=0D=0A> > > > James=0D= =0A> > > >=0D=0A> > > >=0D=0A> > > > > -----Original Message-----=0D=0A> > = > > > From: Dawson, Martin=0D=0A> > > > > Sent: Tuesday, 11 September 2007 = 12:36 PM=0D=0A> > > > > To: Brian Rosen; Winterbottom, James; Thomson, Mart= in;=0D=0A> > > > geopriv@ietf.org=0D=0A> > > > > Subject: RE: [Geopriv] res= ponseTime reprise=0D=0A> > > > >=0D=0A> > > > > OK - we can do that.=0D=0A>= > > > >=0D=0A> > > > > Cheers,=0D=0A> > > > > Martin=0D=0A> > > > >=0D=0A>= > > > > -----Original Message-----=0D=0A> > > > > From: Brian Rosen [mailt= o:br@brianrosen.net]=0D=0A> > > > > Sent: Tuesday, 11 September 2007 12:27 = PM=0D=0A> > > > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin;=0D= =0A> > > > geopriv@ietf.org=0D=0A> > > > > Subject: RE: [Geopriv] responseT= ime reprise=0D=0A> > > > >=0D=0A> > > > > I want a distinguished value in t= he ResponseTime field if that=0D=0Ais=0D=0A> > > > > all there is.=0D=0A> >= > > >=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > > > -----Original Message= -----=0D=0A> > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.co= m]=0D=0A> > > > > > Sent: Monday, September 10, 2007 6:41 PM=0D=0A> > > > >= > To: Brian Rosen; Winterbottom, James; Thomson, Martin;=0D=0A> > > > geop= riv@ietf.org=0D=0A> > > > > > Subject: RE: [Geopriv] responseTime reprise=0D= =0A> > > > > >=0D=0A> > > > > > I think the text you have below is suitable= for inclusion=0D=0Ain,=0D=0A> > say,=0D=0A> > > > the=0D=0A> > > > > > ECR= IT BCP. We need text for the HELD spec - which I don't=0D=0Athink=0D=0A> > = > > should=0D=0A> > > > > > be quantifying anything. I gather you'd like an= optional=0D=0A> > parameter=0D=0A> > > > in=0D=0A> > > > > > the HELD requ= est that is binary and used to indicate that=0D=0Athe=0D=0A> > > > purpose = of=0D=0A> > > > > > the location is for emergency route/dispatch=3F=0D=0A> = > > > > >=0D=0A> > > > > > Cheers,=0D=0A> > > > > > Martin=0D=0A> > > > > >=0D= =0A> > > > > > -----Original Message-----=0D=0A> > > >=0D=0A> > > >=0D=0A> = >=0D=0A--------------------------------------------------------------------= --=0D=0A> > > > ----=0D=0A> > > > ----------------------=0D=0A> > > > This = message is for the designated recipient only and may=0D=0Acontain=0D=0A> > = > > privileged, proprietary, or otherwise private information.=0D=0A> > > >= If you have received it in error, please notify the sender=0D=0A> > immedi= ately=0D=0A> > >=0D=0A> > > > and delete the original. Any unauthorized us= e of this email is=0D=0A> > > > prohibited.=0D=0A> > > >=0D=0A> >=0D=0A----= ------------------------------------------------------------------=0D=0A> >= > > ----=0D=0A> > > > ----------------------=0D=0A> > > > [mf2]=0D=0A> > >=0D= =0A> > >=0D=0A> > >=0D=0A> > > ____________________________________________= ___=0D=0A> > > Geopriv mailing list=0D=0A> > > Geopriv@ietf.org=0D=0A> > > = https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A> >=0D=0A> >=0D=0A-----= -------------------------------------------------------------------=0D=0A> = --=0D=0A> > ----------------------=0D=0A> > This message is for the designa= ted recipient only and may=0D=0A> > contain privileged, proprietary, or oth= erwise private information.=0D=0A> > If you have received it in error, plea= se notify the sender=0D=0A> > immediately and delete the original. Any una= uthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A---------= ---------------------------------------------------------------=0D=0A> --=0D= =0A> > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A---------= ---------------------------------------------------------------------------= ------------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 15:43:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBcD-0007Cx-VQ; Tue, 11 Sep 2007 15:41:41 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVBcC-0007Cn-Lw for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:41:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBcC-0007Cd-9F for geopriv@ietf.org; Tue, 11 Sep 2007 15:41:40 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVBcB-0007bq-7l for geopriv@ietf.org; Tue, 11 Sep 2007 15:41:40 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IVBbz-0001Gb-4s; Tue, 11 Sep 2007 14:41:27 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Mary Barnes'" , "'Dawson, Martin'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 15:41:35 -0400 Message-ID: <04be01c7f4ab$c5056ac0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAARIrCAAAHuGUAAAbXGAAADHitA= In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Huh? I just made an argument that you don't need any extra text and LocationType COULD be used with the distinguished values Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, September 11, 2007 3:22 PM > To: Brian Rosen; Mary Barnes; Dawson, Martin; Thomson, Martin; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > Yes, let's just add extra text. > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, 12 September 2007 5:16 AM > > To: Winterbottom, James; 'Mary Barnes'; Dawson, Martin; Thomson, > Martin; > > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > I don't understand that. > > > > Let's first see if we agree on basic principals: > > 1. Conversion should never be done implicitly. It could be explict if > you > > want. > > 2. Conversion on emergency calls must not be done. > > 3. A LIS may have multiple determination mechanisms. It's possible, > > albeit > > unlikely, that one could determine a civic and another determine a > geo. > > Despite the fact that I don't think it will happen very often, I'd > rather > > not prohibit that. > > 4. It may be even more unlikely that a LIS would have multiple > > determination > > mechanisms one or more of which resulted in civic and one or more that > > resulted in geo AND that at least one civic and at least one geo meet > the > > local regulatory requirements, but again, I wouldn't want to prohibit > it. > > > > That means that locationType still matters, right? Unlikely perhaps, > but > > possible. I don't think we need extra text for this. I don't think > we > > imply any locationType with the distinguished values. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Tuesday, September 11, 2007 2:58 PM > > > To: Mary Barnes; Brian Rosen; Dawson, Martin; Thomson, Martin; > > > geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > The only reason that I suggested svc as a separate attribute was > that it > > > makes adding other "special cases" easier later. If this isn't a > concern > > > then I have no objection to Brian's approach. > > > > > > I would point out one further thing, and that is if you specify > > > emergencyRouting or emergencyDispatch, then also providing a > > > locationType is moot as the LIS MUST provide location in the form > > > suitable for those services. > > > > > > Cheers > > > James > > > > > > > -----Original Message----- > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > Sent: Wednesday, 12 September 2007 4:42 AM > > > > To: Brian Rosen; Winterbottom, James; Dawson, Martin; Thomson, > Martin; > > > > geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > First, thanks to Martin Thomson for restarting this discussion. > > > > > > > > I've been following this ping pong match and trying to figure out > how > > > we > > > > could get consensus and it seems there is a proposal on the table > with > > > > which both camps A and camps B agree. I know there was a camp C > that > > > > didn't see the need at all for a responseTime, but I'm hoping that > > > this > > > > compromise is agreeable at this point in time. > > > > > > > > Are others that had not been so entrenched in camps A, B or C okay > > > with > > > > this approach? It seems similar to several of the other past > > > compromise > > > > proposals in allowing specification of two elements to meet > everyone's > > > > requirements. > > > > > > > > In the case that folks are agreeable to the general approach, do > we > > > have > > > > any other opinions on whether the "svc" is part of the > responseTime > > > > rather than a separate element. I would actually prefer the > approach > > > of > > > > having two tokens in responseTime, as Brian suggested, since it > would > > > > then restrict the "svc" as a qualifer associated with the time. > And, > > > in > > > > this case, I think an IANA registry would be unnecessary. So, I'm > > > > hoping folks are now in the mode to debate and comment on this > detail > > > > rather than the general approach. > > > > > > > > Regards, > > > > Mary > > > > - HELD editor > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, September 11, 2007 7:25 AM > > > > To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin'; > > > > geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > Can I live with it? Yes. > > > > I think defining two tokens that can go in ResponseTime is easier. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > > Sent: Tuesday, September 11, 2007 12:01 AM > > > > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; > geopriv@ietf.org > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > So here is my proposal. > > > > > > > > > > > > > > > > > > > > civic > > > > > geodetic > > > > > locationURI > > > > > > > > > > > > > > > > > > > > This request says give me location for routing an emergency call > > > > > within > > > > > 3 seconds please. Where svc is a new attribute specifying what > you > > > > > want it for. This could be an IANA registry item if we wanted to > go > > > > that far. > > > > > > > > > > Similarly if you want location for dispatch: > > > > > > > > > > > > > > > > > > > > civic > > > > > geodetic > > > > > > > > > > > > > > > > > > > > You could even ditch the 30 seconds if the thing making the > request > > > > > doesn't care how long it takes. > > > > > > > > > > Brian, can you live with this? > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dawson, Martin > > > > > > Sent: Tuesday, 11 September 2007 12:36 PM > > > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > > > > geopriv@ietf.org > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > OK - we can do that. > > > > > > > > > > > > Cheers, > > > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Tuesday, 11 September 2007 12:27 PM > > > > > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin; > > > > > geopriv@ietf.org > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > I want a distinguished value in the ResponseTime field if that > is > > > > > > all there is. > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > > Sent: Monday, September 10, 2007 6:41 PM > > > > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > > > > geopriv@ietf.org > > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > > > I think the text you have below is suitable for inclusion > in, > > > say, > > > > > the > > > > > > > ECRIT BCP. We need text for the HELD spec - which I don't > think > > > > > should > > > > > > > be quantifying anything. I gather you'd like an optional > > > parameter > > > > > in > > > > > > > the HELD request that is binary and used to indicate that > the > > > > > purpose of > > > > > > > the location is for emergency route/dispatch? > > > > > > > > > > > > > > Cheers, > > > > > > > Martin > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > ---- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > contain > > > > > privileged, proprietary, or otherwise private information. > > > > > If you have received it in error, please notify the sender > > > immediately > > > > > > > > > and delete the original. Any unauthorized use of this email is > > > > > prohibited. > > > > > > > > > ---------------------------------------------------------------------- > > > > > ---- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 15:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBor-00020l-Co; Tue, 11 Sep 2007 15:54:45 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVBoq-00020d-3u for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:54:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBop-00020V-QM for geopriv@ietf.org; Tue, 11 Sep 2007 15:54:43 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBoo-0005P6-HY for geopriv@ietf.org; Tue, 11 Sep 2007 15:54:43 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_15_04_04 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 15:04:03 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 14:54:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 14:54:42 -0500 Message-ID: In-Reply-To: <04be01c7f4ab$c5056ac0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAARIrCAAAHuGUAAAbXGAAADHitAAAB3o0A== References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> <04be01c7f4ab$c5056ac0$640fa 8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 19:54:40.0679 (UTC) FILETIME=[97365B70:01C7F4AD] X-Spam-Score: 1.8 (+) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Let me try again.=0D=0A=0D=0ARequesting emergencyRouting stipulates an appl= ication and flags this to=0D=0Athe LIS. The LIS knows what the local PSAP c= an handle, and application=0D=0Amaking the request shouldn't care about the= form since it has already=0D=0Astated what it plans to do with it.=0D=0A=0D= =0ADoes that make sense=3F=0D=0A=0D=0A=20=0D=0A=0D=0A> -----Original Messag= e-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Wed= nesday, 12 September 2007 5:42 AM=0D=0A> To: Winterbottom, James; 'Mary Bar= nes'; Dawson, Martin; Thomson,=0D=0AMartin;=0D=0A> geopriv@ietf.org=0D=0A> = Subject: RE: [Geopriv] responseTime reprise=0D=0A>=20=0D=0A> Huh=3F I just= made an argument that you don't need any extra text and=0D=0A> LocationTyp= e COULD be used with the distinguished values=0D=0A>=20=0D=0A> Brian=0D=0A>= =20=0D=0A> > -----Original Message-----=0D=0A> > From: Winterbottom, James = [mailto:James.Winterbottom@andrew.com]=0D=0A> > Sent: Tuesday, September 11= , 2007 3:22 PM=0D=0A> > To: Brian Rosen; Mary Barnes; Dawson, Martin; Thoms= on, Martin;=0D=0A> > geopriv@ietf.org=0D=0A> > Subject: RE: [Geopriv] respo= nseTime reprise=0D=0A> >=0D=0A> > Yes, let's just add extra text.=0D=0A> >=0D= =0A> > > -----Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br= @brianrosen.net]=0D=0A> > > Sent: Wednesday, 12 September 2007 5:16 AM=0D=0A= > > > To: Winterbottom, James; 'Mary Barnes'; Dawson, Martin; Thomson,=0D=0A= > > Martin;=0D=0A> > > geopriv@ietf.org=0D=0A> > > Subject: RE: [Geopriv] r= esponseTime reprise=0D=0A> > >=0D=0A> > > I don't understand that.=0D=0A> >= >=0D=0A> > > Let's first see if we agree on basic principals:=0D=0A> > > 1= =2E Conversion should never be done implicitly. It could be=0D=0Aexplict i= f=0D=0A> > you=0D=0A> > > want.=0D=0A> > > 2. Conversion on emergency calls= must not be done.=0D=0A> > > 3. A LIS may have multiple determination mech= anisms. It's=0D=0Apossible,=0D=0A> > > albeit=0D=0A> > > unlikely, that on= e could determine a civic and another determine a=0D=0A> > geo.=0D=0A> > > = Despite the fact that I don't think it will happen very often, I'd=0D=0A> >= rather=0D=0A> > > not prohibit that.=0D=0A> > > 4. It may be even more unl= ikely that a LIS would have multiple=0D=0A> > > determination=0D=0A> > > me= chanisms one or more of which resulted in civic and one or more=0D=0Athat=0D= =0A> > > resulted in geo AND that at least one civic and at least one geo=0D= =0Ameet=0D=0A> > the=0D=0A> > > local regulatory requirements, but again, I= wouldn't want to=0D=0Aprohibit=0D=0A> > it.=0D=0A> > >=0D=0A> > > That mea= ns that locationType still matters, right=3F Unlikely=0D=0Aperhaps,=0D=0A>= > but=0D=0A> > > possible. I don't think we need extra text for this. I = don't=0D=0Athink=0D=0A> > we=0D=0A> > > imply any locationType with the dis= tinguished values.=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > ----= -Original Message-----=0D=0A> > > > From: Winterbottom, James [mailto:James= =2EWinterbottom@andrew.com]=0D=0A> > > > Sent: Tuesday, September 11, 2007 = 2:58 PM=0D=0A> > > > To: Mary Barnes; Brian Rosen; Dawson, Martin; Thomson,= Martin;=0D=0A> > > > geopriv@ietf.org=0D=0A> > > > Subject: RE: [Geopriv] = responseTime reprise=0D=0A> > > >=0D=0A> > > > The only reason that I sugge= sted svc as a separate attribute was=0D=0A> > that it=0D=0A> > > > makes ad= ding other "special cases" easier later. If this isn't a=0D=0A> > concern=0D= =0A> > > > then I have no objection to Brian's approach.=0D=0A> > > >=0D=0A= > > > > I would point out one further thing, and that is if you specify=0D=0A= > > > > emergencyRouting or emergencyDispatch, then also providing a=0D=0A>= > > > locationType is moot as the LIS MUST provide location in the=0D=0Afo= rm=0D=0A> > > > suitable for those services.=0D=0A> > > >=0D=0A> > > > Chee= rs=0D=0A> > > > James=0D=0A> > > >=0D=0A> > > > > -----Original Message----= -=0D=0A> > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com]=0D=0A> >= > > > Sent: Wednesday, 12 September 2007 4:42 AM=0D=0A> > > > > To: Brian = Rosen; Winterbottom, James; Dawson, Martin; Thomson,=0D=0A> > Martin;=0D=0A= > > > > > geopriv@ietf.org=0D=0A> > > > > Subject: RE: [Geopriv] responseTi= me reprise=0D=0A> > > > >=0D=0A> > > > > First, thanks to Martin Thomson fo= r restarting this=0D=0Adiscussion.=0D=0A> > > > >=0D=0A> > > > > I've been = following this ping pong match and trying to figure=0D=0Aout=0D=0A> > how=0D= =0A> > > > we=0D=0A> > > > > could get consensus and it seems there is a pr= oposal on the=0D=0Atable=0D=0A> > with=0D=0A> > > > > which both camps A an= d camps B agree. I know there was a=0D=0Acamp C=0D=0A> > that=0D=0A> > > = > > didn't see the need at all for a responseTime, but I'm hoping=0D=0Athat=0D= =0A> > > > this=0D=0A> > > > > compromise is agreeable at this point in tim= e.=0D=0A> > > > >=0D=0A> > > > > Are others that had not been so entrenched= in camps A, B or C=0D=0Aokay=0D=0A> > > > with=0D=0A> > > > > this approac= h=3F It seems similar to several of the other past=0D=0A> > > > compromise=0D= =0A> > > > > proposals in allowing specification of two elements to meet=0D= =0A> > everyone's=0D=0A> > > > > requirements.=0D=0A> > > > >=0D=0A> > > > = > In the case that folks are agreeable to the general approach,=0D=0Ado=0D=0A= > > we=0D=0A> > > > have=0D=0A> > > > > any other opinions on whether the "= svc" is part of the=0D=0A> > responseTime=0D=0A> > > > > rather than a sepa= rate element. I would actually prefer the=0D=0A> > approach=0D=0A> > > > of=0D= =0A> > > > > having two tokens in responseTime, as Brian suggested, since=0D= =0Ait=0D=0A> > would=0D=0A> > > > > then restrict the "svc" as a qualifer a= ssociated with the=0D=0Atime.=0D=0A> > And,=0D=0A> > > > in=0D=0A> > > > > = this case, I think an IANA registry would be unnecessary. So,=0D=0AI'm=0D=0A= > > > > > hoping folks are now in the mode to debate and comment on this=0D= =0A> > detail=0D=0A> > > > > rather than the general approach.=0D=0A> > > >= >=0D=0A> > > > > Regards,=0D=0A> > > > > Mary=0D=0A> > > > > - HELD editor=0D= =0A> > > > >=0D=0A> > > > > -----Original Message-----=0D=0A> > > > > From:= Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > Sent: Tuesday, Septe= mber 11, 2007 7:25 AM=0D=0A> > > > > To: 'Winterbottom, James'; 'Dawson, Ma= rtin'; 'Thomson,=0D=0AMartin';=0D=0A> > > > > geopriv@ietf.org=0D=0A> > > >= > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > > >=0D=0A> > > > = > Can I live with it=3F Yes.=0D=0A> > > > > I think defining two tokens th= at can go in ResponseTime is=0D=0Aeasier.=0D=0A> > > > >=0D=0A> > > > > Bri= an=0D=0A> > > > >=0D=0A> > > > > > -----Original Message-----=0D=0A> > > > = > > From: Winterbottom, James=0D=0A[mailto:James.Winterbottom@andrew.com]=0D= =0A> > > > > > Sent: Tuesday, September 11, 2007 12:01 AM=0D=0A> > > > > > = To: Dawson, Martin; Brian Rosen; Thomson, Martin;=0D=0A> > geopriv@ietf.org=0D= =0A> > > > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > > > >=0D= =0A> > > > > > So here is my proposal.=0D=0A> > > > > >=0D=0A> > > > > > =0D=0A> > > > > = > =09=0D=0A> > > > > > =09=09civic=0D=0A> > > > > > =09=09geo= detic=0D=0A> > > > > > =09=09locationURI=0D=0A> > > > > > =09=0D=0A> > > > > > =0D=0A> > > > > >=0D=0A> > > > > > Thi= s request says give me location for routing an emergency=0D=0Acall=0D=0A> >= > > > > within=0D=0A> > > > > > 3 seconds please. Where svc is a new attri= bute specifying=0D=0Awhat=0D=0A> > you=0D=0A> > > > > > want it for. This c= ould be an IANA registry item if we=0D=0Awanted to=0D=0A> > go=0D=0A> > > >= > that far.=0D=0A> > > > > >=0D=0A> > > > > > Similarly if you want locati= on for dispatch:=0D=0A> > > > > >=0D=0A> > > > > > =0D=0A> > > > > > =09=0D= =0A> > > > > > =09=09civic=0D=0A> > > > > > =09=09geodetic=0D=0A> > > > > >= =09=0D=0A> > > > > > =0D=0A> > > > > >=0D= =0A> > > > > > You could even ditch the 30 seconds if the thing making the=0D= =0A> > request=0D=0A> > > > > > doesn't care how long it takes.=0D=0A> > > = > > >=0D=0A> > > > > > Brian, can you live with this=3F=0D=0A> > > > > >=0D= =0A> > > > > > Cheers=0D=0A> > > > > > James=0D=0A> > > > > >=0D=0A> > > > = > >=0D=0A> > > > > > > -----Original Message-----=0D=0A> > > > > > > From: = Dawson, Martin=0D=0A> > > > > > > Sent: Tuesday, 11 September 2007 12:36 PM=0D= =0A> > > > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin;=0D=0A= > > > > > > geopriv@ietf.org=0D=0A> > > > > > > Subject: RE: [Geopriv] resp= onseTime reprise=0D=0A> > > > > > >=0D=0A> > > > > > > OK - we can do that.=0D= =0A> > > > > > >=0D=0A> > > > > > > Cheers,=0D=0A> > > > > > > Martin=0D=0A= > > > > > > >=0D=0A> > > > > > > -----Original Message-----=0D=0A> > > > > = > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > > > Sent: T= uesday, 11 September 2007 12:27 PM=0D=0A> > > > > > > To: Dawson, Martin; W= interbottom, James; Thomson, Martin;=0D=0A> > > > > > geopriv@ietf.org=0D=0A= > > > > > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > > > > = >=0D=0A> > > > > > > I want a distinguished value in the ResponseTime field= if=0D=0Athat=0D=0A> > is=0D=0A> > > > > > > all there is.=0D=0A> > > > > >= >=0D=0A> > > > > > >=0D=0A> > > > > > >=0D=0A> > > > > > > > -----Original= Message-----=0D=0A> > > > > > > > From: Dawson, Martin [mailto:Martin.Daws= on@andrew.com]=0D=0A> > > > > > > > Sent: Monday, September 10, 2007 6:41 P= M=0D=0A> > > > > > > > To: Brian Rosen; Winterbottom, James; Thomson, Marti= n;=0D=0A> > > > > > geopriv@ietf.org=0D=0A> > > > > > > > Subject: RE: [Geo= priv] responseTime reprise=0D=0A> > > > > > > >=0D=0A> > > > > > > > I thin= k the text you have below is suitable for=0D=0Ainclusion=0D=0A> > in,=0D=0A= > > > > say,=0D=0A> > > > > > the=0D=0A> > > > > > > > ECRIT BCP. We need t= ext for the HELD spec - which I=0D=0Adon't=0D=0A> > think=0D=0A> > > > > > = should=0D=0A> > > > > > > > be quantifying anything. I gather you'd like an= optional=0D=0A> > > > parameter=0D=0A> > > > > > in=0D=0A> > > > > > > > t= he HELD request that is binary and used to indicate=0D=0Athat=0D=0A> > the=0D= =0A> > > > > > purpose of=0D=0A> > > > > > > > the location is for emergenc= y route/dispatch=3F=0D=0A> > > > > > > >=0D=0A> > > > > > > > Cheers,=0D=0A= > > > > > > > > Martin=0D=0A> > > > > > > >=0D=0A> > > > > > > > -----Origi= nal Message-----=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D= =0A----------------------------------------------------------------------=0D= =0A> > > > > > ----=0D=0A> > > > > > ----------------------=0D=0A> > > > > = > This message is for the designated recipient only and may=0D=0A> > contai= n=0D=0A> > > > > > privileged, proprietary, or otherwise private informatio= n.=0D=0A> > > > > > If you have received it in error, please notify the sen= der=0D=0A> > > > immediately=0D=0A> > > > >=0D=0A> > > > > > and delete the= original. Any unauthorized use of this email=0D=0Ais=0D=0A> > > > > > pro= hibited.=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A----------------------= ------------------------------------------------=0D=0A> > > > > > ----=0D=0A= > > > > > > ----------------------=0D=0A> > > > > > [mf2]=0D=0A> > > > >=0D= =0A> > > > >=0D=0A> > > > >=0D=0A> > > > > ________________________________= _______________=0D=0A> > > > > Geopriv mailing list=0D=0A> > > > > Geopriv@= ietf.org=0D=0A> > > > > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A= > > > >=0D=0A> > > >=0D=0A> >=0D=0A----------------------------------------= --------------------------------=0D=0A> > > --=0D=0A> > > > ---------------= -------=0D=0A> > > > This message is for the designated recipient only and = may=0D=0A> > > > contain privileged, proprietary, or otherwise private=0D=0A= information.=0D=0A> > > > If you have received it in error, please notify t= he sender=0D=0A> > > > immediately and delete the original. Any unauthoriz= ed use of=0D=0A> > > > this email is prohibited.=0D=0A> > > >=0D=0A> >=0D=0A= ------------------------------------------------------------------------=0D= =0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > [mf2]=0D=0A> >= >=0D=0A> >=0D=0A> >=0D=0A-------------------------------------------------= -----------------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > = This message is for the designated recipient only and may=0D=0A> > contain = privileged, proprietary, or otherwise private information.=0D=0A> > If you = have received it in error, please notify the sender=0D=0A> > immediately an= d delete the original. Any unauthorized use of=0D=0A> > this email is proh= ibited.=0D=0A> >=0D=0A-----------------------------------------------------= -------------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2= ]=0D=0A>=20=0D=0A=0D=0A----------------------------------------------------= --------------------------------------------=0D=0AThis message is for the d= esignated recipient only and may=0D=0Acontain privileged, proprietary, or o= therwise private information. =20=0D=0AIf you have received it in error, pl= ease notify the sender=0D=0Aimmediately and delete the original. Any unaut= horized use of=0D=0Athis email is prohibited.=0D=0A------------------------= ------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 16:11:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVC3M-00033c-30; Tue, 11 Sep 2007 16:09:44 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVC3J-0002za-39 for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:09:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVC3I-0002zS-8w for geopriv@ietf.org; Tue, 11 Sep 2007 16:09:40 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVC3G-0005f1-VQ for geopriv@ietf.org; Tue, 11 Sep 2007 16:09:40 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IVC34-0007jG-Md; Tue, 11 Sep 2007 15:09:27 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Mary Barnes'" , "'Dawson, Martin'" , "'Thomson, Martin'" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> <04be01c7f4ab$c5056ac0$640fa8c0@cis.neus tar.com> Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 16:09:34 -0400 Message-ID: <04ca01c7f4af$ae509800$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAARIrCAAAHuGUAAAbXGAAADHitAAAB3o0AAAtCDA In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Sorry, no. I agree that the LIS knows what the use is, and therefore does know what is acceptable. However, as I explained, it could be that the LIS could, for example, deliver either civic or geo meeting local requirements. In that case, the client's choice may be appropriate. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, September 11, 2007 3:55 PM > To: Brian Rosen; Mary Barnes; Dawson, Martin; Thomson, Martin; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > Let me try again. > > Requesting emergencyRouting stipulates an application and flags this to > the LIS. The LIS knows what the local PSAP can handle, and application > making the request shouldn't care about the form since it has already > stated what it plans to do with it. > > Does that make sense? > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, 12 September 2007 5:42 AM > > To: Winterbottom, James; 'Mary Barnes'; Dawson, Martin; Thomson, > Martin; > > geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > Huh? I just made an argument that you don't need any extra text and > > LocationType COULD be used with the distinguished values > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Tuesday, September 11, 2007 3:22 PM > > > To: Brian Rosen; Mary Barnes; Dawson, Martin; Thomson, Martin; > > > geopriv@ietf.org > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > Yes, let's just add extra text. > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, 12 September 2007 5:16 AM > > > > To: Winterbottom, James; 'Mary Barnes'; Dawson, Martin; Thomson, > > > Martin; > > > > geopriv@ietf.org > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > I don't understand that. > > > > > > > > Let's first see if we agree on basic principals: > > > > 1. Conversion should never be done implicitly. It could be > explict if > > > you > > > > want. > > > > 2. Conversion on emergency calls must not be done. > > > > 3. A LIS may have multiple determination mechanisms. It's > possible, > > > > albeit > > > > unlikely, that one could determine a civic and another determine a > > > geo. > > > > Despite the fact that I don't think it will happen very often, I'd > > > rather > > > > not prohibit that. > > > > 4. It may be even more unlikely that a LIS would have multiple > > > > determination > > > > mechanisms one or more of which resulted in civic and one or more > that > > > > resulted in geo AND that at least one civic and at least one geo > meet > > > the > > > > local regulatory requirements, but again, I wouldn't want to > prohibit > > > it. > > > > > > > > That means that locationType still matters, right? Unlikely > perhaps, > > > but > > > > possible. I don't think we need extra text for this. I don't > think > > > we > > > > imply any locationType with the distinguished values. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > > Sent: Tuesday, September 11, 2007 2:58 PM > > > > > To: Mary Barnes; Brian Rosen; Dawson, Martin; Thomson, Martin; > > > > > geopriv@ietf.org > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > The only reason that I suggested svc as a separate attribute was > > > that it > > > > > makes adding other "special cases" easier later. If this isn't a > > > concern > > > > > then I have no objection to Brian's approach. > > > > > > > > > > I would point out one further thing, and that is if you specify > > > > > emergencyRouting or emergencyDispatch, then also providing a > > > > > locationType is moot as the LIS MUST provide location in the > form > > > > > suitable for those services. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: Wednesday, 12 September 2007 4:42 AM > > > > > > To: Brian Rosen; Winterbottom, James; Dawson, Martin; Thomson, > > > Martin; > > > > > > geopriv@ietf.org > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > First, thanks to Martin Thomson for restarting this > discussion. > > > > > > > > > > > > I've been following this ping pong match and trying to figure > out > > > how > > > > > we > > > > > > could get consensus and it seems there is a proposal on the > table > > > with > > > > > > which both camps A and camps B agree. I know there was a > camp C > > > that > > > > > > didn't see the need at all for a responseTime, but I'm hoping > that > > > > > this > > > > > > compromise is agreeable at this point in time. > > > > > > > > > > > > Are others that had not been so entrenched in camps A, B or C > okay > > > > > with > > > > > > this approach? It seems similar to several of the other past > > > > > compromise > > > > > > proposals in allowing specification of two elements to meet > > > everyone's > > > > > > requirements. > > > > > > > > > > > > In the case that folks are agreeable to the general approach, > do > > > we > > > > > have > > > > > > any other opinions on whether the "svc" is part of the > > > responseTime > > > > > > rather than a separate element. I would actually prefer the > > > approach > > > > > of > > > > > > having two tokens in responseTime, as Brian suggested, since > it > > > would > > > > > > then restrict the "svc" as a qualifer associated with the > time. > > > And, > > > > > in > > > > > > this case, I think an IANA registry would be unnecessary. So, > I'm > > > > > > hoping folks are now in the mode to debate and comment on this > > > detail > > > > > > rather than the general approach. > > > > > > > > > > > > Regards, > > > > > > Mary > > > > > > - HELD editor > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Tuesday, September 11, 2007 7:25 AM > > > > > > To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, > Martin'; > > > > > > geopriv@ietf.org > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > Can I live with it? Yes. > > > > > > I think defining two tokens that can go in ResponseTime is > easier. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > > > > > > > Sent: Tuesday, September 11, 2007 12:01 AM > > > > > > > To: Dawson, Martin; Brian Rosen; Thomson, Martin; > > > geopriv@ietf.org > > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > > > So here is my proposal. > > > > > > > > > > > > > > > > > > > > > > > > > > > > civic > > > > > > > geodetic > > > > > > > locationURI > > > > > > > > > > > > > > > > > > > > > > > > > > > > This request says give me location for routing an emergency > call > > > > > > > within > > > > > > > 3 seconds please. Where svc is a new attribute specifying > what > > > you > > > > > > > want it for. This could be an IANA registry item if we > wanted to > > > go > > > > > > that far. > > > > > > > > > > > > > > Similarly if you want location for dispatch: > > > > > > > > > > > > > > > > > > > > > > > > > > > > civic > > > > > > > geodetic > > > > > > > > > > > > > > > > > > > > > > > > > > > > You could even ditch the 30 seconds if the thing making the > > > request > > > > > > > doesn't care how long it takes. > > > > > > > > > > > > > > Brian, can you live with this? > > > > > > > > > > > > > > Cheers > > > > > > > James > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dawson, Martin > > > > > > > > Sent: Tuesday, 11 September 2007 12:36 PM > > > > > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > > > > > > geopriv@ietf.org > > > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > > > > > OK - we can do that. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Martin > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > > Sent: Tuesday, 11 September 2007 12:27 PM > > > > > > > > To: Dawson, Martin; Winterbottom, James; Thomson, Martin; > > > > > > > geopriv@ietf.org > > > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > > > > > I want a distinguished value in the ResponseTime field if > that > > > is > > > > > > > > all there is. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > > > > Sent: Monday, September 10, 2007 6:41 PM > > > > > > > > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; > > > > > > > geopriv@ietf.org > > > > > > > > > Subject: RE: [Geopriv] responseTime reprise > > > > > > > > > > > > > > > > > > I think the text you have below is suitable for > inclusion > > > in, > > > > > say, > > > > > > > the > > > > > > > > > ECRIT BCP. We need text for the HELD spec - which I > don't > > > think > > > > > > > should > > > > > > > > > be quantifying anything. I gather you'd like an optional > > > > > parameter > > > > > > > in > > > > > > > > > the HELD request that is binary and used to indicate > that > > > the > > > > > > > purpose of > > > > > > > > > the location is for emergency route/dispatch? > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Martin > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > ---- > > > > > > > ---------------------- > > > > > > > This message is for the designated recipient only and may > > > contain > > > > > > > privileged, proprietary, or otherwise private information. > > > > > > > If you have received it in error, please notify the sender > > > > > immediately > > > > > > > > > > > > > and delete the original. Any unauthorized use of this email > is > > > > > > > prohibited. > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > ---- > > > > > > > ---------------------- > > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Geopriv mailing list > > > > > > Geopriv@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 16:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVC4H-0005dG-3k; Tue, 11 Sep 2007 16:10:41 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVC4E-0005Wn-J8 for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:10:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVC4E-0005SU-3K for geopriv@ietf.org; Tue, 11 Sep 2007 16:10:38 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVC4C-0005fx-7Q for geopriv@ietf.org; Tue, 11 Sep 2007 16:10:37 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_15_19_58 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 15:19:58 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 15:10:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 15:10:38 -0500 Message-ID: In-Reply-To: <04ca01c7f4af$ae509800$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acfze0F6bU94lryzR0KJFvhH7LpmbgALx5uwAALZYqAAAL0VoAALvqEgAAFKcUAAATJZYAAAyFSwAAGO2LAACAnCQAAAQ2+wAAJkSZAAEjWSgAAJSaGgAARIrCAAAHuGUAAAbXGAAADHitAAAB3o0AAAtCDAAAA2hqA= References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> <04be01c7f4ab$c5056ac0$640fa 8c0@cis.neus tar.com> <04ca01c7f4af$ae509800$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 20:10:35.0571 (UTC) FILETIME=[D05F5030:01C7F4AF] X-Spam-Score: 1.8 (+) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I can live with that.=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: = Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Wednesday, 12 September= 2007 6:10 AM=0D=0A> To: Winterbottom, James; 'Mary Barnes'; Dawson, Martin= ; Thomson,=0D=0AMartin;=0D=0A> geopriv@ietf.org=0D=0A> Subject: RE: [Geopri= v] responseTime reprise=0D=0A>=20=0D=0A> Sorry, no.=0D=0A>=20=0D=0A> I agre= e that the LIS knows what the use is, and therefore does know=0D=0Awhat=0D=0A= > is=0D=0A> acceptable. However, as I explained, it could be that the LIS = could,=0D=0Afor=0D=0A> example, deliver either civic or geo meeting local r= equirements. In=0D=0Athat=0D=0A> case, the client's choice may be appropri= ate.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original Mess= age-----=0D=0A> > From: Winterbottom, James [mailto:James.Winterbottom@andr= ew.com]=0D=0A> > Sent: Tuesday, September 11, 2007 3:55 PM=0D=0A> > To: Bri= an Rosen; Mary Barnes; Dawson, Martin; Thomson, Martin;=0D=0A> > geopriv@ie= tf.org=0D=0A> > Subject: RE: [Geopriv] responseTime reprise=0D=0A> >=0D=0A>= > Let me try again.=0D=0A> >=0D=0A> > Requesting emergencyRouting stipulat= es an application and flags this=0D=0Ato=0D=0A> > the LIS. The LIS knows wh= at the local PSAP can handle, and=0D=0Aapplication=0D=0A> > making the requ= est shouldn't care about the form since it has=0D=0Aalready=0D=0A> > stated= what it plans to do with it.=0D=0A> >=0D=0A> > Does that make sense=3F=0D=0A= > >=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From= : Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Wednesday, 12 Sep= tember 2007 5:42 AM=0D=0A> > > To: Winterbottom, James; 'Mary Barnes'; Daws= on, Martin; Thomson,=0D=0A> > Martin;=0D=0A> > > geopriv@ietf.org=0D=0A> > = > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >=0D=0A> > > Huh=3F = I just made an argument that you don't need any extra text=0D=0Aand=0D=0A>= > > LocationType COULD be used with the distinguished values=0D=0A> > >=0D= =0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > = > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A>= > > > Sent: Tuesday, September 11, 2007 3:22 PM=0D=0A> > > > To: Brian Ros= en; Mary Barnes; Dawson, Martin; Thomson, Martin;=0D=0A> > > > geopriv@ietf= =2Eorg=0D=0A> > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > = >=0D=0A> > > > Yes, let's just add extra text.=0D=0A> > > >=0D=0A> > > > > = -----Original Message-----=0D=0A> > > > > From: Brian Rosen [mailto:br@bria= nrosen.net]=0D=0A> > > > > Sent: Wednesday, 12 September 2007 5:16 AM=0D=0A= > > > > > To: Winterbottom, James; 'Mary Barnes'; Dawson, Martin;=0D=0AThom= son,=0D=0A> > > > Martin;=0D=0A> > > > > geopriv@ietf.org=0D=0A> > > > > Su= bject: RE: [Geopriv] responseTime reprise=0D=0A> > > > >=0D=0A> > > > > I d= on't understand that.=0D=0A> > > > >=0D=0A> > > > > Let's first see if we a= gree on basic principals:=0D=0A> > > > > 1. Conversion should never be done= implicitly. It could be=0D=0A> > explict if=0D=0A> > > > you=0D=0A> > > >= > want.=0D=0A> > > > > 2. Conversion on emergency calls must not be done.=0D= =0A> > > > > 3. A LIS may have multiple determination mechanisms. It's=0D=0A= > > possible,=0D=0A> > > > > albeit=0D=0A> > > > > unlikely, that one could= determine a civic and another=0D=0Adetermine a=0D=0A> > > > geo.=0D=0A> > = > > > Despite the fact that I don't think it will happen very often,=0D=0AI= 'd=0D=0A> > > > rather=0D=0A> > > > > not prohibit that.=0D=0A> > > > > 4. = It may be even more unlikely that a LIS would have multiple=0D=0A> > > > > = determination=0D=0A> > > > > mechanisms one or more of which resulted in ci= vic and one or=0D=0Amore=0D=0A> > that=0D=0A> > > > > resulted in geo AND t= hat at least one civic and at least one=0D=0Ageo=0D=0A> > meet=0D=0A> > > >= the=0D=0A> > > > > local regulatory requirements, but again, I wouldn't wa= nt to=0D=0A> > prohibit=0D=0A> > > > it.=0D=0A> > > > >=0D=0A> > > > > That= means that locationType still matters, right=3F Unlikely=0D=0A> > perhaps= ,=0D=0A> > > > but=0D=0A> > > > > possible. I don't think we need extra te= xt for this. I don't=0D=0A> > think=0D=0A> > > > we=0D=0A> > > > > imply a= ny locationType with the distinguished values.=0D=0A> > > > >=0D=0A> > > > = > Brian=0D=0A> > > > >=0D=0A> > > > > > -----Original Message-----=0D=0A> >= > > > > From: Winterbottom, James=0D=0A[mailto:James.Winterbottom@andrew.c= om]=0D=0A> > > > > > Sent: Tuesday, September 11, 2007 2:58 PM=0D=0A> > > >= > > To: Mary Barnes; Brian Rosen; Dawson, Martin; Thomson,=0D=0AMartin;=0D= =0A> > > > > > geopriv@ietf.org=0D=0A> > > > > > Subject: RE: [Geopriv] res= ponseTime reprise=0D=0A> > > > > >=0D=0A> > > > > > The only reason that I = suggested svc as a separate attribute=0D=0Awas=0D=0A> > > > that it=0D=0A> = > > > > > makes adding other "special cases" easier later. If this=0D=0Aisn= 't a=0D=0A> > > > concern=0D=0A> > > > > > then I have no objection to Bria= n's approach.=0D=0A> > > > > >=0D=0A> > > > > > I would point out one furth= er thing, and that is if you=0D=0Aspecify=0D=0A> > > > > > emergencyRouting= or emergencyDispatch, then also providing a=0D=0A> > > > > > locationType = is moot as the LIS MUST provide location in the=0D=0A> > form=0D=0A> > > > = > > suitable for those services.=0D=0A> > > > > >=0D=0A> > > > > > Cheers=0D= =0A> > > > > > James=0D=0A> > > > > >=0D=0A> > > > > > > -----Original Mess= age-----=0D=0A> > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.co= m]=0D=0A> > > > > > > Sent: Wednesday, 12 September 2007 4:42 AM=0D=0A> > >= > > > > To: Brian Rosen; Winterbottom, James; Dawson, Martin;=0D=0AThomson= ,=0D=0A> > > > Martin;=0D=0A> > > > > > > geopriv@ietf.org=0D=0A> > > > > >= > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > > > > >=0D=0A> > = > > > > > First, thanks to Martin Thomson for restarting this=0D=0A> > disc= ussion.=0D=0A> > > > > > >=0D=0A> > > > > > > I've been following this ping= pong match and trying to=0D=0Afigure=0D=0A> > out=0D=0A> > > > how=0D=0A> = > > > > > we=0D=0A> > > > > > > could get consensus and it seems there is a= proposal on=0D=0Athe=0D=0A> > table=0D=0A> > > > with=0D=0A> > > > > > > w= hich both camps A and camps B agree. I know there was a=0D=0A> > camp C=0D= =0A> > > > that=0D=0A> > > > > > > didn't see the need at all for a respons= eTime, but I'm=0D=0Ahoping=0D=0A> > that=0D=0A> > > > > > this=0D=0A> > > >= > > > compromise is agreeable at this point in time.=0D=0A> > > > > > >=0D= =0A> > > > > > > Are others that had not been so entrenched in camps A, B=0D= =0Aor C=0D=0A> > okay=0D=0A> > > > > > with=0D=0A> > > > > > > this approac= h=3F It seems similar to several of the other=0D=0Apast=0D=0A> > > > > > c= ompromise=0D=0A> > > > > > > proposals in allowing specification of two ele= ments to=0D=0Ameet=0D=0A> > > > everyone's=0D=0A> > > > > > > requirements.=0D= =0A> > > > > > >=0D=0A> > > > > > > In the case that folks are agreeable to= the general=0D=0Aapproach,=0D=0A> > do=0D=0A> > > > we=0D=0A> > > > > > ha= ve=0D=0A> > > > > > > any other opinions on whether the "svc" is part of th= e=0D=0A> > > > responseTime=0D=0A> > > > > > > rather than a separate eleme= nt. I would actually prefer=0D=0Athe=0D=0A> > > > approach=0D=0A> > > > > >= of=0D=0A> > > > > > > having two tokens in responseTime, as Brian suggeste= d,=0D=0Asince=0D=0A> > it=0D=0A> > > > would=0D=0A> > > > > > > then restri= ct the "svc" as a qualifer associated with the=0D=0A> > time.=0D=0A> > > > = And,=0D=0A> > > > > > in=0D=0A> > > > > > > this case, I think an IANA regi= stry would be unnecessary.=0D=0ASo,=0D=0A> > I'm=0D=0A> > > > > > > hoping = folks are now in the mode to debate and comment on=0D=0Athis=0D=0A> > > > d= etail=0D=0A> > > > > > > rather than the general approach.=0D=0A> > > > > >= >=0D=0A> > > > > > > Regards,=0D=0A> > > > > > > Mary=0D=0A> > > > > > > -= HELD editor=0D=0A> > > > > > >=0D=0A> > > > > > > -----Original Message---= --=0D=0A> > > > > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> >= > > > > > Sent: Tuesday, September 11, 2007 7:25 AM=0D=0A> > > > > > > To:= 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson,=0D=0A> > Martin';=0D=0A= > > > > > > > geopriv@ietf.org=0D=0A> > > > > > > Subject: RE: [Geopriv] re= sponseTime reprise=0D=0A> > > > > > >=0D=0A> > > > > > > Can I live with it= =3F Yes.=0D=0A> > > > > > > I think defining two tokens that can go in Res= ponseTime is=0D=0A> > easier.=0D=0A> > > > > > >=0D=0A> > > > > > > Brian=0D= =0A> > > > > > >=0D=0A> > > > > > > > -----Original Message-----=0D=0A> > >= > > > > > From: Winterbottom, James=0D=0A> > [mailto:James.Winterbottom@an= drew.com]=0D=0A> > > > > > > > Sent: Tuesday, September 11, 2007 12:01 AM=0D= =0A> > > > > > > > To: Dawson, Martin; Brian Rosen; Thomson, Martin;=0D=0A>= > > > geopriv@ietf.org=0D=0A> > > > > > > > Subject: RE: [Geopriv] respons= eTime reprise=0D=0A> > > > > > > >=0D=0A> > > > > > > > So here is my propo= sal.=0D=0A> > > > > > > >=0D=0A> > > > > > > > =0D=0A> > > > > > > > =09=0D=0A> > > > > > > > =09=09civic=0D=0A> > > > > > > > =09=09geodetic=0D=0A= > > > > > > > > =09=09locationURI=0D=0A> > > > > > > > =09=0D= =0A> > > > > > > > =0D=0A> > > > > > > >=0D=0A> > > > > >= > > This request says give me location for routing an=0D=0Aemergency=0D=0A= > > call=0D=0A> > > > > > > > within=0D=0A> > > > > > > > 3 seconds please.= Where svc is a new attribute=0D=0Aspecifying=0D=0A> > what=0D=0A> > > > yo= u=0D=0A> > > > > > > > want it for. This could be an IANA registry item if = we=0D=0A> > wanted to=0D=0A> > > > go=0D=0A> > > > > > > that far.=0D=0A> >= > > > > > >=0D=0A> > > > > > > > Similarly if you want location for dispat= ch:=0D=0A> > > > > > > >=0D=0A> > > > > > > > =0D=0A> > > > > > > > =09=0D=0A> > > > > > > > =09=09civic=0D=0A> > > > > > > > =09=09geodetic=0D= =0A> > > > > > > > =09=0D=0A> > > > > > > > =0D=0A> > > > > > > >=0D=0A> > > > > > > > You could even ditch the 30 se= conds if the thing making=0D=0Athe=0D=0A> > > > request=0D=0A> > > > > > > = > doesn't care how long it takes.=0D=0A> > > > > > > >=0D=0A> > > > > > > >= Brian, can you live with this=3F=0D=0A> > > > > > > >=0D=0A> > > > > > > >= Cheers=0D=0A> > > > > > > > James=0D=0A> > > > > > > >=0D=0A> > > > > > > = >=0D=0A> > > > > > > > > -----Original Message-----=0D=0A> > > > > > > > > = From: Dawson, Martin=0D=0A> > > > > > > > > Sent: Tuesday, 11 September 200= 7 12:36 PM=0D=0A> > > > > > > > > To: Brian Rosen; Winterbottom, James; Tho= mson, Martin;=0D=0A> > > > > > > > geopriv@ietf.org=0D=0A> > > > > > > > > = Subject: RE: [Geopriv] responseTime reprise=0D=0A> > > > > > > > >=0D=0A> >= > > > > > > > OK - we can do that.=0D=0A> > > > > > > > >=0D=0A> > > > > >= > > > Cheers,=0D=0A> > > > > > > > > Martin=0D=0A> > > > > > > > >=0D=0A> = > > > > > > > > -----Original Message-----=0D=0A> > > > > > > > > From: Bri= an Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > > > > > Sent: Tuesday, 1= 1 September 2007 12:27 PM=0D=0A> > > > > > > > > To: Dawson, Martin; Winter= bottom, James; Thomson,=0D=0AMartin;=0D=0A> > > > > > > > geopriv@ietf.org=0D= =0A> > > > > > > > > Subject: RE: [Geopriv] responseTime reprise=0D=0A> > >= > > > > > >=0D=0A> > > > > > > > > I want a distinguished value in the Res= ponseTime field=0D=0Aif=0D=0A> > that=0D=0A> > > > is=0D=0A> > > > > > > > = > all there is.=0D=0A> > > > > > > > >=0D=0A> > > > > > > > >=0D=0A> > > > = > > > > >=0D=0A> > > > > > > > > > -----Original Message-----=0D=0A> > > > = > > > > > > From: Dawson, Martin=0D=0A[mailto:Martin.Dawson@andrew.com]=0D=0A= > > > > > > > > > > Sent: Monday, September 10, 2007 6:41 PM=0D=0A> > > > >= > > > > > To: Brian Rosen; Winterbottom, James; Thomson,=0D=0AMartin;=0D=0A= > > > > > > > > geopriv@ietf.org=0D=0A> > > > > > > > > > Subject: RE: [Geo= priv] responseTime reprise=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > = > I think the text you have below is suitable for=0D=0A> > inclusion=0D=0A>= > > > in,=0D=0A> > > > > > say,=0D=0A> > > > > > > > the=0D=0A> > > > > > = > > > > ECRIT BCP. We need text for the HELD spec - which I=0D=0A> > don't=0D= =0A> > > > think=0D=0A> > > > > > > > should=0D=0A> > > > > > > > > > be qu= antifying anything. I gather you'd like an=0D=0Aoptional=0D=0A> > > > > > p= arameter=0D=0A> > > > > > > > in=0D=0A> > > > > > > > > > the HELD request = that is binary and used to indicate=0D=0A> > that=0D=0A> > > > the=0D=0A> >= > > > > > > purpose of=0D=0A> > > > > > > > > > the location is for emerge= ncy route/dispatch=3F=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Che= ers,=0D=0A> > > > > > > > > > Martin=0D=0A> > > > > > > > > >=0D=0A> > > > = > > > > > > -----Original Message-----=0D=0A> > > > > > > >=0D=0A> > > > > = > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A-------------------------= ---------------------------------------------=0D=0A> > > > > > > > ----=0D=0A= > > > > > > > > ----------------------=0D=0A> > > > > > > > This message is= for the designated recipient only and=0D=0Amay=0D=0A> > > > contain=0D=0A>= > > > > > > > privileged, proprietary, or otherwise private=0D=0Ainformati= on.=0D=0A> > > > > > > > If you have received it in error, please notify th= e=0D=0Asender=0D=0A> > > > > > immediately=0D=0A> > > > > > >=0D=0A> > > > = > > > > and delete the original. Any unauthorized use of this=0D=0Aemail=0D= =0A> > is=0D=0A> > > > > > > > prohibited.=0D=0A> > > > > > > >=0D=0A> > > = > > >=0D=0A> > > >=0D=0A> >=0D=0A------------------------------------------= ----------------------------=0D=0A> > > > > > > > ----=0D=0A> > > > > > > >= ----------------------=0D=0A> > > > > > > > [mf2]=0D=0A> > > > > > >=0D=0A= > > > > > > >=0D=0A> > > > > > >=0D=0A> > > > > > > _______________________= ________________________=0D=0A> > > > > > > Geopriv mailing list=0D=0A> > >= > > > > Geopriv@ietf.org=0D=0A> > > > > > > https://www1.ietf.org/mailman/= listinfo/geopriv=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D= =0A------------------------------------------------------------------------=0D= =0A> > > > > --=0D=0A> > > > > > ----------------------=0D=0A> > > > > > Th= is message is for the designated recipient only and may=0D=0A> > > > > > co= ntain privileged, proprietary, or otherwise private=0D=0A> > information.=0D= =0A> > > > > > If you have received it in error, please notify the sender=0D= =0A> > > > > > immediately and delete the original. Any unauthorized use=0D= =0Aof=0D=0A> > > > > > this email is prohibited.=0D=0A> > > > > >=0D=0A> > = > >=0D=0A> >=0D=0A---------------------------------------------------------= ---------------=0D=0A> > > > > --=0D=0A> > > > > > ----------------------=0D= =0A> > > > > > [mf2]=0D=0A> > > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D=0A= ------------------------------------------------------------------------=0D= =0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > This message i= s for the designated recipient only and may=0D=0A> > > > contain privileged= , proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you h= ave received it in error, please notify the sender=0D=0A> > > > immediately= and delete the original. Any unauthorized use of=0D=0A> > > > this email = is prohibited.=0D=0A> > > >=0D=0A> >=0D=0A---------------------------------= ---------------------------------------=0D=0A> > > --=0D=0A> > > > --------= --------------=0D=0A> > > > [mf2]=0D=0A> > >=0D=0A> >=0D=0A> >=0D=0A-------= -----------------------------------------------------------------=0D=0A> --=0D= =0A> > ----------------------=0D=0A> > This message is for the designated r= ecipient only and may=0D=0A> > contain privileged, proprietary, or otherwis= e private information.=0D=0A> > If you have received it in error, please no= tify the sender=0D=0A> > immediately and delete the original. Any unauthor= ized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A--------------= ----------------------------------------------------------=0D=0A> --=0D=0A>= > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A-------------= ---------------------------------------------------------------------------= --------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 16:20:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCCR-0004Zb-0j; Tue, 11 Sep 2007 16:19:07 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVCCQ-0004ZU-JS for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:19:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCCP-0004ZE-8r for geopriv@ietf.org; Tue, 11 Sep 2007 16:19:06 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVCCO-0000GJ-Ic for geopriv@ietf.org; Tue, 11 Sep 2007 16:19:04 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8BKInwG013359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2007 13:18:49 -0700 Received: from [98.207.7.244] (carbuncle.qualcomm.com [129.46.226.27]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8BKIleL026151; Tue, 11 Sep 2007 13:18:48 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <021301c7f3ae$ 0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> <04be01c7f4ab$c5056ac0$640fa 8c0@cis.neustar.com> Date: Tue, 11 Sep 2007 13:18:48 -0700 To: "Winterbottom, James" , "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , From: Ted Hardie Subject: RE: [Geopriv] responseTime reprise Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 2:54 PM -0500 9/11/07, Winterbottom, James wrote: >Let me try again. > >Requesting emergencyRouting stipulates an application and flags this to >the LIS. The LIS knows what the local PSAP can handle, and application >making the request shouldn't care about the form since it has already >stated what it plans to do with it. > >Does that make sense? Doesn't make sense to me yet because "The LIS knows what the local PSAP can handle" presumes a pretty well-serviced out of band channel that passes this information and keeps it up to date. Brian said: >3. A LIS may have multiple determination mechanisms. It's possible, albeit >unlikely, that one could determine a civic and another determine a geo. >Despite the fact that I don't think it will happen very often, I'd rather >not prohibit that. >4. It may be even more unlikely that a LIS would have multiple determination >mechanisms one or more of which resulted in civic and one or more that >resulted in geo AND that at least one civic and at least one geo meet the >local regulatory requirements, but again, I wouldn't want to prohibit it. > >That means that locationType still matters, right? Unlikely perhaps, but >possible. I don't think we need extra text for this. I don't think we >imply any locationType with the distinguished values. I thought that this was a reasonable set of points for "locationType still matters", and presuming an out-of-band channel doesn't really seem to eliminate it for me. What am I missing about your point? Ted _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 16:45:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCac-0007QT-2Y; Tue, 11 Sep 2007 16:44:06 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVCab-0007QC-8N for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:44:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCaa-0007Q3-T1 for geopriv@ietf.org; Tue, 11 Sep 2007 16:44:04 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVCaa-0000yk-EB for geopriv@ietf.org; Tue, 11 Sep 2007 16:44:04 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_15_53_26 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 15:53:26 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 15:44:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 15:44:07 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acf0sPhgl0QV4Zh+TLeyUof2cEUC8AAAFWOQ References: <021301c7f3ae$ 0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> <04be01c7f4ab$c5056ac0$64 0fa 8c0@cis. neustar.com> From: "Winterbottom, James" To: "Ted Hardie" , "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 20:44:03.0751 (UTC) FILETIME=[7D574370:01C7F4B4] X-Spam-Score: 1.8 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Ted,=0D=0A=0D=0AA LIS services local areas, and it may service several j= urisdictions.=0D=0AThe LIS needs to know what kinds of location are applica= ble for PSAP=0D=0Arouting in those areas. This may be out of band, but it h= as been a very=0D=0Astrong assumption of the LIS in i3 and i3 which is wher= e the LIS was=0D=0Aborn. I think it has been somewhat assumed even in these= circles,=0D=0Abecause a LIS providing a civic location that doesn't valida= te through=0D=0Athe local LoST server is kind of silly.=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Ted Hardie [mailto:hardie@qualcomm.com]=0D=0A> Sent: Wednesday, = 12 September 2007 6:19 AM=0D=0A> To: Winterbottom, James; Brian Rosen; Mary= Barnes; Dawson, Martin;=0D=0A> Thomson, Martin; geopriv@ietf.org=0D=0A> Su= bject: RE: [Geopriv] responseTime reprise=0D=0A>=20=0D=0A> At 2:54 PM -0500= 9/11/07, Winterbottom, James wrote:=0D=0A> >Let me try again.=0D=0A> >=0D=0A= > >Requesting emergencyRouting stipulates an application and flags this=0D=0A= to=0D=0A> >the LIS. The LIS knows what the local PSAP can handle, and=0D=0A= application=0D=0A> >making the request shouldn't care about the form since = it has already=0D=0A> >stated what it plans to do with it.=0D=0A> >=0D=0A> = >Does that make sense=3F=0D=0A>=20=0D=0A> Doesn't make sense to me yet beca= use "The LIS knows what the local=0D=0APSAP=0D=0A> can handle" presumes a p= retty well-serviced out of band channel that=0D=0A> passes=0D=0A> this info= rmation and keeps it up to date.=0D=0A>=20=0D=0A> Brian said:=0D=0A>=20=0D=0A= > >3. A LIS may have multiple determination mechanisms. It's possible,=0D=0A= > albeit=0D=0A> >unlikely, that one could determine a civic and another det= ermine a=0D=0Ageo.=0D=0A> >Despite the fact that I don't think it will happ= en very often, I'd=0D=0Arather=0D=0A> >not prohibit that.=0D=0A> >4. It may= be even more unlikely that a LIS would have multiple=0D=0A> determination=0D= =0A> >mechanisms one or more of which resulted in civic and one or more=0D=0A= that=0D=0A> >resulted in geo AND that at least one civic and at least one g= eo meet=0D=0Athe=0D=0A> >local regulatory requirements, but again, I wouldn= 't want to prohibit=0D=0Ait.=0D=0A> >=0D=0A> >That means that locationType = still matters, right=3F Unlikely perhaps,=0D=0Abut=0D=0A> >possible. I do= n't think we need extra text for this. I don't think=0D=0Awe=0D=0A> >imply= any locationType with the distinguished values.=0D=0A>=20=0D=0A> I thought= that this was a reasonable set of points for "locationType=0D=0Astill=0D=0A= > matters", and presuming an out-of-band channel doesn't really seem=0D=0A>= to eliminate it for me. What am I missing about your point=3F=0D=0A>=20=0D= =0A> =09=09=09=09=09Ted=0D=0A>=20=0D=0A=0D=0A------------------------------= ------------------------------------------------------------------=0D=0AThi= s message is for the designated recipient only and may=0D=0Acontain privile= ged, proprietary, or otherwise private information. =20=0D=0AIf you have re= ceived it in error, please notify the sender=0D=0Aimmediately and delete th= e original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--= ---------------------------------------------------------------------------= -------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 17:29:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDGf-0004Tu-LS; Tue, 11 Sep 2007 17:27:33 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVDGd-0004LZ-Rj for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 17:27:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDGd-0004LR-Hx for geopriv@ietf.org; Tue, 11 Sep 2007 17:27:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVDGc-0007d7-40 for geopriv@ietf.org; Tue, 11 Sep 2007 17:27:31 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8BLRE9T018430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Sep 2007 14:27:14 -0700 Received: from [98.207.7.244] (carbuncle.qualcomm.com [129.46.226.27]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8BLRAoV031951; Tue, 11 Sep 2007 14:27:13 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <021301c7f3ae$ 0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> <04be01c7f4ab$c5056ac0$64 0fa 8c0@cis. neustar.com> Date: Tue, 11 Sep 2007 14:27:12 -0700 To: "Winterbottom, James" , "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , From: Ted Hardie Subject: RE: [Geopriv] responseTime reprise Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 3:44 PM -0500 9/11/07, Winterbottom, James wrote: >Hi Ted, > >A LIS services local areas, and it may service several jurisdictions. >The LIS needs to know what kinds of location are applicable for PSAP >routing in those areas. This may be out of band, but it has been a very >strong assumption of the LIS in i3 and i3 which is where the LIS was >born. I think it has been somewhat assumed even in these circles, >because a LIS providing a civic location that doesn't validate through >the local LoST server is kind of silly. > >Cheers >James Imagine for a moment a 12k-person enterprise. It has a wiremap database that it wishes to make available as a HELD-enabled LIS, rather than using DHCP to push down the information on login. Our organization has sites in San Diego, Campbell, San Jose, Palo Alto (all California), plus sites in Oregon, Massachusetts, North Carolina, Texas, England, Germany, China, and Japan that are served by its corporate network; it has some 40+ other sites that are not served directly by its corporate network, but which have users using VPNs in fixed locations where the wire map database might be included to cover the endpoint. That's a lot of local knowledge of PSAP routing mechanisms. And note that our example is pretty small fry in terms of sites..... Ted > > > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Wednesday, 12 September 2007 6:19 AM >> To: Winterbottom, James; Brian Rosen; Mary Barnes; Dawson, Martin; >> Thomson, Martin; geopriv@ietf.org >> Subject: RE: [Geopriv] responseTime reprise >> >> At 2:54 PM -0500 9/11/07, Winterbottom, James wrote: >> >Let me try again. >> > >> >Requesting emergencyRouting stipulates an application and flags this >to >> >the LIS. The LIS knows what the local PSAP can handle, and >application >> >making the request shouldn't care about the form since it has already >> >stated what it plans to do with it. >> > >> >Does that make sense? >> >> Doesn't make sense to me yet because "The LIS knows what the local >PSAP >> can handle" presumes a pretty well-serviced out of band channel that >> passes >> this information and keeps it up to date. >> >> Brian said: >> >> >3. A LIS may have multiple determination mechanisms. It's possible, >> albeit >> >unlikely, that one could determine a civic and another determine a >geo. >> >Despite the fact that I don't think it will happen very often, I'd >rather >> >not prohibit that. >> >4. It may be even more unlikely that a LIS would have multiple >> determination >> >mechanisms one or more of which resulted in civic and one or more >that >> >resulted in geo AND that at least one civic and at least one geo meet >the >> >local regulatory requirements, but again, I wouldn't want to prohibit >it. >> > >> >That means that locationType still matters, right? Unlikely perhaps, >but >> >possible. I don't think we need extra text for this. I don't think >we >> >imply any locationType with the distinguished values. >> >> I thought that this was a reasonable set of points for "locationType >still >> matters", and presuming an out-of-band channel doesn't really seem >> to eliminate it for me. What am I missing about your point? >> >> Ted >> > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 17:35:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDMF-0000PR-V2; Tue, 11 Sep 2007 17:33:19 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVDMD-0000Mi-Uf for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 17:33:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDMD-0000Ky-IB for geopriv@ietf.org; Tue, 11 Sep 2007 17:33:17 -0400 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVDMC-0001tJ-La for geopriv@ietf.org; Tue, 11 Sep 2007 17:33:17 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 11 Sep 2007 14:33:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 14:32:35 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750838EB9D@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acf0upekgoVpCWHrTYuesNmCH3Td3AAAE9Zg References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com><036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com><037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com><038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com><040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com><04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com><04be01c7f4ab$c5056ac0$64 0fa 8c0@cis. neu star.com> From: "Roger Marshall" To: "Ted Hardie" , "Winterbottom, James" , "Brian Rosen" , "Mary Barnes" , "Dawson, Martin" , "Thomson, Martin" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Agreed. I also think that the 12k-person enterprise might become subject to a requirement for any/all civic locations to be validated via LoST, for example - but that'd probably be the extent of local PSAP knowledge. -roger marshall.=20 > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com]=20 > Sent: Tuesday, September 11, 2007 2:27 PM > To: Winterbottom, James; Brian Rosen; Mary Barnes; Dawson,=20 > Martin; Thomson, Martin; geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise >=20 > At 3:44 PM -0500 9/11/07, Winterbottom, James wrote: > >Hi Ted, > > > >A LIS services local areas, and it may service several jurisdictions. > >The LIS needs to know what kinds of location are applicable for PSAP=20 > >routing in those areas. This may be out of band, but it has=20 > been a very=20 > >strong assumption of the LIS in i3 and i3 which is where the LIS was=20 > >born. I think it has been somewhat assumed even in these circles,=20 > >because a LIS providing a civic location that doesn't=20 > validate through=20 > >the local LoST server is kind of silly. > > > >Cheers > >James > Imagine for a moment a 12k-person enterprise. It has a=20 > wiremap database that it wishes to make available as a=20 > HELD-enabled LIS, rather than using DHCP to push down the=20 > information on login. >=20 > Our organization has sites in San Diego, Campbell, San Jose,=20 > Palo Alto (all California), plus sites in Oregon,=20 > Massachusetts, North Carolina, Texas, England, Germany,=20 > China, and Japan that are served by its corporate network;=20 > it has some 40+ other sites that are not served directly by=20 > its corporate network, but which have users using VPNs in=20 > fixed locations where the wire map database might be included=20 > to cover the endpoint. >=20 > That's a lot of local knowledge of PSAP routing mechanisms. =20 > And note that our example is pretty small fry in terms of sites..... >=20 > Ted >=20 >=20 >=20 >=20 >=20 >=20 > > > > > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Wednesday, 12 September 2007 6:19 AM > >> To: Winterbottom, James; Brian Rosen; Mary Barnes; Dawson, Martin;=20 > >> Thomson, Martin; geopriv@ietf.org > >> Subject: RE: [Geopriv] responseTime reprise > >> > >> At 2:54 PM -0500 9/11/07, Winterbottom, James wrote: > >> >Let me try again. > >> > > >> >Requesting emergencyRouting stipulates an application and=20 > flags this > >to > >> >the LIS. The LIS knows what the local PSAP can handle, and > >application > >> >making the request shouldn't care about the form since it has=20 > >> >already stated what it plans to do with it. > >> > > >> >Does that make sense? > >> > >> Doesn't make sense to me yet because "The LIS knows what the local > >PSAP > >> can handle" presumes a pretty well-serviced out of band=20 > channel that=20 > >> passes this information and keeps it up to date. > >> > >> Brian said: > >> > >> >3. A LIS may have multiple determination mechanisms. =20 > It's possible, > >> albeit > >> >unlikely, that one could determine a civic and another determine a > >geo. > >> >Despite the fact that I don't think it will happen very often, I'd > >rather > >> >not prohibit that. > >> >4. It may be even more unlikely that a LIS would have multiple > >> determination > >> >mechanisms one or more of which resulted in civic and one or more > >that > >> >resulted in geo AND that at least one civic and at least one geo=20 > >> >meet > >the > >> >local regulatory requirements, but again, I wouldn't want to=20 > >> >prohibit > >it. > >> > > >> >That means that locationType still matters, right? Unlikely=20 > >> >perhaps, > >but > >> >possible. I don't think we need extra text for this. I=20 > don't think > >we > >> >imply any locationType with the distinguished values. > >> > >> I thought that this was a reasonable set of points for=20 > "locationType > >still > >> matters", and presuming an out-of-band channel doesn't=20 > really seem to=20 > >> eliminate it for me. What am I missing about your point? > >> > >> Ted > >> > > > >------------------------------------------------------------- > ---------- > >------------------------- This message is for the designated=20 > recipient=20 > >only and may contain privileged, proprietary, or otherwise private=20 > >information. > >If you have received it in error, please notify the sender=20 > immediately=20 > >and delete the original. Any unauthorized use of this email is=20 > >prohibited. > >------------------------------------------------------------- > ---------- > >------------------------- > >[mf2] > > > > > > > >_______________________________________________ > >Geopriv mailing list > >Geopriv@ietf.org > >https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 18:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVE18-0002Im-4R; Tue, 11 Sep 2007 18:15:34 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVE17-0002I5-CZ for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 18:15:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVE17-0002Hw-1I; Tue, 11 Sep 2007 18:15:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVE16-0002o9-Jk; Tue, 11 Sep 2007 18:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7CFFF2AC49; Tue, 11 Sep 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IVE0c-000156-4p; Tue, 11 Sep 2007 18:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Sep 2007 18:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: geopriv@ietf.org Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-lbyr-requirements-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org --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 : Requirements for a Location-by-Reference Mechanism Author(s) : R. Marshall Filename : draft-ietf-geopriv-lbyr-requirements-00.txt Pages : 19 Date : 2007-9-11 This document defines terminology and provides requirements relating to a Location-by-Reference approach to handling location information within SIP signaling and other Internet messaging. The key for a Location-by-Reference mechanism is the Location URI, which is a reference to a location, and is used by either an end-device or a middlebox to represent a location, and is used as a key by a dereferencing protocol to get a usable form of location. An example application for which the Location-by-Reference mechanism is used is emergency call routing with voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lbyr-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-lbyr-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-geopriv-lbyr-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-11173323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-geopriv-lbyr-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-geopriv-lbyr-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-11173323.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --NextPart-- From geopriv-bounces@ietf.org Tue Sep 11 19:04:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVElB-00057e-Cc; Tue, 11 Sep 2007 19:03:09 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVElA-00057A-Bg for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 19:03:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVElA-000572-1x for geopriv@ietf.org; Tue, 11 Sep 2007 19:03:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVEl8-0001To-So for geopriv@ietf.org; Tue, 11 Sep 2007 19:03:08 -0400 X-IronPort-AV: E=Sophos;i="4.20,240,1186372800"; d="scan'208";a="70800415" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Sep 2007 19:03:04 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8BN36Ar013714; Tue, 11 Sep 2007 19:03:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8BN34BY001423; Tue, 11 Sep 2007 23:03:04 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 19:03:04 -0400 Received: from mlinsnerwxp ([10.82.170.69]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 19:03:03 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 19:03:01 -0400 Message-ID: <00f901c7f4c7$e77481b0$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Acf0sPhgl0QV4Zh+TLeyUof2cEUC8AAAFWOQAAUcN/A= X-OriginalArrivalTime: 11 Sep 2007 23:03:04.0072 (UTC) FILETIME=[E88F4080:01C7F4C7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1023; t=1189551786; x=1190415786; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20responseTime=20reprise |Sender:=20 |To:=20=22'Winterbottom, =20James'=22=20, =0 A=20=20=20=20=20=20=20=20; bh=Soc/qA/GQYQ616fgIoxdhLaspiqqnL3ed7YvH/jH8Tg=; b=QUvxgujItbQSU+IqkDzHX3mXIgI5LPaetsLgBGCb/j12nKTd+AH5VGE8SdqLMynFe+5t1DVx 17ZhUALDa44QMPO6CgwlruSifVDCn1Va/V5DUv9Axe+u4mlc72kMvUHT; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James, > > A LIS services local areas, and it may service several jurisdictions. > The LIS needs to know what kinds of location are applicable > for PSAP routing in those areas. This may be out of band, but > it has been a very strong assumption of the LIS in i3 and i3 > which is where the LIS was born. I think it has been somewhat > assumed even in these circles, because a LIS providing a > civic location that doesn't validate through the local LoST > server is kind of silly. Silly is quite subjective. What incentive does a LIS operator (SP or Enterprise) have to 'validate' via LoST? XYZ Corp. located in the U.S. loads up it's LIS with USPS approved/formated civic locations. It doesn't validate, 911 call fails routing. Who is liable? My point: There is no basis for putting responsibility on the LIS operator for knowing/caring about civic location formats nor jurisdicational required response time/accuracy. fyi, LIS first was defined in TIA TSB-146 in 2001. -Marc- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 19:09:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVEpr-0004Af-CE; Tue, 11 Sep 2007 19:07:59 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVEpq-000474-6O for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 19:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVEpp-00046X-Sh for geopriv@ietf.org; Tue, 11 Sep 2007 19:07:57 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVEpo-0001av-HI for geopriv@ietf.org; Tue, 11 Sep 2007 19:07:57 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_18_17_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 18:17:19 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 18:07:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 18:07:54 -0500 Message-ID: In-Reply-To: <00f901c7f4c7$e77481b0$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acf0sPhgl0QV4Zh+TLeyUof2cEUC8AAAFWOQAAUcN/AAAJjaIA== References: <00f901c7f4c7$e77481b0$220d0d0a@amer.cisco.com> From: "Winterbottom, James" To: "Marc Linsner" , X-OriginalArrivalTime: 11 Sep 2007 23:07:56.0133 (UTC) FILETIME=[96A43950:01C7F4C8] X-Spam-Score: 1.8 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Marc,=0D=0A=0D=0ALet us, as so commonly do, agree to disagree on whether th= ere is a point=0D=0Ain the LIS operator ensuring that locations can be used= for emergency=0D=0Arouting or not. While I don't believe that that is the = only reason for=0D=0Ahaving LIS, I fully recognize that meeting regulations= in this area will=0D=0Abe the impetus for them being deployed. That said, = they will need to=0D=0Awork for that purpose and so the LIS operator will m= ake sure that they=0D=0Ado.=0D=0A=0D=0ADisagree if you like.=0D=0A=0D=0AChe= ers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Marc Li= nsner [mailto:mlinsner@cisco.com]=0D=0A> Sent: Wednesday, 12 September 2007= 9:03 AM=0D=0A> To: Winterbottom, James; geopriv@ietf.org=0D=0A> Subject: R= E: [Geopriv] responseTime reprise=0D=0A>=20=0D=0A> James,=0D=0A>=20=0D=0A> = >=0D=0A> > A LIS services local areas, and it may service several=0D=0Ajuri= sdictions.=0D=0A> > The LIS needs to know what kinds of location are applic= able=0D=0A> > for PSAP routing in those areas. This may be out of band, but=0D= =0A> > it has been a very strong assumption of the LIS in i3 and i3=0D=0A> = > which is where the LIS was born. I think it has been somewhat=0D=0A> > as= sumed even in these circles, because a LIS providing a=0D=0A> > civic locat= ion that doesn't validate through the local LoST=0D=0A> > server is kind of= silly.=0D=0A>=20=0D=0A> Silly is quite subjective.=0D=0A>=20=0D=0A> What i= ncentive does a LIS operator (SP or Enterprise) have to=0D=0A'validate'=0D=0A= > via=0D=0A> LoST=3F=0D=0A>=20=0D=0A> XYZ Corp. located in the U.S. loads u= p it's LIS with USPS=0D=0A> approved/formated=0D=0A> civic locations. It d= oesn't validate, 911 call fails routing. Who is=0D=0A> liable=3F=0D=0A>=20=0D= =0A> My point: There is no basis for putting responsibility on the LIS=0D=0A= operator=0D=0A> for knowing/caring about civic location formats nor jurisdi= cational=0D=0A> required=0D=0A> response time/accuracy.=0D=0A>=20=0D=0A> fy= i, LIS first was defined in TIA TSB-146 in 2001.=0D=0A>=20=0D=0A> -Marc-=0D= =0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 19:45:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVFOS-0005gT-NR; Tue, 11 Sep 2007 19:43:44 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVFOR-0005gO-1R for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 19:43:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVFOQ-0005gG-M2 for geopriv@ietf.org; Tue, 11 Sep 2007 19:43:42 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVFOQ-0004zB-0m for geopriv@ietf.org; Tue, 11 Sep 2007 19:43:42 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_18_53_04 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 18:53:04 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 18:43:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 18:43:38 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acf0uobXkUBI3olSQOG3cwglwbZqAAAEc5fg References: <021301c7f3ae$ 0c1c9f90$640fa8c0@cis.neustar.com> <023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com> <036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com> <037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com> <038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com> <040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> <04b801c7f4a8$22f6ef40$640fa8c0@cis.neustar.com> <04be01c7f4ab$c5056ac0$64 0fa 8c0@cis . neustar.com> From: "Dawson, Martin" To: "Ted Hardie" , "Winterbottom, James" , "Brian Rosen" , "Mary Barnes" , "Thomson, Martin" , X-OriginalArrivalTime: 11 Sep 2007 23:43:41.0200 (UTC) FILETIME=[95337900:01C7F4CD] X-Spam-Score: 1.8 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Ted,=0D=0A=0D=0AYes - that's the implication. You might be able to rely = on somebody=0D=0Aelse's efforts for routing and call on a global network of= LoST servers=0D=0Ato do emergency call routing. But if a jurisdiction has = particular=0D=0Arequirements on the form of the location information, the a= dministrator=0D=0Aof LIS covering those sites will need to be aware of that= =2E=0D=0A=0D=0AFrankly, I wouldn't expect to be able to rely on a robust gl= obal network=0D=0Aof LoST servers any time soon either, so you'll probably = need to have=0D=0Athe local knowledge necessary to query the local LoST ser= vice in any=0D=0Acase.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Origi= nal Message-----=0D=0AFrom: Ted Hardie [mailto:hardie@qualcomm.com]=20=0D=0A= Sent: Wednesday, 12 September 2007 7:27 AM=0D=0ATo: Winterbottom, James; Br= ian Rosen; Mary Barnes; Dawson, Martin;=0D=0AThomson, Martin; geopriv@ietf.= org=0D=0ASubject: RE: [Geopriv] responseTime reprise=0D=0A=0D=0AAt 3:44 PM = -0500 9/11/07, Winterbottom, James wrote:=0D=0A>Hi Ted,=0D=0A>=0D=0A>A LIS = services local areas, and it may service several jurisdictions.=0D=0A>The L= IS needs to know what kinds of location are applicable for PSAP=0D=0A>routi= ng in those areas. This may be out of band, but it has been a very=0D=0A>st= rong assumption of the LIS in i3 and i3 which is where the LIS was=0D=0A>bo= rn. I think it has been somewhat assumed even in these circles,=0D=0A>becau= se a LIS providing a civic location that doesn't validate through=0D=0A>the= local LoST server is kind of silly.=0D=0A>=0D=0A>Cheers=0D=0A>James=0D=0AI= magine for a moment a 12k-person enterprise. It has a wiremap=0D=0Adataba= se=0D=0Athat it wishes to make available as a HELD-enabled LIS, rather than=0D= =0Ausing=0D=0ADHCP to push down the information on login.=0D=0A=0D=0AOur or= ganization has sites in San Diego, Campbell, San Jose, Palo Alto=0D=0A(all = California), plus sites in Oregon, Massachusetts, North Carolina,=0D=0ATexa= s,=0D=0AEngland, Germany, China, and Japan that are served by its corporat= e=0D=0Anetwork;=0D=0Ait has some 40+ other sites that are not served direct= ly by its=0D=0Acorporate network,=0D=0Abut which have users using VPNs in f= ixed locations where the wire map=0D=0Adatabase might be included to cover = the endpoint.=0D=0A=0D=0AThat's a lot of local knowledge of PSAP routing me= chanisms. And note=0D=0Athat=0D=0Aour example is pretty small fry in terms= of sites.....=0D=0A=0D=0A=09=09=09=09=09Ted=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A>=0D=0A>=0D=0A>=0D=0A>> -----Original Message-----=0D=0A>> From: T= ed Hardie [mailto:hardie@qualcomm.com]=0D=0A>> Sent: Wednesday, 12 Septembe= r 2007 6:19 AM=0D=0A>> To: Winterbottom, James; Brian Rosen; Mary Barnes; D= awson, Martin;=0D=0A>> Thomson, Martin; geopriv@ietf.org=0D=0A>> Subject: R= E: [Geopriv] responseTime reprise=0D=0A>>=0D=0A>> At 2:54 PM -0500 9/11/07,= Winterbottom, James wrote:=0D=0A>> >Let me try again.=0D=0A>> >=0D=0A>> >R= equesting emergencyRouting stipulates an application and flags this=0D=0A>t= o=0D=0A>> >the LIS. The LIS knows what the local PSAP can handle, and=0D=0A= >application=0D=0A>> >making the request shouldn't care about the form sinc= e it has=0D=0Aalready=0D=0A>> >stated what it plans to do with it.=0D=0A>> = >=0D=0A>> >Does that make sense=3F=0D=0A>>=0D=0A>> Doesn't make sense to me= yet because "The LIS knows what the local=0D=0A>PSAP=0D=0A>> can handle" p= resumes a pretty well-serviced out of band channel that=0D=0A>> passes=0D=0A= >> this information and keeps it up to date.=0D=0A>>=0D=0A>> Brian said:=0D= =0A>>=0D=0A>> >3. A LIS may have multiple determination mechanisms. It's p= ossible,=0D=0A>> albeit=0D=0A>> >unlikely, that one could determine a civic= and another determine a=0D=0A>geo.=0D=0A>> >Despite the fact that I don't = think it will happen very often, I'd=0D=0A>rather=0D=0A>> >not prohibit tha= t.=0D=0A>> >4. It may be even more unlikely that a LIS would have multiple=0D= =0A>> determination=0D=0A>> >mechanisms one or more of which resulted in ci= vic and one or more=0D=0A>that=0D=0A>> >resulted in geo AND that at least o= ne civic and at least one geo=0D=0Ameet=0D=0A>the=0D=0A>> >local regulatory= requirements, but again, I wouldn't want to=0D=0Aprohibit=0D=0A>it.=0D=0A>= > >=0D=0A>> >That means that locationType still matters, right=3F Unlikely=0D= =0Aperhaps,=0D=0A>but=0D=0A>> >possible. I don't think we need extra text = for this. I don't think=0D=0A>we=0D=0A>> >imply any locationType with the = distinguished values.=0D=0A>>=0D=0A>> I thought that this was a reasonable = set of points for "locationType=0D=0A>still=0D=0A>> matters", and presuming= an out-of-band channel doesn't really seem=0D=0A>> to eliminate it for me.= What am I missing about your point=3F=0D=0A>>=0D=0A>>=09=09=09=09=09Ted=0D= =0A>>=0D=0A>=0D=0A>--------------------------------------------------------= ---------------=0D=0A-------------------------=0D=0A>This message is for th= e designated recipient only and may=0D=0A>contain privileged, proprietary, = or otherwise private information.=20=0D=0A>If you have received it in error= , please notify the sender=0D=0A>immediately and delete the original. Any = unauthorized use of=0D=0A>this email is prohibited.=0D=0A>-----------------= ------------------------------------------------------=0D=0A---------------= ----------=0D=0A>[mf2]=0D=0A>=0D=0A>=0D=0A>=0D=0A>_________________________= ______________________=0D=0A>Geopriv mailing list=0D=0A>Geopriv@ietf.org=0D= =0A>https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A=0D=0A-------= ---------------------------------------------------------------------------= --------------=0D=0AThis message is for the designated recipient only and m= ay=0D=0Acontain privileged, proprietary, or otherwise private information. = =20=0D=0AIf you have received it in error, please notify the sender=0D=0Aim= mediately and delete the original. Any unauthorized use of=0D=0Athis email= is prohibited.=0D=0A------------------------------------------------------= ------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 20:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVG92-0008LQ-B7; Tue, 11 Sep 2007 20:31:52 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVG91-0008LL-JN for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 20:31:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVG91-0008Jr-7U for geopriv@ietf.org; Tue, 11 Sep 2007 20:31:51 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVG90-0005nS-PS for geopriv@ietf.org; Tue, 11 Sep 2007 20:31:51 -0400 X-SEF-Processed: 5_0_0_910__2007_09_11_19_41_10 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 11 Sep 2007 19:41:10 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Sep 2007 19:31:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 19:31:45 -0500 Message-ID: In-Reply-To: <00f901c7f4c7$e77481b0$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] responseTime reprise Thread-Index: Acf0sPhgl0QV4Zh+TLeyUof2cEUC8AAAFWOQAAUcN/AAA5Yk8A== References: <00f901c7f4c7$e77481b0$220d0d0a@amer.cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , "Winterbottom, James" , X-OriginalArrivalTime: 12 Sep 2007 00:31:47.0814 (UTC) FILETIME=[4DC1D060:01C7F4D4] X-Spam-Score: 1.8 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Certainly - if the LIS operator has no incentive (private or regulatory)=0D= =0Ato make emergency calls work then they mightn't work. The point is=0D=0A= somewhat moot.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Mess= age-----=0D=0AFrom: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D=0ASent: = Wednesday, 12 September 2007 9:03 AM=0D=0ATo: Winterbottom, James; geopriv@= ietf.org=0D=0ASubject: RE: [Geopriv] responseTime reprise=0D=0A=0D=0AJames,= =20=0D=0A=0D=0A>=20=0D=0A> A LIS services local areas, and it may service s= everal jurisdictions.=0D=0A> The LIS needs to know what kinds of location a= re applicable=20=0D=0A> for PSAP routing in those areas. This may be out of= band, but=20=0D=0A> it has been a very strong assumption of the LIS in i3 = and i3=20=0D=0A> which is where the LIS was born. I think it has been somew= hat=20=0D=0A> assumed even in these circles, because a LIS providing a=20=0D= =0A> civic location that doesn't validate through the local LoST=20=0D=0A> = server is kind of silly.=0D=0A=0D=0ASilly is quite subjective.=0D=0A=0D=0AW= hat incentive does a LIS operator (SP or Enterprise) have to 'validate'=0D=0A= via=0D=0ALoST=3F=0D=0A=0D=0AXYZ Corp. located in the U.S. loads up it's LIS= with USPS=0D=0Aapproved/formated=0D=0Acivic locations. It doesn't validat= e, 911 call fails routing. Who is=0D=0Aliable=3F=0D=0A=0D=0AMy point: There= is no basis for putting responsibility on the LIS=0D=0Aoperator=0D=0Afor k= nowing/caring about civic location formats nor jurisdicational=0D=0Arequire= d=0D=0Aresponse time/accuracy.=0D=0A=0D=0Afyi, LIS first was defined in TIA= TSB-146 in 2001.=0D=0A=0D=0A-Marc-=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= _______________________________________________=0D=0AGeopriv mailing list=0D= =0AGeopriv@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 11 21:28:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVH0S-0000n2-EP; Tue, 11 Sep 2007 21:27:04 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVH0R-0000mx-J8 for geopriv-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 21:27:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVH0P-0000mo-PO for geopriv@ietf.org; Tue, 11 Sep 2007 21:27:03 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVH0P-0006g9-2C for geopriv@ietf.org; Tue, 11 Sep 2007 21:27:01 -0400 Received: from SusieandCarl (c-24-8-177-87.hsd1.co.comcast.net [24.8.177.87]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l8C1Q2sQ026073 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Sep 2007 21:26:07 -0400 Message-ID: <023601c7f4db$f0a133a0$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Mary Barnes" , "Brian Rosen" , "Winterbottom, James" , "Dawson, Martin" , "Thomson, Martin" , References: <021301c7f3ae$0c1c9f90$640fa8c0@cis.neustar.com><023901c7f3bc$ae4e5980$640fa8c0@cis.neustar.com><036901c7f3f0$5728f0f0$640fa8c0@cis.neustar.com><037301c7f3f8$5d1d78c0$640fa8c0@cis.neustar.com><038e01c7f41b$3fe057f0$640fa8c0@cis.neustar.com><040401c7f46e$b6a4c4e0$640fa8c0@cis.neustar.com> Subject: Re: [Geopriv] responseTime reprise Date: Tue, 11 Sep 2007 19:22:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.91.2/4249/Tue Sep 11 20:16:44 2007 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I have no objection to the proposal. I would only say that if there is no responseTime parameter, then guaranteed as soon as the draft is approved, then someone will say, "Hey what about some sort of response time parameter". Also, FYI, it is easy to encode time info using GML if there is that requirement. Regards Carl ----- Original Message ----- From: "Mary Barnes" To: "Brian Rosen" ; "Winterbottom, James" ; "Dawson, Martin" ; "Thomson, Martin" ; Sent: Tuesday, September 11, 2007 12:41 PM Subject: RE: [Geopriv] responseTime reprise > First, thanks to Martin Thomson for restarting this discussion. > > I've been following this ping pong match and trying to figure out how we > could get consensus and it seems there is a proposal on the table with > which both camps A and camps B agree. I know there was a camp C that > didn't see the need at all for a responseTime, but I'm hoping that this > compromise is agreeable at this point in time. > > Are others that had not been so entrenched in camps A, B or C okay with > this approach? It seems similar to several of the other past compromise > proposals in allowing specification of two elements to meet everyone's > requirements. > > In the case that folks are agreeable to the general approach, do we have > any other opinions on whether the "svc" is part of the responseTime > rather than a separate element. I would actually prefer the approach of > having two tokens in responseTime, as Brian suggested, since it would > then restrict the "svc" as a qualifer associated with the time. And, in > this case, I think an IANA registry would be unnecessary. So, I'm > hoping folks are now in the mode to debate and comment on this detail > rather than the general approach. > > Regards, > Mary > - HELD editor > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, September 11, 2007 7:25 AM > To: 'Winterbottom, James'; 'Dawson, Martin'; 'Thomson, Martin'; > geopriv@ietf.org > Subject: RE: [Geopriv] responseTime reprise > > Can I live with it? Yes. > I think defining two tokens that can go in ResponseTime is easier. > > Brian > >> -----Original Message----- >> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >> Sent: Tuesday, September 11, 2007 12:01 AM >> To: Dawson, Martin; Brian Rosen; Thomson, Martin; geopriv@ietf.org >> Subject: RE: [Geopriv] responseTime reprise >> >> So here is my proposal. >> >> >> >> civic >> geodetic >> locationURI >> >> >> >> This request says give me location for routing an emergency call >> within >> 3 seconds please. Where svc is a new attribute specifying what you >> want it for. This could be an IANA registry item if we wanted to go > that far. >> >> Similarly if you want location for dispatch: >> >> >> >> civic >> geodetic >> >> >> >> You could even ditch the 30 seconds if the thing making the request >> doesn't care how long it takes. >> >> Brian, can you live with this? >> >> Cheers >> James >> >> >> > -----Original Message----- >> > From: Dawson, Martin >> > Sent: Tuesday, 11 September 2007 12:36 PM >> > To: Brian Rosen; Winterbottom, James; Thomson, Martin; >> geopriv@ietf.org >> > Subject: RE: [Geopriv] responseTime reprise >> > >> > OK - we can do that. >> > >> > Cheers, >> > Martin >> > >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Tuesday, 11 September 2007 12:27 PM >> > To: Dawson, Martin; Winterbottom, James; Thomson, Martin; >> geopriv@ietf.org >> > Subject: RE: [Geopriv] responseTime reprise >> > >> > I want a distinguished value in the ResponseTime field if that is >> > all there is. >> > >> > >> > >> > > -----Original Message----- >> > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> > > Sent: Monday, September 10, 2007 6:41 PM >> > > To: Brian Rosen; Winterbottom, James; Thomson, Martin; >> geopriv@ietf.org >> > > Subject: RE: [Geopriv] responseTime reprise >> > > >> > > I think the text you have below is suitable for inclusion in, say, >> the >> > > ECRIT BCP. We need text for the HELD spec - which I don't think >> should >> > > be quantifying anything. I gather you'd like an optional parameter >> in >> > > the HELD request that is binary and used to indicate that the >> purpose of >> > > the location is for emergency route/dispatch? >> > > >> > > Cheers, >> > > Martin >> > > >> > > -----Original Message----- >> >> ---------------------------------------------------------------------- >> ---- >> ---------------------- >> This message is for the designated recipient only and may contain >> privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender immediately > >> and delete the original. Any unauthorized use of this email is >> prohibited. >> ---------------------------------------------------------------------- >> ---- >> ---------------------- >> [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Sep 12 06:45:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVPh5-00039t-Do; Wed, 12 Sep 2007 06:43:39 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVPh3-00039k-H9 for geopriv-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 06:43:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVPh3-00037T-5b for geopriv@ietf.org; Wed, 12 Sep 2007 06:43:37 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVPh2-0007gC-FL for geopriv@ietf.org; Wed, 12 Sep 2007 06:43:36 -0400 Received: (qmail invoked by alias); 12 Sep 2007 10:43:34 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp003) with SMTP; 12 Sep 2007 12:43:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX190Lv5YLRF0HvnIVhFdyYX7TnYdpa9iTPP73VtbxY Zql4Ydb5Kmc5Ve Message-ID: <46E7C2D5.3060805@gmx.net> Date: Wed, 12 Sep 2007 12:43:33 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Geopriv] draft-ietf-geopriv-l7-lcp-ps-05.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, I submitted a new version of draft-ietf-geopriv-l7-lcp-ps after I noticed that the anycast description for the LIS discovery has been commented out. You can find the draft here: http://www.tschofenig.priv.at/svn/draft-tschofenig-geopriv-l7-lcp-ps/draft-ietf-geopriv-l7-lcp-ps-05.txt I made some minor editorial changes to the other discovery mechanisms as well. Finally, I added the following requirement based on the discussions we had on the PIDF-LO profile draft. " Requirement L7-10: PIDF-LO Creation When a LIS creates a PIDF-LO [20] then it MUST put the element into the element of the presence document (see [21]). This ensures that the resulting PIDF-LO document, which is subsequently distributed to other entities, conforms to the rules outlined in [22]. " Let me know if you are fine with it. Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Sep 12 09:03:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVRqS-0008IY-Km; Wed, 12 Sep 2007 09:01:28 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVRqR-0008IB-5N for geopriv-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 09:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVRqQ-0008Hu-DB for geopriv@ietf.org; Wed, 12 Sep 2007 09:01:26 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVRqP-0006Hd-4s for geopriv@ietf.org; Wed, 12 Sep 2007 09:01:26 -0400 X-IronPort-AV: E=Sophos;i="4.20,244,1186383600"; d="scan'208";a="17573723" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Sep 2007 06:01:24 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8CD1OrO027088; Wed, 12 Sep 2007 06:01:24 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8CD1LoJ026241; Wed, 12 Sep 2007 13:01:22 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 09:01:21 -0400 Received: from mlinsnerwxp ([10.82.170.69]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 09:01:20 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , Subject: RE: [Geopriv] responseTime reprise Date: Wed, 12 Sep 2007 09:01:20 -0400 Message-ID: <004a01c7f53d$04208a00$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Acf0sPhgl0QV4Zh+TLeyUof2cEUC8AAAFWOQAAUcN/AAAJjaIAAcBLfQ X-OriginalArrivalTime: 12 Sep 2007 13:01:21.0342 (UTC) FILETIME=[041195E0:01C7F53D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3496; t=1189602084; x=1190466084; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20responseTime=20reprise |Sender:=20; bh=kGDh9eKR7J7iQiIa/VLZpBvokGrBRj/N6Ud7c07fRkM=; b=JwbAjEg2bzdSdEyz4hJ/ub1VVpnMPClex0v5em8r9OiFgezJvy44UsDWngt6vqUkoCWHiZt2 DOo7W+RBq56U4LbyE/8mdyzeZTxtW8VzXxPtRFBmtN28SzEdXkHESLhXljA6jEZwEUHj0itpzg 9jrD4+OkpuONasSvGMsCnPhvQ=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org James, The point of my comment continues the mantra I've stated for several years. The more unique you make the requirements for successful emergency calling, the more likely there will be failures. I believe we all agree and wish that emergency calling will be significantly less than 1% of the uses of location information in the future. To this point, let's make emergency calling work just like the remaining 99% of the location based applications. Yes, there will be a few 'small' adjustments to accommodate ES due to it's nature. But making assumptions that a LIS operator will do more than load the wire map db with locally recognized civic location data AND basing the ES calling architecture on this fact is, IMO, asking for failure. I'm simply stating my experience with various other Internet-based/IP applications. I realize not all I'm advocating can/will be solved within IETF protocols. So, it worries me when we start adding things to protocols like, 'give me an ES location-type'. Carry-on, -Marc- > > Let us, as so commonly do, agree to disagree on whether there > is a point in the LIS operator ensuring that locations can be > used for emergency routing or not. While I don't believe that > that is the only reason for having LIS, I fully recognize > that meeting regulations in this area will be the impetus for > them being deployed. That said, they will need to work for > that purpose and so the LIS operator will make sure that they do. > > Disagree if you like. > > Cheers > James > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Wednesday, 12 September 2007 9:03 AM > > To: Winterbottom, James; geopriv@ietf.org > > Subject: RE: [Geopriv] responseTime reprise > > > > James, > > > > > > > > A LIS services local areas, and it may service several > jurisdictions. > > > The LIS needs to know what kinds of location are > applicable for PSAP > > > routing in those areas. This may be out of band, but it > has been a > > > very strong assumption of the LIS in i3 and i3 which is where the > > > LIS was born. I think it has been somewhat assumed even in these > > > circles, because a LIS providing a civic location that doesn't > > > validate through the local LoST server is kind of silly. > > > > Silly is quite subjective. > > > > What incentive does a LIS operator (SP or Enterprise) have to > 'validate' > > via > > LoST? > > > > XYZ Corp. located in the U.S. loads up it's LIS with USPS > > approved/formated civic locations. It doesn't validate, 911 call > > fails routing. Who is liable? > > > > My point: There is no basis for putting responsibility on the LIS > operator > > for knowing/caring about civic location formats nor jurisdicational > > required response time/accuracy. > > > > fyi, LIS first was defined in TIA TSB-146 in 2001. > > > > -Marc- > > > > > > > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Wed Sep 12 11:11:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVTqE-0005Yu-3u; Wed, 12 Sep 2007 11:09:22 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVTqD-0005Yf-KB for geopriv-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 11:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVTqD-0005YX-AS for geopriv@ietf.org; Wed, 12 Sep 2007 11:09:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVTqC-0001KZ-3m for geopriv@ietf.org; Wed, 12 Sep 2007 11:09:21 -0400 X-IronPort-AV: E=Sophos;i="4.20,245,1186383600"; d="scan'208";a="216773191" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2007 08:09:19 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8CF9J00016700; Wed, 12 Sep 2007 08:09:19 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l8CF9Iav022814; Wed, 12 Sep 2007 15:09:19 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <29DD4D9F-56AC-4BF3-9785-F91F09B79750@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Wed, 12 Sep 2007 08:07:50 -0700 To: GEOPRIV X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=335; t=1189609759; x=1190473759; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Some=20documents=20from=20DSL=20Forum |Sender:=20; bh=m6c0RAkwmjeHO/pD2a2MYKfxuMiqbB5oh3T9UDUZjbM=; b=CG6wVl/AWsvdXtLy6h8Y32Y0OdZUt3cZ8fpBK0AdIZyn4AtZSVYKZ78j4UWlPeSuQEkuOfOO wqWO3O5u27pWQNq46cmF95bzmznw5Hj0bmOpUd/R7sMTL2KXwxHV4Yzt980a6b7OdpfHIjdXce QxbsvuZuxXN7sULdSkJfkJiVQ=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Jon Peterson Subject: [Geopriv] Some documents from DSL Forum X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org This message was also sent to ECRIT but please only reply to one list. In my IETF AD Role I received some documents from DSL Forum that are of relevant to this WG. I have posted them at: http://www.dial911anddie.com/DSLForum/WT-164v2.pdf and http://www.dial911anddie.com/DSLForum/WT-164v2-xls.pdf Thanks, Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Berglesbttbl@northwestfurs.com Wed Sep 12 11:26:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVU74-0000aA-NT for geopriv-archive@lists.ietf.org; Wed, 12 Sep 2007 11:26:46 -0400 Received: from [217.220.207.9] (helo=[217.220.207.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVU73-0007HT-Tz for geopriv-archive@lists.ietf.org; Wed, 12 Sep 2007 11:26:46 -0400 Received: from computer5 ([128.173.32.41] helo=computer5) by h217-220-207-9-static.albacom.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1rOkbi-000KNC-OE for geopriv-archive@lists.ietf.org; Wed, 12 Sep 2007 17:27:32 +0200 Message-ID: <000201c7f551$5a123fd0$09cfdcd9@computer5> From: "Biagio Bergles" To: Subject: saripmel Date: Wed, 12 Sep 2007 17:26:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F562.1D9B0FD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C7F562.1D9B0FD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://negvator.com/ compliments geopriv-archive What is the Best Way to Enlarge Penis? Biagio Bergles ------=_NextPart_000_0005_01C7F562.1D9B0FD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://negvator.com/
compliments geopriv-archive
What is the Best Way to Enlarge = Penis?
Biagio Bergles
------=_NextPart_000_0005_01C7F562.1D9B0FD0-- From geopriv-bounces@ietf.org Wed Sep 12 12:16:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUrv-0002kj-Jj; Wed, 12 Sep 2007 12:15:11 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVUrn-0002ib-J4 for geopriv-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 12:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUrn-0002i9-3p; Wed, 12 Sep 2007 12:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVUrm-0002un-C3; Wed, 12 Sep 2007 12:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3845E26E3F; Wed, 12 Sep 2007 16:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IVUrm-0007x0-4G; Wed, 12 Sep 2007 12:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Sep 2007 12:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: geopriv@ietf.org Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-l7-lcp-ps-05.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org --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 : GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements Author(s) : H. Tschofenig, H. Schulzrinne Filename : draft-ietf-geopriv-l7-lcp-ps-05.txt Pages : 25 Date : 2007-9-12 This document provides a problem statement, lists requirements and captures design aspects for a Geopriv Layer 7 Location Configuration Protocol L7 (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation Protocol (LoST) or to convey location within SIP to other entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-l7-lcp-ps-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-9-12113359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-geopriv-l7-lcp-ps-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-12113359.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --NextPart-- From geopriv-bounces@ietf.org Thu Sep 13 12:03:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVrAb-0006ot-D1; Thu, 13 Sep 2007 12:03:57 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVrAZ-0006l9-Kj for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 12:03:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVrAZ-0006l1-B0 for geopriv@ietf.org; Thu, 13 Sep 2007 12:03:55 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVrAY-0000A3-3t for geopriv@ietf.org; Thu, 13 Sep 2007 12:03:55 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DG3p516190 for ; Thu, 13 Sep 2007 16:03:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Sep 2007 11:01:45 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/Bw== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1720796865==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1720796865== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F61F.AA8A7F64" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F61F.AA8A7F64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This thread never seemed to conclude with clear consensus as to whether folks see a need for both these specific location types rather than being able to use a common "civic" locationType. I went back through the threads and the majority of the responses indicated that both of the values should be the same (with Canada being the exception?). Since the thread did diverge somewhat (into how conversions etc. are done), I would like to do a quick query to see if folks are okay with removing those two values from the locationType in the HELD draft? =20 And, just to be precise, we're proposing changing locationType from a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, locationURI} to a set of {any, civic, geodetic, locationURI}. =20 Regards, Mary Editor HELD=20 ------_=_NextPart_001_01C7F61F.AA8A7F64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Postal" and "Jurisdicational" civic = locations - reprise

Hi all,

This thread never seemed to conclude = with clear consensus as to whether folks see a need for both these = specific location types rather than being able to use a common = "civic" locationType.     I went back = through the threads and the majority of the responses indicated that = both of the values should be the same (with Canada being the = exception?).   Since the thread did diverge somewhat (into how = conversions etc. are done), I would like to do a quick query to see if = folks are okay with removing those two values from the locationType in = the HELD draft?  

And, just to be precise, we're = proposing changing locationType from a set of {any, civic, geodetic, = postalCivic, jurisdictionalCivic, locationURI} to a set of

{any, civic, geodetic, = locationURI}. 

Regards,
Mary
Editor HELD


------_=_NextPart_001_01C7F61F.AA8A7F64-- --===============1720796865== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1720796865==-- From geopriv-bounces@ietf.org Thu Sep 13 12:08:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVrEn-0006W6-O1; Thu, 13 Sep 2007 12:08:17 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVrEm-0006W1-HX for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 12:08:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVrEl-0006Vt-Mq for geopriv@ietf.org; Thu, 13 Sep 2007 12:08:16 -0400 Received: from mail1.911.org ([65.67.130.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVrEl-0001XY-1Q for geopriv@ietf.org; Thu, 13 Sep 2007 12:08:15 -0400 Received: from ghcmail [192.168.6.230] by mail1.911.org - SurfControl E-mail Filter (5.5.0); Thu, 13 Sep 2007 11:05:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 11:08:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAAG9yg References: From: "Marc Berryman" To: "Mary Barnes" , X-SEF-Processed: 5_5_0_191__2007_09_13_11_05_49 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0138365003==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0138365003== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F620.4899692C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F620.4899692C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mary, I do not think that Jurisdiction and Postal need to be the same, often they are not the same, since postal rarely follows the same "boundaries" as jurisdictional. Since they may, or may not, be the same is the reason they are both included. You can not assume they are the same. =20 Marc B =20 Marc Berryman, ENP Geographic Information Systems Greater Harris County 9-1-1 Emergency Network Houston, Texas (713) 407-2254 mberryman@911.org ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Thursday, September 13, 2007 11:02 AM To: geopriv@ietf.org Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise =20 Hi all,=20 This thread never seemed to conclude with clear consensus as to whether folks see a need for both these specific location types rather than being able to use a common "civic" locationType. I went back through the threads and the majority of the responses indicated that both of the values should be the same (with Canada being the exception?). Since the thread did diverge somewhat (into how conversions etc. are done), I would like to do a quick query to see if folks are okay with removing those two values from the locationType in the HELD draft? =20 And, just to be precise, we're proposing changing locationType from a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, locationURI} to a set of {any, civic, geodetic, locationURI}. =20 Regards,=20 Mary=20 Editor HELD=20 =20 ------_=_NextPart_001_01C7F620.4899692C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Postal" and "Jurisdicational" civic = locations - reprise

Mary,

 I do not think that = Jurisdiction and Postal need to be the same, often they are not the same, since postal = rarely follows the same “boundaries” as jurisdictional. Since they = may, or may not, be the same is the reason they are both included. You can not = assume they are the same.

 

Marc B

 

Marc Berryman, ENP
Geographic Information Systems
Greater Harris County 9-1-1 Emergency = Network
Houston, = Texas      (713) 407-2254
mberryman@911.org

From: Mary = Barnes [mailto:mary.barnes@nortel.com]
Sent: Thursday, September = 13, 2007 11:02 AM
To: geopriv@ietf.org
Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - = reprise

 

Hi all,

This thread never seemed to conclude with clear consensus as to whether folks = see a need for both these specific location types rather than being able to = use a common "civic" locationType.     I went = back through the threads and the majority of the responses indicated that = both of the values should be the same (with Canada being the exception?).   Since the thread did diverge somewhat (into how conversions etc. are done), I would like to do a quick query to see if = folks are okay with removing those two values from the locationType in the = HELD draft?  

And, just to be precise, we're proposing changing locationType from a set of = {any, civic, geodetic, postalCivic, jurisdictionalCivic, locationURI} to a set = of

{any, civic, geodetic, locationURI}. 

Regards,
Mary
Editor HELD

 

------_=_NextPart_001_01C7F620.4899692C-- --===============0138365003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0138365003==-- From geopriv-bounces@ietf.org Thu Sep 13 13:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVsqM-0004ea-CO; Thu, 13 Sep 2007 13:51:10 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVsqL-0004eG-1R for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 13:51:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVsqK-0004e8-KT for geopriv@ietf.org; Thu, 13 Sep 2007 13:51:08 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVsqK-000488-6x for geopriv@ietf.org; Thu, 13 Sep 2007 13:51:08 -0400 Received: from ([139.76.131.79]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.29466265; Thu, 13 Sep 2007 13:50:49 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 13:50:49 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 13:50:48 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 13:50:46 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise thread-index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAAG9ygAAMwFmA= References: From: "Stark, Barbara" To: "Marc Berryman" , "Mary Barnes" , X-OriginalArrivalTime: 13 Sep 2007 17:50:48.0719 (UTC) FILETIME=[9E3EC1F0:01C7F62E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0651660661==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0651660661== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F62E.9DE9736E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F62E.9DE9736E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The impression I was left with, was that it was possible to describe a particular physical civic location with a single PIDF-LO. Within that LO there may be jurisdictional and postal fields. These are already defined in the PIDF-LO docs. The street address (and possibly the jurisdictional community name) may have several (not just 2) "correct" ways to express it, but it should be possible to translate from one to another, so only one needs to be kept in the LIS. =20 What appeared to be touched on, but never really discussed, was whether there needed to be the ability to say "I would like to have the mailing address for where I am." As Guy and Jerome mentioned, the location of the mailbox does not necessarily coincide with the physical location of the device making the request. =20 So, I don't see value in separate jurisdictional and postal requests to describe a single physical location, because both should be expressible within a single PIDF-LO. There MAY be value in being able to request the mailing address for a physical location. Barbara=20 ________________________________ From: Marc Berryman [mailto:MBerryman@911.org]=20 Sent: Thursday, September 13, 2007 12:08 PM To: Mary Barnes; geopriv@ietf.org Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Mary, I do not think that Jurisdiction and Postal need to be the same, often they are not the same, since postal rarely follows the same "boundaries" as jurisdictional. Since they may, or may not, be the same is the reason they are both included. You can not assume they are the same. =20 Marc B =20 Marc Berryman, ENP Geographic Information Systems Greater Harris County 9-1-1 Emergency Network Houston, Texas (713) 407-2254 mberryman@911.org ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Thursday, September 13, 2007 11:02 AM To: geopriv@ietf.org Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise =20 Hi all,=20 This thread never seemed to conclude with clear consensus as to whether folks see a need for both these specific location types rather than being able to use a common "civic" locationType. I went back through the threads and the majority of the responses indicated that both of the values should be the same (with Canada being the exception?). Since the thread did diverge somewhat (into how conversions etc. are done), I would like to do a quick query to see if folks are okay with removing those two values from the locationType in the HELD draft? =20 And, just to be precise, we're proposing changing locationType from a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, locationURI} to a set of {any, civic, geodetic, locationURI}. =20 Regards,=20 Mary=20 Editor HELD=20 =20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 ------_=_NextPart_001_01C7F62E.9DE9736E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable "Postal" and = "Jurisdicational" civic locations - reprise
The impression I was left with, was that it was = possible to=20 describe a particular physical civic location with a single PIDF-LO. = Within that=20 LO there may be jurisdictional and postal fields. These are already = defined in=20 the PIDF-LO docs. The street address (and possibly the jurisdictional = community=20 name) may have several (not just 2) "correct" ways to express it, but it = should=20 be possible to translate from one to another, so only one needs to be = kept in=20 the LIS.
 
What appeared to be touched on, but never = really discussed,=20 was whether there needed to be the ability to say "I would like to have = the=20 mailing address for where I am." As Guy and Jerome mentioned, the = location=20 of the mailbox does not necessarily coincide with the physical location = of the=20 device making the request.
 
So, I don't see value in separate = jurisdictional and postal=20 requests to describe a single physical location, because both should be=20 expressible within a single PIDF-LO. There MAY be value in being able to = request=20 the mailing address for a physical location.
Barbara 

From: Marc Berryman = [mailto:MBerryman@911.org]=20
Sent: Thursday, September 13, 2007 12:08 PM
To: = Mary=20 Barnes; geopriv@ietf.org
Subject: RE: [Geopriv] "Postal" and=20 "Jurisdicational" civic locations - reprise

Mary,

 I do = not think=20 that Jurisdiction and Postal need to be the same, often they are not the = same,=20 since postal rarely follows the same “boundaries” as = jurisdictional. Since they=20 may, or may not, be the same is the reason they are both included. You = can not=20 assume they are the same.

 

Marc=20 B

 

Marc Berryman, ENP
Geographic=20 Information Systems
Greater Harris County 9-1-1 Emergency=20 Network
Houston,=20 Texas     =20 (713) 407-2254
mberryman@911.org

From: Mary=20 Barnes [mailto:mary.barnes@nortel.com]
Sent: Thursday, September 13, = 2007 11:02=20 AM
To:=20 geopriv@ietf.org
Subject:=20 [Geopriv] "Postal" and "Jurisdicational" civic locations -=20 reprise

 

Hi=20 all,

This thread never seemed = to conclude=20 with clear consensus as to whether folks see a need for both these = specific=20 location types rather than being able to use a common "civic"=20 locationType.     I went back through the threads = and the=20 majority of the responses indicated that both of the values should be = the same=20 (with Canada being the=20 exception?).   Since the thread did diverge somewhat (into how = conversions etc. are done), I would like to do a quick query to see if = folks are=20 okay with removing those two values from the locationType in the HELD=20 draft?  

And, just to be precise, = we're=20 proposing changing locationType from a set of {any, civic, geodetic,=20 postalCivic, jurisdictionalCivic, locationURI} to a set=20 of

{any, civic, geodetic,=20 locationURI}. 

Regards, =
Mary =
Editor HELD=20

 

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA621

 ------_=_NextPart_001_01C7F62E.9DE9736E-- --===============0651660661== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0651660661==-- From geopriv-bounces@ietf.org Thu Sep 13 14:06:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVt5d-0001vS-II; Thu, 13 Sep 2007 14:06:57 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVt5c-0001s7-HJ for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 14:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVt5c-0001rw-7U for geopriv@ietf.org; Thu, 13 Sep 2007 14:06:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVt5b-0002zm-27 for geopriv@ietf.org; Thu, 13 Sep 2007 14:06:56 -0400 X-IronPort-AV: E=Sophos;i="4.20,250,1186372800"; d="scan'208,217";a="70978430" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Sep 2007 14:06:55 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DI6s6c029203; Thu, 13 Sep 2007 14:06:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DI6nE4000370; Thu, 13 Sep 2007 18:06:54 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 14:06:38 -0400 Received: from mlinsnerwxp ([10.82.170.69]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 14:06:37 -0400 From: "Marc Linsner" To: "'Mary Barnes'" , Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 14:06:35 -0400 Message-ID: <00b601c7f630$d368eac0$220d0d0a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAEUisA In-Reply-To: X-OriginalArrivalTime: 13 Sep 2007 18:06:38.0418 (UTC) FILETIME=[D44F5320:01C7F630] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1551; t=1189706814; x=1190570814; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20=22Postal=22=20and=20=22Jurisdicational=2 2=20civic=20locations=20-=20reprise |Sender:=20 |To:=20=22'Mary=20Barnes'=22=20, =20; bh=sFsmCfREb6ErIw8s256cYPmI145vytgO4t1WTvKuYWc=; b=hF3vBdpoKPAvTfOOVNpZy9VZ4rXmVED7QEfleR6cHXW4JTG0z7haJdU4mkgQtEL57qAH3qhD 7W517Ee+36tlw3otG+MZbBiSkogIm+ACke9h2kZS9dXDePWZde04kJZn; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1224485612==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1224485612== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01C7F60F.4C574AC0" This is a multi-part message in MIME format. ------=_NextPart_000_00B7_01C7F60F.4C574AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary, {any, civic, geodetic, locationURI}. I agree with this proposal. -Marc- ------=_NextPart_000_00B7_01C7F60F.4C574AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Postal" and "Jurisdicational" civic locations - = reprise
Mary,
 

{any, civic, geodetic,=20 locationURI}.  
 

I agree with this proposal.

-Marc- 

------=_NextPart_000_00B7_01C7F60F.4C574AC0-- --===============1224485612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1224485612==-- From geopriv-bounces@ietf.org Thu Sep 13 14:20:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVtIH-0006I6-3D; Thu, 13 Sep 2007 14:20:01 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVtIE-00068k-Qf for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 14:19:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVtIE-00067o-Cw for geopriv@ietf.org; Thu, 13 Sep 2007 14:19:58 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVtID-00068Y-Mc for geopriv@ietf.org; Thu, 13 Sep 2007 14:19:58 -0400 Received: from ([139.76.131.31]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.184522814; Thu, 13 Sep 2007 14:19:32 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 14:19:32 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 14:19:32 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 14:19:31 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05A7F17D@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise thread-index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAEpgYQ References: From: "Stark, Barbara" To: "Mary Barnes" , X-OriginalArrivalTime: 13 Sep 2007 18:19:32.0225 (UTC) FILETIME=[A188E710:01C7F632] X-Spam-Score: 0.2 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1179923728==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1179923728== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F632.A16A7FD6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F632.A16A7FD6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I'm uncomfortable with mixing locationURI with the other 3. A device should be able to request a locationURI that points to a civic, geodetic, or any. With locationURI mixed in, this suggests that locationURI is always "any", or that whoever requests dereferencing of the URI can request the type. Barbara ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Thursday, September 13, 2007 12:02 PM To: geopriv@ietf.org Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Hi all,=20 This thread never seemed to conclude with clear consensus as to whether folks see a need for both these specific location types rather than being able to use a common "civic" locationType. I went back through the threads and the majority of the responses indicated that both of the values should be the same (with Canada being the exception?). Since the thread did diverge somewhat (into how conversions etc. are done), I would like to do a quick query to see if folks are okay with removing those two values from the locationType in the HELD draft? =20 And, just to be precise, we're proposing changing locationType from a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, locationURI} to a set of {any, civic, geodetic, locationURI}. =20 Regards,=20 Mary=20 Editor HELD=20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 ------_=_NextPart_001_01C7F632.A16A7FD6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable "Postal" and "Jurisdicational" civic locations - = reprise
I'm uncomfortable with mixing locationURI = with the=20 other 3. A device should be able to request a locationURI that points to = a=20 civic, geodetic, or any. With locationURI mixed in, this suggests that=20 locationURI is always "any", or that whoever requests dereferencing of = the URI=20 can request the type.
Barbara

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: Thursday, September 13, = 2007=20 12:02 PM
To: geopriv@ietf.org
Subject: [Geopriv] = "Postal"=20 and "Jurisdicational" civic locations - reprise

Hi all,

This thread never seemed to conclude with = clear=20 consensus as to whether folks see a need for both these specific = location types=20 rather than being able to use a common "civic"=20 locationType.     I went back through the threads = and the=20 majority of the responses indicated that both of the values should be = the same=20 (with Canada being the exception?).   Since the thread did = diverge=20 somewhat (into how conversions etc. are done), I would like to do a = quick query=20 to see if folks are okay with removing those two values from the = locationType in=20 the HELD draft?  

And, just to be precise, we're proposing = changing=20 locationType from a set of {any, civic, geodetic, postalCivic,=20 jurisdictionalCivic, locationURI} to a set of

{any, civic, geodetic, = locationURI}. =20

Regards,
Mary
Editor HELD=20


*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA625

 ------_=_NextPart_001_01C7F632.A16A7FD6-- --===============1179923728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1179923728==-- From geopriv-bounces@ietf.org Thu Sep 13 14:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVtey-0002tn-Im; Thu, 13 Sep 2007 14:43:28 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVtex-0002tg-1n for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 14:43:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVtev-0002tY-Ms for geopriv@ietf.org; Thu, 13 Sep 2007 14:43:26 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVteu-00006z-OP for geopriv@ietf.org; Thu, 13 Sep 2007 14:43:25 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DIhJk06529; Thu, 13 Sep 2007 18:43:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: locationURI as a separate flag (was RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 13:41:07 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7F17D@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: locationURI as a separate flag (was RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAEpgYQAABkxtA= References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F17D@crexc41p> From: "Mary Barnes" To: "Stark, Barbara" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1259523161==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1259523161== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F635.EDF8EF2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F635.EDF8EF2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barbara, =20 We did discuss this suggestion in the past. One reason why it was decided to keep it as is (and the reason put forth for the discussion in Chicago) was that this seems to complicate things and introduce additional complexity in terms of handling a locationURI boolean along with an "any" for the locationType (e.g., if the boolean is false, but "any" is requested and there are only locationURIs available at that specific LIS, what is the expected behavior?). And, as you mention, the current approach is also consistent with the dereferencing being handled separate from the request for location.=20 =20 As is, "any" will return all forms of location types, including all forms of locationURIs that are available, per the description of locationURI in section 7.5. I guess you're asking for a way of getting only a specific scheme of locationURI? And, in this case, I'm assuming you'd be using the "exact" attribute? =20 =20 Mary.=20 =20 ________________________________ From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Thursday, September 13, 2007 1:20 PM To: Barnes, Mary (RICH2:AR00); geopriv@ietf.org Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise I'm uncomfortable with mixing locationURI with the other 3. A device should be able to request a locationURI that points to a civic, geodetic, or any. With locationURI mixed in, this suggests that locationURI is always "any", or that whoever requests dereferencing of the URI can request the type. Barbara ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Thursday, September 13, 2007 12:02 PM To: geopriv@ietf.org Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Hi all,=20 This thread never seemed to conclude with clear consensus as to whether folks see a need for both these specific location types rather than being able to use a common "civic" locationType. I went back through the threads and the majority of the responses indicated that both of the values should be the same (with Canada being the exception?). Since the thread did diverge somewhat (into how conversions etc. are done), I would like to do a quick query to see if folks are okay with removing those two values from the locationType in the HELD draft? =20 And, just to be precise, we're proposing changing locationType from a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, locationURI} to a set of {any, civic, geodetic, locationURI}. =20 Regards,=20 Mary=20 Editor HELD=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625 ------_=_NextPart_001_01C7F635.EDF8EF2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Postal" and "Jurisdicational" civic locations - = reprise
Hi Barbara,
 
We did discuss this suggestion in the = past.  One=20 reason why it was decided to keep it as is (and the reason put forth for = the=20 discussion in Chicago) was that this seems to complicate things and = introduce=20 additional complexity in terms of handling a locationURI boolean = along with=20 an "any" for the locationType (e.g., if the boolean is false, but "any" = is=20 requested and there are only locationURIs available at that specific = LIS, what=20 is the expected behavior?).  And, as you mention, the current = approach is=20 also consistent with the dereferencing being handled separate from the = request=20 for location.
 
As is, "any" will return all forms of = location types,=20 including all forms of locationURIs that are available, per the = description of=20 locationURI in section 7.5.  I guess you're asking for a way of = getting=20 only a specific scheme of locationURI?  And, in this case, I'm = assuming=20 you'd be using the "exact" attribute? 
 
Mary.
 
From: Stark, Barbara = [mailto:bs7652@att.com]=20
Sent: Thursday, September 13, 2007 1:20 PM
To: = Barnes, Mary=20 (RICH2:AR00); geopriv@ietf.org
Subject: RE: [Geopriv] "Postal" = and=20 "Jurisdicational" civic locations - reprise

I'm uncomfortable with mixing locationURI = with the=20 other 3. A device should be able to request a locationURI that points to = a=20 civic, geodetic, or any. With locationURI mixed in, this suggests that=20 locationURI is always "any", or that whoever requests dereferencing of = the URI=20 can request the type.
Barbara

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: Thursday, September 13, = 2007=20 12:02 PM
To: geopriv@ietf.org
Subject: [Geopriv] = "Postal"=20 and "Jurisdicational" civic locations - reprise

Hi all,

This thread never seemed to conclude with = clear=20 consensus as to whether folks see a need for both these specific = location types=20 rather than being able to use a common "civic"=20 locationType.     I went back through the threads = and the=20 majority of the responses indicated that both of the values should be = the same=20 (with Canada being the exception?).   Since the thread did = diverge=20 somewhat (into how conversions etc. are done), I would like to do a = quick query=20 to see if folks are okay with removing those two values from the = locationType in=20 the HELD draft?  

And, just to be precise, we're proposing = changing=20 locationType from a set of {any, civic, geodetic, postalCivic,=20 jurisdictionalCivic, locationURI} to a set of

{any, civic, geodetic, = locationURI}. =20

Regards,
Mary
Editor HELD =


*****

The information = transmitted is=20 intended only for the person or entity to which it is addressed and may = contain=20 confidential, proprietary, and/or privileged material. Any review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers.=20 GA625

 ------_=_NextPart_001_01C7F635.EDF8EF2C-- --===============1259523161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1259523161==-- From geopriv-bounces@ietf.org Thu Sep 13 14:53:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVtod-0004o1-7w; Thu, 13 Sep 2007 14:53:27 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVtob-0004n1-J7 for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 14:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVtob-0004mg-8q for geopriv@ietf.org; Thu, 13 Sep 2007 14:53:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVtoZ-00044V-Ue for geopriv@ietf.org; Thu, 13 Sep 2007 14:53:25 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IVtog-0005K5-BO; Thu, 13 Sep 2007 13:53:30 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Mary Barnes'" , References: <00b601c7f630$d368eac0$220d0d0a@amer.cisco.com> Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 14:53:17 -0400 Message-ID: <090001c7f637$5b6972e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAEUisAAAGqMdA= In-Reply-To: <00b601c7f630$d368eac0$220d0d0a@amer.cisco.com> 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 2.2 (++) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1265115718==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1265115718== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0901_01C7F615.D457D2E0" This is a multi-part message in MIME format. ------=_NextPart_000_0901_01C7F615.D457D2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, this is how I see it _____ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Thursday, September 13, 2007 2:07 PM To: 'Mary Barnes'; geopriv@ietf.org Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Mary, {any, civic, geodetic, locationURI}. I agree with this proposal. -Marc- ------=_NextPart_000_0901_01C7F615.D457D2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Postal" and "Jurisdicational" civic = locations - reprise

Yes, this is how I see = it

 

From: = Marc Linsner [mailto:mlinsner@cisco.com] =
Sent: Thursday, September = 13, 2007 2:07 PM
To: 'Mary Barnes'; geopriv@ietf.org
Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - = reprise

 

Mary,

 

{any, civic, geodetic, locationURI}.  
 

I agree with this = proposal.

-Marc- 

------=_NextPart_000_0901_01C7F615.D457D2E0-- --===============1265115718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1265115718==-- From geopriv-bounces@ietf.org Thu Sep 13 15:08:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVu2z-0000Mq-6B; Thu, 13 Sep 2007 15:08:17 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVu2y-0000Ml-EA for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 15:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVu2y-0000Md-4Q for geopriv@ietf.org; Thu, 13 Sep 2007 15:08:16 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVu2w-0004IT-Mz for geopriv@ietf.org; Thu, 13 Sep 2007 15:08:16 -0400 Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.184530055; Thu, 13 Sep 2007 15:07:55 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 15:07:55 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 15:07:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: locationURI as a separate flag (was RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 15:07:50 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05A7F19B@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: locationURI as a separate flag (was RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAEpgYQAABkxtAAAWwSQA== References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F17D@crexc41p> From: "Stark, Barbara" To: "Mary Barnes" , X-OriginalArrivalTime: 13 Sep 2007 19:07:54.0960 (UTC) FILETIME=[63B31D00:01C7F639] X-Spam-Score: 0.2 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1632269527==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1632269527== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F639.637B4A0E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F639.637B4A0E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable OK. I don't think it's important. Barbara ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Thursday, September 13, 2007 2:41 PM To: Stark, Barbara; geopriv@ietf.org Subject: locationURI as a separate flag (was RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Hi Barbara, =20 We did discuss this suggestion in the past. One reason why it was decided to keep it as is (and the reason put forth for the discussion in Chicago) was that this seems to complicate things and introduce additional complexity in terms of handling a locationURI boolean along with an "any" for the locationType (e.g., if the boolean is false, but "any" is requested and there are only locationURIs available at that specific LIS, what is the expected behavior?). And, as you mention, the current approach is also consistent with the dereferencing being handled separate from the request for location.=20 =20 As is, "any" will return all forms of location types, including all forms of locationURIs that are available, per the description of locationURI in section 7.5. I guess you're asking for a way of getting only a specific scheme of locationURI? And, in this case, I'm assuming you'd be using the "exact" attribute? =20 =20 Mary.=20 =20 ________________________________ From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Thursday, September 13, 2007 1:20 PM To: Barnes, Mary (RICH2:AR00); geopriv@ietf.org Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise I'm uncomfortable with mixing locationURI with the other 3. A device should be able to request a locationURI that points to a civic, geodetic, or any. With locationURI mixed in, this suggests that locationURI is always "any", or that whoever requests dereferencing of the URI can request the type. Barbara ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Thursday, September 13, 2007 12:02 PM To: geopriv@ietf.org Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Hi all,=20 This thread never seemed to conclude with clear consensus as to whether folks see a need for both these specific location types rather than being able to use a common "civic" locationType. I went back through the threads and the majority of the responses indicated that both of the values should be the same (with Canada being the exception?). Since the thread did diverge somewhat (into how conversions etc. are done), I would like to do a quick query to see if folks are okay with removing those two values from the locationType in the HELD draft? =20 And, just to be precise, we're proposing changing locationType from a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, locationURI} to a set of {any, civic, geodetic, locationURI}. =20 Regards,=20 Mary=20 Editor HELD=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625 ------_=_NextPart_001_01C7F639.637B4A0E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable "Postal" and "Jurisdicational" civic locations - = reprise
OK. I don't think it's = important.
Barbara

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: Thursday, September 13, = 2007=20 2:41 PM
To: Stark, Barbara; = geopriv@ietf.org
Subject:=20 locationURI as a separate flag (was RE: [Geopriv] "Postal" and = "Jurisdicational"=20 civic locations - reprise

Hi Barbara,
 
We did discuss this suggestion in the = past.  One=20 reason why it was decided to keep it as is (and the reason put forth for = the=20 discussion in Chicago) was that this seems to complicate things and = introduce=20 additional complexity in terms of handling a locationURI boolean = along with=20 an "any" for the locationType (e.g., if the boolean is false, but "any" = is=20 requested and there are only locationURIs available at that specific = LIS, what=20 is the expected behavior?).  And, as you mention, the current = approach is=20 also consistent with the dereferencing being handled separate from the = request=20 for location.
 
As is, "any" will return all forms of = location types,=20 including all forms of locationURIs that are available, per the = description of=20 locationURI in section 7.5.  I guess you're asking for a way of = getting=20 only a specific scheme of locationURI?  And, in this case, I'm = assuming=20 you'd be using the "exact" attribute? 
 
Mary.
 
From: Stark, Barbara = [mailto:bs7652@att.com]=20
Sent: Thursday, September 13, 2007 1:20 PM
To: = Barnes, Mary=20 (RICH2:AR00); geopriv@ietf.org
Subject: RE: [Geopriv] "Postal" = and=20 "Jurisdicational" civic locations - reprise

I'm uncomfortable with mixing locationURI = with the=20 other 3. A device should be able to request a locationURI that points to = a=20 civic, geodetic, or any. With locationURI mixed in, this suggests that=20 locationURI is always "any", or that whoever requests dereferencing of = the URI=20 can request the type.
Barbara

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: Thursday, September 13, = 2007=20 12:02 PM
To: geopriv@ietf.org
Subject: [Geopriv] = "Postal"=20 and "Jurisdicational" civic locations - reprise

Hi all,

This thread never seemed to conclude with = clear=20 consensus as to whether folks see a need for both these specific = location types=20 rather than being able to use a common "civic"=20 locationType.     I went back through the threads = and the=20 majority of the responses indicated that both of the values should be = the same=20 (with Canada being the exception?).   Since the thread did = diverge=20 somewhat (into how conversions etc. are done), I would like to do a = quick query=20 to see if folks are okay with removing those two values from the = locationType in=20 the HELD draft?  

And, just to be precise, we're proposing = changing=20 locationType from a set of {any, civic, geodetic, postalCivic,=20 jurisdictionalCivic, locationURI} to a set of

{any, civic, geodetic, = locationURI}. =20

Regards,
Mary
Editor HELD =


*****

The information = transmitted is=20 intended only for the person or entity to which it is addressed and may = contain=20 confidential, proprietary, and/or privileged material. Any review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers.=20 GA625

 ------_=_NextPart_001_01C7F639.637B4A0E-- --===============1632269527== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1632269527==-- From geopriv-bounces@ietf.org Thu Sep 13 16:31:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvLl-00017q-Tk; Thu, 13 Sep 2007 16:31:45 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVvLk-00010V-9A for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 16:31:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvLj-000104-SJ for geopriv@ietf.org; Thu, 13 Sep 2007 16:31:43 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVvLj-00039D-Cb for geopriv@ietf.org; Thu, 13 Sep 2007 16:31:43 -0400 X-SEF-Processed: 5_0_0_910__2007_09_13_15_41_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 13 Sep 2007 15:41:07 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Sep 2007 15:31:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 15:31:39 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7F17D@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAEpgYQAARicCA= References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F17D@crexc41p> From: "Winterbottom, James" To: "Stark, Barbara" , "Mary Barnes" , X-OriginalArrivalTime: 13 Sep 2007 20:31:42.0780 (UTC) FILETIME=[18838FC0:01C7F645] X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1395644820==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1395644820== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F645.185449F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F645.185449F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barbara,=0D=0A=0D=0A=20=0D=0A=0D=0AI believe that the location URI fits = very nicely with the other 3.=0D=0A=0D=0APresently the location URI points = to something on the LIS that either=0D=0Ahas the location(s) or can get the= location(s) of the device. The HELD=0D=0Adereference draft basically said = that the requesting device can ask for=0D=0Aonly a specific of location, bu= t with the demise of the context, so to=0D=0Awent the type of control you a= re asking for below. This is why I wrote a=0D=0Aseparate context draft, so = a Target can specifically control the=0D=0Apolicies associated with a locat= ion URI. I am now of the opinion that=0D=0Athis should be an extension rath= er than something that we introduce into=0D=0Athe base specification.=0D=0A=0D= =0A=20=0D=0A=0D=0AI also don't believe that the URI is always returned with= "any", it says=0D=0Athat it may be however, or and LIS may return any othe= r type. It is any,=0D=0Anot all.=0D=0A=0D=0A=20=0D=0A=0D=0AThe dereference = draft has explicit text around the dereferencer=0D=0Arequesting a location = URI type:=0D=0A=0D=0A=20=0D=0A=0D=0A'The LCS MUST respond with a 400 "Reque= st Error" if it receives a=0D=0Arequest for a locationURI where HELD is bei= ng used as a dereference=0D=0Aprotocol.'=0D=0A=0D=0A=20=0D=0A=0D=0AObviousl= y the error number is changing, but the condition was=0D=0Aconsidered.=0D=0A=0D= =0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: Stark, Barbara [mailto= :bs7652@att.com]=20=0D=0ASent: Friday, 14 September 2007 4:20 AM=0D=0ATo: M= ary Barnes; geopriv@ietf.org=0D=0ASubject: RE: [Geopriv] "Postal" and "Juri= sdicational" civic locations -=0D=0Areprise=0D=0A=0D=0A=20=0D=0A=0D=0AI'm u= ncomfortable with mixing locationURI with the other 3. A device=0D=0Ashould= be able to request a locationURI that points to a civic,=0D=0Ageodetic, or= any. With locationURI mixed in, this suggests that=0D=0AlocationURI is alw= ays "any", or that whoever requests dereferencing of=0D=0Athe URI can reque= st the type.=0D=0A=0D=0ABarbara=0D=0A=0D=0A=20=0D=0A=0D=0A_________________= _______________=0D=0A=0D=0AFrom: Mary Barnes [mailto:mary.barnes@nortel.com= ]=20=0D=0ASent: Thursday, September 13, 2007 12:02 PM=0D=0ATo: geopriv@ietf= =2Eorg=0D=0ASubject: [Geopriv] "Postal" and "Jurisdicational" civic locatio= ns -=0D=0Areprise=0D=0A=0D=0AHi all,=20=0D=0A=0D=0AThis thread never seemed= to conclude with clear consensus as to whether=0D=0Afolks see a need for b= oth these specific location types rather than=0D=0Abeing able to use a comm= on "civic" locationType. I went back through=0D=0Athe threads and the m= ajority of the responses indicated that both of the=0D=0Avalues should be t= he same (with Canada being the exception=3F). Since=0D=0Athe thread did d= iverge somewhat (into how conversions etc. are done), I=0D=0Awould like to = do a quick query to see if folks are okay with removing=0D=0Athose two valu= es from the locationType in the HELD draft=3F =20=0D=0A=0D=0AAnd, just to = be precise, we're proposing changing locationType from a=0D=0Aset of {any, = civic, geodetic, postalCivic, jurisdictionalCivic,=0D=0AlocationURI} to a s= et of=0D=0A=0D=0A{any, civic, geodetic, locationURI}. =20=0D=0A=0D=0ARegard= s,=20=0D=0AMary=20=0D=0AEditor HELD=20=0D=0A=0D=0A=20=0D=0A=0D=0A*****=0D=0A=0D= =0AThe information transmitted is intended only for the person or entity to=0D= =0Awhich it is addressed and may contain confidential, proprietary, and/or=0D= =0Aprivileged material. Any review, retransmission, dissemination or other=0D= =0Ause of, or taking of any action in reliance upon this information by=0D=0A= persons or entities other than the intended recipient is prohibited. If=0D=0A= you received this in error, please contact the sender and delete the=0D=0Am= aterial from all computers. GA625=0D=0A=0D=0A------------------------------= ------------------------------------------------------------------=0D=0AThi= s message is for the designated recipient only and may=0D=0Acontain privile= ged, proprietary, or otherwise private information. =20=0D=0AIf you have re= ceived it in error, please notify the sender=0D=0Aimmediately and delete th= e original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--= ---------------------------------------------------------------------------= -------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C7F645.185449F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A"Posta= l" and "Jurisdicational" civic locations -=0D=0Areprise</tit= le>=0D=0A<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:s= marttags"=0D=0A name=3D"country-region"/>=0D=0A<o:SmartTagType namespaceuri= =3D"urn:schemas-microsoft-com:office:smarttags"=0D=0A name=3D"place"/>=0D=0A= <!--[if !mso]>=0D=0A<style>=0D=0Ast1\:*{behavior:url(#default#ieooui) }=0D=0A= </style>=0D=0A<![endif]-->=0D=0A<style>=0D=0A<!--=0D=0A /* Font Definitions= */=0D=0A @font-face=0D=0A=09{font-family:Tahoma;=0D=0A=09panose-1:2 11 6 4= 3 5 4 4 2 4;}=0D=0A /* Style Definitions */=0D=0A p.MsoNormal, li.MsoNorma= l, div.MsoNormal=0D=0A=09{margin:0cm;=0D=0A=09margin-bottom:.0001pt;=0D=0A=09= font-size:12.0pt;=0D=0A=09font-family:"Times New Roman";}=0D=0Aa:link, span= =2EMsoHyperlink=0D=0A=09{color:blue;=0D=0A=09text-decoration:underline;}=0D= =0Aa:visited, span.MsoHyperlinkFollowed=0D=0A=09{color:purple;=0D=0A=09text= -decoration:underline;}=0D=0Ap=0D=0A=09{mso-margin-top-alt:auto;=0D=0A=09ma= rgin-right:0cm;=0D=0A=09mso-margin-bottom-alt:auto;=0D=0A=09margin-left:0cm= ;=0D=0A=09font-size:12.0pt;=0D=0A=09font-family:"Times New Roman";}=0D=0Apr= e=0D=0A=09{margin:0cm;=0D=0A=09margin-bottom:.0001pt;=0D=0A=09font-size:10.= 0pt;=0D=0A=09font-family:"Courier New";}=0D=0Aspan.EmailStyle18=0D=0A=09{ms= o-style-type:personal-reply;=0D=0A=09font-family:Arial;=0D=0A=09color:navy;= }=0D=0A@page Section1=0D=0A=09{size:595.3pt 841.9pt;=0D=0A=09margin:72.0pt = 90.0pt 72.0pt 90.0pt;}=0D=0Adiv.Section1=0D=0A=09{page:Section1;}=0D=0A-->=0D= =0A</style>=0D=0A=0D=0A</head>=0D=0A=0D=0A<body lang=3DEN-AU link=3Dblue vl= ink=3Dpurple>=0D=0A=0D=0A<div class=3DSection1>=0D=0A=0D=0A<p class=3DMsoNo= rmal><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A= 10.0pt;font-family:Arial;color:navy'>Hi Barbara,<o:p></o:p></span></font></= p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial= ><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:navy'><o:p>&= nbsp;</o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D= 2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-fami= ly:Arial;color:navy'>I believe that the location URI fits very=0D=0Anicely = with the other 3.<o:p></o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNor= mal><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A= 10.0pt;font-family:Arial;color:navy'>Presently the location URI points to=0D= =0Asomething on the LIS that either has the location(s) or can get the loca= tion(s)=0D=0Aof the device. The HELD dereference draft basically said that = the requesting device=0D=0Acan ask for only a specific of location, but wit= h the demise of the context, so=0D=0Ato went the type of control you are as= king for below. This is why I wrote a=0D=0Aseparate context draft, so a Tar= get can specifically control the policies=0D=0Aassociated with a location U= RI. I am now of the opinion that this should be an=0D=0Aextension rather th= an something that we introduce into the base specification.<o:p></o:p></spa= n></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy f= ace=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:n= avy'><o:p> </o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><f= ont size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A10.0p= t;font-family:Arial;color:navy'>I also don’t believe that the URI is=0D= =0Aalways returned with “any”, it says that it may be however, = or and=0D=0ALIS may return any other type. It is any, not all.<o:p></o:p></= span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dnav= y face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;colo= r:navy'><o:p> </o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal= ><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A10= =2E0pt;font-family:Arial;color:navy'>The dereference draft has explicit tex= t=0D=0Aaround the dereferencer requesting a location URI type:<o:p></o:p></= span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dnav= y face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;colo= r:navy'><o:p> </o:p></span></font></p>=0D=0A=0D=0A<pre><font size=3D2 = color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;=0D=0Afont-family= :Arial;color:navy'>‘</span></font>The LCS MUST respond with a 400 &qu= ot;Request Error" if it receives a request for a locationURI where HEL= D is being used as a dereference protocol.’<o:p></o:p></pre>=0D=0A=0D= =0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span styl= e=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:navy'><o:p> </o:p>= </span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dn= avy face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;co= lor:navy'>Obviously the error number is changing,=0D=0Abut the condition wa= s considered.<o:p></o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal>= <font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A10.= 0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>=0D=0A=0D= =0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span styl= e=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:navy'>Cheers<o:p></o:p>= </span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dn= avy face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;co= lor:navy'>James<o:p></o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNorma= l><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A1= 0.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>=0D=0A=0D= =0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span styl= e=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:navy'><o:p> </o:p>= </span></font></p>=0D=0A=0D=0A<div style=3D'border:none;border-left:solid b= lue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>=0D=0A=0D=0A<div>=0D=0A=0D=0A<div clas= s=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font size=3D3=0D=0A= face=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>=0D=0A=0D= =0A<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>=0D=0A=0D=0A</s= pan></font></div>=0D=0A=0D=0A<p class=3DMsoNormal><b><font size=3D2 face=3D= Tahoma><span lang=3DEN-US=0D=0Astyle=3D'font-size:10.0pt;font-family:Tahoma= ;font-weight:bold'>From:</span></font></b><font=0D=0Asize=3D2 face=3DTahoma= ><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma'>=0D=0ASta= rk, Barbara [mailto:bs7652@att.com] <br>=0D=0A<b><span style=3D'font-weight= :bold'>Sent:</span></b> Friday, 14 September 2007=0D=0A4:20 AM<br>=0D=0A<b>= <span style=3D'font-weight:bold'>To:</span></b> Mary Barnes; geopriv@ietf.o= rg<br>=0D=0A<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [Ge= opriv]=0D=0A"Postal" and "Jurisdicational" civic locati= ons - reprise</span></font><span=0D=0Alang=3DEN-US><o:p></o:p></span></p>=0D= =0A=0D=0A</div>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D3 face=3D"Time= s New Roman"><span style=3D'font-size:=0D=0A12.0pt'><o:p> </o:p></span= ></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dblue fa= ce=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:bl= ue'>I'm uncomfortable with mixing=0D=0AlocationURI with the other 3. A= device should be able to request a locationURI=0D=0Athat points to a civic= , geodetic, or any. With locationURI mixed in, this=0D=0Asuggests that loca= tionURI is always "any", or that whoever requests=0D=0Adereferenc= ing of the URI can request the type.</span></font><o:p></o:p></p>=0D=0A=0D=0A= <p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=3D= 'font-size:=0D=0A10.0pt;font-family:Arial;color:blue'>Barbara</span></font>= <o:p></o:p></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D3 face=3D"Time= s New Roman"><span style=3D'font-size:=0D=0A12.0pt'><o:p> </o:p></span= ></font></p>=0D=0A=0D=0A<div class=3DMsoNormal align=3Dcenter style=3D'text= -align:center'><font size=3D3=0D=0Aface=3D"Times New Roman"><span lang=3DEN= -US style=3D'font-size:12.0pt'>=0D=0A=0D=0A<hr size=3D2 width=3D"100%" alig= n=3Dcenter tabIndex=3D-1>=0D=0A=0D=0A</span></font></div>=0D=0A=0D=0A<p cla= ss=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=3DTaho= ma><span=0D=0Alang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma;fon= t-weight:bold'>From:</span></font></b><font=0D=0Asize=3D2 face=3DTahoma><sp= an lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma'>=0D=0AMary Ba= rnes [mailto:mary.barnes@nortel.com] <br>=0D=0A<b><span style=3D'font-weigh= t:bold'>Sent:</span></b> Thursday, September 13, 2007=0D=0A12:02 PM<br>=0D=0A= <b><span style=3D'font-weight:bold'>To:</span></b> geopriv@ietf.org<br>=0D=0A= <b><span style=3D'font-weight:bold'>Subject:</span></b> [Geopriv]=0D=0A&quo= t;Postal" and "Jurisdicational" civic locations - reprise</s= pan></font><span=0D=0Alang=3DEN-US><o:p></o:p></span></p>=0D=0A=0D=0A<p><fo= nt size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'= ><!-- Converted from text/rtf format -->Hi=0D=0Aall,</span></font> <o:p></o= :p></p>=0D=0A=0D=0A<p><font size=3D2 face=3DArial><span style=3D'font-size:= 10.0pt;font-family:Arial'>This=0D=0Athread never seemed to conclude with cl= ear consensus as to whether folks see a=0D=0Aneed for both these specific l= ocation types rather than being able to use a=0D=0Acommon "civic"= locationType.     I went back=0D=0Athrough the threads= and the majority of the responses indicated that both of=0D=0Athe values s= hould be the same (with <st1:country-region w:st=3D"on"><st1:place=0D=0A w:= st=3D"on">Canada</st1:place></st1:country-region> being the=0D=0Aexception=3F= ).   Since the thread did diverge somewhat (into how=0D=0Aconvers= ions etc. are done), I would like to do a quick query to see if folks=0D=0A= are okay with removing those two values from the locationType in the HELD=0D= =0Adraft=3F   </span></font><o:p></o:p></p>=0D=0A=0D=0A<p><font s= ize=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>And= ,=0D=0Ajust to be precise, we're proposing changing locationType from a set= of {any,=0D=0Acivic, geodetic, postalCivic, jurisdictionalCivic, locationU= RI} to a set of</span></font><o:p></o:p></p>=0D=0A=0D=0A<p><font size=3D2 f= ace=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>{any,=0D=0Ac= ivic, geodetic, locationURI}.  </span></font><o:p></o:p></p>=0D=0A=0D=0A= <p><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:= Arial'>Regards,</span></font>=0D=0A<br>=0D=0A<font size=3D2 face=3DArial><s= pan style=3D'font-size:10.0pt;font-family:Arial'>Mary</span></font>=0D=0A<b= r>=0D=0A<font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-fa= mily:Arial'>Editor=0D=0AHELD </span></font><o:p></o:p></p>=0D=0A=0D=0A<p cl= ass=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D'font= -size:=0D=0A12.0pt'><o:p> </o:p></span></font></p>=0D=0A=0D=0A</div>=0D= =0A=0D=0A</div>=0D=0A=0D=0A<br><br><table bgcolor=3Dwhite style=3D"color:bl= ack"><tr><td><br>----------------------------------------------------------= --------------------------------------<br>=0D=0AThis message is&n= bsp;for the designated recipient only and may= <br>=0D=0Acontain privileged, proprietary, or otherwise=  private information.  <br>=0D=0AIf you have&= nbsp;received it in error, please notify the&= nbsp;sender<br>=0D=0Aimmediately and delete the origina= l.  Any unauthorized use of<br>=0D=0Athis ema= il is prohibited.<br>=0D=0A--------------------------------------= ----------------------------------------------------------<br>=0D=0A[mf2]</= td></tr></table></body>=0D=0A=0D=0A<!--[object_id=3D#att.com#]--><P align=3D= left><FONT face=3DTahoma size=3D2><FONT color=3D#0000ff><FONT face=3DTahoma= color=3D#000000 size=3D2>*****</FONT></P>=0D=0A<P><FONT face=3DTahoma colo= r=3D#000000 size=3D2>The information transmitted is intended only for the p= erson or entity to which it is addressed and may contain confidential, prop= rietary, and/or privileged material. Any review, retransmission, disseminat= ion or other use of, or taking of any action in reliance upon this informat= ion by persons or entities other than the intended recipient is prohibited.= If you received this in error, please contact the sender and delete the ma= terial from all computers. GA625</FONT></P></FONT></FONT>=0D=0A</html>=0D=0A= ------_=_NextPart_001_01C7F645.185449F1-- --===============1395644820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1395644820==-- From geopriv-bounces@ietf.org Thu Sep 13 16:38:39 2007 Return-path: <geopriv-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvSQ-0000om-Kx; Thu, 13 Sep 2007 16:38:38 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVvSP-0000od-N8 for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 16:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvSP-0000oU-DI for geopriv@ietf.org; Thu, 13 Sep 2007 16:38:37 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVvSN-0006jI-JZ for geopriv@ietf.org; Thu, 13 Sep 2007 16:38:37 -0400 X-SEF-Processed: 5_0_0_910__2007_09_13_15_47_58 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 13 Sep 2007 15:47:57 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Sep 2007 15:38:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 15:38:30 -0500 Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF10358115F@AHQEX1.andrew.com> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAAG9ygAAMwFmAABjQlsA== References: <E3F9D87C63E2774390FE67C924EC99BB16E79ACB@zrc2hxm1.corp.nortel.com><B42DAB382ECF4441B2B151522CACAFAA01167328@ghcmail.ghc911.org> <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p> From: "Winterbottom, James" <James.Winterbottom@andrew.com> To: "Stark, Barbara" <bs7652@att.com>, "Marc Berryman" <MBerryman@911.org>, "Mary Barnes" <mary.barnes@nortel.com>, <geopriv@ietf.org> X-OriginalArrivalTime: 13 Sep 2007 20:38:32.0576 (UTC) FILETIME=[0CC57800:01C7F646] X-Spam-Score: -0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy <geopriv.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe> List-Post: <mailto:geopriv@ietf.org> List-Help: <mailto:geopriv-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1494666757==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1494666757== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F646.0CC0D82E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F646.0CC0D82E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barbara,=0D=0A=0D=0A=20=0D=0A=0D=0AI am a little confused by this respon= se.=0D=0A=0D=0A=20=0D=0A=0D=0AExpressing the civic location types in the PI= DF-LO is one issue.=0D=0A=0D=0ABeing able to request just a jurisdictional = civic, or just a postal=0D=0Acivic using HELD is a different issue.=0D=0A=0D= =0A=20=0D=0A=0D=0AI don't think issue one is really resolved, but I also do= n't think that=0D=0Ait has any direct bearing on issues 2.=0D=0A=0D=0A=20=0D= =0A=0D=0AYour last sentence makes me think that you see some benefit in lea= ving=0D=0AjurisdictionalCivic and postalCivic in HELD. Is that right=3F=0D=0A=0D= =0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: Stark, Barbara [mailto= :bs7652@att.com]=20=0D=0ASent: Friday, 14 September 2007 3:51 AM=0D=0ATo: M= arc Berryman; Mary Barnes; geopriv@ietf.org=0D=0ASubject: RE: [Geopriv] "Po= stal" and "Jurisdicational" civic locations -=0D=0Areprise=0D=0A=0D=0A=20=0D= =0A=0D=0AThe impression I was left with, was that it was possible to descri= be a=0D=0Aparticular physical civic location with a single PIDF-LO. Within = that LO=0D=0Athere may be jurisdictional and postal fields. These are alrea= dy defined=0D=0Ain the PIDF-LO docs. The street address (and possibly the j= urisdictional=0D=0Acommunity name) may have several (not just 2) "correct" = ways to express=0D=0Ait, but it should be possible to translate from one to= another, so only=0D=0Aone needs to be kept in the LIS.=0D=0A=0D=0A=20=0D=0A=0D= =0AWhat appeared to be touched on, but never really discussed, was whether=0D= =0Athere needed to be the ability to say "I would like to have the mailing=0D= =0Aaddress for where I am." As Guy and Jerome mentioned, the location of=0D= =0Athe mailbox does not necessarily coincide with the physical location of=0D= =0Athe device making the request.=0D=0A=0D=0A=20=0D=0A=0D=0ASo, I don't see= value in separate jurisdictional and postal requests to=0D=0Adescribe a si= ngle physical location, because both should be expressible=0D=0Awithin a si= ngle PIDF-LO. There MAY be value in being able to request the=0D=0Amailing = address for a physical location.=0D=0A=0D=0ABarbara=20=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: Marc Berryman [mailto:= MBerryman@911.org]=20=0D=0ASent: Thursday, September 13, 2007 12:08 PM=0D=0A= To: Mary Barnes; geopriv@ietf.org=0D=0ASubject: RE: [Geopriv] "Postal" and = "Jurisdicational" civic locations -=0D=0Areprise=0D=0A=0D=0AMary,=0D=0A=0D=0A= I do not think that Jurisdiction and Postal need to be the same, often=0D=0A= they are not the same, since postal rarely follows the same "boundaries"=0D= =0Aas jurisdictional. Since they may, or may not, be the same is the reason=0D= =0Athey are both included. You can not assume they are the same.=0D=0A=0D=0A= =20=0D=0A=0D=0AMarc B=0D=0A=0D=0A=20=0D=0A=0D=0AMarc Berryman, ENP=0D=0AGeo= graphic Information Systems=0D=0AGreater Harris County 9-1-1 Emergency Netw= ork=0D=0AHouston, Texas (713) 407-2254=0D=0Amberryman@911.org=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: Mary Barnes [mailto:ma= ry.barnes@nortel.com]=20=0D=0ASent: Thursday, September 13, 2007 11:02 AM=0D= =0ATo: geopriv@ietf.org=0D=0ASubject: [Geopriv] "Postal" and "Jurisdication= al" civic locations -=0D=0Areprise=0D=0A=0D=0A=20=0D=0A=0D=0AHi all,=20=0D=0A=0D= =0AThis thread never seemed to conclude with clear consensus as to whether=0D= =0Afolks see a need for both these specific location types rather than=0D=0A= being able to use a common "civic" locationType. I went back through=0D= =0Athe threads and the majority of the responses indicated that both of the=0D= =0Avalues should be the same (with Canada being the exception=3F). Since=0D= =0Athe thread did diverge somewhat (into how conversions etc. are done), I=0D= =0Awould like to do a quick query to see if folks are okay with removing=0D= =0Athose two values from the locationType in the HELD draft=3F =20=0D=0A=0D= =0AAnd, just to be precise, we're proposing changing locationType from a=0D= =0Aset of {any, civic, geodetic, postalCivic, jurisdictionalCivic,=0D=0Aloc= ationURI} to a set of=0D=0A=0D=0A{any, civic, geodetic, locationURI}. =20=0D= =0A=0D=0ARegards,=20=0D=0AMary=20=0D=0AEditor HELD=20=0D=0A=0D=0A=20=0D=0A=0D= =0A*****=0D=0A=0D=0AThe information transmitted is intended only for the pe= rson or entity to=0D=0Awhich it is addressed and may contain confidential, = proprietary, and/or=0D=0Aprivileged material. Any review, retransmission, d= issemination or other=0D=0Ause of, or taking of any action in reliance upon= this information by=0D=0Apersons or entities other than the intended recip= ient is prohibited. If=0D=0Ayou received this in error, please contact the = sender and delete the=0D=0Amaterial from all computers. GA621=0D=0A=0D=0A--= ---------------------------------------------------------------------------= -------------------=0D=0AThis message is for the designated recipient only = and may=0D=0Acontain privileged, proprietary, or otherwise private informat= ion. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C7F646.0CC0D82E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww= w.w3.org/TR/REC-html40">=0D=0A=0D=0A<head>=0D=0A<meta http-equiv=3DContent-= Type content=3D"text/html; charset=3Dus-ascii">=0D=0A<meta name=3DGenerator= content=3D"Microsoft Word 11 (filtered medium)">=0D=0A<!--[if !mso]>=0D=0A= <style>=0D=0Av\:* {behavior:url(#default#VML);}=0D=0Ao\:* {behavior:url(#de= fault#VML);}=0D=0Aw\:* {behavior:url(#default#VML);}=0D=0A.shape {behavior:= url(#default#VML);}=0D=0A</style>=0D=0A<![endif]-->=0D=0A<title>"Posta= l" and "Jurisdicational" civic locations -=0D=0Areprise</tit= le>=0D=0A<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:s= marttags"=0D=0A name=3D"State"/>=0D=0A<o:SmartTagType namespaceuri=3D"urn:s= chemas-microsoft-com:office:smarttags"=0D=0A name=3D"City"/>=0D=0A<o:SmartT= agType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=0D=0A na= me=3D"country-region"/>=0D=0A<o:SmartTagType namespaceuri=3D"urn:schemas-mi= crosoft-com:office:smarttags"=0D=0A name=3D"place"/>=0D=0A<o:SmartTagType n= amespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=0D=0A name=3D"Pl= aceName"/>=0D=0A<!--[if !mso]>=0D=0A<style>=0D=0Ast1\:*{behavior:url(#defau= lt#ieooui) }=0D=0A</style>=0D=0A<![endif]-->=0D=0A<style>=0D=0A<!--=0D=0A /= * Font Definitions */=0D=0A @font-face=0D=0A=09{font-family:Tahoma;=0D=0A=09= panose-1:2 11 6 4 3 5 4 4 2 4;}=0D=0A /* Style Definitions */=0D=0A p.MsoNo= rmal, li.MsoNormal, div.MsoNormal=0D=0A=09{margin:0cm;=0D=0A=09margin-botto= m:.0001pt;=0D=0A=09font-size:12.0pt;=0D=0A=09font-family:"Times New Roman";= }=0D=0Aa:link, span.MsoHyperlink=0D=0A=09{color:blue;=0D=0A=09text-decorati= on:underline;}=0D=0Aa:visited, span.MsoHyperlinkFollowed=0D=0A=09{color:pur= ple;=0D=0A=09text-decoration:underline;}=0D=0Ap=0D=0A=09{mso-margin-top-alt= :auto;=0D=0A=09margin-right:0cm;=0D=0A=09mso-margin-bottom-alt:auto;=0D=0A=09= margin-left:0cm;=0D=0A=09font-size:12.0pt;=0D=0A=09font-family:"Times New R= oman";}=0D=0Aspan.EmailStyle18=0D=0A=09{mso-style-type:personal;=0D=0A=09fo= nt-family:Arial;=0D=0A=09color:blue;=0D=0A=09font-weight:normal;=0D=0A=09fo= nt-style:normal;=0D=0A=09text-decoration:none none;}=0D=0Aspan.EmailStyle19=0D= =0A=09{mso-style-type:personal-reply;=0D=0A=09font-family:Arial;=0D=0A=09co= lor:navy;}=0D=0A@page Section1=0D=0A=09{size:612.0pt 792.0pt;=0D=0A=09margi= n:72.0pt 90.0pt 72.0pt 90.0pt;}=0D=0Adiv.Section1=0D=0A=09{page:Section1;}=0D= =0A-->=0D=0A</style>=0D=0A=0D=0A</head>=0D=0A=0D=0A<body lang=3DEN-AU link=3D= blue vlink=3Dpurple>=0D=0A=0D=0A<div class=3DSection1>=0D=0A=0D=0A<p class=3D= MsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size= :=0D=0A10.0pt;font-family:Arial;color:navy'>Hi Barbara,<o:p></o:p></span></= font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D= Arial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:navy'><= o:p> </o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font si= ze=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font= -family:Arial;color:navy'>I am a little confused by this response.<o:p></o:= p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3D= navy face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;c= olor:navy'><o:p> </o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNor= mal><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A= 10.0pt;font-family:Arial;color:navy'>Expressing the civic location types in= the=0D=0APIDF-LO is one issue.<o:p></o:p></span></font></p>=0D=0A=0D=0A<p = class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D'f= ont-size:=0D=0A10.0pt;font-family:Arial;color:navy'>Being able to request j= ust a=0D=0Ajurisdictional civic, or just a postal civic using HELD is a dif= ferent issue.<o:p></o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal>= <font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A10.= 0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>=0D=0A=0D= =0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span styl= e=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:navy'>I don’t thi= nk issue one is really=0D=0Aresolved, but I also don’t think that it = has any direct bearing on issues=0D=0A2.<o:p></o:p></span></font></p>=0D=0A=0D= =0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span styl= e=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:navy'><o:p> </o:p>= </span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dn= avy face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;co= lor:navy'>Your last sentence makes me think that you=0D=0Asee some benefit = in leaving jurisdictionalCivic and postalCivic in HELD. Is that=0D=0Aright=3F= <o:p></o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D= 2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-fami= ly:Arial;color:navy'><o:p> </o:p></span></font></p>=0D=0A=0D=0A<p clas= s=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-= size:=0D=0A10.0pt;font-family:Arial;color:navy'>Cheers<o:p></o:p></span></f= ont></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3D= Arial><span style=3D'font-size:=0D=0A10.0pt;font-family:Arial;color:navy'>J= ames<o:p></o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font siz= e=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:=0D=0A10.0pt;font-= family:Arial;color:navy'><o:p> </o:p></span></font></p>=0D=0A=0D=0A<p = class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=3D'f= ont-size:=0D=0A10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span= ></font></p>=0D=0A=0D=0A<div style=3D'border:none;border-left:solid blue 1.= 5pt;padding:0cm 0cm 0cm 4.0pt'>=0D=0A=0D=0A<div>=0D=0A=0D=0A<div class=3DMs= oNormal align=3Dcenter style=3D'text-align:center'><font size=3D3=0D=0Aface= =3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:12.0pt'>=0D=0A=0D= =0A<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>=0D=0A=0D=0A</s= pan></font></div>=0D=0A=0D=0A<p class=3DMsoNormal><b><font size=3D2 face=3D= Tahoma><span lang=3DEN-US=0D=0Astyle=3D'font-size:10.0pt;font-family:Tahoma= ;font-weight:bold'>From:</span></font></b><font=0D=0Asize=3D2 face=3DTahoma= ><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma'>=0D=0ASta= rk, Barbara [mailto:bs7652@att.com] <br>=0D=0A<b><span style=3D'font-weight= :bold'>Sent:</span></b> Friday, 14 September 2007=0D=0A3:51 AM<br>=0D=0A<b>= <span style=3D'font-weight:bold'>To:</span></b> Marc Berryman; Mary Barnes;=0D= =0Ageopriv@ietf.org<br>=0D=0A<b><span style=3D'font-weight:bold'>Subject:</= span></b> RE: [Geopriv]=0D=0A"Postal" and "Jurisdicational&q= uot; civic locations - reprise</span></font><span=0D=0Alang=3DEN-US><o:p></= o:p></span></p>=0D=0A=0D=0A</div>=0D=0A=0D=0A<p class=3DMsoNormal><font siz= e=3D3 face=3D"Times New Roman"><span style=3D'font-size:=0D=0A12.0pt'><o:p>=  </o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D= 2 color=3Dblue face=3DArial><span lang=3DEN-US=0D=0Astyle=3D'font-size:10.0= pt;font-family:Arial;color:blue'>The impression I was left=0D=0Awith, was t= hat it was possible to describe a particular physical civic location=0D=0Aw= ith a single PIDF-LO. Within that LO there may be jurisdictional and postal=0D= =0Afields. These are already defined in the PIDF-LO docs. The street addres= s (and=0D=0Apossibly the jurisdictional community name) may have several (n= ot just 2)=0D=0A"correct" ways to express it, but it should be po= ssible to translate=0D=0Afrom one to another, so only one needs to be kept = in the LIS.</span></font><span=0D=0Alang=3DEN-US><o:p></o:p></span></p>=0D=0A=0D= =0A<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span lang=3D= EN-US=0D=0Astyle=3D'font-size:12.0pt'> <o:p></o:p></span></font></p>=0D= =0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><spa= n lang=3DEN-US=0D=0Astyle=3D'font-size:10.0pt;font-family:Arial;color:blue'= >What appeared to be touched=0D=0Aon, but never really discussed, was wheth= er there needed to be the ability to=0D=0Asay "I would like to have th= e mailing address for where I am."=0D=0AAs Guy and Jerome mention= ed, the location of the mailbox does not necessarily=0D=0Acoincide with the= physical location of the device making the request.</span></font><span=0D=0A= lang=3DEN-US><o:p></o:p></span></p>=0D=0A=0D=0A<p class=3DMsoNormal><font s= ize=3D3 face=3D"Times New Roman"><span lang=3DEN-US=0D=0Astyle=3D'font-size= :12.0pt'> <o:p></o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNorma= l><font size=3D2 color=3Dblue face=3DArial><span lang=3DEN-US=0D=0Astyle=3D= 'font-size:10.0pt;font-family:Arial;color:blue'>So, I don't see value in=0D= =0Aseparate jurisdictional and postal requests to describe a single physica= l=0D=0Alocation, because both should be expressible within a single PIDF-LO= =2E There MAY=0D=0Abe value in being able to request the mailing address fo= r a physical location.</span></font><span=0D=0Alang=3DEN-US><o:p></o:p></sp= an></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3D= Arial><span lang=3DEN-US=0D=0Astyle=3D'font-size:10.0pt;font-family:Arial;c= olor:blue'>Barbara </span></font><span=0D=0Alang=3DEN-US><o:p></o:p></= span></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D3 face=3D"Times New = Roman"><span lang=3DEN-US=0D=0Astyle=3D'font-size:12.0pt'><o:p> </o:p>= </span></font></p>=0D=0A=0D=0A<div class=3DMsoNormal align=3Dcenter style=3D= 'text-align:center'><font size=3D3=0D=0Aface=3D"Times New Roman"><span lang= =3DEN-US style=3D'font-size:12.0pt'>=0D=0A=0D=0A<hr size=3D2 width=3D"100%"= align=3Dcenter tabIndex=3D-1>=0D=0A=0D=0A</span></font></div>=0D=0A=0D=0A<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=3D= Tahoma><span=0D=0Alang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma= ;font-weight:bold'>From:</span></font></b><font=0D=0Asize=3D2 face=3DTahoma= ><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Tahoma'>=0D=0AMar= c Berryman [mailto:MBerryman@911.org] <br>=0D=0A<b><span style=3D'font-weig= ht:bold'>Sent:</span></b> Thursday, September 13, 2007=0D=0A12:08 PM<br>=0D= =0A<b><span style=3D'font-weight:bold'>To:</span></b> Mary Barnes; geopriv@= ietf.org<br>=0D=0A<b><span style=3D'font-weight:bold'>Subject:</span></b> R= E: [Geopriv]=0D=0A"Postal" and "Jurisdicational" civic = locations - reprise</span></font><span=0D=0Alang=3DEN-US><o:p></o:p></span>= </p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D3 color=3Dblue face=3DAri= al><span lang=3DEN-US=0D=0Astyle=3D'font-size:12.0pt;font-family:Arial;colo= r:blue'>Mary,<o:p></o:p></span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal>= <font size=3D3 color=3Dblue face=3DArial><span lang=3DEN-US=0D=0Astyle=3D'f= ont-size:12.0pt;font-family:Arial;color:blue'> I do not think that=0D=0A= Jurisdiction and Postal need to be the same, often they are not the same, s= ince=0D=0Apostal rarely follows the same “boundaries” as jurisd= ictional.=0D=0ASince they may, or may not, be the same is the reason they a= re both included.=0D=0AYou can not assume they are the same.<o:p></o:p></sp= an></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D3 color=3Dblue = face=3DArial><span lang=3DEN-US=0D=0Astyle=3D'font-size:12.0pt;font-family:= Arial;color:blue'><o:p> </o:p></span></font></p>=0D=0A=0D=0A<p class=3D= MsoNormal><font size=3D3 color=3Dblue face=3DArial><span lang=3DEN-US=0D=0A= style=3D'font-size:12.0pt;font-family:Arial;color:blue'>Marc B<o:p></o:p></= span></font></p>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D3 color=3Dblu= e face=3DArial><span lang=3DEN-US=0D=0Astyle=3D'font-size:12.0pt;font-famil= y:Arial;color:blue'><o:p> </o:p></span></font></p>=0D=0A=0D=0A<div>=0D= =0A=0D=0A<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3D"Times New= Roman"><span=0D=0Alang=3DEN-US style=3D'font-size:10.0pt;color:blue'>Marc = Berryman, ENP<br>=0D=0AGeographic Information Systems<br>=0D=0AGreater <st1= :place w:st=3D"on"><st1:PlaceName w:st=3D"on">Harris</st1:PlaceName> <st1:P= laceName=0D=0A w:st=3D"on">County</st1:PlaceName></st1:place> 9-1-1 Emergen= cy Network<br>=0D=0A<st1:place w:st=3D"on"><st1:City w:st=3D"on">Houston</s= t1:City>, <st1:State w:st=3D"on">Texas</st1:State></st1:place>  &= nbsp;  =0D=0A(713) 407-2254<br>=0D=0Amberryman@911.org</span></fo= nt><font face=3DArial><span lang=3DEN-US=0D=0Astyle=3D'font-family:Arial'><= o:p></o:p></span></font></p>=0D=0A=0D=0A</div>=0D=0A=0D=0A<div>=0D=0A=0D=0A= <div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz= e=3D3=0D=0Aface=3D"Times New Roman"><span lang=3DEN-US style=3D'font-size:1= 2.0pt'>=0D=0A=0D=0A<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1= >=0D=0A=0D=0A</span></font></div>=0D=0A=0D=0A<p class=3DMsoNormal><b><font = size=3D2 face=3DTahoma><span lang=3DEN-US=0D=0Astyle=3D'font-size:10.0pt;fo= nt-family:Tahoma;font-weight:bold'>From:</span></font></b><font=0D=0Asize=3D= 2 face=3DTahoma><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Ta= homa'>=0D=0AMary Barnes [mailto:mary.barnes@nortel.com] <br>=0D=0A<b><span = style=3D'font-weight:bold'>Sent:</span></b> Thursday, September 13, 2007=0D= =0A11:02 AM<br>=0D=0A<b><span style=3D'font-weight:bold'>To:</span></b> geo= priv@ietf.org<br>=0D=0A<b><span style=3D'font-weight:bold'>Subject:</span><= /b> [Geopriv]=0D=0A"Postal" and "Jurisdicational" civic= locations - reprise</span></font><span=0D=0Alang=3DEN-US><o:p></o:p></span= ></p>=0D=0A=0D=0A</div>=0D=0A=0D=0A<p class=3DMsoNormal><font size=3D3 face= =3D"Times New Roman"><span lang=3DEN-US=0D=0Astyle=3D'font-size:12.0pt'><o:= p> </o:p></span></font></p>=0D=0A=0D=0A<p><font size=3D2 face=3DArial>= <span lang=3DEN-US style=3D'font-size:10.0pt;font-family:=0D=0AArial'>Hi al= l,</span></font><span lang=3DEN-US> <o:p></o:p></span></p>=0D=0A=0D=0A<p><f= ont size=3D2 face=3DArial><span lang=3DEN-US style=3D'font-size:10.0pt;font= -family:=0D=0AArial'>This thread never seemed to conclude with clear consen= sus as to whether=0D=0Afolks see a need for both these specific location ty= pes rather than being able=0D=0Ato use a common "civic" locationT= ype.     I went=0D=0Aback through the threads and the m= ajority of the responses indicated that both=0D=0Aof the values should be t= he same (with <st1:place w:st=3D"on"><st1:country-region=0D=0A w:st=3D"on">= Canada</st1:country-region></st1:place> being the=0D=0Aexception=3F). =   Since the thread did diverge somewhat (into how=0D=0Aconversions etc= =2E are done), I would like to do a quick query to see if folks=0D=0Aare ok= ay with removing those two values from the locationType in the HELD=0D=0Adr= aft=3F   </span></font><span lang=3DEN-US><o:p></o:p></span></p>=0D= =0A=0D=0A<p><font size=3D2 face=3DArial><span lang=3DEN-US style=3D'font-si= ze:10.0pt;font-family:=0D=0AArial'>And, just to be precise, we're proposing= changing locationType from a=0D=0Aset of {any, civic, geodetic, postalCivi= c, jurisdictionalCivic, locationURI} to=0D=0Aa set of</span></font><span la= ng=3DEN-US><o:p></o:p></span></p>=0D=0A=0D=0A<p><font size=3D2 face=3DArial= ><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:=0D=0AArial'>{any= , civic, geodetic, locationURI}.  </span></font><span=0D=0Alang=3DEN-U= S><o:p></o:p></span></p>=0D=0A=0D=0A<p><font size=3D2 face=3DArial><span la= ng=3DEN-US style=3D'font-size:10.0pt;font-family:=0D=0AArial'>Regards,</spa= n></font><span lang=3DEN-US> <br>=0D=0A</span><font size=3D2 face=3DArial><= span lang=3DEN-US style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>Mary</= span></font><span lang=3DEN-US> <br>=0D=0A</span><font size=3D2 face=3DAria= l><span lang=3DEN-US style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>Edi= tor HELD </span></font><span lang=3DEN-US><o:p></o:p></span></p>=0D=0A=0D=0A= <p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span lang=3DE= N-US=0D=0Astyle=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>=0D= =0A=0D=0A</div>=0D=0A=0D=0A</div>=0D=0A=0D=0A<br><br><table bgcolor=3Dwhite= style=3D"color:black"><tr><td><br>----------------------------------------= --------------------------------------------------------<br>=0D=0AThis = ;message is for the designated recipient only=  and may<br>=0D=0Acontain privileged, proprietary, = ;or otherwise private information.  <br>=0D=0AIf&n= bsp;you have received it in error, please&nbs= p;notify the sender<br>=0D=0Aimmediately and delete&nbs= p;the original.  Any unauthorized use of<br>=0D= =0Athis email is prohibited.<br>=0D=0A----------------------= --------------------------------------------------------------------------<= br>=0D=0A[mf2]</td></tr></table></body>=0D=0A=0D=0A<!--[object_id=3D#att.co= m#]--><P align=3Dleft><FONT face=3DTahoma size=3D2><FONT color=3D#0000ff><F= ONT face=3DTahoma color=3D#000000 size=3D2>*****</FONT></P>=0D=0A<P><FONT f= ace=3DTahoma color=3D#000000 size=3D2>The information transmitted is intend= ed only for the person or entity to which it is addressed and may contain c= onfidential, proprietary, and/or privileged material. Any review, retransmi= ssion, dissemination or other use of, or taking of any action in reliance u= pon this information by persons or entities other than the intended recipie= nt is prohibited. If you received this in error, please contact the sender = and delete the material from all computers. GA621</FONT></P></FONT></FONT>=0D= =0A</html>=0D=0A ------_=_NextPart_001_01C7F646.0CC0D82E-- --===============1494666757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1494666757==-- From geopriv-bounces@ietf.org Thu Sep 13 19:52:15 2007 Return-path: <geopriv-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVyTm-00055j-Gv; Thu, 13 Sep 2007 19:52:14 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVyTk-00055A-QM for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 19:52:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVyTk-00054f-DD for geopriv@ietf.org; Thu, 13 Sep 2007 19:52:12 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVyTj-0007zp-S9 for geopriv@ietf.org; Thu, 13 Sep 2007 19:52:12 -0400 Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.184552609; Thu, 13 Sep 2007 19:51:49 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 19:51:49 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 19:51:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 19:51:47 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p> In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF10358115F@AHQEX1.andrew.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAAG9ygAAMwFmAABjQlsAABcyMA References: <E3F9D87C63E2774390FE67C924EC99BB16E79ACB@zrc2hxm1.corp.nortel.com><B42DAB382ECF4441B2B151522CACAFAA01167328@ghcmail.ghc911.org> <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p> <E51D5B15BFDEFD448F90BDD17D41CFF10358115F@AHQEX1.andrew.com> From: "Stark, Barbara" <bs7652@att.com> To: "Winterbottom, James" <James.Winterbottom@andrew.com>, "Marc Berryman" <MBerryman@911.org>, "Mary Barnes" <mary.barnes@nortel.com>, <geopriv@ietf.org> X-OriginalArrivalTime: 13 Sep 2007 23:51:49.0007 (UTC) FILETIME=[0CC869F0:01C7F661] X-Spam-Score: 0.0 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy <geopriv.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe> List-Post: <mailto:geopriv@ietf.org> List-Help: <mailto:geopriv-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1821823212==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============1821823212== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F661.0CA5E5F2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F661.0CA5E5F2 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The reason for wanting a postal address would likely be because the device user wants to have something mailed or delivered. If this is true, then the goal of a "postal" request should be to get the location where mail and packages should be sent, and not necessarily the actual location where the device is. These locations may be the same or they may be different, as Jerome and Guy described. =20 On the other hand, if we insist that postal formulations must still describe the actual physical location and not necessarily a mailing address, then I don't see what compelling use there is for such a distinction. =20 If people want the mailing address, I can see the potential use, but I don't care whether we do that or not. On the other hand, if people want a postal-only formulation of a physical location, which may or may not be useful for shipping packages and sending mail, then I don't get it. =20 As a potential LIS implementer, I don't really see the need for the complexity of having separate street names stored for various locations, for the special cases where they differ. Which means, I wouldn't plan on it. Let someone use a street-name mapping function. Besides, the location data we have in our database has 9-digit zip in most cases. It's real easy to do a reverse lookup to get the official postal street name, given a 9-digit zip code.=20 =20 So let me ask -- is "postal" supposed to be the address where people at the current location get mail? If it can't be used to send mail, then where's the value in providing a LO with only the postal fields in it? Barbara ________________________________ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Thursday, September 13, 2007 4:39 PM To: Stark, Barbara; Marc Berryman; Mary Barnes; geopriv@ietf.org Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Hi Barbara, =20 I am a little confused by this response. =20 Expressing the civic location types in the PIDF-LO is one issue. Being able to request just a jurisdictional civic, or just a postal civic using HELD is a different issue. =20 I don't think issue one is really resolved, but I also don't think that it has any direct bearing on issues 2. =20 Your last sentence makes me think that you see some benefit in leaving jurisdictionalCivic and postalCivic in HELD. Is that right? =20 Cheers James =20 =20 ________________________________ From: Stark, Barbara [mailto:bs7652@att.com]=20 Sent: Friday, 14 September 2007 3:51 AM To: Marc Berryman; Mary Barnes; geopriv@ietf.org Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise =20 The impression I was left with, was that it was possible to describe a particular physical civic location with a single PIDF-LO. Within that LO there may be jurisdictional and postal fields. These are already defined in the PIDF-LO docs. The street address (and possibly the jurisdictional community name) may have several (not just 2) "correct" ways to express it, but it should be possible to translate from one to another, so only one needs to be kept in the LIS. =20 What appeared to be touched on, but never really discussed, was whether there needed to be the ability to say "I would like to have the mailing address for where I am." As Guy and Jerome mentioned, the location of the mailbox does not necessarily coincide with the physical location of the device making the request. =20 So, I don't see value in separate jurisdictional and postal requests to describe a single physical location, because both should be expressible within a single PIDF-LO. There MAY be value in being able to request the mailing address for a physical location. Barbara=20 =20 ________________________________ From: Marc Berryman [mailto:MBerryman@911.org]=20 Sent: Thursday, September 13, 2007 12:08 PM To: Mary Barnes; geopriv@ietf.org Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Mary, I do not think that Jurisdiction and Postal need to be the same, often they are not the same, since postal rarely follows the same "boundaries" as jurisdictional. Since they may, or may not, be the same is the reason they are both included. You can not assume they are the same. =20 Marc B =20 Marc Berryman, ENP Geographic Information Systems Greater Harris County 9-1-1 Emergency Network Houston, Texas (713) 407-2254 mberryman@911.org ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Thursday, September 13, 2007 11:02 AM To: geopriv@ietf.org Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise =20 Hi all,=20 This thread never seemed to conclude with clear consensus as to whether folks see a need for both these specific location types rather than being able to use a common "civic" locationType. I went back through the threads and the majority of the responses indicated that both of the values should be the same (with Canada being the exception?). Since the thread did diverge somewhat (into how conversions etc. are done), I would like to do a quick query to see if folks are okay with removing those two values from the locationType in the HELD draft? =20 And, just to be precise, we're proposing changing locationType from a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, locationURI} to a set of {any, civic, geodetic, locationURI}. =20 Regards,=20 Mary=20 Editor HELD=20 =20 ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2]=09 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ------_=_NextPart_001_01C7F661.0CA5E5F2 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20 "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20 "urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>"Postal" and = "Jurisdicational" civic locations - reprise
The reason for wanting a postal address would = likely be=20 because the device user wants to have something mailed or delivered. If = this is=20 true, then the goal of a "postal" request should be to get the location = where=20 mail and packages should be sent, and not necessarily the actual = location where=20 the device is. These locations may be the same or they may be = different, as=20 Jerome and Guy described.
 
On the other hand, if we insist that postal = formulations=20 must still describe the actual physical location and not necessarily a = mailing=20 address, then I don't see what compelling use there is for such a=20 distinction.
 
If people want the mailing address, I can see = the potential=20 use, but I don't care whether we do that or not. On the other hand, if = people=20 want a postal-only formulation of a physical location, which may or may = not be=20 useful for shipping packages and sending mail, then I don't get=20 it.
 
As a potential LIS implementer, I don't really = see the need=20 for the complexity of having separate street names stored for various = locations,=20 for the special cases where they differ. Which means, I wouldn't plan on = it. Let=20 someone use a street-name mapping function. Besides, the location data = we have=20 in our database has 9-digit zip in most cases. It's real easy to do a = reverse=20 lookup to get the official postal street name, given a 9-digit zip code. =
 
So let me ask -- is "postal" supposed to be = the address=20 where people at the current location get mail? If it can't be used to = send mail,=20 then where's the value in providing a LO with only the postal fields in=20 it?
Barbara

From: Winterbottom, James=20 [mailto:James.Winterbottom@andrew.com]
Sent: Thursday, = September 13,=20 2007 4:39 PM
To: Stark, Barbara; Marc Berryman; Mary Barnes;=20 geopriv@ietf.org
Subject: RE: [Geopriv] "Postal" and = "Jurisdicational"=20 civic locations - reprise

Hi=20 Barbara,

 

I am a little = confused=20 by this response.

 

Expressing = the civic=20 location types in the PIDF-LO is one issue.

Being able to = request=20 just a jurisdictional civic, or just a postal civic using HELD is a = different=20 issue.

 

I don’t = think issue one=20 is really resolved, but I also don’t think that it has any direct = bearing on=20 issues 2.

 

Your last = sentence=20 makes me think that you see some benefit in leaving jurisdictionalCivic = and=20 postalCivic in HELD. Is that right?

 

Cheers

James

 

 

From: Stark, Barbara=20 [mailto:bs7652@att.com]
Sent:=20 Friday, 14 September 2007 3:51 AM
To: Marc Berryman; Mary Barnes;=20 geopriv@ietf.org
Subject: RE:=20 [Geopriv] "Postal" and "Jurisdicational" civic locations -=20 reprise

 

The = impression I was=20 left with, was that it was possible to describe a particular physical = civic=20 location with a single PIDF-LO. Within that LO there may be = jurisdictional and=20 postal fields. These are already defined in the PIDF-LO docs. The street = address=20 (and possibly the jurisdictional community name) may have several (not = just 2)=20 "correct" ways to express it, but it should be possible to translate = from one to=20 another, so only one needs to be kept in the LIS.

 

What appeared = to be=20 touched on, but never really discussed, was whether there needed to be = the=20 ability to say "I would like to have the mailing address for = where I am."=20 As Guy and Jerome mentioned, the location of the mailbox does not = necessarily=20 coincide with the physical location of the device making the=20 request.

 

So, I don't = see value=20 in separate jurisdictional and postal requests to describe a single = physical=20 location, because both should be expressible within a single PIDF-LO. = There MAY=20 be value in being able to request the mailing address for a physical=20 location.

Barbara 

 

From: Marc Berryman=20 [mailto:MBerryman@911.org]
Sent: Thursday, September 13, = 2007 12:08=20 PM
To: Mary Barnes;=20 geopriv@ietf.org
Subject: RE:=20 [Geopriv] "Postal" and "Jurisdicational" civic locations -=20 reprise

Mary,

 I do = not think=20 that Jurisdiction and Postal need to be the same, often they are not the = same,=20 since postal rarely follows the same “boundaries” as = jurisdictional. Since they=20 may, or may not, be the same is the reason they are both included. You = can not=20 assume they are the same.

 

Marc=20 B

 

Marc Berryman, = ENP
Geographic=20 Information Systems
Greater Harris County 9-1-1 Emergency=20 Network
Houston,=20 Texas     =20 (713) 407-2254
mberryman@911.org

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: Thursday, September 13, = 2007 11:02=20 AM
To:=20 geopriv@ietf.org
Subject:=20 [Geopriv] "Postal" and "Jurisdicational" civic locations -=20 reprise

 

Hi all,

This thread never seemed = to conclude=20 with clear consensus as to whether folks see a need for both these = specific=20 location types rather than being able to use a common "civic"=20 locationType.     I went back through the threads = and the=20 majority of the responses indicated that both of the values should be = the same=20 (with Canada being the=20 exception?).   Since the thread did diverge somewhat (into how = conversions etc. are done), I would like to do a quick query to see if = folks are=20 okay with removing those two values from the locationType in the HELD=20 draft?  

And, just to be precise, = we're=20 proposing changing locationType from a set of {any, civic, geodetic,=20 postalCivic, jurisdictionalCivic, locationURI} to a set = of

{any, civic, geodetic,=20 locationURI}. 

Regards,
Mary=20
Editor HELD =

 



=

-----------------------------------------------------------------= -------------------------------
This message is for&nbs= p;the designated recipient only and may
conta= in privileged, proprietary, or otherwise private=  information.  
If you have received&nbs= p;it in error, please notify the sender
= immediately and delete the original.  Any&n= bsp;unauthorized use of
this email is prohibi= ted.
-----------------------------------------------------------------= -------------------------------
[mf2]

*****

The information = transmitted is=20 intended only for the person or entity to which it is addressed and may = contain=20 confidential, proprietary, and/or privileged material. Any review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers.=20 GA621

 ------_=_NextPart_001_01C7F661.0CA5E5F2-- --===============1821823212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============1821823212==-- From geopriv-bounces@ietf.org Thu Sep 13 20:08:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVyj4-0002xH-PT; Thu, 13 Sep 2007 20:08:02 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IVyj3-0002sA-6L for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 20:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVyj2-0002s2-S3 for geopriv@ietf.org; Thu, 13 Sep 2007 20:08:00 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVyj1-0002g4-1X for geopriv@ietf.org; Thu, 13 Sep 2007 20:08:00 -0400 X-SEF-Processed: 5_0_0_910__2007_09_13_19_17_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 13 Sep 2007 19:17:23 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Sep 2007 19:07:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 19:07:55 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAAG9ygAAMwFmAABjQlsAABcyMAAAWq8uA= References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p> From: "Dawson, Martin" To: "Stark, Barbara" , "Winterbottom, James" , "Marc Berryman" , "Mary Barnes" , X-OriginalArrivalTime: 14 Sep 2007 00:07:57.0776 (UTC) FILETIME=[4E36D500:01C7F663] X-Spam-Score: -0.0 (/) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0903280692==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0903280692== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F663.4DD48EA6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F663.4DD48EA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barbara,=0D=0A=20=0D=0AI think this confusion has been drifting around f= or a while... the term=0D=0A"postal" is being interpreted as both a particu= lar "form" and a=0D=0Aparticular "use". I think the most significant intent= is the "form".=0D=0A=20=0D=0AThat is:=0D=0AJurisdictional Civic is the for= mat prescribed by some applicable=0D=0Aauthority for the purposes of emerge= ncy services (and whatever other=0D=0Aservice is applicable for that jurisd= icational form)=0D=0APostal Civic is the format as generally prescribed for= describing a=0D=0Apostal address and as, presumably, prescribed by some Po= stal service=0D=0Aauthority.=0D=0A=20=0D=0AThe problem, of course, is that = somebody's postal address may actually=0D=0Abe a post-office box or other l= ocation not actually associated with the=0D=0Aspatial location of the perso= n/target in question. The presumption, that=0D=0Athe "postal" civic form is= prescribed by a postal servcie authority is=0D=0Aprobably unwarranted as w= ell; can anyone claim this is true worldwide or=0D=0Ais it a bit of a North= American bias=3F=0D=0A=20=0D=0APerhaps it would be better if we dropped th= e term "Postal" civic and=0D=0Areplaced it with something with less baggage= - such as "Common Civic" -=0D=0Awith the definitition that it's the format= used for prescribing a civic=0D=0Aaddress as understood colloquially for t= he region in question and which=0D=0Ais the default usage for applications = which fall outside of the=0D=0Ajurisdictional service scope.=0D=0A=20=0D=0A= Cheers,=0D=0AMartin=0D=0A=0D=0A________________________________=0D=0A=0D=0A= From: Stark, Barbara [mailto:bs7652@att.com]=20=0D=0ASent: Friday, 14 Septe= mber 2007 9:52 AM=0D=0ATo: Winterbottom, James; Marc Berryman; Mary Barnes;= geopriv@ietf.org=0D=0ASubject: RE: [Geopriv] "Postal" and "Jurisdicational= " civic locations -=0D=0Areprise=0D=0A=0D=0A=0D=0AThe reason for wanting a = postal address would likely be because the=0D=0Adevice user wants to have s= omething mailed or delivered. If this is=0D=0Atrue, then the goal of a "pos= tal" request should be to get the location=0D=0Awhere mail and packages sho= uld be sent, and not necessarily the actual=0D=0Alocation where the device = is. These locations may be the same or they=0D=0Amay be different, as Jerom= e and Guy described.=0D=0A=20=0D=0AOn the other hand, if we insist that pos= tal formulations must still=0D=0Adescribe the actual physical location and = not necessarily a mailing=0D=0Aaddress, then I don't see what compelling us= e there is for such a=0D=0Adistinction.=0D=0A=20=0D=0AIf people want the ma= iling address, I can see the potential use, but I=0D=0Adon't care whether w= e do that or not. On the other hand, if people want=0D=0Aa postal-only form= ulation of a physical location, which may or may not=0D=0Abe useful for shi= pping packages and sending mail, then I don't get it.=0D=0A=20=0D=0AAs a po= tential LIS implementer, I don't really see the need for the=0D=0Acomplexit= y of having separate street names stored for various locations,=0D=0Afor th= e special cases where they differ. Which means, I wouldn't plan on=0D=0Ait.= Let someone use a street-name mapping function. Besides, the=0D=0Alocation= data we have in our database has 9-digit zip in most cases.=0D=0AIt's real= easy to do a reverse lookup to get the official postal street=0D=0Aname, g= iven a 9-digit zip code.=20=0D=0A=20=0D=0ASo let me ask -- is "postal" supp= osed to be the address where people at=0D=0Athe current location get mail=3F= If it can't be used to send mail, then=0D=0Awhere's the value in providing= a LO with only the postal fields in it=3F=0D=0ABarbara=0D=0A=0D=0A________= ________________________=0D=0A=0D=0AFrom: Winterbottom, James [mailto:James= =2EWinterbottom@andrew.com]=20=0D=0ASent: Thursday, September 13, 2007 4:39= PM=0D=0ATo: Stark, Barbara; Marc Berryman; Mary Barnes; geopriv@ietf.org=0D= =0ASubject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations -=0D= =0Areprise=0D=0A=0D=0A=0D=0A=0D=0AHi Barbara,=0D=0A=0D=0A=20=0D=0A=0D=0AI a= m a little confused by this response.=0D=0A=0D=0A=20=0D=0A=0D=0AExpressing = the civic location types in the PIDF-LO is one issue.=0D=0A=0D=0ABeing able= to request just a jurisdictional civic, or just a postal=0D=0Acivic using = HELD is a different issue.=0D=0A=0D=0A=20=0D=0A=0D=0AI don't think issue on= e is really resolved, but I also don't think that=0D=0Ait has any direct be= aring on issues 2.=0D=0A=0D=0A=20=0D=0A=0D=0AYour last sentence makes me th= ink that you see some benefit in leaving=0D=0AjurisdictionalCivic and posta= lCivic in HELD. Is that right=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0A= James=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A____________________________= ____=0D=0A=0D=0AFrom: Stark, Barbara [mailto:bs7652@att.com]=20=0D=0ASent: = Friday, 14 September 2007 3:51 AM=0D=0ATo: Marc Berryman; Mary Barnes; geop= riv@ietf.org=0D=0ASubject: RE: [Geopriv] "Postal" and "Jurisdicational" civ= ic locations -=0D=0Areprise=0D=0A=0D=0A=20=0D=0A=0D=0AThe impression I was = left with, was that it was possible to describe a=0D=0Aparticular physical = civic location with a single PIDF-LO. Within that LO=0D=0Athere may be juri= sdictional and postal fields. These are already defined=0D=0Ain the PIDF-LO= docs. The street address (and possibly the jurisdictional=0D=0Acommunity n= ame) may have several (not just 2) "correct" ways to express=0D=0Ait, but i= t should be possible to translate from one to another, so only=0D=0Aone nee= ds to be kept in the LIS.=0D=0A=0D=0A=20=0D=0A=0D=0AWhat appeared to be tou= ched on, but never really discussed, was whether=0D=0Athere needed to be th= e ability to say "I would like to have the mailing=0D=0Aaddress for where I= am." As Guy and Jerome mentioned, the location of=0D=0Athe mailbox does no= t necessarily coincide with the physical location of=0D=0Athe device making= the request.=0D=0A=0D=0A=20=0D=0A=0D=0ASo, I don't see value in separate j= urisdictional and postal requests to=0D=0Adescribe a single physical locati= on, because both should be expressible=0D=0Awithin a single PIDF-LO. There = MAY be value in being able to request the=0D=0Amailing address for a physic= al location.=0D=0A=0D=0ABarbara=20=0D=0A=0D=0A=20=0D=0A=0D=0A______________= __________________=0D=0A=0D=0AFrom: Marc Berryman [mailto:MBerryman@911.org= ]=20=0D=0ASent: Thursday, September 13, 2007 12:08 PM=0D=0ATo: Mary Barnes;= geopriv@ietf.org=0D=0ASubject: RE: [Geopriv] "Postal" and "Jurisdicational= " civic locations -=0D=0Areprise=0D=0A=0D=0AMary,=0D=0A=0D=0A I do not thin= k that Jurisdiction and Postal need to be the same, often=0D=0Athey are not= the same, since postal rarely follows the same "boundaries"=0D=0Aas jurisd= ictional. Since they may, or may not, be the same is the reason=0D=0Athey a= re both included. You can not assume they are the same.=0D=0A=0D=0A=20=0D=0A=0D= =0AMarc B=0D=0A=0D=0A=20=0D=0A=0D=0AMarc Berryman, ENP=0D=0AGeographic Info= rmation Systems=0D=0AGreater Harris County 9-1-1 Emergency Network=0D=0AHou= ston, Texas (713) 407-2254=0D=0Amberryman@911.org=0D=0A=0D=0A_________= _______________________=0D=0A=0D=0AFrom: Mary Barnes [mailto:mary.barnes@no= rtel.com]=20=0D=0ASent: Thursday, September 13, 2007 11:02 AM=0D=0ATo: geop= riv@ietf.org=0D=0ASubject: [Geopriv] "Postal" and "Jurisdicational" civic l= ocations -=0D=0Areprise=0D=0A=0D=0A=20=0D=0A=0D=0AHi all,=20=0D=0A=0D=0AThi= s thread never seemed to conclude with clear consensus as to whether=0D=0Af= olks see a need for both these specific location types rather than=0D=0Abei= ng able to use a common "civic" locationType. I went back through=0D=0A= the threads and the majority of the responses indicated that both of the=0D= =0Avalues should be the same (with Canada being the exception=3F). Since=0D= =0Athe thread did diverge somewhat (into how conversions etc. are done), I=0D= =0Awould like to do a quick query to see if folks are okay with removing=0D= =0Athose two values from the locationType in the HELD draft=3F =20=0D=0A=0D= =0AAnd, just to be precise, we're proposing changing locationType from a=0D= =0Aset of {any, civic, geodetic, postalCivic, jurisdictionalCivic,=0D=0Aloc= ationURI} to a set of=0D=0A=0D=0A{any, civic, geodetic, locationURI}. =20=0D= =0A=0D=0ARegards,=20=0D=0AMary=20=0D=0AEditor HELD=20=0D=0A=0D=0A=20=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A------------------------------------------------------= ------------------=0D=0A------------------------=0D=0AThis message is for t= he designated recipient only and may=0D=0Acontain privileged, proprietary, = or otherwise private information. =20=0D=0AIf you have received it in error= , please notify the sender=0D=0Aimmediately and delete the original. Any u= nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------= ----------------------------------------------------=0D=0A-----------------= -------=0D=0A[mf2]=09=0D=0A=0D=0A*****=0D=0A=0D=0AThe information transmitt= ed is intended only for the person or entity to=0D=0Awhich it is addressed = and may contain confidential, proprietary, and/or=0D=0Aprivileged material.= Any review, retransmission, dissemination or other=0D=0Ause of, or taking = of any action in reliance upon this information by=0D=0Apersons or entities= other than the intended recipient is prohibited. If=0D=0Ayou received this= in error, please contact the sender and delete the=0D=0Amaterial from all = computers. GA621=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C7F663.4DD48EA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A"Post= al" and "Jurisdicational" civic locations - reprise=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A
Hi Barbara,
=0D=0A
 
=0D=0A
I think this confusion has been drifting around for a =0D= =0Awhile... the term "postal" is being interpreted as both a particular "fo= rm" and=20=0D=0Aa particular "use". I think the most significant intent is = the=20=0D=0A"form".
=0D=0A
 
=0D=0A
That is:
=0D=0A
<= STRONG>Jurisdictional Civic is the format=20=0D=0Aprescribed by so= me applicable authority for the purposes of emergency services=20=0D=0A(and= whatever other service is applicable for that jurisdicational=20=0D=0Aform= )
=0D=0A
Po= stal Civic is the format as generally=20=0D=0Aprescribed for descr= ibing a postal address and as, presumably, prescribed by=20=0D=0Asome Posta= l service authority.
=0D=0A
=  
=0D=0A
The=20=0D=0Aproblem, of course, is that somebody's= postal address may actually be a=20=0D=0Apost-office box or other location= not actually associated with the spatial=20=0D=0Alocation of the person/ta= rget in question. The presumption, that the "postal"=20=0D=0Acivic form is = prescribed by a postal servcie authority is probably unwarranted=20=0D=0Aas= well; can anyone claim this is true worldwide or is it a bit of a North =0D= =0AAmerican bias=3F
=0D=0A
&= nbsp;
=0D=0A
Perhaps it would be better if we dropped th= e term "Postal" civic and=20=0D=0Areplaced it with something with less bagg= age - such as "Common Civic" - with the=20=0D=0Adefinitition that it's the = format used for prescribing a civic address as=20=0D=0Aunderstood colloquia= lly for the region in question and which is the default=20=0D=0Ausage for a= pplications which fall outside of the jurisdictional service=20=0D=0Ascope.=
=0D=0A
 
=0D=0ACheers,=0D=0A
Martin
=0D=0A

=0D=0A
=0D=0A
=0D=0AFrom: Stark, Barbara [mailto:bs= 7652@att.com]=20=0D=0A
Sent: Friday, 14 September 2007 9:52 AMTo: Winterbottom,=20=0D=0AJames; Marc Berryman; Mary Barnes; geopri= v@ietf.org
Subject: RE:=20=0D=0A[Geopriv] "Postal" and "Jurisdica= tional" civic locations -=20=0D=0Areprise

=0D=0A
=0D=0A
The reason for wanting a po= stal address would likely be=20=0D=0Abecause the device user wants to have = something mailed or delivered. If this is=20=0D=0Atrue, then the goal of a = "postal" request should be to get the location where=20=0D=0Amail and packa= ges should be sent, and not necessarily the actual location where=20=0D=0At= he device is. These locations may be the same or they may be different= , as=20=0D=0AJerome and Guy described.
=0D=0A
 
=0D=0A
On the other hand, if we insist that postal formulation= s=20=0D=0Amust still describe the actual physical location and not necessar= ily a mailing=20=0D=0Aaddress, then I don't see what compelling use there i= s for such a=20=0D=0Adistinction.
=0D=0A
 
=0D=0A
If people want the mailing address, I can see the potential =0D= =0Ause, but I don't care whether we do that or not. On the other hand, if p= eople=20=0D=0Awant a postal-only formulation of a physical location, which = may or may not be=20=0D=0Auseful for shipping packages and sending mail, th= en I don't get=20=0D=0Ait.
=0D=0A
 
=0D=0A
= As a potential LIS implementer, I don't really see the need=20=0D= =0Afor the complexity of having separate street names stored for various lo= cations,=20=0D=0Afor the special cases where they differ. Which means, I wo= uldn't plan on it. Let=20=0D=0Asomeone use a street-name mapping function. = Besides, the location data we have=20=0D=0Ain our database has 9-digit zip = in most cases. It's real easy to do a reverse=20=0D=0Alookup to get the off= icial postal street name, given a 9-digit zip code.=20=0D=0A<= /DIV>=0D=0A
 
=0D= =0A
= So let me ask -- is "postal" suppo= sed to be the address=20=0D=0Awhere people at the current location get mail= =3F If it can't be used to send mail,=20=0D=0Athen where's the value in pro= viding a LO with only the postal fields in=20=0D=0Ait=3F=0D=0A
Barbara

=0D= =0A
=0D= =0A
=0D=0AFrom: Winter= bottom, James=20=0D=0A[mailto:James.Winterbottom@andrew.com]
Sent: Thursday, September 13,=20=0D=0A2007 4:39 PM
To: Stark, Barbar= a; Marc Berryman; Mary Barnes;=20=0D=0Ageopriv@ietf.org
Subject: = RE: [Geopriv] "Postal" and "Jurisdicational"=20=0D=0Acivic locations - repr= ise

=0D=0A
=0D=0A
=0D=0A=

Hi=20=0D=0ABarba= ra,

=0D=0A

 

=0D=0A

I am a little confused=20=0D= =0Aby this response.

=0D=0A

 

=0D= =0A

Expressing th= e civic=20=0D=0Alocation types in the PIDF-LO is one issue.

=0D=0A

Being able to request=20=0D=0Ajust a jurisdictional civic, or just a po= stal civic using HELD is a different=20=0D=0Aissue.

=0D=0A

 

=0D=0A

I don’t think issue one=20=0D=0Ais really resol= ved, but I also don’t think that it has any direct bearing on=20=0D=0A= issues 2.

=0D=0A

 

=0D=0A

Your last sentence =0D= =0Amakes me think that you see some benefit in leaving jurisdictionalCivic = and=20=0D=0ApostalCivic in HELD. Is that right=3F<= /P>=0D=0A

&= nbsp;

=0D=0A

Cheers

=0D=0A

James

=0D=0A

 

=0D=0A

 

=0D=0A=0D=0A
=0D=0A
=0D= =0A
=0D=0A
=0D=0A

From: St= ark, Barbara=20=0D=0A[mailto:bs7652@att.com]
Sent:=20=0D=0AFriday, 14 September 2007 3:51 AM
To: Marc Berryman; Ma= ry Barnes;=20=0D=0Ageopriv@ietf.org
Subject: RE:=20=0D=0A[Geopriv] "Postal" and "Jurisdicational" c= ivic locations -=20=0D=0Areprise

=0D=0A

 <= /FONT>

=0D=0A

The impression I was=20=0D=0Aleft with, was that it was possib= le to describe a particular physical civic=20=0D=0Alocation with a single P= IDF-LO. Within that LO there may be jurisdictional and=20=0D=0Apostal field= s. These are already defined in the PIDF-LO docs. The street address=20=0D=0A= (and possibly the jurisdictional community name) may have several (not just= 2)=20=0D=0A"correct" ways to express it, but it should be possible to tran= slate from one to=20=0D=0Aanother, so only one needs to be kept in the LIS.=

=0D=0A

 

=0D=0A

What ap= peared to be=20=0D=0Atouched on, but never really discussed, was whether th= ere needed to be the=20=0D=0Aability to say "I would like to have the maili= ng address for where I am."=20=0D=0AAs Guy and Jerome mentioned, the l= ocation of the mailbox does not necessarily=20=0D=0Acoincide with the physi= cal location of the device making the=20=0D=0Arequest.

=0D=0A

 

=0D=0A

So, I don't see value=20=0D=0Ain= separate jurisdictional and postal requests to describe a single physical =0D= =0Alocation, because both should be expressible within a single PIDF-LO. Th= ere MAY=20=0D=0Abe value in being able to request the mailing address for a= physical=20=0D=0Alocation.

=0D=0A

= Barbara 

=0D=0A

 

=0D=0A
=0D=0A
=0D=0A
=0D=0A

From: Marc = Berryman=20=0D=0A[mailto:MBerryman@911.org]
Sent: Thursday, September 13, 2007 12:08=20=0D= =0APM
To: Mary Barnes; =0D= =0Ageopriv@ietf.org
Subject:= RE:=20=0D=0A[Geopriv] "Postal" and "Jurisdicational" civic locations -= =20=0D=0Areprise

=0D=0A=

Ma= ry,

=0D=0A

 I do not think=20=0D=0Athat Juris= diction and Postal need to be the same, often they are not the same,=20=0D=0A= since postal rarely follows the same “boundaries” as jurisdicti= onal. Since they=20=0D=0Amay, or may not, be the same is the reason they ar= e both included. You can not=20=0D=0Aassume they are the same.

=0D=0A

 

=0D=0A

Marc=20=0D=0AB

=0D=0A

 

=0D=0A=0D=0A

Ma= rc Berryman, ENP
Geographic=20=0D=0AInformation Systems
Greater Harris= County 9-1-= 1 Emergency=20=0D=0ANetwork
Houston,=20=0D=0ATexas     =20=0D=0A(713) 407-2254
mberryman@91= 1.org

=0D=0A
=0D=0A=0D=0A
=0D=0A
=0D=0A

From: Mary Barnes=20=0D=0A[mailto:mary.barnes@nortel.com]
Sent: Thursday, September 13, 200= 7 11:02=20=0D=0AAM
To: =0D= =0Ageopriv@ietf.org
Subject:= =20=0D=0A[Geopriv] "Postal" and "Jurisdicational" civic locations -=20=0D= =0Areprise

=0D=0A=

 

=0D= =0A

Hi all,

=0D=0A

This thread = never seemed to conclude=20=0D=0Awith clear consensus as to whether folks s= ee a need for both these specific=20=0D=0Alocation types rather than being = able to use a common "civic"=20=0D=0AlocationType.     = I went back through the threads and the=20=0D=0Amajority of the responses i= ndicated that both of the values should be the same=20=0D=0A(with Canada being the=20=0D=0Aexception=3F).   Since the t= hread did diverge somewhat (into how=20=0D=0Aconversions etc. are done), I = would like to do a quick query to see if folks are=20=0D=0Aokay with removi= ng those two values from the locationType in the HELD=20=0D=0Adraft=3F = ; 

=0D=0A

And, just to be precise, we're=20=0D=0Aproposing cha= nging locationType from a set of {any, civic, geodetic,=20=0D=0ApostalCivic= , jurisdictionalCivic, locationURI} to a set of

=0D=0A

{any,= civic, geodetic,=20=0D=0AlocationURI}. 

=0D=0A

Regards,=
<= SPAN lang=3DEN-US=20=0D=0Astyle=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Mar= y=20=0D=0A
Editor HELD

=0D=0A

 <= /FONT>



=0D=0A=0D=0A =0D=0A =0D=0A =

------------------------= ------------------------------------------------------------------------This message is for the designated recipient=  only and may
contain privileged, proprietary,&= nbsp;or otherwise private information.  
If&nbs= p;you have received it in error, please = notify the sender
immediately and delete the&nb= sp;original.  Any unauthorized use of
this = ;email is prohibited.
----------------------------------------= --------------------------------------------------------
[mf2]
=0D=0A

*****

=0D=0A

The information transmitted is=20=0D=0Aintended only for t= he person or entity to which it is addressed and may contain=20=0D=0Aconfid= ential, proprietary, and/or privileged material. Any review,=20=0D=0Aretran= smission, dissemination or other use of, or taking of any action in=20=0D=0A= reliance upon this information by persons or entities other than the intend= ed=20=0D=0Arecipient is prohibited. If you received this in error, please c= ontact the=20=0D=0Asender and delete the material from all computers.=20=0D= =0AGA621




----------------------------------------------------= --------------------------------------------
=0D=0AThis message&nbs= p;is for the designated recipient only and&nb= sp;may
=0D=0Acontain privileged, proprietary, or oth= erwise private information.  
=0D=0AIf you = ;have received it in error, please notify&nbs= p;the sender
=0D=0Aimmediately and delete the o= riginal.  Any unauthorized use of
=0D=0Athis&nb= sp;email is prohibited.
=0D=0A--------------------------------= ----------------------------------------------------------------
=0D=0A[= mf2]
=0D=0A ------_=_NextPart_001_01C7F663.4DD48EA6-- --===============0903280692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0903280692==-- From geopriv-bounces@ietf.org Thu Sep 13 22:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0iJ-0008MI-0R; Thu, 13 Sep 2007 22:15:23 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IW0iH-0008C0-Ey for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 22:15:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0iG-00086o-Uy for geopriv@ietf.org; Thu, 13 Sep 2007 22:15:21 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW0iG-0003o4-0W for geopriv@ietf.org; Thu, 13 Sep 2007 22:15:20 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8E2FGZO029565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Sep 2007 22:15:16 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p> References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <69DB989C-CAE8-4B45-AF7B-5E3239A83C0E@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 22:15:27 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The usage of 'postal' has caused a fair amount of confusion, since it =20= tends to conflate several different things: (1) a street address, possibly with a different postal community name =20= (PCN), which we already have in PIDF; (2) special street-like addresses, such as rural carrier routes, that =20= are only used for postal delivery and are meaningless to anybody else; (3) post office boxes (4) short addresses that only contain, say, organization name, city =20 and zip code, such as those used for the Internal Revenue Service in =20 the United States (example: IRS, Fresno, CA 93888-0002) Our definition of 'civic' has always only included (1), as only that =20 form satisfies the pizza delivery test. If you can't get pizza =20 delivered to it, it's beyond our scope. If it weren't so long and =20 unwieldy, we'd say a "(common) civic address as used by the postal =20 service". Brian has asked this before and the only interesting case that we are =20= concerned about is whether there are multiple interesting forms of =20 (1) that we need to distinguish, i.e., that are not just internal =20 aliases of each other. (Aliases can occur, for example, if a street =20 is renamed and the old name is still accepted for postal delivery.) =20 So far, the conclusion seems to be 'no'. Fortunately, we don't have to solve this problem now. If a new =20 address-like place naming form is discovered somewhere, we can add it =20= later, once we actually understand it and can name it. In many cases, we'll only need to add information elements, as long =20 as each (1) civic address has a single defined value. For example, if =20= we wanted to add a carrier route indication, we can just add a =20 corresponding label, since each house/apartment is on exactly one =20 route. Clearly, for PO boxes, there is no such direct equivalence. In short, I don't see a need for going postal. Henning On Sep 13, 2007, at 7:51 PM, Stark, Barbara wrote: > The reason for wanting a postal address would likely be because the =20= > device user wants to have something mailed or delivered. If this is =20= > true, then the goal of a "postal" request should be to get the =20 > location where mail and packages should be sent, and not =20 > necessarily the actual location where the device is. These =20 > locations may be the same or they may be different, as Jerome and =20 > Guy described. > > On the other hand, if we insist that postal formulations must still =20= > describe the actual physical location and not necessarily a mailing =20= > address, then I don't see what compelling use there is for such a =20 > distinction. > > If people want the mailing address, I can see the potential use, =20 > but I don't care whether we do that or not. On the other hand, if =20 > people want a postal-only formulation of a physical location, which =20= > may or may not be useful for shipping packages and sending mail, =20 > then I don't get it. > > As a potential LIS implementer, I don't really see the need for the =20= > complexity of having separate street names stored for various =20 > locations, for the special cases where they differ. Which means, I =20 > wouldn't plan on it. Let someone use a street-name mapping =20 > function. Besides, the location data we have in our database has 9-=20 > digit zip in most cases. It's real easy to do a reverse lookup to =20 > get the official postal street name, given a 9-digit zip code. > > So let me ask -- is "postal" supposed to be the address where =20 > people at the current location get mail? If it can't be used to =20 > send mail, then where's the value in providing a LO with only the =20 > postal fields in it? > Barbara > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, September 13, 2007 4:39 PM > To: Stark, Barbara; Marc Berryman; Mary Barnes; geopriv@ietf.org > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic =20 > locations - reprise > > Hi Barbara, > > > > I am a little confused by this response. > > > > Expressing the civic location types in the PIDF-LO is one issue. > > Being able to request just a jurisdictional civic, or just a postal =20= > civic using HELD is a different issue. > > > > I don=92t think issue one is really resolved, but I also don=92t think = =20 > that it has any direct bearing on issues 2. > > > > Your last sentence makes me think that you see some benefit in =20 > leaving jurisdictionalCivic and postalCivic in HELD. Is that right? > > > > Cheers > > James > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Friday, 14 September 2007 3:51 AM > To: Marc Berryman; Mary Barnes; geopriv@ietf.org > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic =20 > locations - reprise > > > > The impression I was left with, was that it was possible to =20 > describe a particular physical civic location with a single PIDF-=20 > LO. Within that LO there may be jurisdictional and postal fields. =20 > These are already defined in the PIDF-LO docs. The street address =20 > (and possibly the jurisdictional community name) may have several =20 > (not just 2) "correct" ways to express it, but it should be =20 > possible to translate from one to another, so only one needs to be =20 > kept in the LIS. > > > > What appeared to be touched on, but never really discussed, was =20 > whether there needed to be the ability to say "I would like to have =20= > the mailing address for where I am." As Guy and Jerome mentioned, =20 > the location of the mailbox does not necessarily coincide with the =20 > physical location of the device making the request. > > > > So, I don't see value in separate jurisdictional and postal =20 > requests to describe a single physical location, because both =20 > should be expressible within a single PIDF-LO. There MAY be value =20 > in being able to request the mailing address for a physical location. > > Barbara > > > > From: Marc Berryman [mailto:MBerryman@911.org] > Sent: Thursday, September 13, 2007 12:08 PM > To: Mary Barnes; geopriv@ietf.org > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic =20 > locations - reprise > > Mary, > > I do not think that Jurisdiction and Postal need to be the same, =20 > often they are not the same, since postal rarely follows the same =20 > =93boundaries=94 as jurisdictional. Since they may, or may not, be the = =20 > same is the reason they are both included. You can not assume they =20 > are the same. > > > > Marc B > > > > Marc Berryman, ENP > Geographic Information Systems > Greater Harris County 9-1-1 Emergency Network > Houston, Texas (713) 407-2254 > mberryman@911.org > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Thursday, September 13, 2007 11:02 AM > To: geopriv@ietf.org > Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - =20= > reprise > > > > Hi all, > > This thread never seemed to conclude with clear consensus as to =20 > whether folks see a need for both these specific location types =20 > rather than being able to use a common "civic" locationType. I =20 > went back through the threads and the majority of the responses =20 > indicated that both of the values should be the same (with Canada =20 > being the exception?). Since the thread did diverge somewhat =20 > (into how conversions etc. are done), I would like to do a quick =20 > query to see if folks are okay with removing those two values from =20 > the locationType in the HELD draft? > > And, just to be precise, we're proposing changing locationType from =20= > a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, =20 > locationURI} to a set of > > {any, civic, geodetic, locationURI}. > > Regards, > Mary > Editor HELD > > > > > > > ----------------------------------------------------------------------=20= > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ----------------------------------------------------------------------=20= > -------------------------- > [mf2] > ***** > > The information transmitted is intended only for the person or =20 > entity to which it is addressed and may contain confidential, =20 > proprietary, and/or privileged material. Any review, =20 > retransmission, dissemination or other use of, or taking of any =20 > action in reliance upon this information by persons or entities =20 > other than the intended recipient is prohibited. If you received =20 > this in error, please contact the sender and delete the material =20 > from all computers. GA621 > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 13 22:23:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0py-0007gL-FO; Thu, 13 Sep 2007 22:23:18 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IW0px-0007ev-5s for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 22:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW0pw-0007en-SQ for geopriv@ietf.org; Thu, 13 Sep 2007 22:23:16 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW0pv-0006AX-Ip for geopriv@ietf.org; Thu, 13 Sep 2007 22:23:16 -0400 X-SEF-Processed: 5_0_0_910__2007_09_13_21_32_38 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 13 Sep 2007 21:32:38 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Sep 2007 21:23:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 21:23:11 -0500 Message-ID: In-Reply-To: <69DB989C-CAE8-4B45-AF7B-5E3239A83C0E@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2dSFZ4ybvZFh5Sg+vw+TboEfRFAAAM/og References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p><7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p> <69DB989C-CAE8-4B45-AF7B-5E3239A83C0E@cs.columbia.edu> From: "Winterbottom, James" To: "GEOPRIV" X-OriginalArrivalTime: 14 Sep 2007 02:23:12.0964 (UTC) FILETIME=[333E4040:01C7F676] X-Spam-Score: 1.8 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org =0D=0AMary,=0D=0A=0D=0AI don't see a need for postal and jurisdictional civ= ic in the location=0D=0Arequest. One of the messiest bits of code in the op= en source LIS is=0D=0Adealing with a location request that contains civic, = postalCivic and=0D=0AjurisdictionalCivic.=0D=0A=0D=0AI am for limiting this= to simply civic.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 13 23:37:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW1zM-000213-IG; Thu, 13 Sep 2007 23:37:04 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IW1zL-0001xq-Hf for geopriv-confirm+ok@megatron.ietf.org; Thu, 13 Sep 2007 23:37:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW1zL-0001vD-5g for geopriv@ietf.org; Thu, 13 Sep 2007 23:37:03 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW1zK-0005cE-OV for geopriv@ietf.org; Thu, 13 Sep 2007 23:37:03 -0400 X-SEF-Processed: 5_0_0_910__2007_09_13_22_46_25 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 13 Sep 2007 22:46:24 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Sep 2007 22:36:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Thu, 13 Sep 2007 22:36:59 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2dSFZ4ybvZFh5Sg+vw+TboEfRFAAAM/ogAAJHuuA= References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p><7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p><69DB989C-CAE8-4B45-AF7B-5E3239A83C0E@cs.columbia.edu> From: "Thomson, Martin" To: "Winterbottom, James" , "GEOPRIV" X-OriginalArrivalTime: 14 Sep 2007 03:36:59.0603 (UTC) FILETIME=[81B9C230:01C7F680] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0610543243==" Errors-To: geopriv-bounces@ietf.org --===============0610543243== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdsbCBqdXN0IGFkZCBteSB2b2ljZSB0byB0aGUgY29uc2Vuc3VzLiAgImNpdmljIiBpcyBhZGVx dWF0ZS4NCg0KQXMgSGVubmluZyBwb2ludHMgb3V0LCB0aGVyZSBwcm9iYWJseSBpc24ndCBjb21w bGV0ZSBzdXBwb3J0IGZvciBwb3N0YWwgYWRkcmVzc2VzIGluIHRoZSBjdXJyZW50IHNldCBvZiBk cmFmdHMgYW5kIFJGQ3MuDQoNClBlcmhhcHMgc29tZW9uZSBjYW4gd3JpdGUgYSBob3ctdG8tdXNl LXJldmlzZWQtY2l2aWMtdG8tc2VuZC1wb3N0YWwtYWRkcmVzc2VzIGRyYWZ0LCBhbG9uZyB3aXRo IGEgaG93LXRvLWdldC1hbi1hZGRyZXNzLWxhYmVsLWZyb20tYS1yZXZpc2VkLWNpdmljLWZvcm0g ZHJhZnQuDQoNClRhLA0KTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogV2ludGVyYm90dG9tLCBKYW1lcyBbbWFpbHRvOkphbWVzLldpbnRlcmJvdHRvbUBhbmRy ZXcuY29tXQ0KPiBTZW50OiBGcmlkYXksIDE0IFNlcHRlbWJlciAyMDA3IDEyOjIzIFBNDQo+IFRv OiBHRU9QUklWDQo+IFN1YmplY3Q6IFJFOiBbR2VvcHJpdl0gIlBvc3RhbCIgYW5kICJKdXJpc2Rp Y2F0aW9uYWwiIGNpdmljIGxvY2F0aW9ucyAtDQo+IHJlcHJpc2UNCj4gDQo+IA0KPiBNYXJ5LA0K PiANCj4gSSBkb24ndCBzZWUgYSBuZWVkIGZvciBwb3N0YWwgYW5kIGp1cmlzZGljdGlvbmFsIGNp dmljIGluIHRoZSBsb2NhdGlvbg0KPiByZXF1ZXN0LiBPbmUgb2YgdGhlIG1lc3NpZXN0IGJpdHMg b2YgY29kZSBpbiB0aGUgb3BlbiBzb3VyY2UgTElTIGlzDQo+IGRlYWxpbmcgd2l0aCBhIGxvY2F0 aW9uIHJlcXVlc3QgdGhhdCBjb250YWlucyBjaXZpYywgcG9zdGFsQ2l2aWMgYW5kDQo+IGp1cmlz ZGljdGlvbmFsQ2l2aWMuDQo+IA0KPiBJIGFtIGZvciBsaW1pdGluZyB0aGlzIHRvIHNpbXBseSBj aXZpYy4NCj4gDQo+IENoZWVycw0KPiBKYW1lcw0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQg cmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KPiBjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5 LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiBpbW1lZGlhdGVseSBh bmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQo+IHRoaXMg ZW1haWwgaXMgcHJvaGliaXRlZC4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiBbbWYyXQ0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBHZW9w cml2QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dl b3ByaXYNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1l c3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRh aW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0 aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1 dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= --===============0610543243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0610543243==-- From geopriv-bounces@ietf.org Fri Sep 14 08:52:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWAex-0007rZ-6B; Fri, 14 Sep 2007 08:52:35 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWAev-0007r0-4C for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 08:52:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWAet-0007qX-V7 for geopriv@ietf.org; Fri, 14 Sep 2007 08:52:32 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWAes-0004Xq-P9 for geopriv@ietf.org; Fri, 14 Sep 2007 08:52:31 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IWAf5-0007ri-9f; Fri, 14 Sep 2007 07:52:43 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Stark, Barbara'" References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p><7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p> <69DB989C-CAE8-4B45-AF7B-5E3239A83C0E@cs.columbia.edu> Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Fri, 14 Sep 2007 08:52:21 -0400 Message-ID: <09da01c7f6ce$1ab73a60$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf2dSQQ4u8np433ToihZxE3n4dpJgAV2gbw In-Reply-To: <69DB989C-CAE8-4B45-AF7B-5E3239A83C0E@cs.columbia.edu> 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Well of course the choice bit on this is: > In short, I don't see a need for going postal. with which I totally agree. I think we make way too much out of postal beyond what we have (PCN). One more piece of info: Post Office Boxes are around in various forms in various countries. In the U.S., it used to be common to use them for rural addressing of mail. That has largely disappeared. Locations get street addresses, and they get them because 9-1-1 requires them, and the post office goes along with the addressing authorities. It's not completely gone, because there are still some areas of the country that don't have "E9-1-1", where the "E" is the part that has automatic location showing up with the call. Where E9-1-1 is implemented, every actual house/farm/store/factory/... location which gets mail has a street address. Post Office Boxes still exist in the U.S. as mailing destinations where the box is actually in the post office. The thing is, that's not a location as Geopriv would define it. So, please, let's get rid of postalCivic and jurisdictionalCivic as protocol elements. It sometimes helps to explain the issues (for example, in ecrit-framework), but we don't need protocol mechanisms beyond PCN to represent location for the U.S. I would not claim to speak for other countries, but so far, we don't have any conflicting information from other countries. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, September 13, 2007 10:15 PM > To: Stark, Barbara > Cc: GEOPRIV > Subject: Re: [Geopriv] "Postal" and "Jurisdicational" civic locations - > reprise > > The usage of 'postal' has caused a fair amount of confusion, since it > tends to conflate several different things: > > (1) a street address, possibly with a different postal community name > (PCN), which we already have in PIDF; > > (2) special street-like addresses, such as rural carrier routes, that > are only used for postal delivery and are meaningless to anybody else; > > (3) post office boxes > > (4) short addresses that only contain, say, organization name, city > and zip code, such as those used for the Internal Revenue Service in > the United States (example: IRS, Fresno, CA 93888-0002) > > Our definition of 'civic' has always only included (1), as only that > form satisfies the pizza delivery test. If you can't get pizza > delivered to it, it's beyond our scope. If it weren't so long and > unwieldy, we'd say a "(common) civic address as used by the postal > service". > > Brian has asked this before and the only interesting case that we are > concerned about is whether there are multiple interesting forms of > (1) that we need to distinguish, i.e., that are not just internal > aliases of each other. (Aliases can occur, for example, if a street > is renamed and the old name is still accepted for postal delivery.) > So far, the conclusion seems to be 'no'. > > Fortunately, we don't have to solve this problem now. If a new > address-like place naming form is discovered somewhere, we can add it > later, once we actually understand it and can name it. > > In many cases, we'll only need to add information elements, as long > as each (1) civic address has a single defined value. For example, if > we wanted to add a carrier route indication, we can just add a > corresponding label, since each house/apartment is on exactly one > route. Clearly, for PO boxes, there is no such direct equivalence. > > In short, I don't see a need for going postal. > > Henning > > On Sep 13, 2007, at 7:51 PM, Stark, Barbara wrote: > > > The reason for wanting a postal address would likely be because the > > device user wants to have something mailed or delivered. If this is > > true, then the goal of a "postal" request should be to get the > > location where mail and packages should be sent, and not > > necessarily the actual location where the device is. These > > locations may be the same or they may be different, as Jerome and > > Guy described. > > > > On the other hand, if we insist that postal formulations must still > > describe the actual physical location and not necessarily a mailing > > address, then I don't see what compelling use there is for such a > > distinction. > > > > If people want the mailing address, I can see the potential use, > > but I don't care whether we do that or not. On the other hand, if > > people want a postal-only formulation of a physical location, which > > may or may not be useful for shipping packages and sending mail, > > then I don't get it. > > > > As a potential LIS implementer, I don't really see the need for the > > complexity of having separate street names stored for various > > locations, for the special cases where they differ. Which means, I > > wouldn't plan on it. Let someone use a street-name mapping > > function. Besides, the location data we have in our database has 9- > > digit zip in most cases. It's real easy to do a reverse lookup to > > get the official postal street name, given a 9-digit zip code. > > > > So let me ask -- is "postal" supposed to be the address where > > people at the current location get mail? If it can't be used to > > send mail, then where's the value in providing a LO with only the > > postal fields in it? > > Barbara > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Thursday, September 13, 2007 4:39 PM > > To: Stark, Barbara; Marc Berryman; Mary Barnes; geopriv@ietf.org > > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic > > locations - reprise > > > > Hi Barbara, > > > > > > > > I am a little confused by this response. > > > > > > > > Expressing the civic location types in the PIDF-LO is one issue. > > > > Being able to request just a jurisdictional civic, or just a postal > > civic using HELD is a different issue. > > > > > > > > I don't think issue one is really resolved, but I also don't think > > that it has any direct bearing on issues 2. > > > > > > > > Your last sentence makes me think that you see some benefit in > > leaving jurisdictionalCivic and postalCivic in HELD. Is that right? > > > > > > > > Cheers > > > > James > > > > > > > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Friday, 14 September 2007 3:51 AM > > To: Marc Berryman; Mary Barnes; geopriv@ietf.org > > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic > > locations - reprise > > > > > > > > The impression I was left with, was that it was possible to > > describe a particular physical civic location with a single PIDF- > > LO. Within that LO there may be jurisdictional and postal fields. > > These are already defined in the PIDF-LO docs. The street address > > (and possibly the jurisdictional community name) may have several > > (not just 2) "correct" ways to express it, but it should be > > possible to translate from one to another, so only one needs to be > > kept in the LIS. > > > > > > > > What appeared to be touched on, but never really discussed, was > > whether there needed to be the ability to say "I would like to have > > the mailing address for where I am." As Guy and Jerome mentioned, > > the location of the mailbox does not necessarily coincide with the > > physical location of the device making the request. > > > > > > > > So, I don't see value in separate jurisdictional and postal > > requests to describe a single physical location, because both > > should be expressible within a single PIDF-LO. There MAY be value > > in being able to request the mailing address for a physical location. > > > > Barbara > > > > > > > > From: Marc Berryman [mailto:MBerryman@911.org] > > Sent: Thursday, September 13, 2007 12:08 PM > > To: Mary Barnes; geopriv@ietf.org > > Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic > > locations - reprise > > > > Mary, > > > > I do not think that Jurisdiction and Postal need to be the same, > > often they are not the same, since postal rarely follows the same > > "boundaries" as jurisdictional. Since they may, or may not, be the > > same is the reason they are both included. You can not assume they > > are the same. > > > > > > > > Marc B > > > > > > > > Marc Berryman, ENP > > Geographic Information Systems > > Greater Harris County 9-1-1 Emergency Network > > Houston, Texas (713) 407-2254 > > mberryman@911.org > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Thursday, September 13, 2007 11:02 AM > > To: geopriv@ietf.org > > Subject: [Geopriv] "Postal" and "Jurisdicational" civic locations - > > reprise > > > > > > > > Hi all, > > > > This thread never seemed to conclude with clear consensus as to > > whether folks see a need for both these specific location types > > rather than being able to use a common "civic" locationType. I > > went back through the threads and the majority of the responses > > indicated that both of the values should be the same (with Canada > > being the exception?). Since the thread did diverge somewhat > > (into how conversions etc. are done), I would like to do a quick > > query to see if folks are okay with removing those two values from > > the locationType in the HELD draft? > > > > And, just to be precise, we're proposing changing locationType from > > a set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, > > locationURI} to a set of > > > > {any, civic, geodetic, locationURI}. > > > > Regards, > > Mary > > Editor HELD > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > -------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ---------------------------------------------------------------------- > > -------------------------- > > [mf2] > > ***** > > > > The information transmitted is intended only for the person or > > entity to which it is addressed and may contain confidential, > > proprietary, and/or privileged material. Any review, > > retransmission, dissemination or other use of, or taking of any > > action in reliance upon this information by persons or entities > > other than the intended recipient is prohibited. If you received > > this in error, please contact the sender and delete the material > > from all computers. GA621 > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 11:18:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCwN-0005o1-Hw; Fri, 14 Sep 2007 11:18:43 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWCwM-0005nw-CX for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 11:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCwM-0005no-2b for geopriv@ietf.org; Fri, 14 Sep 2007 11:18:42 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWCwK-0000Ts-Qf for geopriv@ietf.org; Fri, 14 Sep 2007 11:18:42 -0400 Received: from SusieandCarl (c-24-8-177-87.hsd1.co.comcast.net [24.8.177.87]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l8EFIIDO013876 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Sep 2007 11:18:25 -0400 Message-ID: <011301c7f6e2$8125ac00$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Thomson, Martin" , "Winterbottom, James" , "GEOPRIV" References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F15A@crexc41p><7582BC68E4994F4ABF0BD4723975C3FA05A7F233@crexc41p><69DB989C-CAE8-4B45-AF7B-5E3239A83C0E@cs.columbia.edu> Subject: Re: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Fri, 14 Sep 2007 09:18:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.91.2/4272/Fri Sep 14 04:36:36 2007 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I concur. Perhaps before moving into the "postal" realm, the work of the OASIS UBL/CIQ technical committee and the xNAL and xAL standards should be reviewed. Regards Carl ----- Original Message ----- From: "Thomson, Martin" To: "Winterbottom, James" ; "GEOPRIV" Sent: Thursday, September 13, 2007 9:36 PM Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise > I'll just add my voice to the consensus. "civic" is adequate. > > As Henning points out, there probably isn't complete support for postal > addresses in the current set of drafts and RFCs. > > Perhaps someone can write a > how-to-use-revised-civic-to-send-postal-addresses draft, along with a > how-to-get-an-address-label-from-a-revised-civic-form draft. > > Ta, > Martin > >> -----Original Message----- >> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >> Sent: Friday, 14 September 2007 12:23 PM >> To: GEOPRIV >> Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - >> reprise >> >> >> Mary, >> >> I don't see a need for postal and jurisdictional civic in the location >> request. One of the messiest bits of code in the open source LIS is >> dealing with a location request that contains civic, postalCivic and >> jurisdictionalCivic. >> >> I am for limiting this to simply civic. >> >> Cheers >> James >> -------------------------------------------------------------------------- >> ---------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> -------------------------------------------------------------------------- >> ---------------------- >> [mf2] >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > -------------------------------------------------------------------------------- > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 13:34:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWF3b-0007K2-VI; Fri, 14 Sep 2007 13:34:19 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWF3b-0007Ju-B5 for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 13:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWF3a-0007Jk-U0 for geopriv@ietf.org; Fri, 14 Sep 2007 13:34:18 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWF3Z-0004DC-ME for geopriv@ietf.org; Fri, 14 Sep 2007 13:34:18 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IWF3l-00082s-MS for geopriv@ietf.org; Fri, 14 Sep 2007 12:34:30 -0500 From: "Brian Rosen" To: "'GEOPRIV'" Date: Fri, 14 Sep 2007 13:34:13 -0400 Message-ID: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf29XcnR6/t9UtaRtGTcmUust7M1Q== 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Geopriv] HELD and persistent TLS connections in emergency calls X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org One of the uses for HELD is for an end device to obtain its location. The recommendations in ecrit-phonebcp say that the end device should get its location when it boots, periodically thereafter, and as it makes an emergency call. The time to complete the operation doesn't matter in the first two cases, but does at call time. Location sent by value should be protected from eavesdropping. TLS is of course the mechanism of choice for HELD. Unless we change our position, we've stated that the security of the reference is the same as the value. That means getting a reference doesn't help; you would want to protect the transfer of the reference with TLS. What should the recommendation be for the TLS connection between the endpoint and the HELD server? Seems like we have two bad choices: 1. The endpoint maintains a persistent TLS connection. This seems impossible for a LIS to maintain, and wasteful for the device 2. We incur very long time to establish the TLS session at call time. I think this is currently something in the 1/2 second or more range for a typical phone like embedded controller, sometimes much more. That is WAY too long for emergency call, where we're attempting to keep call set up in the 2 seconds from dial to ring. I don't have an answer here. We don't use TLS with the other LCPs; we have other mechanisms that protect the privacy to various degrees. TLS is an excellent mechanism for this purpose. I just don't know how to deal with the setup time. Brian _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 13:54:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFNI-0004lC-Vd; Fri, 14 Sep 2007 13:54:40 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWFNH-0004ks-Pn for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 13:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFNH-0004kj-Fg for geopriv@ietf.org; Fri, 14 Sep 2007 13:54:39 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWFNG-0004rR-AL for geopriv@ietf.org; Fri, 14 Sep 2007 13:54:39 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8EHsNR1018536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Sep 2007 13:54:23 -0400 (EDT) In-Reply-To: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Fri, 14 Sep 2007 13:54:36 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org There are well-known ways to reduce the cost of TLS establishment. I think this is called session resumption, but I'm not a TLS expert. The cost on the device for maintaining a TLS session is essentially zero, since no packets are exchanged while idle and devices are unlikely to hold more than a handful of connections. I would not rule out maintaining TLS connections; this is mainly a memory issue. We're doing measurements on SIP scaling, with hundreds of thousands of open (TCP) connections on a single server. Henning On Sep 14, 2007, at 1:34 PM, Brian Rosen wrote: > One of the uses for HELD is for an end device to obtain its > location. The > recommendations in ecrit-phonebcp say that the end device should > get its > location when it boots, periodically thereafter, and as it makes an > emergency call. The time to complete the operation doesn't matter > in the > first two cases, but does at call time. > > Location sent by value should be protected from eavesdropping. TLS > is of > course the mechanism of choice for HELD. Unless we change our > position, > we've stated that the security of the reference is the same as the > value. > That means getting a reference doesn't help; you would want to > protect the > transfer of the reference with TLS. > > What should the recommendation be for the TLS connection between the > endpoint and the HELD server? Seems like we have two bad choices: > 1. The endpoint maintains a persistent TLS connection. This seems > impossible for a LIS to maintain, and wasteful for the device > 2. We incur very long time to establish the TLS session at call > time. I > think this is currently something in the 1/2 second or more range > for a > typical phone like embedded controller, sometimes much more. That > is WAY > too long for emergency call, where we're attempting to keep call > set up in > the 2 seconds from dial to ring. > > > I don't have an answer here. We don't use TLS with the other LCPs; > we have > other mechanisms that protect the privacy to various degrees. TLS > is an > excellent mechanism for this purpose. I just don't know how to > deal with > the setup time. > > Brian > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 14:11:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFd8-0003Tu-Ny; Fri, 14 Sep 2007 14:11:02 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWFd8-0003Tm-0j for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 14:11:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFd7-0003Td-Li for geopriv@ietf.org; Fri, 14 Sep 2007 14:11:01 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWFd7-0007Ko-5N for geopriv@ietf.org; Fri, 14 Sep 2007 14:11:01 -0400 X-IronPort-AV: E=Sophos;i="4.20,256,1186383600"; d="scan'208";a="10101015" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 14 Sep 2007 11:11:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8EIB04K029445; Fri, 14 Sep 2007 11:11:00 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8EIB0uD026338; Fri, 14 Sep 2007 18:11:00 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 11:11:00 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.113.186]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 11:10:59 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Sep 2007 13:10:59 -0500 To: Henning Schulzrinne , Brian Rosen From: "James M. Polk" Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls In-Reply-To: <5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> <5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 14 Sep 2007 18:10:59.0918 (UTC) FILETIME=[9A96CEE0:01C7F6FA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2831; t=1189793460; x=1190657460; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Geopriv]=20HELD=20and=20persistent=20TLS=20connectio ns=20in=20emergency=0A=20=20calls |Sender:=20; bh=xi5k7CorL1ybMRi5Fm/Y0rv2Lc9afPoXkD+RN4cEcVs=; b=JfZxD1O2b0qOz0W+suhEd60zRRLVnmVMyJm8VyOe5LeCM6SyMT9r3glrc3A+eycG0CIRFRUo v0Aoi5XFKKYJzDF4LLB5lxg0kDcQ5fi5vgT83/3z8qaqvGijtZnSZtl9; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org There needs to be a way for a mobile endpoint to end a persistent TLS session when it moves to another LIS, if that happens - otherwise a LIS is going to have a bunch of sessions with no other end to communicate with, right? At 12:54 PM 9/14/2007, Henning Schulzrinne wrote: >There are well-known ways to reduce the cost of TLS establishment. I >think this is called session resumption, but I'm not a TLS expert. > >The cost on the device for maintaining a TLS session is essentially >zero, since no packets are exchanged while idle and devices are >unlikely to hold more than a handful of connections. > >I would not rule out maintaining TLS connections; this is mainly a >memory issue. We're doing measurements on SIP scaling, with hundreds >of thousands of open (TCP) connections on a single server. > >Henning > >On Sep 14, 2007, at 1:34 PM, Brian Rosen wrote: > >>One of the uses for HELD is for an end device to obtain its >>location. The >>recommendations in ecrit-phonebcp say that the end device should >>get its >>location when it boots, periodically thereafter, and as it makes an >>emergency call. The time to complete the operation doesn't matter >>in the >>first two cases, but does at call time. >> >>Location sent by value should be protected from eavesdropping. TLS >>is of >>course the mechanism of choice for HELD. Unless we change our >>position, >>we've stated that the security of the reference is the same as the >>value. >>That means getting a reference doesn't help; you would want to >>protect the >>transfer of the reference with TLS. >> >>What should the recommendation be for the TLS connection between the >>endpoint and the HELD server? Seems like we have two bad choices: >>1. The endpoint maintains a persistent TLS connection. This seems >>impossible for a LIS to maintain, and wasteful for the device >>2. We incur very long time to establish the TLS session at call >>time. I >>think this is currently something in the 1/2 second or more range >>for a >>typical phone like embedded controller, sometimes much more. That >>is WAY >>too long for emergency call, where we're attempting to keep call >>set up in >>the 2 seconds from dial to ring. >> >> >>I don't have an answer here. We don't use TLS with the other LCPs; >>we have >>other mechanisms that protect the privacy to various degrees. TLS >>is an >>excellent mechanism for this purpose. I just don't know how to >>deal with >>the setup time. >> >>Brian >> >> >> >>_______________________________________________ >>Geopriv mailing list >>Geopriv@ietf.org >>https://www1.ietf.org/mailman/listinfo/geopriv > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 14:23:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFos-0007LV-GE; Fri, 14 Sep 2007 14:23:10 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWFoq-0007AU-NK for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 14:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFoq-00077v-Bt for geopriv@ietf.org; Fri, 14 Sep 2007 14:23:08 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWFop-0006A3-29 for geopriv@ietf.org; Fri, 14 Sep 2007 14:23:08 -0400 Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.184607270; Fri, 14 Sep 2007 14:22:46 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 14 Sep 2007 14:22:46 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 14 Sep 2007 14:22:45 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Fri, 14 Sep 2007 14:22:44 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05A7F3AD@crexc41p> In-Reply-To: <5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] HELD and persistent TLS connections in emergency calls thread-index: Acf2+G9GCqZrsy8mTfW4gtmhqjay9QAArd/Q References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> <5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> From: "Stark, Barbara" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 14 Sep 2007 18:22:45.0833 (UTC) FILETIME=[3F58E390:01C7F6FC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I strongly suspect that LIS operators would balk at the idea of maintaining persistent TLS connections for this. The threat of potential attack within a tightly controlled access network has not been proven to be sufficiently probable to warrant the added expense. Possible, yes. But there is nothing to show that it's probable. I think it's more likely that someone gets a Trojan on their device that captures the location and sends it out, than it is likely that the device to LIS communication is sniffed. Barbara -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Friday, September 14, 2007 1:55 PM To: Brian Rosen Cc: 'GEOPRIV' Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls There are well-known ways to reduce the cost of TLS establishment. I =20 think this is called session resumption, but I'm not a TLS expert. The cost on the device for maintaining a TLS session is essentially =20 zero, since no packets are exchanged while idle and devices are =20 unlikely to hold more than a handful of connections. I would not rule out maintaining TLS connections; this is mainly a =20 memory issue. We're doing measurements on SIP scaling, with hundreds =20 of thousands of open (TCP) connections on a single server. Henning On Sep 14, 2007, at 1:34 PM, Brian Rosen wrote: > One of the uses for HELD is for an end device to obtain its =20 > location. The > recommendations in ecrit-phonebcp say that the end device should =20 > get its > location when it boots, periodically thereafter, and as it makes an > emergency call. The time to complete the operation doesn't matter =20 > in the > first two cases, but does at call time. > > Location sent by value should be protected from eavesdropping. TLS =20 > is of > course the mechanism of choice for HELD. Unless we change our =20 > position, > we've stated that the security of the reference is the same as the =20 > value. > That means getting a reference doesn't help; you would want to =20 > protect the > transfer of the reference with TLS. > > What should the recommendation be for the TLS connection between the > endpoint and the HELD server? Seems like we have two bad choices: > 1. The endpoint maintains a persistent TLS connection. This seems > impossible for a LIS to maintain, and wasteful for the device > 2. We incur very long time to establish the TLS session at call =20 > time. I > think this is currently something in the 1/2 second or more range =20 > for a > typical phone like embedded controller, sometimes much more. That =20 > is WAY > too long for emergency call, where we're attempting to keep call =20 > set up in > the 2 seconds from dial to ring. > > > I don't have an answer here. We don't use TLS with the other LCPs; =20 > we have > other mechanisms that protect the privacy to various degrees. TLS =20 > is an > excellent mechanism for this purpose. I just don't know how to =20 > deal with > the setup time. > > Brian > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 15:14:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWGcV-0000ef-Mq; Fri, 14 Sep 2007 15:14:27 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWGcT-0000eO-Os for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 15:14:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWGcT-0000eF-E7 for geopriv@ietf.org; Fri, 14 Sep 2007 15:14:25 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWGcS-0007Y0-8f for geopriv@ietf.org; Fri, 14 Sep 2007 15:14:25 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IWGcP-0001vS-5i; Fri, 14 Sep 2007 15:14:21 -0400 Message-ID: <46EADD81.40906@bbn.com> Date: Fri, 14 Sep 2007 15:14:09 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> In-Reply-To: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Brian, First, I agree with Henning that RFC 4507 (TLS session resumption without server-side state) is an appropriate mechanism to use in acquiring location from a HELD server for use in an emergency call. (The session resumption mechanism allows a client to keep state which it can use to re-establish a session to the same server without doing a full TLS handshake.) However, I imagine that Barbara is correct that in some deployment scenarios operators will decide that the risk of eavesdropping on the connection from device to HELD server is not large enough to justify the use of TLS. Nonetheless, it is surely appropriate for ecrit-phonebcp to recommend the use of TLS (with RFC 4507 session resumption). Second, with regard to the following comment: Brian Rosen wrote: >Location sent by value should be protected from eavesdropping. TLS is of >course the mechanism of choice for HELD. Unless we change our position, >we've stated that the security of the reference is the same as the value. >That means getting a reference doesn't help; you would want to protect the >transfer of the reference with TLS. > > I assume that "we" in this case means Ecrit and not Geopriv. The current version of the Geopriv location-by-reference document indicates that a deference mechanism MUST support authentication upon de-reference. This seems appropriate because, in general, the location server may need to know the identity of the party doing the deference in order to properly apply the privacy rules. I understand that in the context of emergency calls that there may be public safety concerns that necessitate unauthenticated deference, but surely this is not true in general. - Matt Lepinski :-> _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 15:23:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWGlT-0007g7-O4; Fri, 14 Sep 2007 15:23:43 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWGlS-0007g1-5c for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 15:23:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWGlR-0007fs-Rg for geopriv@ietf.org; Fri, 14 Sep 2007 15:23:41 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWGlQ-0008Rv-LP for geopriv@ietf.org; Fri, 14 Sep 2007 15:23:41 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IWGlb-00029T-Mn; Fri, 14 Sep 2007 14:23:51 -0500 From: "Brian Rosen" To: "'Matt Lepinski'" References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> <46EADD81.40906@bbn.com> Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Fri, 14 Sep 2007 15:23:36 -0400 Message-ID: <0a9b01c7f704$c1149570$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf3A4V+wuriIv0ZQvWbwFNygcgDyAAAJFCw In-Reply-To: <46EADD81.40906@bbn.com> 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Matt Since the target of a reference doesn't know what kind of credentials the LIS will require, and has no way to control that, I think in Geopriv, we would have to say that the reference must be treated with the same security considerations as the value. Brian > -----Original Message----- > From: Matt Lepinski [mailto:mlepinski@bbn.com] > Sent: Friday, September 14, 2007 3:14 PM > To: Brian Rosen > Cc: 'GEOPRIV' > Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency > calls > > Brian, > > First, I agree with Henning that RFC 4507 (TLS session resumption > without server-side state) is an appropriate mechanism to use in > acquiring location from a HELD server for use in an emergency call. (The > session resumption mechanism allows a client to keep state which it can > use to re-establish a session to the same server without doing a full > TLS handshake.) However, I imagine that Barbara is correct that in some > deployment scenarios operators will decide that the risk of > eavesdropping on the connection from device to HELD server is not large > enough to justify the use of TLS. Nonetheless, it is surely appropriate > for ecrit-phonebcp to recommend the use of TLS (with RFC 4507 session > resumption). > > Second, with regard to the following comment: > > Brian Rosen wrote: > > >Location sent by value should be protected from eavesdropping. TLS is of > >course the mechanism of choice for HELD. Unless we change our position, > >we've stated that the security of the reference is the same as the value. > >That means getting a reference doesn't help; you would want to protect > the > >transfer of the reference with TLS. > > > > > I assume that "we" in this case means Ecrit and not Geopriv. The current > version of the Geopriv location-by-reference document indicates that a > deference mechanism MUST support authentication upon de-reference. This > seems appropriate because, in general, the location server may need to > know the identity of the party doing the deference in order to properly > apply the privacy rules. I understand that in the context of emergency > calls that there may be public safety concerns that necessitate > unauthenticated deference, but surely this is not true in general. > > - Matt Lepinski :-> _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 15:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWGpD-0000AY-HF; Fri, 14 Sep 2007 15:27:35 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWGpB-0000AB-LK for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 15:27:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWGpB-0000A3-BP for geopriv@ietf.org; Fri, 14 Sep 2007 15:27:33 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWGpA-00005h-4P for geopriv@ietf.org; Fri, 14 Sep 2007 15:27:33 -0400 X-IronPort-AV: E=Sophos;i="4.20,256,1186383600"; d="scan'208";a="218352931" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Sep 2007 12:27:31 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8EJRVnY006396; Fri, 14 Sep 2007 12:27:31 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l8EJRUW0002430; Fri, 14 Sep 2007 19:27:31 GMT In-Reply-To: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Fri, 14 Sep 2007 12:25:57 -0700 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3702; t=1189798051; x=1190662051; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Geopriv]=20HELD=20and=20persistent=20TLS=20connectio ns=20in=20emergency=20calls |Sender:=20; bh=GKCX4ae2fUlmsC1gRIrL2t95//fQqmVuXS/xZoZiMfs=; b=WCYzm4wsWW5/zvpQGttOjou30OO0dJE7ZZ8Y8Pf00RQjI0snx0Ygtp83xxRlim5LIO4IDI8s PxE6VxQ6RxsuaUefa3KtbkisMQDzaaNMAcxsNkr6YHZJnCU73tTYsVLO; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Few random thoughts.... Certainly session resumption might work well here - basically when the device connected the first time it would do the public key operation to set up session once then save a secret that could be used for future sessions without doing the expensive public key operations. There are extensions to allow session resumption to only store state on the client not server - RFC 4507 and soon to be approved update to it. It would be well worth having a look at the session resumption stuff and seeing how to specify it's usage - it is implemented in many TLS stacks including OpenSSL. I also think it would be worth looking at what the time to set up a TLS session is. The first thing would be to look at what size keys should the server use - some recommendation for key size specific to LIS might help keep people from using things way too large. The information transfered over HELD is unlikely to have high long term value and that might change the key sizes chosen. It would then be good to guess what the processors might be on the very low end stuff by the time any of this actually gets deployed. My gut feeling is 1/2 second does not sound quite right. Whatever the answer is, it would be nice to see this analysis. I can also imagine that in some cases getting a reference might help in that the host that eventually fetched the reference might have a much faster processor than a low end mobile phone. Cullen PS - I simultaneously agree with Henning that it might be possible to use long lived TLS connection while agreeing with Barbara that regardless of the feasibility, operators will hate the idea. Hows that for being on the fence :-) But I hope we can avoid having to do this approach. On Sep 14, 2007, at 10:34 AM, Brian Rosen wrote: > One of the uses for HELD is for an end device to obtain its > location. The > recommendations in ecrit-phonebcp say that the end device should > get its > location when it boots, periodically thereafter, and as it makes an > emergency call. The time to complete the operation doesn't matter > in the > first two cases, but does at call time. > > Location sent by value should be protected from eavesdropping. TLS > is of > course the mechanism of choice for HELD. Unless we change our > position, > we've stated that the security of the reference is the same as the > value. > That means getting a reference doesn't help; you would want to > protect the > transfer of the reference with TLS. > > What should the recommendation be for the TLS connection between the > endpoint and the HELD server? Seems like we have two bad choices: > 1. The endpoint maintains a persistent TLS connection. This seems > impossible for a LIS to maintain, and wasteful for the device > 2. We incur very long time to establish the TLS session at call > time. I > think this is currently something in the 1/2 second or more range > for a > typical phone like embedded controller, sometimes much more. That > is WAY > too long for emergency call, where we're attempting to keep call > set up in > the 2 seconds from dial to ring. > > > I don't have an answer here. We don't use TLS with the other LCPs; > we have > other mechanisms that protect the privacy to various degrees. TLS > is an > excellent mechanism for this purpose. I just don't know how to > deal with > the setup time. > > Brian > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 17:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWIkA-0004j8-EE; Fri, 14 Sep 2007 17:30:30 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWIk9-0004j3-UD for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 17:30:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWIk9-0004iu-ID for geopriv@ietf.org; Fri, 14 Sep 2007 17:30:29 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWIk8-0005tx-SK for geopriv@ietf.org; Fri, 14 Sep 2007 17:30:29 -0400 X-SEF-Processed: 5_0_0_910__2007_09_14_16_39_50 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 14 Sep 2007 16:39:50 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Sep 2007 16:30:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Fri, 14 Sep 2007 16:30:22 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] HELD and persistent TLS connections in emergency calls Thread-Index: Acf2+qddgNp6gA+oSnOjwHdHi3sxKQAG6f6A References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com><5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> From: "Winterbottom, James" To: "James M. Polk" , "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 14 Sep 2007 21:30:24.0248 (UTC) FILETIME=[75E2AF80:01C7F716] X-Spam-Score: 1.8 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org This is possible James, but it does depend a lot on how you configure=0D=0A= LIS and what kinds of network you are in. If the LIS can get information=0D= =0Aabout a device leaving the network then the problem is fairly much=0D=0A= resolved.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message--= ---=0D=0A> From: James M. Polk [mailto:jmpolk@cisco.com]=0D=0A> Sent: Satur= day, 15 September 2007 4:11 AM=0D=0A> To: Henning Schulzrinne; Brian Rosen=0D= =0A> Cc: 'GEOPRIV'=0D=0A> Subject: Re: [Geopriv] HELD and persistent TLS co= nnections in=0D=0Aemergency=0D=0A> calls=0D=0A>=20=0D=0A> There needs to be= a way for a mobile endpoint to end a persistent TLS=0D=0A> session when it= moves to another LIS, if that happens - otherwise a=0D=0A> LIS is going to= have a bunch of sessions with no other end to=0D=0A> communicate with, rig= ht=3F=0D=0A>=20=0D=0A> At 12:54 PM 9/14/2007, Henning Schulzrinne wrote:=0D= =0A> >There are well-known ways to reduce the cost of TLS establishment. I=0D= =0A> >think this is called session resumption, but I'm not a TLS expert.=0D= =0A> >=0D=0A> >The cost on the device for maintaining a TLS session is esse= ntially=0D=0A> >zero, since no packets are exchanged while idle and devices= are=0D=0A> >unlikely to hold more than a handful of connections.=0D=0A> >=0D= =0A> >I would not rule out maintaining TLS connections; this is mainly a=0D= =0A> >memory issue. We're doing measurements on SIP scaling, with hundreds=0D= =0A> >of thousands of open (TCP) connections on a single server.=0D=0A> >=0D= =0A> >Henning=0D=0A> >=0D=0A> >On Sep 14, 2007, at 1:34 PM, Brian Rosen wro= te:=0D=0A> >=0D=0A> >>One of the uses for HELD is for an end device to obta= in its=0D=0A> >>location. The=0D=0A> >>recommendations in ecrit-phonebcp s= ay that the end device should=0D=0A> >>get its=0D=0A> >>location when it bo= ots, periodically thereafter, and as it makes an=0D=0A> >>emergency call. = The time to complete the operation doesn't matter=0D=0A> >>in the=0D=0A> >>= first two cases, but does at call time.=0D=0A> >>=0D=0A> >>Location sent by= value should be protected from eavesdropping. TLS=0D=0A> >>is of=0D=0A> >= >course the mechanism of choice for HELD. Unless we change our=0D=0A> >>pos= ition,=0D=0A> >>we've stated that the security of the reference is the same= as the=0D=0A> >>value.=0D=0A> >>That means getting a reference doesn't hel= p; you would want to=0D=0A> >>protect the=0D=0A> >>transfer of the referenc= e with TLS.=0D=0A> >>=0D=0A> >>What should the recommendation be for the TL= S connection between the=0D=0A> >>endpoint and the HELD server=3F Seems li= ke we have two bad choices:=0D=0A> >>1. The endpoint maintains a persistent= TLS connection. This seems=0D=0A> >>impossible for a LIS to maintain, and= wasteful for the device=0D=0A> >>2. We incur very long time to establish t= he TLS session at call=0D=0A> >>time. I=0D=0A> >>think this is currently s= omething in the 1/2 second or more range=0D=0A> >>for a=0D=0A> >>typical ph= one like embedded controller, sometimes much more. That=0D=0A> >>is WAY=0D= =0A> >>too long for emergency call, where we're attempting to keep call=0D=0A= > >>set up in=0D=0A> >>the 2 seconds from dial to ring.=0D=0A> >>=0D=0A> >>=0D= =0A> >>I don't have an answer here. We don't use TLS with the other LCPs;=0D= =0A> >>we have=0D=0A> >>other mechanisms that protect the privacy to variou= s degrees. TLS=0D=0A> >>is an=0D=0A> >>excellent mechanism for this purpos= e. I just don't know how to=0D=0A> >>deal with=0D=0A> >>the setup time.=0D= =0A> >>=0D=0A> >>Brian=0D=0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >>_____________= __________________________________=0D=0A> >>Geopriv mailing list=0D=0A> >>G= eopriv@ietf.org=0D=0A> >>https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A= > >=0D=0A> >=0D=0A> >=0D=0A> >_____________________________________________= __=0D=0A> >Geopriv mailing list=0D=0A> >Geopriv@ietf.org=0D=0A> >https://ww= w1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A>=20=0D=0A> ___________= ____________________________________=0D=0A> Geopriv mailing list=0D=0A> Geo= priv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 17:57:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJAT-0003H5-DL; Fri, 14 Sep 2007 17:57:41 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWJAR-00035n-L4 for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 17:57:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJAR-00034l-AK for geopriv@ietf.org; Fri, 14 Sep 2007 17:57:39 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWJAR-0006ll-16 for geopriv@ietf.org; Fri, 14 Sep 2007 17:57:39 -0400 Received: from [10.2.2.94] ([65.124.181.3]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8ELvTwv008094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Sep 2007 17:57:29 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7F3AD@crexc41p> References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> <5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA05A7F3AD@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <517DB3EE-F714-46F9-967E-E7EDAF5B0521@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Fri, 14 Sep 2007 17:57:25 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org This may be (barely) true for DSL, but is probably not a safe assumption for 802.11. On the other hand, 802.11 location isn't all that interesting unless there's triangulation, since everybody will get the same (obvious) location of the AP. On Sep 14, 2007, at 2:22 PM, Stark, Barbara wrote: > I strongly suspect that LIS operators would balk at the idea of > maintaining persistent TLS connections for this. The threat of > potential > attack within a tightly controlled access network has not been > proven to > be sufficiently probable to warrant the added expense. Possible, yes. > But there is nothing to show that it's probable. I think it's more > likely that someone gets a Trojan on their device that captures the > location and sends it out, than it is likely that the device to LIS > communication is sniffed. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 18:16:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJSv-0007On-VC; Fri, 14 Sep 2007 18:16:45 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWJSv-0007Oe-5i for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 18:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJSu-0007OV-SE for geopriv@ietf.org; Fri, 14 Sep 2007 18:16:44 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWJSt-0005G4-EU for geopriv@ietf.org; Fri, 14 Sep 2007 18:16:44 -0400 X-SEF-Processed: 5_0_0_910__2007_09_14_17_25_47 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 14 Sep 2007 17:25:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Sep 2007 17:16:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Fri, 14 Sep 2007 17:16:19 -0500 Message-ID: In-Reply-To: <517DB3EE-F714-46F9-967E-E7EDAF5B0521@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] HELD and persistent TLS connections in emergency calls Thread-Index: Acf3GkfUfxQKqTalS4ea/CRAo5p33gAAjwNg References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com><5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA05A7F3AD@crexc41p> <517DB3EE-F714-46F9-967E-E7EDAF5B0521@cs.columbia.edu> From: "Winterbottom, James" To: "Henning Schulzrinne" , "Stark, Barbara" X-OriginalArrivalTime: 14 Sep 2007 22:16:21.0476 (UTC) FILETIME=[E1524A40:01C7F71C] X-Spam-Score: 1.8 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org It is unclear to me at least why we are so worried about the potential=0D=0A= 500ms to get setup the location session, when there are at least 2 other=0D= =0ATLS SIP sessions to be established, plus a LoST connection from the=0D=0A= call-server to check the authenticity of the destination as well.=0D=0A=0D=0A= This seems somewhat moot since without valid location you are either not=0D= =0Agoing route at all, or you are going to misroute.=0D=0A=0D=0A> -----Orig= inal Message-----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs.columbia.= edu]=0D=0A> Sent: Saturday, 15 September 2007 7:57 AM=0D=0A> To: Stark, Bar= bara=0D=0A> Cc: GEOPRIV=0D=0A> Subject: Re: [Geopriv] HELD and persistent T= LS connections in=0D=0Aemergency=0D=0A> calls=0D=0A>=20=0D=0A> This may be = (barely) true for DSL, but is probably not a safe=0D=0A> assumption for 802= =2E11. On the other hand, 802.11 location isn't all=0D=0A> that interesting= unless there's triangulation, since everybody will=0D=0A> get the same (ob= vious) location of the AP.=0D=0A>=20=0D=0A> On Sep 14, 2007, at 2:22 PM, St= ark, Barbara wrote:=0D=0A>=20=0D=0A> > I strongly suspect that LIS operator= s would balk at the idea of=0D=0A> > maintaining persistent TLS connections= for this. The threat of=0D=0A> > potential=0D=0A> > attack within a tightl= y controlled access network has not been=0D=0A> > proven to=0D=0A> > be suf= ficiently probable to warrant the added expense. Possible,=0D=0Ayes.=0D=0A>= > But there is nothing to show that it's probable. I think it's more=0D=0A= > > likely that someone gets a Trojan on their device that captures the=0D=0A= > > location and sends it out, than it is likely that the device to LIS=0D=0A= > > communication is sniffed.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> ________= _______________________________________=0D=0A> Geopriv mailing list=0D=0A> = Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 14 18:23:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJZb-0004q8-9U; Fri, 14 Sep 2007 18:23:39 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWJZZ-0004pz-Dn for geopriv-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 18:23:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJZZ-0004pq-2X for geopriv@ietf.org; Fri, 14 Sep 2007 18:23:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWJZY-0007pV-Lo for geopriv@ietf.org; Fri, 14 Sep 2007 18:23:36 -0400 X-IronPort-AV: E=Sophos;i="4.20,257,1186383600"; d="scan'208";a="218446253" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Sep 2007 15:23:36 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8EMNaaE016426; Fri, 14 Sep 2007 15:23:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l8EMNUeB025373; Fri, 14 Sep 2007 22:23:35 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 15:23:30 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.113.186]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 15:23:29 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Sep 2007 17:23:26 -0500 To: Henning Schulzrinne , "Stark, Barbara" From: "James M. Polk" Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls In-Reply-To: <517DB3EE-F714-46F9-967E-E7EDAF5B0521@cs.columbia.edu> References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> <5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA05A7F3AD@crexc41p> <517DB3EE-F714-46F9-967E-E7EDAF5B0521@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 14 Sep 2007 22:23:29.0972 (UTC) FILETIME=[E0B99740:01C7F71D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1394; t=1189808616; x=1190672616; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Geopriv]=20HELD=20and=20persistent=20TLS=20connectio ns=20in=20emergency=0A=20=20calls |Sender:=20; bh=zUQV1s9bLeRbWctjHJhR4eAJjvEH8wHa6B3wAhvXfLw=; b=ZxRxE47l9YpDqCy+VlHreNw3esS3Xnl0fGTKEaO/GUD0Ox+K9efXuQRQsx3tJw2IaezxxAxf wJnHVroLCePs8Q8PkSgPgxRsGbFglGKYmGQVvMgPW7CbOB4qDOcH13C1; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Henning - .11 triangulation is farther along that you are eluding to, and will not be a rare observation, at least in public places. Home networks with only a single antenna won't use triangulation, but there are other means being worked on to know what distance and vector an endpoint is at (with respect to where the single AP is). At 04:57 PM 9/14/2007, Henning Schulzrinne wrote: >This may be (barely) true for DSL, but is probably not a safe >assumption for 802.11. On the other hand, 802.11 location isn't all >that interesting unless there's triangulation, since everybody will >get the same (obvious) location of the AP. > >On Sep 14, 2007, at 2:22 PM, Stark, Barbara wrote: > >>I strongly suspect that LIS operators would balk at the idea of >>maintaining persistent TLS connections for this. The threat of >>potential >>attack within a tightly controlled access network has not been >>proven to >>be sufficiently probable to warrant the added expense. Possible, yes. >>But there is nothing to show that it's probable. I think it's more >>likely that someone gets a Trojan on their device that captures the >>location and sends it out, than it is likely that the device to LIS >>communication is sniffed. > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From vhester@blackbox.net Sat Sep 15 03:10:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWRnN-0001wc-90 for geopriv-archive@lists.ietf.org; Sat, 15 Sep 2007 03:10:25 -0400 Received: from [218.149.152.167] (helo=Network-Tools.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWRnM-0001M6-On for geopriv-archive@lists.ietf.org; Sat, 15 Sep 2007 03:10:25 -0400 Message-ID: <822001c13db4$067fff05$47c85467@blackbox.net> From: No Problem To: geopriv-archive@lists.ietf.org Subject: When you need erection... Date: Sat, 15 Sep 2001 07:09:27 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_A481E719.55D7861D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c This is a multi-part message in MIME format. ------=_NextPart_000_0000_A481E719.55D7861D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Why should you try Viagra? Why Viagra? ...because that look she gives is only meant for you... because an empty nest is the chance to fall in love all over again... because reading the Sunday paper doesnt take all day. If you have ED, youve already got plenty of reasons to choose Viagra, but here are some more that you should know about. Learn more / order Viagra online! ------=_NextPart_000_0000_A481E719.55D7861D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Why should you try = Viagra?

Why Viagra? ...because that look she gives is = only meant for you...
because an empty nest is the chance to fall = in love all over again...
because reading the Sunday paper = doesn’t take all day.

If you have ED, you’ve already got plenty = of reasons to choose Viagra,
but here are some more that you = should know about.

Learn more / order Viagra = online!

 ------=_NextPart_000_0000_A481E719.55D7861D-- From geopriv-bounces@ietf.org Sat Sep 15 04:27:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWSzm-0004Fx-Va; Sat, 15 Sep 2007 04:27:18 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWSzl-0004AR-Cq for geopriv-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 04:27:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWSzh-00044w-BK for geopriv@ietf.org; Sat, 15 Sep 2007 04:27:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWSzg-0003uq-IW for geopriv@ietf.org; Sat, 15 Sep 2007 04:27:13 -0400 Received: (qmail invoked by alias); 15 Sep 2007 08:27:11 -0000 Received: from p54987CAB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.171] by mail.gmx.net (mp037) with SMTP; 15 Sep 2007 10:27:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18iqI5OCvIiOK97qX6H8LTL7rIFzK1CZTbTc8aYJN CZZzL7y//iD0SO Message-ID: <46EB975F.2010408@gmx.net> Date: Sat, 15 Sep 2007 10:27:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> In-Reply-To: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Brian, I agree that this is a challenging question. I believe for a cellular access network it is challenging to periodically fetch location information (given that you may only have an emergency call once in your lifetime) and to keep a TCP connection up and running all the time. Ciao Hannes Brian Rosen wrote: > One of the uses for HELD is for an end device to obtain its location. The > recommendations in ecrit-phonebcp say that the end device should get its > location when it boots, periodically thereafter, and as it makes an > emergency call. The time to complete the operation doesn't matter in the > first two cases, but does at call time. > > Location sent by value should be protected from eavesdropping. TLS is of > course the mechanism of choice for HELD. Unless we change our position, > we've stated that the security of the reference is the same as the value. > That means getting a reference doesn't help; you would want to protect the > transfer of the reference with TLS. > > What should the recommendation be for the TLS connection between the > endpoint and the HELD server? Seems like we have two bad choices: > 1. The endpoint maintains a persistent TLS connection. This seems > impossible for a LIS to maintain, and wasteful for the device > 2. We incur very long time to establish the TLS session at call time. I > think this is currently something in the 1/2 second or more range for a > typical phone like embedded controller, sometimes much more. That is WAY > too long for emergency call, where we're attempting to keep call set up in > the 2 seconds from dial to ring. > > > I don't have an answer here. We don't use TLS with the other LCPs; we have > other mechanisms that protect the privacy to various degrees. TLS is an > excellent mechanism for this purpose. I just don't know how to deal with > the setup time. > > Brian > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 15 04:38:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTAd-00071d-C3; Sat, 15 Sep 2007 04:38:31 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWTAc-00071S-8d for geopriv-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 04:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTAb-00071I-V0 for geopriv@ietf.org; Sat, 15 Sep 2007 04:38:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWTAa-0008Tv-D8 for geopriv@ietf.org; Sat, 15 Sep 2007 04:38:29 -0400 Received: (qmail invoked by alias); 15 Sep 2007 08:38:26 -0000 Received: from p54987CAB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.171] by mail.gmx.net (mp026) with SMTP; 15 Sep 2007 10:38:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+rn5ksSYOrAxGJKOrTcbqdXGW1vkLRRzbwyRB9Bi xWaCanuRKGThOS Message-ID: <46EB9A02.5040901@gmx.net> Date: Sat, 15 Sep 2007 10:38:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> <5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'GEOPRIV' , Henning Schulzrinne X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Henning, > At 12:54 PM 9/14/2007, Henning Schulzrinne wrote: >> There are well-known ways to reduce the cost of TLS establishment. I >> think this is called session resumption, but I'm not a TLS expert. >> This entirely correct. TLS session resumption would certainly help in this case. For the performance read here: http://pages.cs.wisc.edu/~cao/WISP98/final-versions/artg.ps (I am sure that there are better and more recent papers but I have to search a bit...) Even better, there is also http://tools.ietf.org/html/rfc4507 "Transport Layer Security (TLS) Session Resumption without Server-Side State" that provides session resumption without keeping state at the server. Performance data can be found here: http://crypto.stanford.edu/~dabo/abstracts/fasttrack.html Maybe that's something we should consider for HELD to provide a scalable and lightweight solution Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 15 05:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTW5-000217-MJ; Sat, 15 Sep 2007 05:00:41 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWTW3-000210-6C for geopriv-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 05:00:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTW2-00020s-F0 for geopriv@ietf.org; Sat, 15 Sep 2007 05:00:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWTW1-0004l5-Eh for geopriv@ietf.org; Sat, 15 Sep 2007 05:00:38 -0400 Received: (qmail invoked by alias); 15 Sep 2007 09:00:35 -0000 Received: from p54987CAB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.171] by mail.gmx.net (mp031) with SMTP; 15 Sep 2007 11:00:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19sLGIU7ipsEJAX/TgKt8SqwQjdkPx2WW0qq/5xMQ Fp/OnPO3cUV9Q/ Message-ID: <46EB9F34.9010802@gmx.net> Date: Sat, 15 Sep 2007 11:00:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Cullen, Cullen Jennings wrote: > > Few random thoughts.... > > Certainly session resumption might work well here - basically when the > device connected the first time it would do the public key operation > to set up session once then save a secret that could be used for > future sessions without doing the expensive public key operations. > There are extensions to allow session resumption to only store state > on the client not server - RFC 4507 and soon to be approved update to it. Yep; http://www.ietf.org/internet-drafts/draft-salowey-tls-rfc4507bis-01.txt (Document already in *RFC Ed Queue*) > It would be well worth having a look at the session resumption stuff > and seeing how to specify it's usage - it is implemented in many TLS > stacks including OpenSSL. > > I also think it would be worth looking at what the time to set up a > TLS session is. We have done some performance measurements, see http://www.tmg.informatik.uni-goettingen.de/publications/1297/psk_tls_gi2006_final.pdf The analysis did not consider session resumption. However, as one can easily see the key length and the selected mode has an impact on the performance. > The first thing would be to look at what size keys should the server > use - some recommendation for key size specific to LIS might help keep > people from using things way too large. The information transfered > over HELD is unlikely to have high long term value and that might > change the key sizes chosen. It would then be good to guess what the > processors might be on the very low end stuff by the time any of this > actually gets deployed. My gut feeling is 1/2 second does not sound > quite right. Whatever the answer is, it would be nice to see this > analysis. While the above-mentioned study consider "low-end machines" as well it did not focus on mobile phones. Maybe that's something to add. With the low-end servers we have used 1/2 second is certainly not correct. > > I can also imagine that in some cases getting a reference might help > in that the host that eventually fetched the reference might have a > much faster processor than a low end mobile phone. Ciao Hannes > Cullen > > PS - I simultaneously agree with Henning that it might be possible to > use long lived TLS connection while agreeing with Barbara that > regardless of the feasibility, operators will hate the idea. Hows that > for being on the fence :-) But I hope we can avoid having to do this > approach. > > > On Sep 14, 2007, at 10:34 AM, Brian Rosen wrote: > >> One of the uses for HELD is for an end device to obtain its >> location. The >> recommendations in ecrit-phonebcp say that the end device should get its >> location when it boots, periodically thereafter, and as it makes an >> emergency call. The time to complete the operation doesn't matter in >> the >> first two cases, but does at call time. >> >> Location sent by value should be protected from eavesdropping. TLS >> is of >> course the mechanism of choice for HELD. Unless we change our position, >> we've stated that the security of the reference is the same as the >> value. >> That means getting a reference doesn't help; you would want to >> protect the >> transfer of the reference with TLS. >> >> What should the recommendation be for the TLS connection between the >> endpoint and the HELD server? Seems like we have two bad choices: >> 1. The endpoint maintains a persistent TLS connection. This seems >> impossible for a LIS to maintain, and wasteful for the device >> 2. We incur very long time to establish the TLS session at call time. I >> think this is currently something in the 1/2 second or more range for a >> typical phone like embedded controller, sometimes much more. That is >> WAY >> too long for emergency call, where we're attempting to keep call set >> up in >> the 2 seconds from dial to ring. >> >> >> I don't have an answer here. We don't use TLS with the other LCPs; >> we have >> other mechanisms that protect the privacy to various degrees. TLS is an >> excellent mechanism for this purpose. I just don't know how to deal >> with >> the setup time. >> >> Brian >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 15 05:00:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTWI-00025X-Jr; Sat, 15 Sep 2007 05:00:54 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWTWH-00025M-Ce for geopriv-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 05:00:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWTWH-00025C-1w for geopriv@ietf.org; Sat, 15 Sep 2007 05:00:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWTWG-0004lQ-HL for geopriv@ietf.org; Sat, 15 Sep 2007 05:00:52 -0400 Received: (qmail invoked by alias); 15 Sep 2007 09:00:51 -0000 Received: from p54987CAB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.171] by mail.gmx.net (mp057) with SMTP; 15 Sep 2007 11:00:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19H0LpaPvZHGNtnN2XnCs6sOGSqxZxrw1GugsEdp7 Nm2yyLrc3POs7h Message-ID: <46EB9F43.5020203@gmx.net> Date: Sat, 15 Sep 2007 11:00:51 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Matt Lepinski Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> <46EADD81.40906@bbn.com> In-Reply-To: <46EADD81.40906@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Matt, > I assume that "we" in this case means Ecrit and not Geopriv. The > current version of the Geopriv location-by-reference document > indicates that a deference mechanism MUST support authentication upon > de-reference. This seems appropriate because, in general, the location > server may need to know the identity of the party doing the deference > in order to properly apply the privacy rules. I understand that in the > context of emergency calls that there may be public safety concerns > that necessitate unauthenticated deference, but surely this is not > true in general. > The dereferencing protocol is a separate story. I believe that Brian was primarily talking about the exchange between the end host and the LIS to retrieve either an LbyV or an LbyR. Ciao Hannes > - Matt Lepinski :-> > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 15 10:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWYQb-0000OW-E9; Sat, 15 Sep 2007 10:15:21 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWYQa-0000Lz-AC for geopriv-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 10:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWYQZ-0000LR-Vz for geopriv@ietf.org; Sat, 15 Sep 2007 10:15:19 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWYQY-00027e-N1 for geopriv@ietf.org; Sat, 15 Sep 2007 10:15:19 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IWYQo-0004wA-O3; Sat, 15 Sep 2007 09:15:34 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Henning Schulzrinne'" , "'Stark, Barbara'" References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com><5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA05A7F3AD@crexc41p><517DB3EE-F714-46F9-967E-E7EDAF5B0521@cs.columbia.edu> Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Sat, 15 Sep 2007 10:15:12 -0400 Message-ID: <0b7201c7f7a2$d6893f70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf3GkfUfxQKqTalS4ea/CRAo5p33gAAjwNgACFDdeA= In-Reply-To: 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The two other TLS sessions (actually there are more) are endpoint to proxy and proxy to ESRP (the ESRP will have connections to the PSAP and the PSAP to the call taker. The ESRP may have one or more ESRPs in the path to the PSAP). All of those will normally have persistent TLS connections because there will be occasional traffic on all of them. Of course every proxy will not have persistent TLS connections to every ESRP. It will only keep connections to ESRPs it regularly deals with, which I assume would just be experiential based on traffic. The horsepower on the proxy to proxy connections makes the cost of the TLS establishment smaller than on an endpoint. The statistics for call completion time will be fine if this connection caching mechanism works. The LoST connection is somewhat more interesting. I think the TLS resumption mechanism in 4507 (thanks all for the reference, I think that is the answer to the original question) will work here. At one point we were wondering about if we needed the same level of security since there was no identity information in the LoST query, but I think in practice that a query from a random endpoint to LoST could be assumed to be with its own location, and thus probably in need of privacy. That, of course, is an ecrit question, which is why I didn't raise it in the original email. I assumed we would use the same solution. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, September 14, 2007 6:16 PM > To: Henning Schulzrinne; Stark, Barbara > Cc: GEOPRIV > Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency > calls > > It is unclear to me at least why we are so worried about the potential > 500ms to get setup the location session, when there are at least 2 other > TLS SIP sessions to be established, plus a LoST connection from the > call-server to check the authenticity of the destination as well. > > This seems somewhat moot since without valid location you are either not > going route at all, or you are going to misroute. > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Saturday, 15 September 2007 7:57 AM > > To: Stark, Barbara > > Cc: GEOPRIV > > Subject: Re: [Geopriv] HELD and persistent TLS connections in > emergency > > calls > > > > This may be (barely) true for DSL, but is probably not a safe > > assumption for 802.11. On the other hand, 802.11 location isn't all > > that interesting unless there's triangulation, since everybody will > > get the same (obvious) location of the AP. > > > > On Sep 14, 2007, at 2:22 PM, Stark, Barbara wrote: > > > > > I strongly suspect that LIS operators would balk at the idea of > > > maintaining persistent TLS connections for this. The threat of > > > potential > > > attack within a tightly controlled access network has not been > > > proven to > > > be sufficiently probable to warrant the added expense. Possible, > yes. > > > But there is nothing to show that it's probable. I think it's more > > > likely that someone gets a Trojan on their device that captures the > > > location and sends it out, than it is likely that the device to LIS > > > communication is sniffed. > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Hestervfwkr@duabotzb.mailnet.dyndns.biz Sat Sep 15 16:20:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWe88-0006oN-1l for geopriv-archive@lists.ietf.org; Sat, 15 Sep 2007 16:20:40 -0400 Received: from 89-125-86-223.dhcp-ripwave.irishbroadband.ie ([89.125.86.223] helo=acer-318de0055e.dhcp-ripwave.irishbroadband.ie) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWe85-0000Ns-C7 for geopriv-archive@lists.ietf.org; Sat, 15 Sep 2007 16:20:39 -0400 Received: from me ([193.120.132.6] helo=me) by acer-318de0055e.dhcp-ripwave.irishbroadband.ie ( sendmail 8.13.3/8.13.1) with esmtpa id 1KJzhu-000TGF-xA for geopriv-archive@lists.ietf.org; Sat, 15 Sep 2007 21:20:31 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 15 Sep 2007 21:20:18 +0100 To: geopriv-archive@lists.ietf.org From: "Herbert Hester" Subject: suyemats Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Antivirus: avast! (VPS 000774-6, 14/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Greeting geopriv-archive Did you know 80% of ladies prefer a man that is big, they say its more fulfilling Herbert Hester http://boligia.com/ From Dwain_jack@scientific-drilling.nl Sat Sep 15 18:10:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWfqP-0005qV-QS for geopriv-archive@lists.ietf.org; Sat, 15 Sep 2007 18:10:29 -0400 Received: from [86.68.142.62] (helo=[86.68.142.94]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWfqP-0002VE-5H for geopriv-archive@lists.ietf.org; Sat, 15 Sep 2007 18:10:29 -0400 Received: from salon ([152.119.183.74] helo=salon) by [86.68.142.94] ( sendmail 8.13.3/8.13.1) with esmtpa id 1Sldpy-000FRF-Ne for geopriv-archive@lists.ietf.org; Sun, 16 Sep 2007 00:12:50 +0200 Message-ID: <000801c7f7e5$7e21bc20$5e8e4456@salon> From: "Dwain jack" To: Subject: udargnon Date: Sun, 16 Sep 2007 00:12:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7F7F6.41AA8C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C7F7F6.41AA8C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://bookscoole.com/ Wazzup geopriv-archive With other partners, I can reach orgasm within a couple of minutes, but = he is so small, I just can't Dwain jack ------=_NextPart_000_0009_01C7F7F6.41AA8C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://bookscoole.com/
Wazzup geopriv-archive
With other partners, I can reach orgasm within = a couple=20 of minutes, but he is so small, I just can't
Dwain jack
------=_NextPart_000_0009_01C7F7F6.41AA8C20-- From geopriv-bounces@ietf.org Sun Sep 16 05:53:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWqoh-00087J-VH; Sun, 16 Sep 2007 05:53:27 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWqog-000879-QS for geopriv-confirm+ok@megatron.ietf.org; Sun, 16 Sep 2007 05:53:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWqog-000871-Gq for geopriv@ietf.org; Sun, 16 Sep 2007 05:53:26 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWqof-0004w0-Bi for geopriv@ietf.org; Sun, 16 Sep 2007 05:53:26 -0400 Received: from [84.186.175.237] (p54BAAFED.dip.t-dialin.net [84.186.175.237]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8G9rNNf023868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 16 Sep 2007 05:53:24 -0400 (EDT) Message-ID: <46ECFD14.5070808@cs.columbia.edu> Date: Sun, 16 Sep 2007 11:53:24 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com><5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA05A7F3AD@crexc41p> <517DB3EE-F714-46F9-967E-E7EDAF5B0521@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org In many cases, all of these connections are going to be existing already and are essentially 'nailed up'. For example, the proxy would have a long-term connection to the LoST resolver. I don't know what a call server is. Winterbottom, James wrote: > It is unclear to me at least why we are so worried about the potential > 500ms to get setup the location session, when there are at least 2 other > TLS SIP sessions to be established, plus a LoST connection from the > call-server to check the authenticity of the destination as well. > > This seems somewhat moot since without valid location you are either not > going route at all, or you are going to misroute. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Sep 16 06:09:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWr3w-0003kJ-CH; Sun, 16 Sep 2007 06:09:12 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWr3u-0003kB-Cd for geopriv-confirm+ok@megatron.ietf.org; Sun, 16 Sep 2007 06:09:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWr3u-0003k0-2q for geopriv@ietf.org; Sun, 16 Sep 2007 06:09:10 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWr3s-0005Hg-T8 for geopriv@ietf.org; Sun, 16 Sep 2007 06:09:10 -0400 Received: from [84.186.175.237] (p54BAAFED.dip.t-dialin.net [84.186.175.237]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8GA94Tn024078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 16 Sep 2007 06:09:06 -0400 (EDT) Message-ID: <46ED00C2.4070909@cs.columbia.edu> Date: Sun, 16 Sep 2007 12:09:06 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Geopriv] HELD and persistent TLS connections in emergency calls References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com> <46EB975F.2010408@gmx.net> In-Reply-To: <46EB975F.2010408@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'GEOPRIV' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I suspect that location usage will be fairly constant and common. For an interesting article on using location on cell phones, see the recent issue of Pervasive Computing on Navitime (http://www.navitime.co.jp/), a pedestrian navigation system. Given the update frequencies needed, HELD (or DHCP) is extremely unlikely, however. My guess is that in a few years, many cell phones will be using GPS more or less continuously, for either in-vehicle navigation with traffic alerts or, in countries with usable public transportation systems, for commute optimization. Hannes Tschofenig wrote: > Hi Brian, > > I agree that this is a challenging question. > > I believe for a cellular access network it is challenging to > periodically fetch location information (given that you may only have an > emergency call once in your lifetime) and to keep a TCP connection up > and running all the time. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Sep 16 06:09:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWr48-0003y5-J4; Sun, 16 Sep 2007 06:09:24 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IWr47-0003y0-Tf for geopriv-confirm+ok@megatron.ietf.org; Sun, 16 Sep 2007 06:09:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWr47-0003xs-Ih for geopriv@ietf.org; Sun, 16 Sep 2007 06:09:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWr47-0004xl-4w for geopriv@ietf.org; Sun, 16 Sep 2007 06:09:23 -0400 X-SEF-Processed: 5_0_0_910__2007_09_16_05_18_50 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 16 Sep 2007 05:18:50 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 16 Sep 2007 05:09:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] HELD and persistent TLS connections in emergency calls Date: Sun, 16 Sep 2007 05:09:20 -0500 Message-ID: In-Reply-To: <46ECFD14.5070808@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] HELD and persistent TLS connections in emergency calls Thread-Index: Acf4R3ui4T331tWiR1OoRVXi66RmmgAAVNiQ References: <0a2f01c7f6f5$79431b90$640fa8c0@cis.neustar.com><5CBB5FFD-2784-4DD2-AEDA-C6BD4EFA52CC@cs.columbia.edu><7582BC68E4994F4ABF0BD4723975C3FA05A7F3AD@crexc41p><517DB3EE-F714-46F9-967E-E7EDAF5B0521@cs.columbia.edu> <46ECFD14.5070808@cs.columbia.edu> From: "Winterbottom, James" To: "Henning Schulzrinne" , "GEOPRIV" X-OriginalArrivalTime: 16 Sep 2007 10:09:22.0479 (UTC) FILETIME=[A7330BF0:01C7F849] X-Spam-Score: 1.8 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org A call-server is the proxy in the way you are describing it.=0D=0AI would p= oint out though, that the session between the proxy and the=0D=0ALoST resol= ver, does not mean that there is a 'nailed up' session all the=0D=0Away to = the local LoST server, which may still require a session to be=0D=0Aestabli= shed, and certainly will until the network is fully meshed.=0D=0AFurther mo= re, if the end-point has to do a LoST look up prior to=0D=0Aoriginating the= call, as is suggested by phone BCP, then the problem=0D=0Astill exists.=0D= =0A=0D=0AI think, rather than saying 'hey this is bad', we need a far more=0D= =0Aholistic view and not impose totally ridiculous 'out of thin air' time=0D= =0Arequirements such as those that have been put forward thus far.=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: H= enning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Sunday, 16 Sep= tember 2007 7:53 PM=0D=0A> To: GEOPRIV=0D=0A> Subject: Re: [Geopriv] HELD a= nd persistent TLS connections in=0D=0Aemergency=0D=0A> calls=0D=0A>=20=0D=0A= > In many cases, all of these connections are going to be existing=0D=0Aalr= eady=0D=0A> and are essentially 'nailed up'. For example, the proxy would h= ave a=0D=0A> long-term connection to the LoST resolver.=0D=0A>=20=0D=0A> I = don't know what a call server is.=0D=0A>=20=0D=0A> Winterbottom, James wrot= e:=0D=0A> > It is unclear to me at least why we are so worried about the=0D= =0Apotential=0D=0A> > 500ms to get setup the location session, when there a= re at least 2=0D=0Aother=0D=0A> > TLS SIP sessions to be established, plus = a LoST connection from the=0D=0A> > call-server to check the authenticity o= f the destination as well.=0D=0A> >=0D=0A> > This seems somewhat moot since= without valid location you are either=0D=0Anot=0D=0A> > going route at all= , or you are going to misroute.=0D=0A>=20=0D=0A>=20=0D=0A> ________________= _______________________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@= ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0AThis message is for the designated recipient only= and may=0D=0Acontain privileged, proprietary, or otherwise private informa= tion. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From MuhtashemFedor@spiderwearjunction.com Sun Sep 16 07:49:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWscb-0003WX-Mo for geopriv-archive@lists.ietf.org; Sun, 16 Sep 2007 07:49:05 -0400 Received: from [85.108.67.128] (helo=[85.108.67.128]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWsca-0006sY-8F for geopriv-archive@lists.ietf.org; Sun, 16 Sep 2007 07:49:05 -0400 Received: from imaj ([136.145.14.192] helo=imaj) by [85.108.67.128] ( sendmail 8.13.3/8.13.1) with esmtpa id 1ArNgj-000RZP-Hi for geopriv-archive@lists.ietf.org; Sun, 16 Sep 2007 14:49:59 +0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Sep 2007 14:49:34 +0300 To: geopriv-archive@lists.ietf.org From: "Muhtashem Fedor" Subject: selvresp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.2 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi geopriv-archive Our herbal pills is recommended by top European physicians for penis enlargement Muhtashem Fedor http://cuathime.com/ From Gaspar@gmbhankauf.de Sun Sep 16 11:18:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWvsr-0001sV-L3 for geopriv-archive@lists.ietf.org; Sun, 16 Sep 2007 11:18:05 -0400 Received: from aado32.neoplus.adsl.tpnet.pl ([83.4.92.32] helo=etr8.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWvsq-0003aA-Fr for geopriv-archive@lists.ietf.org; Sun, 16 Sep 2007 11:18:05 -0400 Received: from kuba by gmbhankauf.de with ASMTP id B3DB72B3 for ; Sun, 16 Sep 2007 17:17:53 +0200 Received: from kuba ([183.132.88.62]) by gmbhankauf.de with ESMTP id 7DAE98BC4050 for ; Sun, 16 Sep 2007 17:17:53 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 16 Sep 2007 17:17:41 +0200 To: geopriv-archive@lists.ietf.org From: "kugas Gaspar" Subject: ntipathy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.1 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good day geopriv-archive are you one of many men unsatisfied with your penis size? kugas Gaspar http://www.cumzi.com/ From Gollanwqa@aliensgroup.in Sun Sep 16 20:58:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX4wK-0006RX-Cb for geopriv-archive@lists.ietf.org; Sun, 16 Sep 2007 20:58:16 -0400 Received: from [151.23.65.60] (helo=[151.23.65.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IX4wJ-00024f-RL for geopriv-archive@lists.ietf.org; Sun, 16 Sep 2007 20:58:16 -0400 Received: from eliseo ([108.159.37.199] helo=eliseo) by [151.23.65.60] ( sendmail 8.13.3/8.13.1) with esmtpa id 1cNSdh-000RPS-Aj for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 02:58:50 +0200 Message-ID: <000501c7f8c5$d1fa3530$3c411797@eliseo> From: "dumitru Gollan" To: Subject: 5745364 Date: Mon, 17 Sep 2007 02:58:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7F8D6.95830530" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0003_01C7F8D6.95830530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://ctdaya.com/ Morning geopriv-archive Get 3 FREE bottles if you order 6 mths supply. Herbal penis pills... get = BIG today.. dumitru Gollan ------=_NextPart_000_0003_01C7F8D6.95830530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://ctdaya.com/
Morning geopriv-archive
Get 3 FREE bottles if you order 6 mths supply. = Herbal=20 penis pills... get BIG today..
dumitru Gollan
------=_NextPart_000_0003_01C7F8D6.95830530-- From jjoanna@winning.com Mon Sep 17 12:27:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJRc-0006fh-VD for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 12:27:35 -0400 Received: from ip-191.net-89-3-129.rev.numericable.fr ([89.3.129.191] helo=crqiefjgyn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXJRc-0002ON-6A for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 12:27:32 -0400 Message-ID: From: Erectile To: geopriv-archive@lists.ietf.org Subject: Cheap Viagra and other medicines Date: Thu, 20 Sep 2007 19:22:30 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_3D1100B6.299F7EC6" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_0000_3D1100B6.299F7EC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit What is CIALIS? CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended period of effectiveness, you dont have the pressure to perform within a few hours. You and your partner can relax and take your time choosing the moment that is right for both of you. Benefits of CIALIS Works up to 36 hours Works fast Works Effectively Keeps you ready No need to plan around meals Used by millions of men Buy CIALIS online! ------=_NextPart_000_0000_3D1100B6.299F7EC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

What is CIALIS?

CIALIS is the only ED (Erectile = Disfunction) tablet clinically proven to work both
up to 36 hours = and in as fast as 30 minutes. And because CIALIS has an extended
period of = effectiveness, you don’t have the pressure to perform within a few= hours.
You and your partner can relax and take your time choosing= the moment that is right for both of you.

Benefits of CIALIS =

  • Works up to 36 hours =
  • Works fast
  • Works Effectively =
  • Keeps you ready
  • No need to plan around meals =
  • Used by millions of men =

Buy CIALIS = online!

 ------=_NextPart_000_0000_3D1100B6.299F7EC6-- From DEUCE.Shieh@lecomptoir.ma Mon Sep 17 12:51:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJov-0001q8-Mi for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 12:51:38 -0400 Received: from host170-15-dynamic.3-79-r.retail.telecomitalia.it ([79.3.15.170] helo=host50-110-dynamic.50-82-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXJot-0000I1-Vh for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 12:51:37 -0400 Received: from MAMMALILA ([181.121.145.174]:19373 "EHLO MAMMALILA" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host50-110-dynamic.50-82-r.retail.telecomitalia.it with ESMTP id S22LCBTIFYMVLTZH (ORCPT ); Mon, 17 Sep 2007 18:51:59 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 17 Sep 2007 18:51:42 +0200 To: geopriv-archive@lists.ietf.org From: "DEUCE Shieh" Subject: foersaml Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.7 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Evening geopriv-archive Do women really care about penis size? The answer is yes DEUCE Shieh http://gabopods.com/ From Jae@aimrecords.com Mon Sep 17 17:18:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXNzN-00030j-IV for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 17:18:41 -0400 Received: from adsl-ull-152-28.51-151.net24.it ([151.51.28.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXNzA-0001mD-Rn for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 17:18:35 -0400 Received: by 10.90.128.61 with SMTP id aZEjaGzmoZlqx; Mon, 17 Sep 2007 23:18:39 +0200 (GMT) Received: by 192.168.218.47 with SMTP id XtzatpSwxKHEnQ.6386574678548; Mon, 17 Sep 2007 23:18:37 +0200 (GMT) Message-ID: <000d01c7f970$4e3b21e0$68263397@cab463a473154f9> From: "Jae goertzen" To: Subject: ayagusok Date: Mon, 17 Sep 2007 23:18:34 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7F981.11C3F1E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000775-1, 17/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.8 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7F981.11C3F1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.fxgifts.com/ Yo yo yo geopriv-archive Do women really care about penis size? The answer is yes Jae goertzen ------=_NextPart_000_0008_01C7F981.11C3F1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.fxgifts.com/
Yo yo yo geopriv-archive
Do women really care about penis size? The = answer is yes
Jae goertzen
------=_NextPart_000_0008_01C7F981.11C3F1E0-- From Jaromir_Gristwood@independentdesign.co.uk Mon Sep 17 19:20:55 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXPtf-0003p6-PF for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 19:20:55 -0400 Received: from [189.25.218.57] (helo=18925218057.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXPtc-00087w-Mu for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 19:20:53 -0400 Received: from gustavo ([132.140.134.26] helo=gustavo) by 18925218057.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1EuTTU-000JKT-Ff for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 20:21:44 -0300 Message-ID: <000801c7f981$78311b10$39da19bd@gustavo> From: "Jaromir Gristwood" To: Subject: kcirracc Date: Mon, 17 Sep 2007 20:21:26 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7F968.52E3E310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000775-1, 17/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C7F968.52E3E310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://fuachon.com/ Compliments geopriv-archive African tribes take these herbs all the time, this is why they have such = big cocks! Jaromir Gristwood ------=_NextPart_000_0009_01C7F968.52E3E310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://fuachon.com/
Compliments geopriv-archive
African tribes take these herbs all the time, = this is=20 why they have such big cocks!
Jaromir Gristwood
------=_NextPart_000_0009_01C7F968.52E3E310-- From guillaumeiwle@swiftel.net Mon Sep 17 23:53:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXU9d-0007h5-9Q for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 23:53:41 -0400 Received: from [83.238.23.214] (helo=[83.238.23.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXU9T-0006P6-NZ for geopriv-archive@lists.ietf.org; Mon, 17 Sep 2007 23:53:32 -0400 Received: from grygierz-or1g3l ([139.100.98.90] helo=grygierz-or1g3l) by [83.238.23.214] ( sendmail 8.13.3/8.13.1) with esmtpa id 1SMywo-000NLB-sj for geopriv-archive@lists.ietf.org; Tue, 18 Sep 2007 05:54:09 +0200 Message-ID: <000901c7f9a7$83d04e70$d617ee53@grygierzor1g3l> From: "asdasd guillaume" To: Subject: caliseer Date: Tue, 18 Sep 2007 05:53:46 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7F9B8.47591E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C7F9B8.47591E70 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable http://fvtennis.com/ Good evening geopriv-archive African tribes take these herbs all the time, this is why they have such = big cocks! asdasd guillaume ------=_NextPart_000_0005_01C7F9B8.47591E70 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
http://fvtennis.com/
Good evening geopriv-archive
African tribes take these herbs all the time, = this is=20 why they have such big cocks!
asdasd guillaume
------=_NextPart_000_0005_01C7F9B8.47591E70-- From Pansy-Gray@northvinelandll.org Tue Sep 18 16:44:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXjvW-0002F2-I5 for geopriv-archive@lists.ietf.org; Tue, 18 Sep 2007 16:44:10 -0400 Received: from [193.147.25.160] (helo=[193.147.25.160]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXjvW-0007iW-0U for geopriv-archive@lists.ietf.org; Tue, 18 Sep 2007 16:44:10 -0400 Received: from SIPAS5105 ([179.162.3.67]:29864 "EHLO SIPAS5105" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [193.147.25.160] with ESMTP id S22UKVVVFIOXQGBT (ORCPT ); Tue, 18 Sep 2007 22:44:18 +0200 Message-ID: <000901c7fa34$a95a0180$a01993c1@SIPAS5105> From: "Pansy Gray" To: Subject: sembleur Date: Tue, 18 Sep 2007 22:44:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FA45.6CE2D180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0008_01C7FA45.6CE2D180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.daystsr.com/ Morning geopriv-archive See my penis pictures as proof Pansy Gray ------=_NextPart_000_0008_01C7FA45.6CE2D180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.daystsr.com/
Morning geopriv-archive
See my penis pictures as proof
Pansy Gray
------=_NextPart_000_0008_01C7FA45.6CE2D180-- From OdellmetricWalls@infusionsystems.com Tue Sep 18 22:03:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXou4-0000l6-W2 for geopriv-archive@lists.ietf.org; Tue, 18 Sep 2007 22:03:01 -0400 Received: from pc-242-214-83-200.cm.vtr.net ([200.83.214.242] helo=benavides) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXou0-0007qz-De for geopriv-archive@lists.ietf.org; Tue, 18 Sep 2007 22:02:57 -0400 Message-ID: <944801c7fa61$29159340$f2d653c8@Benavides> From: "Jarvis Barr" To: Subject: Fw: Thank you, we are ready to give a business loan Date: Tue, 18 Sep 2007 21:59:32 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_9444_01C7FA61.29159340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.8 (++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------=_NextPart_000_9444_01C7FA61.29159340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit history does not matter to us! If you have your own business and want IMMEDIATE cash to spend ANY way = you like or wish Extra money to give your business a boost or wish A low = interest loan - NO STRINGS ATTACHED, here is our best deal we can offer = you THIS EVENING (hurry, this tender will expire THIS EVENING): $20,000+ loan Hurry, when the deal is gone, it is gone. Simply Call Us... Do not worry about approval, your credit will not disqualify you! Call Us Free on 877-482-4954 ------=_NextPart_000_9444_01C7FA61.29159340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit history does not matter = to=20 us!
=20
 
If you have your own business and want = IMMEDIATE=20 cash to spend ANY way you like or wish Extra money to give your business = a=20 boost or wish A low interest loan - NO STRINGS ATTACHED, here is our = best deal=20 we can offer you THIS EVENING (hurry, this tender will expire THIS=20 EVENING):
=20
 
$20,000+ loan
 
Hurry, when the deal is gone, it is = gone.=20 Simply Call Us...
=20
 
Do not worry about approval, your = credit will not=20 disqualify you!
=20
 
Call Us Free on = 877-482-4954
------=_NextPart_000_9444_01C7FA61.29159340-- From Moro_gianino@travelalacarte.ca Tue Sep 18 23:04:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXps0-00026f-GZ for geopriv-archive@lists.ietf.org; Tue, 18 Sep 2007 23:04:56 -0400 Received: from host48-90-static.29-87-b.business.telecomitalia.it ([87.29.90.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXprn-000402-TF for geopriv-archive@lists.ietf.org; Tue, 18 Sep 2007 23:04:45 -0400 Received: from sandro ([150.177.145.83] helo=sandro) by host48-90-static.29-87-b.business.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1XhCMA-000EHC-sd for geopriv-archive@lists.ietf.org; Wed, 19 Sep 2007 05:01:04 +0200 Message-ID: <000301c7fa69$4022a1b0$305a1d57@sandro> From: "Moro gianino" To: Subject: nettesor Date: Wed, 19 Sep 2007 05:00:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FA7A.03AB71B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0003_01C7FA7A.03AB71B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.croftytv.com/ Yo yo yo geopriv-archive life is short, dont have a small cock all your life Moro gianino ------=_NextPart_000_0003_01C7FA7A.03AB71B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.croftytv.com/
Yo yo yo geopriv-archive
life is short, dont have a small cock all your = life
Moro gianino
------=_NextPart_000_0003_01C7FA7A.03AB71B0-- From geopriv-bounces@ietf.org Wed Sep 19 10:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY075-0007Pp-H1; Wed, 19 Sep 2007 10:01:11 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IY074-0007PY-Ih for geopriv-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 10:01:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY074-0007P6-8i for geopriv@ietf.org; Wed, 19 Sep 2007 10:01:10 -0400 Received: from bellwecs5.bellnexxia.net ([207.236.237.117] helo=bellwecs5.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IY06y-0002Xs-1K for geopriv@ietf.org; Wed, 19 Sep 2007 10:01:10 -0400 Received: (qmail 16963 invoked from network); 19 Sep 2007 14:00:33 -0000 Received: from g.caron@bell.ca by bellwecs5.srvr.bell.ca with EntrustECS-Server-7.4; 19 Sep 2007 14:00:33 -0000 Received: from bellwfep4.bellnexxia.net (HELO bellwfep4-srv.bellnexxia.net) (207.236.237.110) by bellwecs5.srvr.bell.ca with SMTP; 19 Sep 2007 14:00:33 -0000 Received: from TOROONDC908.bell.corp.bce.ca ([142.182.89.88]) by bellwfep4-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070919140033.EXFP1989.bellwfep4-srv.bellnexxia.net@TOROONDC908.bell.corp.bce.ca>; Wed, 19 Sep 2007 10:00:33 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 10:00:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Date: Wed, 19 Sep 2007 10:00:28 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B3123DA@toroondc912> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] "Postal" and "Jurisdicational" civic locations - reprise Thread-Index: Acf2H2IirAzJnX16T0mZn7BL/If/BwAvhKDQ References: From: To: , X-OriginalArrivalTime: 19 Sep 2007 14:00:29.0107 (UTC) FILETIME=[6F97D030:01C7FAC5] X-Spam-Score: 1.2 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Dear Mary, Dear Geopriv community, In light of what have been discussed in this thread and after further = investigation, here is my position on this topic. I apologize at the = onset for the length of this response. The position exposed herein is based on the following opinions/facts: a) Emergency service is likely to be the first tangible enabler for the = deployment of a location-capable IP infrastructure; b) Coincidentally, commercial location-based services may follow shortly = thereafter; b) User-input location is specifically disallowed for ES in Canada per = regulation. As such, a reference to common-use civic format is less = critical for ES; c) While a valid and desired goal, address conversion between "legacy" = MSAG-based and "common" postal-based formats should not be taken for = granted, at least for the short term. Address translation should not be = made a mandatory step to deploy a location-capable IP infrastructure; = that in order to prevent adding undue delays to implementation for ES; d) As such, a LIS in Canada (and any other country that may see things = the same way) should be able to store multiple civic formats for a = certain period of time to accommodate ES and non-ES applications. I = believe at least one potential LIS vendor stated this was possible; e) After further investigation, I concur with others that in the = majority of cases also in Canada, a jurisdictional civic address should = work in a postal-based application albeit certain potential corner cases = similar to what was mentioned by some U.S. participants; f) Contrary to those however, it is my opinion that those cases should = not be discarded but accommodated, at least with ES in mind; Now, specific to points raised in this thread: 1) Ability to specify different civic formats (Postal, Jurisdictional, = Common or whatever) of an LO =09 I am willing to accept the verdict of the group of *initially* having = only one form of civic format to be available from a civic = address-capable LIS *if* all agree that this LIS would ALWAYS hold at = least one jurisdictionally validated civic address per location. This = civic address would therefore be assumed to be "ES-ready" i.e., routable = and dispatchable in the case of an emergency call. I believe this is the = position of the majority of the vocal Geopriv community. 2) Ability to ask for a specific nature of civic format through HELD If 1) is accepted, there is no *immediate* need to support this feature = in HELD or other LCPs. If the LIS holds more than one civic format for a = particular location, it must supply at least the "ES-ready" LO to the = location requester when locationType=3D"any" or "civic" (with or without = the "exact" attribute). Of course it would be desirable for the LO to be = properly tagged to reflect the application context (if it can not be = guessed by reading the LO itself) so the location recipient can = differentiate between the various civic forms supplied. In summary, since a Location-capable IP architecture should not restrict = non-ES applications (which potentially implies using common-use civic = format) while ensuring ES applications will be fully supported at the = onset, I'm of the view that: - The LIS should at least supply one ES-ready civic address (fine for = the immediate/short term); - Considering a LIS that supplies more than one civic format with no = mechanism to differentiate between them may impede both ES and non-ES = applications, it is desirable for the client to be able to distinguish = the various forms by either A) the LIS providing a characterization in = the response or B) the ability for the client to request a specific = civic format (no characterization in the response; the client creates = its own storage bin per civic "types"). Both options are acceptable to = me. With this added flexibility comes the ability to support the "corner = cases" that may not be otherwise accommodated which could mean disaster = in the case of ES applications. It can be addressed now, or later. Best regards,=09 Guy Caron ________________________________________ De=A0: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Envoy=E9=A0: 13 septembre 2007 12:02 =C0=A0: geopriv@ietf.org Objet=A0: [Geopriv] "Postal" and "Jurisdicational" civic locations - = reprise Hi all,=20 This thread never seemed to conclude with clear consensus as to whether = folks see a need for both these specific location types rather than = being able to use a common "civic" locationType.=A0=A0=A0=A0 I went back = through the threads and the majority of the responses indicated that = both of the values should be the same (with Canada being the = exception?).=A0=A0 Since the thread did diverge somewhat (into how = conversions etc. are done), I would like to do a quick query to see if = folks are okay with removing those two values from the locationType in = the HELD draft?=A0=A0=20 And, just to be precise, we're proposing changing locationType from a = set of {any, civic, geodetic, postalCivic, jurisdictionalCivic, = locationURI} to a set of {any, civic, geodetic, locationURI}.=A0=20 Regards,=20 Mary=20 Editor HELD=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Korpela@seascan.com Wed Sep 19 19:25:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY8uv-0002MW-9i for geopriv-archive@lists.ietf.org; Wed, 19 Sep 2007 19:25:13 -0400 Received: from [201.32.251.24] (helo=20132203188.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY8uu-0001WQ-Lo for geopriv-archive@lists.ietf.org; Wed, 19 Sep 2007 19:25:13 -0400 Received: from elias-d68140de4 by seascan.com with ASMTP id 2940FE8A for ; Wed, 19 Sep 2007 20:25:15 -0300 Received: from elias-d68140de4 ([128.172.25.188]) by seascan.com with ESMTP id 792BEE81C19C for ; Wed, 19 Sep 2007 20:25:15 -0300 Message-ID: <000901c7fb14$4b46fe50$bccb20c9@eliasd68140de4> From: "Ferosh Korpela" To: Subject: ichinose Date: Wed, 19 Sep 2007 20:24:58 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FAFB.25F9C650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C7FAFB.25F9C650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.mandolox.com/ Wazzup geopriv-archive My wife is very happy with what the ManSter pills have done for me. Ferosh Korpela ------=_NextPart_000_0005_01C7FAFB.25F9C650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.mandolox.com/
Wazzup geopriv-archive
My wife is very happy with what the ManSter = pills have=20 done for me.
Ferosh Korpela
------=_NextPart_000_0005_01C7FAFB.25F9C650-- From Eylesdjg@jamesmonte.net Wed Sep 19 23:36:45 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYCqL-0004lF-CX for geopriv-archive@lists.ietf.org; Wed, 19 Sep 2007 23:36:45 -0400 Received: from [190.24.181.75] (helo=adsl201-245240195.dyn.etb.net.co) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYCq9-0007iW-ND for geopriv-archive@lists.ietf.org; Wed, 19 Sep 2007 23:36:34 -0400 Received: from mi-61f2c77ada0a ([150.158.153.142] helo=mi-61f2c77ada0a) by adsl201-245240195.dyn.etb.net.co ( sendmail 8.13.3/8.13.1) with esmtpa id 1NzYaQ-000WDW-Ui for geopriv-archive@lists.ietf.org; Wed, 19 Sep 2007 22:36:38 -0500 Message-ID: <000c01c7fb37$6a655f70$c3f0f5c9@mi61f2c77ada0a> From: "TREV Eyles" To: Subject: inagnak Date: Wed, 19 Sep 2007 22:36:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FB0D.818F5770" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0005_01C7FB0D.818F5770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://matiman.com/ Hi geopriv-archive life is too short to be small TREV Eyles ------=_NextPart_000_0005_01C7FB0D.818F5770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://matiman.com/
Hi geopriv-archive
life is too short to be small
TREV Eyles
------=_NextPart_000_0005_01C7FB0D.818F5770-- From Mark-Pihlajavirta@DESIGN-PLUS.COM Thu Sep 20 04:58:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYHrz-0000U4-H7 for geopriv-archive@lists.ietf.org; Thu, 20 Sep 2007 04:58:47 -0400 Received: from [201.29.210.100] (helo=20129210100.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYHrv-0007wx-Iz for geopriv-archive@lists.ietf.org; Thu, 20 Sep 2007 04:58:44 -0400 Received: by 10.209.14.135 with SMTP id pXXtoxpvrKkHu; Thu, 20 Sep 2007 05:58:45 -0300 (GMT) Received: by 192.168.208.160 with SMTP id psBVgPqMTycGev.1210791068393; Thu, 20 Sep 2007 05:58:43 -0300 (GMT) Message-ID: <000701c7fb64$70873900$64d21dc9@home> From: "Mark Pihlajavirta" To: Subject: pigherd Date: Thu, 20 Sep 2007 05:58:40 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FB4B.4B3A0100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C7FB4B.4B3A0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://cmsko.com/ hello geopriv-archive votes no.1 male enhancement product 2007 Mark Pihlajavirta ------=_NextPart_000_0004_01C7FB4B.4B3A0100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://cmsko.com/
hello geopriv-archive
votes no.1 male enhancement product = 2007
Mark Pihlajavirta
------=_NextPart_000_0004_01C7FB4B.4B3A0100-- From geopriv-bounces@ietf.org Thu Sep 20 10:58:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNTR-0004g8-W8; Thu, 20 Sep 2007 10:57:50 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYNTR-0004fI-B4 for geopriv-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 10:57:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNTQ-0004dI-PQ for geopriv@ietf.org; Thu, 20 Sep 2007 10:57:49 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYNTP-0000dr-Qk for geopriv@ietf.org; Thu, 20 Sep 2007 10:57:48 -0400 Received: from [192.168.2.235] (pool-71-164-172-176.dllstx.fios.verizon.net [71.164.172.176]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l8KEvdTe005961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Sep 2007 09:57:47 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) To: GEOPRIV Message-Id: References: From: Robert Sparks Date: Thu, 20 Sep 2007 09:57:46 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [Geopriv] Fwd: Deployment of the Internet-Draft Submission Tool X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2073522728==" Errors-To: geopriv-bounces@ietf.org --===============2073522728== Content-Type: multipart/alternative; boundary=Apple-Mail-4--607814212 --Apple-Mail-4--607814212 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed fyi Begin forwarded message: > From: IETF Secretariat > Date: September 19, 2007 2:32:20 PM CDT > To: IETF Announcement list > Cc: wgchairs@ietf.org > Subject: Deployment of the Internet-Draft Submission Tool > Reply-To: idst-developers@ietf.org > > The IETF Secretariat is pleased to announce the deployment of the > Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web- > based > application that will allow an IETF participant to submit an > Internet-Draft online, obtain approval to post the draft (if > necessary), > and make the draft immediately available to the community on the IETF > Web site without the assistance of the Secretariat (in most cases). > > The URL for the IDST is: > https://datatracker.ietf.org/idst/upload.cgi > > The URL for instructions for using the IDST is: > http://www.ietf.org/idsubmit_instructions.html > > Although it will still be possible to submit your drafts by e-mail > (i.e., by sending them to internet-drafts@ietf.org), the tool is > available for use effective immediately, and we encourage you to > submit > your drafts via the tool starting today. > > If you have any questions about using the tool or wish to report a > bug, > then please send a message to idst-developers@ietf.org. > > Enjoy!! > > The IETF Secretariat > --Apple-Mail-4--607814212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 fyi

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: September 19, 2007 2:32:20 PM = CDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: = Deployment of the Internet-Draft Submission Tool=A0

The IETF Secretariat is pleased to announce the = deployment of the
Internet-Draft Submission Tool = (IDST)-Phase I.=A0 The IDST = is a Web-based
application that will allow an = IETF participant to submit an
and make the draft immediately = available to the community on the IETF
Web site = without the assistance of the Secretariat (in most cases).

The URL = for the IDST is:

The URL for instructions for = using the IDST is:

Although it will still be = possible to submit your drafts by e-mail
(i.e., = by sending them to internet-drafts@ietf.org), = the tool is
available for use effective = immediately, and we encourage you to submit
your = drafts via the tool starting today.

If you have any questions about = using the tool or wish to report a bug,
then = please send a message to idst-developers@ietf.org.


The IETF Secretariat


= --Apple-Mail-4--607814212-- --===============2073522728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============2073522728==-- From raimachdqa@adi.org.uk Thu Sep 20 14:24:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQh8-0003cR-Vm for geopriv-archive@lists.ietf.org; Thu, 20 Sep 2007 14:24:11 -0400 Received: from i577a3f46.versanet.de ([87.122.63.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYQh8-0007xW-9u for geopriv-archive@lists.ietf.org; Thu, 20 Sep 2007 14:24:10 -0400 Received: from philip ([128.124.19.71] helo=philip) by i577A3F46.versanet.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1rOCJF-000HUQ-Qc for geopriv-archive@lists.ietf.org; Thu, 20 Sep 2007 20:24:37 +0200 Message-ID: <000c01c7fbb3$76b17e90$463f7a57@philip> From: "Marikka raima" To: Subject: silmiemm Date: Thu, 20 Sep 2007 20:24:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FBC4.3A3A4E90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0004_01C7FBC4.3A3A4E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://anmanac.com/ Morning geopriv-archive NEW FASTER ACTING Penis Enlargement pills Marikka raima ------=_NextPart_000_0004_01C7FBC4.3A3A4E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://anmanac.com/
Morning geopriv-archive
NEW FASTER ACTING Penis Enlargement = pills
Marikka raima
------=_NextPart_000_0004_01C7FBC4.3A3A4E90-- From geopriv-bounces@ietf.org Thu Sep 20 14:47:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYR3H-0002qD-4r; Thu, 20 Sep 2007 14:47:03 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYQLr-0007eb-53 for geopriv-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 14:02:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQLq-0007e6-JD; Thu, 20 Sep 2007 14:02:10 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYQLp-0007GS-0w; Thu, 20 Sep 2007 14:02:10 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 63118175AC; Thu, 20 Sep 2007 18:01:28 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IYQL9-0005LW-IR; Thu, 20 Sep 2007 14:01:27 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: mankin@psg.com, rg+ietf@qualcomm.com, andy@hxr.us From: The IESG Message-Id: Date: Thu, 20 Sep 2007 14:01:27 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 X-Mailman-Approved-At: Thu, 20 Sep 2007 14:47:02 -0400 Cc: geopriv@ietf.org, ietf-announce@ietf.org Subject: [Geopriv] Response to appeal dated 22-June-2007 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org IESG Response to the Appeal Against the Removal of the Co-chairs of the GEOPRIV Working Group Introduction This is the IESG response to the appeal by Randall Gellens, Allison Mankin, and Andy Newton posted at: http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf Cullen Jennings recused from all discussion of this appeal. The appeal raises three major points for the IESG to address: 1. The removal of the WG Chairs violates IETF process; 2. The actions taken interfered with the consensus process; and 3. There is a conflict of interest. The appeal also proposes a remedy. This response includes some comments about the proposed remedy. 1. The removal of the WG Chairs violates IETF process RFC 2418 says: Working groups require considerable care and feeding. In addition to general participation, successful working groups benefit from the efforts of participants filling specific functional roles. The Area Director must agree to the specific people performing the WG Chair, and Working Group Consultant roles, and they serve at the discretion of the Area Director. Since all WG chairs "serve at the discretion of the Area Director," they can be replaced at any time. The previous GEOPRIV WG co-chairs were told about their removal in private before the public announcement. This action was not required, but it is the most polite way to handle the situation. Perhaps the public announcement could have provided some rationale, but the authority to remove a WG chair is clear. 2. The actions taken interfered with the consensus process The appeal claims that a sequence of events, including the replacement of the GEOPRIV WG chairs, interfered with the consensus process. From the wording of the appeal, it is not clear which items in the sequence are offered as background. It is clear that removal of the GEOPRIV WG chairs is claimed to have interfered. Some of the events in the sequence occurred more than two months prior to the submission of the appeal, and it is recognized that these events are not subject to appeal. Each of the items in the sequence is addressed for completeness. 2.1. Changing of GEOPRIV WG session time at IETF 68 It appears that many events lead to the unfortunate rescheduling the GEOPRIV session at IETF 68. Andy's broken arm, schedule conflicts, a wedding, and airlines schedules impacted by bad weather on the East Coast of the United States were all contributing factors. As a result, only one of the GEOPRIV co-chairs (Randy) was at the IETF 68 meeting in Prague. The RAI ADs were faced with a situation where either the SPEERMINT WG or the GEOPRIV WG was going to meet without any of their chairs present in the session. With little time to make a decision, the RAI ADs chose to adjust the schedule so that SPEERMINT, the younger of the two WGs, would have a session where a WG chair could attend. Due to the schedule change, Randy was no longer able to attend the session. The change created a conflict with LEMONADE, and Randy needed to be in the LEMONADE session. However, the GEOPRIV WG co- chairs had already selected Henning Schulzrinne (the author of RELO), to co-chair the session with Randy. The decision was made that Jon Peterson (one of the RAI ADs) would co-chair the session with Henning. Scheduling is a problem that faces all ADs. This was a choice of the lesser of two evils. In hindsight, it may not have been the best possible choice. However, a reasonable decision was made. 2.2. Changing of the GEOPRIV WG session agenda at IETF 68 Discussion of Layer 7 Location Configuration Protocol (L7-LCP) was planned, but it is not clear from the agenda that a decision between HELD and RELO was planned. As usual, the first agenda item was an agenda bash. There was an agenda change that moved the discussion of location signing to the end of the session, but this change is not relevant to the appeal. The original agenda is available at: http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt. The minutes summarize the agenda as: A. Agenda Bashing B. Document Status C. Future Directions D. L7-LCP Problem Statement & Requirements E. L7-LCP Protocol Selection F. Geo URI The agenda that was published prior to the meeting does not indicate that RELO would be discussed, and it does not include the "L7-LCP Protocol Selection" agenda item. A participant could easily have been surprised when these topics were added during agenda bashing. Review of the audio stream of the agenda basing portion of the GEOPRIV WG session at IETF 68 makes it clear that all of the participants were made aware of the push for a decision. No one spoke against this proposed change to the agenda, and no one hummed against the revised agenda when asked. 2.3. Assessing the opinion at the GEOPRIV WG session at IETF 68 Discussing the L7-LCP problem statement and HELD were clearly on the agenda that was posted prior to the meeting. It is clear that people following the GEOPRIV WG knew HELD and RELO were the two HTTP L7-LCP candidates. The appeal asserts that no decision should have been made at the WG session at IETF 68. However, it was made clear through hums, that the people in the room felt they needed to make a protocol selection. They clearly indicated that waiting for consensus on the requirements document was not needed. It was recognized that location signing was still a topic of active discussion. However, the still-under-discussion problem statement document no longer included location signing as a requirement. The GEOPRIV WG chose to remove it from the requirements between the -00 and -01 drafts. Draft -02 was available prior to this WG session. The appeal takes issue with the participation of Cullen Jennings in the counting of hands. Ted Hardie and Cullen both helped the Acting GEOPRIV WG Session Chairs count hands. RELO and HELD each got 22 hands. Yet, hums indicated that the people in the room wanted a decision. They were faced with a tie. To break the tie, Cullen cast a vote for RELO. Rohan Mahy stated during the session that Cullen had previously indicated no technical preference between RELO and HELD. However, Cullen did indicate that he believed that a decision had to be made. In hindsight, Cullen regrets casting a vote. In the end, Cullen's vote made no difference since votes from the Jabber room were used to break the tie. By totaling the hands in the room and the Jabber room votes, HELD was declared the winner. The appeal questions the integrity of the Jabber process. The belief is that most Jabber participants were listening to the real-time audio feed; therefore, they were not asked different questions. Rather, they were prompted to organize their responses. The Acting GEOPRIV WG Session Chairs were satisfied that a plurality of opinion had emerged, and no one has challenged their assessment of the outcome. The appeal raises questions regarding RFC 3929. However, RFC 3929 was not employed. Ted Hardie, the author of RFC 3929, explained during the session how the process used was not compatible with RFC 3929. Ted spoke quite clearly about the process that was proposed for selecting the protocol, and based on review of the audio stream the people in the room were in agreement with using the proposed process. 2.4. Interfering with the GEOPRIV WG chairs' processes after IETF 68 It is clear that Cullen Jennings was pushing the GEOPRIV WG to make progress. Over the years, the GEOPRIV WG became a divisive group. Cullen was looking for closure on long-standing unresolved issues that were preventing the GEOPRIV WG from fulfilling their charter. Nearly every AD finds themselves in this situation at one time or another. On March 30, after the IETF 68 meeting in Prague, Cullen told the GEOPRIV WG co-chairs that he planned to relieve them of their positions. The appeal states that a reason given for this decision was that the chairs should "never have allowed the HELD proposal to remain viable." Cullen denies saying such a thing. He also said, "I'm not sure what I said that could have been misinterpreted as meaning this." (Note: The IESG has no way to determine what was actually said during this discussion between Cullen, Randy, Allison, and Andy.) Cullen did not dictate the choice of document editor to the new GEOPRIV WG chair. However, he readily admits that it was "obvious" to him that a good editor would be required. According to Cullen, he asked the previous GEOPRIV WG co-chairs if they had any suggestions. They had none. Therefore, they engaged in a discussion of the qualities to look for in an editor. Cullen suggested they consider Mary Barnes. In a previous conversation with Mary, Cullen had asked her if she would be willing to be editor if the chairs asked her to do so, and she had indicated that she probably had time to take on the job. Mary is not strongly connected to either of the proposals, is very organized, and is experienced at working as an editor on highly controversial proposals. Cullen reports that the previous GEOPRIV WG co-chairs seemed to think Mary sounded like a good choice. The current GEOPRIV WG chair ended up choosing Mary, and he believes that Mary is the best person for the job. After IETF 68, the previous GEOPRIV WG co-chairs began the process to confirm the direction that was set during the GEOPRIV WG session. They used a series of questions, giving mail list members a certain period of time to respond. The previous GEOPRIV WG co-chairs were replaced with the current GEOPRIV WG chair before this process was complete. However, the current GEOPRIV WG chair continued the process. At the end of the allotted time, the current GEOPRIV WG chair assessed the mail list traffic, and determined the consensus. No one, including the three appellants, has approached the current GEOPRIV WG chair to indicate disagreement with the recorded consensus. Any disagreement with this consensus call should begin with the current GEOPRIV WG Chair, and then work its way up the chain if satisfaction is not found. There is no evidence that the change of WG chairs during the consensus call had any impact on its outcome. 3. There is a conflict of interest When dealing with conflict of interest, perception is just as important as reality. It seems that everyone agrees that the GEOPRIV WG has become divided into at least two camps on the HTTP L7-LCP issue. The appeal refers to "the Cisco camp," and claims that Cullen used his IETF leadership position to support that camp. The appeal suggests that Cisco favors a particular L7-LCP solution. From the GEOPRIV WG history it is clear that participants from Cisco have advocated lower layer LCP approaches (such as DHCP), and therefore it is quite difficult to understand how Cullen's effort to force a choice between HELD and RELO supports the inferred Cisco agenda. Since the core DHCP documents had long since been completed (RFC 3825 was published in July 2004), it is the opinion of the IESG that these actions by Cullen did not further any Cisco agenda and were instead targeted at timely completion of the GEOPRIV WG charter. The agenda that was posted prior to IETF 68 and the minutes reflect a time slot for Cullen Jennings to discuss "Future Directions." The appeal says that Cullen used this time to seek acceptance of a DHCP extension. This extension had not been previously discussed in the GEOPRIV WG and at the time had no associated Internet-Draft. However, review of the audio stream from the GEOPRIV WG session shows that very little time was spent discussing any aspect of DHCP. After the meeting, James Polk wrote an individual submission which the GEOPRIV WG may or may not adopt to fill the identified hole. This draft is not a subject of this appeal. The appeal states that the agenda slot was given to Cullen for validation of the current milestones. Milestones were certainly not the focus of any discussion during the GEOPRIV WG session. When asked about updates to GEOPRIV WG milestones, Cullen indicated that he was not prepared to address new milestones until outstanding critical work is complete. There seems to be a serious miscommunication on this point. The message referenced in the appeal is about updates to the milestones in the existing GEOPRIV WG charter. The previous GEOPRIV WG co-chairs were not proposing new work items. The proposed milestones can be found at: http://www.ietf.org/mail-archive/web/geopriv/current/msg02571.html The IESG believes that Cullen's actions are consistent with an AD that is pushing a divisive WG toward closure on chartered work. The IESG also believes that the GEOPRIV WG milestones are seriously out of date, and they should be updated promptly. 4. Proposed Remedy The proposed remedy is not appropriate. Appeals are designed to allow the IETF to reconsider a decision and to correct a mistake. The remedy proposed in the appeal is to move the GEOPRIV WG from the RAI Area to another area. This recommendation does not correct any mistakes that may have been made, nor does it consider the technical needs of the GEOPRIV WG. Rather, it is an attempt to move the GEOPRIV WG to a place in the IETF organization where Cullen Jennings will have less influence. By the way, the question of transferring the GEOPRIV WG to the Applications Area has been discussed on at least one previous occasion. The proposal was discussed by the RAI and Applications ADs, and they decided that the GEOPRIV WG fits well in the RAI Area. They recognized that the GEOPRIV WG has implications for things other than SIP and that it makes use of protocols developed in the Applications Area. As a result of these discussions, Lisa Dusseault, one of the Applications ADs, agreed to be a technical advisor to the GEOPRIV WG. The IETF has at least two mechanisms to address concerns about recurring biased behavior of an AD. While such concerns might be offered as rationale in an appeal, an appeal is not the best mechanism for addressing long-standing AD behavior concerns. In the future, if anyone has such concerns, the IESG believes that these other mechanisms ought to be used to address them. The first and least disruptive mechanism is input to the Nominations Committee (NomCom) when the offending AD is being considered for a subsequent term. The second and much more radical mechanism is the recall process as described in RFC 3777. 5. Conclusion For the reasons provided above, the appeal is denied. The IESG observes that the GEOPRIV WG milestones are out of date. We encourage the RAI ADs to work with the current GEOPRIV WG chair to update them. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 20 17:04:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYTBu-0000Wt-DG; Thu, 20 Sep 2007 17:04:06 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYTBs-0000SH-PC for geopriv-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 17:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYTBs-0000S8-9T for geopriv@ietf.org; Thu, 20 Sep 2007 17:04:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYTBr-0002Mb-3j for geopriv@ietf.org; Thu, 20 Sep 2007 17:04:04 -0400 X-IronPort-AV: E=Sophos;i="4.20,280,1186383600"; d="scan'208";a="222080110" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Sep 2007 14:04:02 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8KL42nK001106 for ; Thu, 20 Sep 2007 14:04:02 -0700 Received: from [128.107.139.80] (dhcp-128-107-139-80.cisco.com [128.107.139.80]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8KL42in011134 for ; Thu, 20 Sep 2007 21:04:02 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1C09730B-FDDE-4067-8BEF-5829174C74D5@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV From: Cullen Jennings Date: Thu, 20 Sep 2007 14:03:56 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=189; t=1190322242; x=1191186242; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Milestones |Sender:=20; bh=LpjqCPVG2m5vfQ9O7JBjiJUaETbee293wtezggobrUk=; b=bWslUmVA2+DNyPfVx0OdEo/wO/CVbPXQl6GvWwj2u5FZfh+IxbNLw4patgXgm/yCB2bXy1OU yCm30Scb1n5Ag+sERTgGtxd+pYlkNvunxq/fMJIbeXJar3OajMKmBLduRf92X9cPQyO8Z2rSIw 2Xe/2F1mfPRffYY+ibNtMwyMc=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Geopriv] Milestones X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I agree with the IESG assessment that I have been amiss on the Milestones for geopriv. Robert and I will be working to get these cleaned up promptly. Cullen _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Holfve@themagicagency.com Fri Sep 21 03:29:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYcxV-000291-TS for geopriv-archive@lists.ietf.org; Fri, 21 Sep 2007 03:29:54 -0400 Received: from sodeistvie.convex.ru ([82.193.152.218]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYcxQ-0002ly-1Y for geopriv-archive@lists.ietf.org; Fri, 21 Sep 2007 03:29:48 -0400 Received: from manager ([109.118.182.76]:17537 "EHLO manager" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by sodeistvie.convex.ru with ESMTP id S22SXPILOQGRVTME (ORCPT ); Fri, 21 Sep 2007 13:30:10 +0600 Message-ID: <000d01c7fc21$2ce42ce0$da98c152@manager> From: "Eman Holfve" To: Subject: lnjirges Date: Fri, 21 Sep 2007 13:29:42 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FC53.777E9CE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0008_01C7FC53.777E9CE0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is = said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter = ending July, 2007 compared with the prior year while fiscal fourth quarter results = for 2007 are on track to exceed this year=92s third quarter results. ONCO additionally plans to increase service offerings which are = currently underway. Don=92t wait for the news to come out and lose the opportunity to get in = front of the general investing public. Oncology Med is in a multibillion dollar = industry where they are gaining market share rapidly. Call your broker now for ONCO. ------=_NextPart_000_0008_01C7FC53.777E9CE0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Rumor News:
Oncology Med. Inc. (OTC: ONCO) a Cancer = Treatment=20 Solutions Group is said to have
experienced over a 1000% increase in revenues = for the=20 fiscal 3rd quarter ending July,
2007 compared with the prior year while fiscal = fourth=20 quarter results for 2007 are on
track to exceed this year=92s third quarter = results.
ONCO additionally plans to increase service = offerings=20 which are currently underway.
Don=92t wait for the news to come out and lose = the=20 opportunity to get in front of the
general investing public. Oncology Med is in = a=20 multibillion dollar industry where
they are gaining market share = rapidly.
Call your broker now for = ONCO.
------=_NextPart_000_0008_01C7FC53.777E9CE0-- From Gaetosigd@aromain.com Fri Sep 21 05:27:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYenH-0002Ef-Sw for geopriv-archive@lists.ietf.org; Fri, 21 Sep 2007 05:27:28 -0400 Received: from amontpellier-158-1-66-220.w90-41.abo.wanadoo.fr ([90.41.81.220] helo=AMontpellier-158-1-2-12.w90-36.abo.wanadoo.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYenH-0005Wq-23 for geopriv-archive@lists.ietf.org; Fri, 21 Sep 2007 05:27:27 -0400 Received: from roch-y9l0enqk91 by aromain.com with ASMTP id 8E603987 for ; Fri, 21 Sep 2007 11:27:37 +0200 Received: from roch-y9l0enqk91 ([167.116.103.65]) by aromain.com with ESMTP id D7222A57082B for ; Fri, 21 Sep 2007 11:27:37 +0200 Message-ID: <000e01c7fc31$912470b0$0c71245a@rochy9l0enqk91> From: "Nhut Gaetos" To: Subject: sivusta Date: Fri, 21 Sep 2007 11:27:02 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FC42.54AD40B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da ------=_NextPart_000_0003_01C7FC42.54AD40B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rumor News: Oncology Med. Inc. (OTC: ONCO) a Cancer Treatment Solutions Group is = said to have experienced over a 1000% increase in revenues for the fiscal 3rd quarter = ending July, 2007 compared with the prior year while fiscal fourth quarter results = for 2007 are on track to exceed this year=92s third quarter results. ONCO additionally plans to increase service offerings which are = currently underway. Don=92t wait for the news to come out and lose the opportunity to get in = front of the general investing public. Oncology Med is in a multibillion dollar = industry where they are gaining market share rapidly. Call your broker now for ONCO. ------=_NextPart_000_0003_01C7FC42.54AD40B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rumor News:
Oncology Med. Inc. (OTC: ONCO) a Cancer = Treatment=20 Solutions Group is said to have
experienced over a 1000% increase in revenues = for the=20 fiscal 3rd quarter ending July,
2007 compared with the prior year while fiscal = fourth=20 quarter results for 2007 are on
track to exceed this year=92s third quarter = results.
ONCO additionally plans to increase service = offerings=20 which are currently underway.
Don=92t wait for the news to come out and lose = the=20 opportunity to get in front of the
general investing public. Oncology Med is in = a=20 multibillion dollar industry where
they are gaining market share = rapidly.
Call your broker now for = ONCO.
------=_NextPart_000_0003_01C7FC42.54AD40B0-- From Nedimiynfcx@aqwfurniture.com Fri Sep 21 05:45:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYf52-0001B5-0W for geopriv-archive@lists.ietf.org; Fri, 21 Sep 2007 05:45:48 -0400 Received: from host87-107-dynamic.51-82-r.retail.telecomitalia.it ([82.51.107.87] helo=host243-121-dynamic.49-82-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYf4v-000256-Hw for geopriv-archive@lists.ietf.org; Fri, 21 Sep 2007 05:45:47 -0400 Received: from user-imaz6vj6z1 ([156.124.98.12]:20762 "EHLO user-imaz6vj6z1" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host243-121-dynamic.49-82-r.retail.telecomitalia.it with ESMTP id S22LAGKGDEMZBAPS (ORCPT ); Fri, 21 Sep 2007 11:46:03 +0200 Message-ID: <000901c7fc34$3040cac0$f3793152@userimaz6vj6z1> From: "Nedim iynfcx" To: Subject: dekrabyl Date: Fri, 21 Sep 2007 11:45:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C7FC44.F3C99AC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.2 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0003_01C7FC44.F3C99AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://masteomy.com/ Morning geopriv-archive I had been looking all over the place for the best penis enlargement = supplements and now I finally found them Nedim iynfcx ------=_NextPart_000_0003_01C7FC44.F3C99AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://masteomy.com/
Morning geopriv-archive
I had been looking all over the place for the = best penis=20 enlargement supplements and now I finally found them
Nedim iynfcx
------=_NextPart_000_0003_01C7FC44.F3C99AC0-- From geopriv-bounces@ietf.org Fri Sep 21 06:10:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYfSh-0002DV-8H; Fri, 21 Sep 2007 06:10:15 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYfSg-0002D0-Ln for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 06:10:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYfSg-0002Ap-8R for geopriv@ietf.org; Fri, 21 Sep 2007 06:10:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYfSe-0002Vl-T5 for geopriv@ietf.org; Fri, 21 Sep 2007 06:10:14 -0400 Received: (qmail invoked by alias); 21 Sep 2007 10:10:12 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp045) with SMTP; 21 Sep 2007 12:10:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+zNYwEM+2zLYXyv+CPzf65nC9+Qspo/nAXlcesU3 ga7FB0RKzlL/3t Message-ID: <46F39883.50704@gmx.net> Date: Fri, 21 Sep 2007 12:10:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV , Sam Hartman Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Geopriv] Issue raised with Geolocation Policy X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, Sam Hartman, our Security AD, reviewed the Geolocation Policy document (see http://tools.ietf.org/html/draft-ietf-geopriv-policy-12). Here is the issue he identified: " I'm trying to think about the mechanisms in section 6 of the geopriv document for reducing the granularity of location. I'm wonder though how effective these mechanisms are in cases where in addition to getting one-time location information I'm also seeing transitions in location information. As an example if I see a transition from one building to a near by building, I may well know much more about the civic location than granularity. Similarly, I'm wondering how much information monitoring transitions in geodetic location would help me in discovering where someone is in the best case. I.E. where they are near a discontinuity in the rounding. " Thanks to Sam for providing a detailed review of our document. In had a discussion with Sam about this issue. I agreed that some information is disclosed when you cross the boundaries. More information is disclosed when the user picks small regions for the boundary (e.g., only room numbers are not shown). I believe it is useful to document this issue. So, I would need feedback from the group. a) Do you think that this is indeed a problem? b) If yes, how should we document this aspect? Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 07:17:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgVz-0006w8-Mx; Fri, 21 Sep 2007 07:17:43 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYgVx-0006uy-Ui for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 07:17:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgVx-0006uq-FK for geopriv@ietf.org; Fri, 21 Sep 2007 07:17:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYgVw-0007mu-Ev for geopriv@ietf.org; Fri, 21 Sep 2007 07:17:41 -0400 Received: (qmail invoked by alias); 21 Sep 2007 11:17:39 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp006) with SMTP; 21 Sep 2007 13:17:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19uUa5jjh5ucTu6UaT2f1vPZaPrLW8fos2C3BEOj+ VDUoVhN3a5QRP1 Message-ID: <46F3A852.1010705@gmx.net> Date: Fri, 21 Sep 2007 13:17:38 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Tim Polk Subject: [Geopriv] [Fwd: [secdir] Security Directorate review of draft-ietf-geopriv-policy-12] X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, Tim has also provided a good review of the draft-ietf-geopriv-policy-12 document. There was one issue he raised that deserves attention. A rule is constructed in a way that there is the capability to allow conditions to be formulated with civic and geodetic information. Now, Tim raised whether it is our expectation to have a user always to provide location information for a specific location-specific condition element in both geo- and civic location format or whether we expect the server todo the translation step. What does the group think about? Ciao Hannes -------- Original Message -------- Subject: [secdir] Security Directorate review of draft-ietf-geopriv-policy-12 Date: Wed, 19 Sep 2007 13:34:19 -0400 From: Tim Polk To: secdir@MIT.EDU CC: draft-ietf-geopriv-policy@tools.ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors but document editors and WG chairs should treat these comments just like any other last call comments. Background: RFC 4745 defines a framework "for creating authorization policies for access to application specific data". The framework was designed with location and presence data in mind, but is not restricted to any particular type of application data. Authorization policies are defined as sets of rules. Rules are structured as conditions, actions, and transformations. RFC 4745 specifies three types of conditions and general procedures for combining results when multiple rules are satisfied in the authorization policy. The types of conditions specified are identity, sphere, and a validity period for the rule (starting and ending time). Definition of actions and transformations is deferred to application specific documents. This specification defines an authorization policy language (in XML) extending RFC 4745 to provide location-specific access control. Two radically different location descriptions are supported: "civic location" and "geodetic location". Civic locations are specified in terms of country, region, city, etc. At its most specific, civic locations can specify a location even more specific than building and room. Geodetic locations are given as locations in the World Geodetic System 84 (essentially, GPS coordinates). Geodetic locations may include or exclude altitude. The granularity of location information may be restricted in either case, based on location recipient or the location itself. From the Introduction: The rule set allows the entity that uses the rules defined in this document to restrict the retention and to enforce access restrictions on location data, including prohibiting any dissemination to particular individuals, during particular times or when the Target is located in a specific region. The [Rule Maker] can also stipulate that only certain parts of the Location Object are to be distributed to recipients or that the resolution of parts of the Location Object is reduced. Comments: I have no issues with the mechanisms described in the document. The mechanisms are very rich, and clearly specified. It should be possible to build independent interoperable implementations from this specification. (I am assuming that base specifications like the WGS 84 and the OpenGIS Markup Language are sufficiently specified, given their general utility in other applications and products.) However, the opening statements in the Security Considerations are a bit of an oversimplification: This document aims to make it simple for users to prevent the unintended disclosure of private information to third parties. This is accomplished through the usage of authorization policies. The authorization policies supported by geopriv-policy are rich but are not simple. The two different but interdependent location classes introduce considerable complexities that need to be highlighted. Civic and geodetic location as are not independent; given accurate geodetic locations one can determine the civic location as well, or vice versa. In addition, the location types may be mixed between rulesets and transformations. However, specifying consistent rulesets and precision levels is not straightforward. For example, I could imagine specifying a ruleset that stated "within a 30 mile radius of Washington DC provide my civic location with a granularity of the building" but elsewhere region only. If the user does not restrict the resolution of the geodetic location as well, a location recipient that requested geodetic location rather than civic location could obtain the private information I had intended to protect. It is also unclear if a user needs to specify the ruleset in terms of both civic and geodetic conditions. Specifying the same geographic area as a civic-condition or a geodetic condition seems tricky. Are we likely to have denial of service problems if conditions aren't specified in both location descriptions, or are policy servers expected to translate between coordinates and civi locations? The security considerations section should include a discussion of the dependencies between the location types and provide guidance to users developing authorization policies in light of these dependencies. _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 07:20:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgXt-0007fr-I0; Fri, 21 Sep 2007 07:19:42 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYgXr-0007fF-PN for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 07:19:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgXr-0007f4-BA for geopriv@ietf.org; Fri, 21 Sep 2007 07:19:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYgXq-0007oo-Hn for geopriv@ietf.org; Fri, 21 Sep 2007 07:19:39 -0400 Received: (qmail invoked by alias); 21 Sep 2007 11:19:37 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp018) with SMTP; 21 Sep 2007 13:19:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19jHyp6/Bljq2TCO0Q+O74iH75OLYRT1jkOfNh4u2 jZlyAacUykAQ/H Message-ID: <46F3A8C8.6040402@gmx.net> Date: Fri, 21 Sep 2007 13:19:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Lisa, Hi all, Background: draft-ietf-geopriv-policy is currently in IESG Evaluation and Lisa has put a DISCUSS on the document. Here are Lisa's comments and I would like to discuss them on the mailing list: https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71788/? https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71781/? Lisa focused on the aspect of user interfaces in her feedback. Thank you Lisa for giving the document so much thought. Here is a copy-and-paste from the comments from the tracker: " This is very complicated (too flexible) for a privacy extension. I do not expect clients from different vendors to be able to interoperate very well over the same policy information. I expect the end result of this to be cases where users believe they have privacy, or intend to have privacy, but do not achieve their goals due to difficulty of getting clients to interoperate with each other and with servers. " " These mechanisms are too complicated and don't give enough thought to how different user-agents are going to interact. In particular, one should imagine setting a privacy policy with one user agent and then trying to edit it with another. It seems that geo-spatial policy creation requires some kind of user interface that includes a map. Is that correct? Are devices without maps then unable to modify or even read policies? I am not sure that the polygons are as cut-and-dried as they appear. I'd like to understand better: - how one knows what is the inside of the polygon, and what is the outside - ... how that interacts with poles and other problems mapping 2D to a sphere - how the altitude stuff works at all with client GUIs - when is altitude known and unknown, independent of knowing a rough long/lat position - whether you can define a polygon for "Alberta" and one for "Saskatchewan" and have any point be in one or the other or completely outside both -- but not *inside* both, and not stuck in-between When it comes to users viewing policies created in the past, the lack of human-readable labels and comments is going to be a real usability problem. What happens when a user or user-agent creates a non-sensical geo-political or geo-spatial location? Are all geo-political elements *really* allowed in conditions? One possible non-sensical policy would be "Show my location unless I'm in seat 32A". Aren't there any restrictions here? How are user agents supposed to handle mixed geo-spatial and civic location conditions? How would that be displayed or represented in a list of policy elements? With the dependency on geopriv-revised-civic-lo, this can't complete yet anyway. " Thoughts? Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 08:57:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYi41-0005Yy-1Q; Fri, 21 Sep 2007 08:56:57 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYi3z-0005YA-VN for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 08:56:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYi3z-0005Xv-Ey for geopriv@ietf.org; Fri, 21 Sep 2007 08:56:55 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYi3y-0002Rz-3h for geopriv@ietf.org; Fri, 21 Sep 2007 08:56:54 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IYi3p-0003MY-FU; Fri, 21 Sep 2007 07:56:45 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'GEOPRIV'" References: <46F3A852.1010705@gmx.net> Subject: RE: [Geopriv] [Fwd: [secdir] Security Directorate review ofdraft-ietf-geopriv-policy-12] Date: Fri, 21 Sep 2007 08:56:50 -0400 Message-ID: <143901c7fc4e$e1f4e480$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf8QQ1TdYJT2+yPSTWSFCxOorcJ6gADM5Hw In-Reply-To: <46F3A852.1010705@gmx.net> 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: 'Tim Polk' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Well, generally, conversion is a bad idea unless you know what is happening downstream. Having said that, I think we should be flexible. I think we should allow the user to specify one, and if the server has the other kind of data, and can convert, it should imply the conditions based on the translation. We should definitely allow the user to specify conditions in both forms, and we should have error and warning mechanisms that tell the user what is happening: Case 1: Server only has one kind of data, user specifies the same one Result: no problem. Case 2: Server only has one kind of data, user specifies the other one Result: I think an error, regardless of whether the server can convert Case 3: Server has both kinds of data, user specified both Result: no problem Case 4: Server has both kinds of data, user specifies one, server can't convert Result: Error Case 5: Server has both kinds of data, user specifies one, server can convert Result: Conversion occurs, no errors. Could have a warning. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, September 21, 2007 7:18 AM > To: GEOPRIV > Cc: Tim Polk > Subject: [Geopriv] [Fwd: [secdir] Security Directorate review ofdraft- > ietf-geopriv-policy-12] > > Hi all, > > Tim has also provided a good review of the draft-ietf-geopriv-policy-12 > document. > > There was one issue he raised that deserves attention. > > A rule is constructed in a way that there is the capability to allow > conditions to be formulated with civic and geodetic information. > Now, Tim raised whether it is our expectation to have a user always to > provide location information for a specific location-specific condition > element in both geo- and civic location format or whether we expect the > server todo the translation step. > > What does the group think about? > > Ciao > Hannes > > -------- Original Message -------- > Subject: [secdir] Security Directorate review of > draft-ietf-geopriv-policy-12 > Date: Wed, 19 Sep 2007 13:34:19 -0400 > From: Tim Polk > To: secdir@MIT.EDU > CC: draft-ietf-geopriv-policy@tools.ietf.org > > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors but document editors and WG chairs should treat > these comments just like any other last call comments. > > Background: > > RFC 4745 defines a framework "for creating authorization > policies for access to application specific data". The framework was > designed with location and presence data in mind, but is not restricted > to any particular type of application data. Authorization policies > are defined > as sets of rules. Rules are structured as conditions, actions, and > transformations. RFC 4745 specifies three types of conditions and > general > procedures for combining results when multiple rules are satisfied in > the > authorization policy. The types of conditions specified are identity, > sphere, and a validity period for the rule (starting and ending time). > Definition of actions and transformations is deferred to application > specific documents. > > This specification defines an authorization policy language (in XML) > extending RFC 4745 to provide location-specific access control. Two > radically different location descriptions are supported: "civic > location" > and "geodetic location". Civic locations are specified in terms of > country, > region, city, etc. At its most specific, civic locations can specify > a location > even more specific than building and room. Geodetic locations are given > as locations in the World Geodetic System 84 (essentially, GPS > coordinates). > Geodetic locations may include or exclude altitude. The granularity of > location information may be restricted in either case, based on location > recipient or the location itself. > > From the Introduction: > > The rule set allows the entity that uses the rules defined in this > document to restrict the retention and to enforce access > restrictions > on location data, including prohibiting any dissemination to > particular individuals, during particular times or when the > Target is > located in a specific region. The [Rule Maker] can also > stipulate that only > certain parts of the Location Object are to be distributed to > recipients or that the resolution of parts of the Location Object is > reduced. > > > Comments: > > I have no issues with the mechanisms described in the document. The > mechanisms are very rich, and clearly specified. It should be > possible to build > independent interoperable implementations from this specification. > (I am assuming that base specifications like the WGS 84 and the OpenGIS > Markup Language are sufficiently specified, given their general > utility in > other applications and products.) > > However, the opening statements in the Security Considerations are a bit > of an oversimplification: > > This document aims to make it simple for users to prevent the > unintended disclosure of private information to third parties. This > is accomplished through the usage of authorization policies. > > The authorization policies supported by geopriv-policy are rich but are > not simple. The two different but interdependent location classes > introduce > considerable complexities that need to be highlighted. Civic and > geodetic > location as are not independent; given accurate geodetic locations > one can > determine the civic location as well, or vice versa. In addition, > the location > types may be mixed between rulesets and transformations. However, > specifying consistent rulesets and precision levels is not > straightforward. > > For example, I could imagine specifying a ruleset that stated "within > a 30 > mile radius of Washington DC provide my civic location with a > granularity of > the building" but elsewhere region only. If the user does not > restrict the > resolution of the geodetic location as well, a location recipient that > requested geodetic location rather than civic location could obtain the > private information I had intended to protect. > > It is also unclear if a user needs to specify the ruleset in terms of > both > civic and geodetic conditions. Specifying the same geographic area as > a civic-condition or a geodetic condition seems tricky. Are we > likely to have > denial of service problems if conditions aren't specified in both > location > descriptions, or are policy servers expected to translate between > coordinates > and civi locations? > > The security considerations section should include a discussion of the > dependencies between the location types and provide guidance to users > developing authorization policies in light of these dependencies. > > > _______________________________________________ > secdir mailing list > secdir@mit.edu > https://mailman.mit.edu/mailman/listinfo/secdir > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 10:17:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjJk-0002zy-4Z; Fri, 21 Sep 2007 10:17:16 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYjJi-0002qw-2t for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 10:17:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjJh-0002pB-P2 for geopriv@ietf.org; Fri, 21 Sep 2007 10:17:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYjJg-0001Yv-AV for geopriv@ietf.org; Fri, 21 Sep 2007 10:17:13 -0400 Received: (qmail invoked by alias); 21 Sep 2007 14:17:11 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp040) with SMTP; 21 Sep 2007 16:17:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX182dGYpso42HJwbF98l3AoEvY9m0hFX3k4lRLSCES 18LVBGbr9+9HsW Message-ID: <46F3D266.8010802@gmx.net> Date: Fri, 21 Sep 2007 16:17:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv] [Fwd: [secdir] Security Directorate review ofdraft-ietf-geopriv-policy-12] References: <46F3A852.1010705@gmx.net> <143901c7fc4e$e1f4e480$640fa8c0@cis.neustar.com> In-Reply-To: <143901c7fc4e$e1f4e480$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: 'GEOPRIV' , 'Tim Polk' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Brian, I like this approach. If the user specifies only the civic condition and the server cannot create the corresponding geodetic location condition then a request by an LR (where the Target's location is only available as geodetic and cannot be related) wouldn't match. Hence, the rule would not fire. No actions and transformations would be executed -- privacy safe failing. I need to think about the error procedures you mentioned... Ciao Hannes Brian Rosen wrote: > Well, generally, conversion is a bad idea unless you know what is happening > downstream. Having said that, I think we should be flexible. I think we > should allow the user to specify one, and if the server has the other kind > of data, and can convert, it should imply the conditions based on the > translation. We should definitely allow the user to specify conditions in > both forms, and we should have error and warning mechanisms that tell the > user what is happening: > > Case 1: Server only has one kind of data, user specifies the same one > Result: no problem. > > Case 2: Server only has one kind of data, user specifies the other one > Result: I think an error, regardless of whether the server can convert > > Case 3: Server has both kinds of data, user specified both > Result: no problem > > Case 4: Server has both kinds of data, user specifies one, server can't > convert > Result: Error > > Case 5: Server has both kinds of data, user specifies one, server can > convert > Result: Conversion occurs, no errors. Could have a warning. > > Brian > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, September 21, 2007 7:18 AM >> To: GEOPRIV >> Cc: Tim Polk >> Subject: [Geopriv] [Fwd: [secdir] Security Directorate review ofdraft- >> ietf-geopriv-policy-12] >> >> Hi all, >> >> Tim has also provided a good review of the draft-ietf-geopriv-policy-12 >> document. >> >> There was one issue he raised that deserves attention. >> >> A rule is constructed in a way that there is the capability to allow >> conditions to be formulated with civic and geodetic information. >> Now, Tim raised whether it is our expectation to have a user always to >> provide location information for a specific location-specific condition >> element in both geo- and civic location format or whether we expect the >> server todo the translation step. >> >> What does the group think about? >> >> Ciao >> Hannes >> >> -------- Original Message -------- >> Subject: [secdir] Security Directorate review of >> draft-ietf-geopriv-policy-12 >> Date: Wed, 19 Sep 2007 13:34:19 -0400 >> From: Tim Polk >> To: secdir@MIT.EDU >> CC: draft-ietf-geopriv-policy@tools.ietf.org >> >> >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors but document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Background: >> >> RFC 4745 defines a framework "for creating authorization >> policies for access to application specific data". The framework was >> designed with location and presence data in mind, but is not restricted >> to any particular type of application data. Authorization policies >> are defined >> as sets of rules. Rules are structured as conditions, actions, and >> transformations. RFC 4745 specifies three types of conditions and >> general >> procedures for combining results when multiple rules are satisfied in >> the >> authorization policy. The types of conditions specified are identity, >> sphere, and a validity period for the rule (starting and ending time). >> Definition of actions and transformations is deferred to application >> specific documents. >> >> This specification defines an authorization policy language (in XML) >> extending RFC 4745 to provide location-specific access control. Two >> radically different location descriptions are supported: "civic >> location" >> and "geodetic location". Civic locations are specified in terms of >> country, >> region, city, etc. At its most specific, civic locations can specify >> a location >> even more specific than building and room. Geodetic locations are given >> as locations in the World Geodetic System 84 (essentially, GPS >> coordinates). >> Geodetic locations may include or exclude altitude. The granularity of >> location information may be restricted in either case, based on location >> recipient or the location itself. >> >> From the Introduction: >> >> The rule set allows the entity that uses the rules defined in this >> document to restrict the retention and to enforce access >> restrictions >> on location data, including prohibiting any dissemination to >> particular individuals, during particular times or when the >> Target is >> located in a specific region. The [Rule Maker] can also >> stipulate that only >> certain parts of the Location Object are to be distributed to >> recipients or that the resolution of parts of the Location Object is >> reduced. >> >> >> Comments: >> >> I have no issues with the mechanisms described in the document. The >> mechanisms are very rich, and clearly specified. It should be >> possible to build >> independent interoperable implementations from this specification. >> (I am assuming that base specifications like the WGS 84 and the OpenGIS >> Markup Language are sufficiently specified, given their general >> utility in >> other applications and products.) >> >> However, the opening statements in the Security Considerations are a bit >> of an oversimplification: >> >> This document aims to make it simple for users to prevent the >> unintended disclosure of private information to third parties. This >> is accomplished through the usage of authorization policies. >> >> The authorization policies supported by geopriv-policy are rich but are >> not simple. The two different but interdependent location classes >> introduce >> considerable complexities that need to be highlighted. Civic and >> geodetic >> location as are not independent; given accurate geodetic locations >> one can >> determine the civic location as well, or vice versa. In addition, >> the location >> types may be mixed between rulesets and transformations. However, >> specifying consistent rulesets and precision levels is not >> straightforward. >> >> For example, I could imagine specifying a ruleset that stated "within >> a 30 >> mile radius of Washington DC provide my civic location with a >> granularity of >> the building" but elsewhere region only. If the user does not >> restrict the >> resolution of the geodetic location as well, a location recipient that >> requested geodetic location rather than civic location could obtain the >> private information I had intended to protect. >> >> It is also unclear if a user needs to specify the ruleset in terms of >> both >> civic and geodetic conditions. Specifying the same geographic area as >> a civic-condition or a geodetic condition seems tricky. Are we >> likely to have >> denial of service problems if conditions aren't specified in both >> location >> descriptions, or are policy servers expected to translate between >> coordinates >> and civi locations? >> >> The security considerations section should include a discussion of the >> dependencies between the location types and provide guidance to users >> developing authorization policies in light of these dependencies. >> >> >> _______________________________________________ >> secdir mailing list >> secdir@mit.edu >> https://mailman.mit.edu/mailman/listinfo/secdir >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 11:50:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYklg-0007lQ-Fw; Fri, 21 Sep 2007 11:50:12 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYklf-0007kX-CW for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 11:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYklf-0007kE-2B; Fri, 21 Sep 2007 11:50:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYklY-0004pf-A1; Fri, 21 Sep 2007 11:50:11 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8LFnmtS012712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Sep 2007 08:49:48 -0700 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8LFnjJV026944; Fri, 21 Sep 2007 08:49:47 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 21 Sep 2007 08:49:44 -0700 To: The IESG , mankin@psg.com, rg+ietf@qualcomm.com, andy@hxr.us From: Ted Hardie Subject: Re: [Geopriv] Response to appeal dated 22-June-2007 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: geopriv@ietf.org, ietf@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I believe this response (I hope inadvertently) appears to remove a valuable principle by which the IESG acted on appeals. I urge the IESG to reconsider the formulation of its response to the appeal to clarify the issues raised below. At 2:01 PM -0400 9/20/07, The IESG wrote: >IESG Response to the Appeal Against the Removal of the Co-chairs of the >GEOPRIV Working Group > > >Introduction > > This is the IESG response to the appeal by Randall Gellens, Allison > Mankin, and Andy Newton posted at: > > http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf > > Cullen Jennings recused from all discussion of this appeal. > > The appeal raises three major points for the IESG to address: > > 1. The removal of the WG Chairs violates IETF process; > > 2. The actions taken interfered with the consensus process; and > > 3. There is a conflict of interest. > > The appeal also proposes a remedy. This response includes some > comments about the proposed remedy. > >1. The removal of the WG Chairs violates IETF process > > RFC 2418 says: > > Working groups require considerable care and feeding. In addition >to > general participation, successful working groups benefit from the > efforts of participants filling specific functional roles. The Area > > Director must agree to the specific people performing the WG Chair, > > and Working Group Consultant roles, and they serve at the >discretion > of the Area Director. > > Since all WG chairs "serve at the discretion of the Area Director," > they can be replaced at any time. The previous GEOPRIV WG co-chairs > were told about their removal in private before the public > announcement. This action was not required, but it is the most > polite way to handle the situation. Perhaps the public announcement > could have provided some rationale, but the authority to remove a WG > chair is clear. In this response, the IESG appears to have read the appeal to state that the removal of the chairs was not within the authority of the Area Director. The appeal statement: http://www3.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf does not support this reading. It does not say that Area Directors do not have the right to remove chairs, it says that the manner and timing by which this was done interfered with the consensus process inappropriately. The remainder of the IESG statement below appears to attempt to address the interference issue. But in choosing to highlight that all "WG chairs serve at the discretion of the Area Director", the IESG appears to be saying that the personnel decisions of an Area Director or the IESG are not subject to appeal. During the time I served on the IESG, it was a general guideline that *any decision* of an Area Director or the IESG was subject to appeal to the IESG. While this is a broad reading of RFC 2026, Section 6.5, I think it is an important point and a principle worth retaining. The appeals process in the IETF is not simply a mechanism for establishing who has what rights; it is a mechanism for conflict resolution. By making all decisions subject to it, we ensure that conflicts which arise are dealt with as early as possible and with as little process as possible. If members of the community believe that a personnel decision was made in a way the interfered with the proper operation of the IETF, I believe asking the IESG to attempt to resolve the conflict is an appropriate thing to do. This appeal response, which re-asserts the authority of the AD to make the original decision, does not seem to support this use of the IETF's normal conflict resolution mechanism. Further, this appeal response appears to say that the only conflict resolution mechanism open to those who disagree with a personnel decision is to invoke one of the removal mechanisms for those who made it. I hope that the IESG will re-structure its response to this appeal to re-affirm that the conflict resolution mechanisms of the IETF are available for this purpose. I also encourage the IESG (and, frankly, the IETF community as a whole) to try to see the appeals process as a way of resolving conflict, rather than a quasi-legal process for determining whether a remedy will be granted. I understand how previous appeals have pushed everyone in that direction, but it is something we must continue to resist. I have worked with Allison, Andy, and Randy for many years, as well as Cullen and Jon. They are all experienced IETF folks who have toiled for years to make things work; forcing them into even more adversarial positions when conflicts do need resolution is a mistake, at least I see it. My thanks for your attention, regards, Ted >2. The actions taken interfered with the consensus process > > The appeal claims that a sequence of events, including the > replacement of the GEOPRIV WG chairs, interfered with the consensus > process. From the wording of the appeal, it is not clear which items > in the sequence are offered as background. It is clear that removal > of the GEOPRIV WG chairs is claimed to have interfered. Some of the > events in the sequence occurred more than two months prior to the > submission of the appeal, and it is recognized that these events are > not subject to appeal. Each of the items in the sequence is > addressed for completeness. > >2.1. Changing of GEOPRIV WG session time at IETF 68 > > It appears that many events lead to the unfortunate rescheduling the > GEOPRIV session at IETF 68. Andy's broken arm, schedule conflicts, a > wedding, and airlines schedules impacted by bad weather on the East > Coast of the United States were all contributing factors. As a > result, only one of the GEOPRIV co-chairs (Randy) was at the IETF 68 > meeting in Prague. The RAI ADs were faced with a situation where > either the SPEERMINT WG or the GEOPRIV WG was going to meet without > any of their chairs present in the session. With little time to make > a decision, the RAI ADs chose to adjust the schedule so that > SPEERMINT, the younger of the two WGs, would have a session where a > WG chair could attend. > > Due to the schedule change, Randy was no longer able to attend the > session. The change created a conflict with LEMONADE, and Randy > needed to be in the LEMONADE session. However, the GEOPRIV WG co- > chairs had already selected Henning Schulzrinne (the author of RELO), > to co-chair the session with Randy. The decision was made that Jon > Peterson (one of the RAI ADs) would co-chair the session with > Henning. > > Scheduling is a problem that faces all ADs. This was a choice of the > lesser of two evils. In hindsight, it may not have been the best > possible choice. However, a reasonable decision was made. > >2.2. Changing of the GEOPRIV WG session agenda at IETF 68 > > Discussion of Layer 7 Location Configuration Protocol (L7-LCP) was > planned, but it is not clear from the agenda that a decision between > HELD and RELO was planned. As usual, the first agenda item was an > agenda bash. There was an agenda change that moved the discussion of > location signing to the end of the session, but this change is not > relevant to the appeal. > > The original agenda is available at: > > http://www3.ietf.org/proceedings/07mar/agenda/geopriv.txt. > > The minutes summarize the agenda as: > > A. Agenda Bashing > B. Document Status > C. Future Directions > D. L7-LCP Problem Statement & Requirements > E. L7-LCP Protocol Selection > F. Geo URI > > The agenda that was published prior to the meeting does not indicate > that RELO would be discussed, and it does not include the "L7-LCP > Protocol Selection" agenda item. A participant could easily have > been surprised when these topics were added during agenda bashing. > > Review of the audio stream of the agenda basing portion of the > GEOPRIV WG session at IETF 68 makes it clear that all of the > participants were made aware of the push for a decision. No one > spoke against this proposed change to the agenda, and no one hummed > against the revised agenda when asked. > >2.3. Assessing the opinion at the GEOPRIV WG session at IETF 68 > > Discussing the L7-LCP problem statement and HELD were clearly on the > agenda that was posted prior to the meeting. It is clear that people > following the GEOPRIV WG knew HELD and RELO were the two HTTP L7-LCP > candidates. The appeal asserts that no decision should have been > made at the WG session at IETF 68. However, it was made clear > through hums, that the people in the room felt they needed to make a > protocol selection. They clearly indicated that waiting for > consensus on the requirements document was not needed. > > It was recognized that location signing was still a topic of active > discussion. However, the still-under-discussion problem statement > document no longer included location signing as a requirement. The > GEOPRIV WG chose to remove it from the requirements between the -00 > and -01 drafts. Draft -02 was available prior to this WG session. > > The appeal takes issue with the participation of Cullen Jennings in > the counting of hands. Ted Hardie and Cullen both helped the Acting > GEOPRIV WG Session Chairs count hands. RELO and HELD each got 22 > hands. Yet, hums indicated that the people in the room wanted a > decision. They were faced with a tie. To break the tie, Cullen cast > a vote for RELO. Rohan Mahy stated during the session that Cullen > had previously indicated no technical preference between RELO and > HELD. However, Cullen did indicate that he believed that a decision > had to be made. In hindsight, Cullen regrets casting a vote. In the > end, Cullen's vote made no difference since votes from the Jabber > room were used to break the tie. By totaling the hands in the room > and the Jabber room votes, HELD was declared the winner. > > The appeal questions the integrity of the Jabber process. The belief > is that most Jabber participants were listening to the real-time > audio feed; therefore, they were not asked different questions. > Rather, they were prompted to organize their responses. The Acting > GEOPRIV WG Session Chairs were satisfied that a plurality of opinion > had emerged, and no one has challenged their assessment of the > outcome. > > The appeal raises questions regarding RFC 3929. However, RFC 3929 > was not employed. Ted Hardie, the author of RFC 3929, explained > during the session how the process used was not compatible with RFC > 3929. Ted spoke quite clearly about the process that was proposed > for selecting the protocol, and based on review of the audio stream > the people in the room were in agreement with using the proposed > process. > >2.4. Interfering with the GEOPRIV WG chairs' processes after IETF 68 > > It is clear that Cullen Jennings was pushing the GEOPRIV WG to make > progress. Over the years, the GEOPRIV WG became a divisive group. > Cullen was looking for closure on long-standing unresolved issues > that were preventing the GEOPRIV WG from fulfilling their charter. > Nearly every AD finds themselves in this situation at one time or > another. > > On March 30, after the IETF 68 meeting in Prague, Cullen told the > GEOPRIV WG co-chairs that he planned to relieve them of their > positions. The appeal states that a reason given for this decision > was that the chairs should "never have allowed the HELD proposal to > remain viable." Cullen denies saying such a thing. He also said, > "I'm not sure what I said that could have been misinterpreted as > meaning this." > > (Note: The IESG has no way to determine what was actually said during > this discussion between Cullen, Randy, Allison, and Andy.) > > Cullen did not dictate the choice of document editor to the new > GEOPRIV WG chair. However, he readily admits that it was "obvious" > to him that a good editor would be required. According to Cullen, he > asked the previous GEOPRIV WG co-chairs if they had any suggestions. > They had none. Therefore, they engaged in a discussion of the > qualities to look for in an editor. Cullen suggested they consider > Mary Barnes. In a previous conversation with Mary, Cullen had asked > her if she would be willing to be editor if the chairs asked her to > do so, and she had indicated that she probably had time to take on > the job. Mary is not strongly connected to either of the proposals, > is very organized, and is experienced at working as an editor on > highly controversial proposals. Cullen reports that the previous > GEOPRIV WG co-chairs seemed to think Mary sounded like a good choice. > The current GEOPRIV WG chair ended up choosing Mary, and he believes > that Mary is the best person for the job. > > After IETF 68, the previous GEOPRIV WG co-chairs began the process to > confirm the direction that was set during the GEOPRIV WG session. > They used a series of questions, giving mail list members a certain > period of time to respond. The previous GEOPRIV WG co-chairs were > replaced with the current GEOPRIV WG chair before this process was > complete. However, the current GEOPRIV WG chair continued the > process. At the end of the allotted time, the current GEOPRIV WG > chair assessed the mail list traffic, and determined the consensus. > No one, including the three appellants, has approached the current > GEOPRIV WG chair to indicate disagreement with the recorded > consensus. Any disagreement with this consensus call should begin > with the current GEOPRIV WG Chair, and then work its way up the chain > if satisfaction is not found. There is no evidence that the change > of WG chairs during the consensus call had any impact on its outcome. > >3. There is a conflict of interest > > When dealing with conflict of interest, perception is just as > important as reality. > > It seems that everyone agrees that the GEOPRIV WG has become divided > into at least two camps on the HTTP L7-LCP issue. The appeal refers > to "the Cisco camp," and claims that Cullen used his IETF leadership > position to support that camp. > > The appeal suggests that Cisco favors a particular L7-LCP solution. > From the GEOPRIV WG history it is clear that participants from Cisco > have advocated lower layer LCP approaches (such as DHCP), and > therefore it is quite difficult to understand how Cullen's effort to > force a choice between HELD and RELO supports the inferred Cisco > agenda. Since the core DHCP documents had long since been completed > (RFC 3825 was published in July 2004), it is the opinion of the IESG > that these actions by Cullen did not further any Cisco agenda and > were instead targeted at timely completion of the GEOPRIV WG charter. > > The agenda that was posted prior to IETF 68 and the minutes reflect a > time slot for Cullen Jennings to discuss "Future Directions." The > appeal says that Cullen used this time to seek acceptance of a DHCP > extension. This extension had not been previously discussed in the > GEOPRIV WG and at the time had no associated Internet-Draft. > However, review of the audio stream from the GEOPRIV WG session shows > that very little time was spent discussing any aspect of DHCP. After > the meeting, James Polk wrote an individual submission which the > GEOPRIV WG may or may not adopt to fill the identified hole. This > draft is not a subject of this appeal. > > The appeal states that the agenda slot was given to Cullen for > validation of the current milestones. Milestones were certainly not > the focus of any discussion during the GEOPRIV WG session. When > asked about updates to GEOPRIV WG milestones, Cullen indicated that > he was not prepared to address new milestones until outstanding > critical work is complete. There seems to be a serious > miscommunication on this point. The message referenced in the appeal > is about updates to the milestones in the existing GEOPRIV WG > charter. The previous GEOPRIV WG co-chairs were not proposing new > work items. The proposed milestones can be found at: > > http://www.ietf.org/mail-archive/web/geopriv/current/msg02571.html > > The IESG believes that Cullen's actions are consistent with an AD > that is pushing a divisive WG toward closure on chartered work. The > IESG also believes that the GEOPRIV WG milestones are seriously out > of date, and they should be updated promptly. > >4. Proposed Remedy > > The proposed remedy is not appropriate. Appeals are designed to > allow the IETF to reconsider a decision and to correct a mistake. > The remedy proposed in the appeal is to move the GEOPRIV WG from the > RAI Area to another area. This recommendation does not correct any > mistakes that may have been made, nor does it consider the technical > needs of the GEOPRIV WG. Rather, it is an attempt to move the > GEOPRIV WG to a place in the IETF organization where Cullen Jennings > will have less influence. > > By the way, the question of transferring the GEOPRIV WG to the > Applications Area has been discussed on at least one previous > occasion. The proposal was discussed by the RAI and Applications > ADs, and they decided that the GEOPRIV WG fits well in the RAI Area. > They recognized that the GEOPRIV WG has implications for things other > than SIP and that it makes use of protocols developed in the > Applications Area. As a result of these discussions, Lisa Dusseault, > one of the Applications ADs, agreed to be a technical advisor to the > GEOPRIV WG. > > The IETF has at least two mechanisms to address concerns about > recurring biased behavior of an AD. While such concerns might be > offered as rationale in an appeal, an appeal is not the best > mechanism for addressing long-standing AD behavior concerns. In the > future, if anyone has such concerns, the IESG believes that these > other mechanisms ought to be used to address them. The first and > least disruptive mechanism is input to the Nominations Committee > (NomCom) when the offending AD is being considered for a subsequent > term. The second and much more radical mechanism is the recall > process as described in RFC 3777. > >5. Conclusion > > For the reasons provided above, the appeal is denied. > > The IESG observes that the GEOPRIV WG milestones are out of date. We > encourage the RAI ADs to work with the current GEOPRIV WG chair to > update them. > > > >_______________________________________________ >Geopriv mailing list >Geopriv@ietf.org >https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 12:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYl70-0002nC-Lu; Fri, 21 Sep 2007 12:12:14 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYl6x-0002ml-Ke for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 12:12:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYl6w-0002m9-TF; Fri, 21 Sep 2007 12:12:10 -0400 Received: from c-24-128-97-133.hsd1.ma.comcast.net ([24.128.97.133] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYl6r-0005Si-MG; Fri, 21 Sep 2007 12:12:10 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A9C6C4A42; Fri, 21 Sep 2007 12:11:59 -0400 (EDT) From: Sam Hartman To: Ted Hardie Subject: Re: [Geopriv] Response to appeal dated 22-June-2007 References: Date: Fri, 21 Sep 2007 12:11:59 -0400 In-Reply-To: (Ted Hardie's message of "Fri, 21 Sep 2007 08:49:44 -0700") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.2 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: geopriv@ietf.org, ietf@ietf.org, mankin@psg.com, The IESG , andy@hxr.us X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Ted, speaking as an individual. I completely agree that personnel decisions of ADs should be able to be appealed. I actually considered proposing text modifications to make it clear that there might be circumstances where it would be appropriate for the IESG to resolve the conflict. I and I suspect others were working on the "good enough" principle and were trying to get a good enough response produced and not deal with all potentially different future situations. So, I do agree that at least from my standpoint this defect in the response was inadvertent. My preferred way forward would be for IESG members to individually either agree or disagree with our reading of the purpose of the appeals process. I think that if the IESG is in broad agreement on this point, reopening and rewording the response would not be an effective use of time. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 13:12:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm2W-0003DS-CZ; Fri, 21 Sep 2007 13:11:40 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYm2U-00033r-JT for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 13:11:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm2T-00030g-SH for geopriv@ietf.org; Fri, 21 Sep 2007 13:11:38 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYm2S-0002go-RY for geopriv@ietf.org; Fri, 21 Sep 2007 13:11:37 -0400 Received: from [10.0.44.126] (apc01.spektrum-hotspot.de [212.77.232.233]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8LHBHuc005135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Sep 2007 13:11:19 -0400 (EDT) In-Reply-To: <143901c7fc4e$e1f4e480$640fa8c0@cis.neustar.com> References: <46F3A852.1010705@gmx.net> <143901c7fc4e$e1f4e480$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BB012C3-9849-4644-A49D-F26DACEDAA07@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] [Fwd: [secdir] Security Directorate review ofdraft-ietf-geopriv-policy-12] Date: Fri, 21 Sep 2007 19:11:19 +0200 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: 'GEOPRIV' , 'Tim Polk' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Note that conditions are additive in the framework, so if both are specified, they both have to match. (This doesn't contradict what you're saying, I think.) On Sep 21, 2007, at 2:56 PM, Brian Rosen wrote: > Well, generally, conversion is a bad idea unless you know what is > happening > downstream. Having said that, I think we should be flexible. I > think we > should allow the user to specify one, and if the server has the > other kind > of data, and can convert, it should imply the conditions based on the > translation. We should definitely allow the user to specify > conditions in > both forms, and we should have error and warning mechanisms that > tell the > user what is happening: > > Case 1: Server only has one kind of data, user specifies the same one > Result: no problem. > > Case 2: Server only has one kind of data, user specifies the other one > Result: I think an error, regardless of whether the server can convert > > Case 3: Server has both kinds of data, user specified both > Result: no problem > > Case 4: Server has both kinds of data, user specifies one, server > can't > convert > Result: Error > > Case 5: Server has both kinds of data, user specifies one, server can > convert > Result: Conversion occurs, no errors. Could have a warning. > > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, September 21, 2007 7:18 AM >> To: GEOPRIV >> Cc: Tim Polk >> Subject: [Geopriv] [Fwd: [secdir] Security Directorate review >> ofdraft- >> ietf-geopriv-policy-12] >> >> Hi all, >> >> Tim has also provided a good review of the draft-ietf-geopriv- >> policy-12 >> document. >> >> There was one issue he raised that deserves attention. >> >> A rule is constructed in a way that there is the capability to allow >> conditions to be formulated with civic and geodetic information. >> Now, Tim raised whether it is our expectation to have a user >> always to >> provide location information for a specific location-specific >> condition >> element in both geo- and civic location format or whether we >> expect the >> server todo the translation step. >> >> What does the group think about? >> >> Ciao >> Hannes >> >> -------- Original Message -------- >> Subject: [secdir] Security Directorate review of >> draft-ietf-geopriv-policy-12 >> Date: Wed, 19 Sep 2007 13:34:19 -0400 >> From: Tim Polk >> To: secdir@MIT.EDU >> CC: draft-ietf-geopriv-policy@tools.ietf.org >> >> >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors but document editors and WG chairs should >> treat >> these comments just like any other last call comments. >> >> Background: >> >> RFC 4745 defines a framework "for creating authorization >> policies for access to application specific data". The framework was >> designed with location and presence data in mind, but is not >> restricted >> to any particular type of application data. Authorization policies >> are defined >> as sets of rules. Rules are structured as conditions, actions, and >> transformations. RFC 4745 specifies three types of conditions and >> general >> procedures for combining results when multiple rules are satisfied in >> the >> authorization policy. The types of conditions specified are >> identity, >> sphere, and a validity period for the rule (starting and ending >> time). >> Definition of actions and transformations is deferred to application >> specific documents. >> >> This specification defines an authorization policy language (in XML) >> extending RFC 4745 to provide location-specific access control. Two >> radically different location descriptions are supported: "civic >> location" >> and "geodetic location". Civic locations are specified in terms of >> country, >> region, city, etc. At its most specific, civic locations can specify >> a location >> even more specific than building and room. Geodetic locations are >> given >> as locations in the World Geodetic System 84 (essentially, GPS >> coordinates). >> Geodetic locations may include or exclude altitude. The >> granularity of >> location information may be restricted in either case, based on >> location >> recipient or the location itself. >> >> From the Introduction: >> >> The rule set allows the entity that uses the rules defined in >> this >> document to restrict the retention and to enforce access >> restrictions >> on location data, including prohibiting any dissemination to >> particular individuals, during particular times or when the >> Target is >> located in a specific region. The [Rule Maker] can also >> stipulate that only >> certain parts of the Location Object are to be distributed to >> recipients or that the resolution of parts of the Location >> Object is >> reduced. >> >> >> Comments: >> >> I have no issues with the mechanisms described in the document. The >> mechanisms are very rich, and clearly specified. It should be >> possible to build >> independent interoperable implementations from this specification. >> (I am assuming that base specifications like the WGS 84 and the >> OpenGIS >> Markup Language are sufficiently specified, given their general >> utility in >> other applications and products.) >> >> However, the opening statements in the Security Considerations are >> a bit >> of an oversimplification: >> >> This document aims to make it simple for users to prevent the >> unintended disclosure of private information to third >> parties. This >> is accomplished through the usage of authorization policies. >> >> The authorization policies supported by geopriv-policy are rich >> but are >> not simple. The two different but interdependent location classes >> introduce >> considerable complexities that need to be highlighted. Civic and >> geodetic >> location as are not independent; given accurate geodetic locations >> one can >> determine the civic location as well, or vice versa. In addition, >> the location >> types may be mixed between rulesets and transformations. However, >> specifying consistent rulesets and precision levels is not >> straightforward. >> >> For example, I could imagine specifying a ruleset that stated "within >> a 30 >> mile radius of Washington DC provide my civic location with a >> granularity of >> the building" but elsewhere region only. If the user does not >> restrict the >> resolution of the geodetic location as well, a location recipient >> that >> requested geodetic location rather than civic location could >> obtain the >> private information I had intended to protect. >> >> It is also unclear if a user needs to specify the ruleset in terms of >> both >> civic and geodetic conditions. Specifying the same geographic >> area as >> a civic-condition or a geodetic condition seems tricky. Are we >> likely to have >> denial of service problems if conditions aren't specified in both >> location >> descriptions, or are policy servers expected to translate between >> coordinates >> and civi locations? >> >> The security considerations section should include a discussion of >> the >> dependencies between the location types and provide guidance to users >> developing authorization policies in light of these dependencies. >> >> >> _______________________________________________ >> secdir mailing list >> secdir@mit.edu >> https://mailman.mit.edu/mailman/listinfo/secdir >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 13:13:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm4c-0006O2-Ki; Fri, 21 Sep 2007 13:13:50 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYm4b-0006Nx-4p for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 13:13:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm4a-0006Nb-N2 for geopriv@ietf.org; Fri, 21 Sep 2007 13:13:48 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYm4a-0002jp-4A for geopriv@ietf.org; Fri, 21 Sep 2007 13:13:48 -0400 Received: from [10.0.44.126] (apc01.spektrum-hotspot.de [212.77.232.233]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8LHDhtQ007768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Sep 2007 13:13:45 -0400 (EDT) In-Reply-To: <46F39883.50704@gmx.net> References: <46F39883.50704@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <205E33A8-F6E9-4AEB-BF3D-79A90C8657D5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Issue raised with Geolocation Policy Date: Fri, 21 Sep 2007 19:13:46 +0200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: GEOPRIV , Sam Hartman X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org There would be a way to address this: you add a random number to the position, with an absolute value of half the privacy region. That way, movement doesn't much matter. On Sep 21, 2007, at 12:10 PM, Hannes Tschofenig wrote: > Hi all, > > Sam Hartman, our Security AD, reviewed the Geolocation Policy document > (see http://tools.ietf.org/html/draft-ietf-geopriv-policy-12). > > Here is the issue he identified: > > " > > I'm trying to think about the mechanisms in section 6 of the geopriv > document for reducing the granularity of location. I'm wonder though > how effective these mechanisms are in cases where in addition to > getting one-time location information I'm also seeing transitions in > location information. > > As an example if I see a transition from one building to a near by > building, I may well know much more about the civic location than > granularity. > > Similarly, I'm wondering how much information monitoring transitions > in geodetic location would help me in discovering where someone is in > the best case. I.E. where they are near a discontinuity in the > rounding. > " > > Thanks to Sam for providing a detailed review of our document. > > In had a discussion with Sam about this issue. I agreed that some > information is disclosed when you cross the boundaries. More > information is disclosed when the user picks small regions for the > boundary (e.g., only room numbers are not shown). I believe it is > useful to document this issue. > > So, I would need feedback from the group. > a) Do you think that this is indeed a problem? > b) If yes, how should we document this aspect? > > Ciao > Hannes > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 13:28:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmJE-0002zs-AA; Fri, 21 Sep 2007 13:28:56 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYm7a-0001Op-6u for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 13:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYm7Z-0001Og-TE for geopriv@ietf.org; Fri, 21 Sep 2007 13:16:53 -0400 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYm7T-0007pE-OG for geopriv@ietf.org; Fri, 21 Sep 2007 13:16:53 -0400 Received: (qmail 28980 invoked by uid 0); 21 Sep 2007 17:16:12 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 21 Sep 2007 17:16:12 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Sep 2007 13:16:07 -0400 To: Ted Hardie From: Russ Housley Subject: Re: [Geopriv] Response to appeal dated 22-June-2007 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Message-Id: X-Mailman-Approved-At: Fri, 21 Sep 2007 13:28:54 -0400 Cc: geopriv@ietf.org, andy@hxr.us, ietf@ietf.org, mankin@psg.com X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Ted: With great respect, I must disagree. The appeal says: "It is the position of the appellants that this removal violates the IETF process by which working groups are governed." This say to me that the appellants believe that Cullen Jennings violated IETF process by replacing the GEOPRIV WG Co-chairs at the time that he did so. I personally reread many BCPs as part of this appeal review, and I could not find any process that was violated by this action. You are correct that any action taken by an AD can be appealed. In particular, RFC 2026 states: All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged. In this particular appeal, there is a lot of background information that describes events that happened outside of the two month window. These can only be taken as context for the actions under appeal. Russ At 11:49 AM 9/21/2007, Ted Hardie wrote: >I believe this response (I hope inadvertently) appears to remove a valuable >principle by which the IESG acted on appeals. > >I urge the IESG to reconsider the formulation of its response to the appeal >to clarify the issues raised below. > > >At 2:01 PM -0400 9/20/07, The IESG wrote: > >IESG Response to the Appeal Against the Removal of the Co-chairs of the > >GEOPRIV Working Group > > > > > >Introduction > > > > This is the IESG response to the appeal by Randall Gellens, Allison > > Mankin, and Andy Newton posted at: > > > > http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf > > > > Cullen Jennings recused from all discussion of this appeal. > > > > The appeal raises three major points for the IESG to address: > > > > 1. The removal of the WG Chairs violates IETF process; > > > > 2. The actions taken interfered with the consensus process; and > > > > 3. There is a conflict of interest. > > > > The appeal also proposes a remedy. This response includes some > > comments about the proposed remedy. > > > >1. The removal of the WG Chairs violates IETF process > > > > RFC 2418 says: > > > > Working groups require considerable care and feeding. In addition > >to > > general participation, successful working groups benefit from the > > efforts of participants filling specific functional roles. The Area > > > > Director must agree to the specific people performing the WG Chair, > > > > and Working Group Consultant roles, and they serve at the > >discretion > > of the Area Director. > > > > Since all WG chairs "serve at the discretion of the Area Director," > > they can be replaced at any time. The previous GEOPRIV WG co-chairs > > were told about their removal in private before the public > > announcement. This action was not required, but it is the most > > polite way to handle the situation. Perhaps the public announcement > > could have provided some rationale, but the authority to remove a WG > > chair is clear. > >In this response, the IESG appears to have read the appeal to state that the >removal of the chairs was not within the authority of the Area Director. > >The appeal statement: > >http://www3.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf > >does not support this reading. It does not say that Area Directors >do not have the right to remove chairs, it says that the manner >and timing by which this was done interfered with the consensus process >inappropriately. The remainder of the IESG statement below appears >to attempt to address the interference issue. But in choosing to highlight >that all "WG chairs serve at the discretion of the Area Director", >the IESG appears to be saying that the personnel decisions of >an Area Director or the IESG are not subject to appeal. > >During the time I served on the IESG, it was a general guideline that >*any decision* of an Area Director or the IESG was subject to appeal >to the IESG. While this is a broad reading of RFC 2026, Section 6.5, >I think it is an important point and a principle worth retaining. The >appeals process in the IETF is not simply a mechanism for establishing >who has what rights; it is a mechanism for conflict resolution. By >making all decisions subject to it, we ensure that conflicts which arise >are dealt with as early as possible and with as little process as possible. > >If members of the community believe that a personnel decision >was made in a way the interfered with the proper operation of the >IETF, I believe asking the IESG to attempt to resolve the conflict is >an appropriate thing to do. This appeal response, which re-asserts the >authority of the AD to make the original decision, does not seem >to support this use of the IETF's normal conflict resolution mechanism. >Further, this appeal response appears to say that the only conflict resolution >mechanism open to those who disagree with a personnel decision >is to invoke one of the removal mechanisms for those who made it. > >I hope that the IESG will re-structure its response to this appeal >to re-affirm that the conflict resolution mechanisms of the IETF are >available for this purpose. I also encourage the IESG (and, frankly, >the IETF community as a whole) to try to see the appeals process >as a way of resolving conflict, rather than a quasi-legal process >for determining >whether a remedy will be granted. I understand how previous appeals >have pushed everyone in that direction, but it is something we must >continue to resist. I have worked with Allison, Andy, and Randy for >many years, as well as Cullen and Jon. They are all experienced >IETF folks who have toiled for years to make things work; forcing them >into even more adversarial positions when conflicts do need resolution >is a mistake, at least I see it. > >My thanks for your attention, > regards, > Ted _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 14:12:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmyv-0006m8-E9; Fri, 21 Sep 2007 14:12:01 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYmyv-0006m0-2y for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 14:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYmyu-0006lP-Og; Fri, 21 Sep 2007 14:12:00 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYmyp-0001Yp-7p; Fri, 21 Sep 2007 14:12:00 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8LIBfJg008068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Sep 2007 11:11:42 -0700 Received: from [129.46.226.27] (vpn-10-50-0-190.qualcomm.com [10.50.0.190]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8LIBdo6024528; Fri, 21 Sep 2007 11:11:40 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <68m7q1$3943n@gatewayhorse2.qualcomm.com> References: <68m7q1$3943n@gatewayhorse2.qualcomm.com> Date: Fri, 21 Sep 2007 11:11:37 -0700 To: Russ Housley From: Ted Hardie Subject: Re: [Geopriv] Response to appeal dated 22-June-2007 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: geopriv@ietf.org, andy@hxr.us, ietf@ietf.org, mankin@psg.com X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 1:16 PM -0400 9/21/07, Russ Housley wrote: >Ted: > >With great respect, I must disagree. The appeal says: "It is the position of the appellants that this removal violates the IETF process by which working groups are governed." This say to me that the appellants believe that Cullen Jennings violated IETF process by replacing the GEOPRIV WG Co-chairs at the time that he did so. I personally reread many BCPs as part of this appeal review, and I could not find any process that was violated by this action. Russ, With equal respect, that statement is part of a much larger context, and I think your reading is too narrow. The immediately prior paragraph says, to take one piece of context out: >In summary, the Co-chairs of the GEOPRIV working group conferred via telephone with >Cullen Jennings regarding irregularities of the GEOPRIV session at IETF 68. Mr. >Jennings participated in the discussion (detailed below) and at the very end of the >call, indicated that he desired to remove the Co-chairs. This was interpreted as a >type of threat. The Co-chairs then published a message to the GEOPRIV mailing list >describing the irregularities of the GEOPRIV meeting at IETF 68, specifically in order >to ensure that IETF process would be followed for the WG. Following this message, >Mr. Jennings sent a strongly worded message to the IETF list, and he removed the >Co-Chairs. This removal occurred during the time period when the Co-chairs were >seeking mailing list consensus on the items discussed during the GEOPRIV session at >IETF 68. The working group chairs are charged in our process with determining consensus of working groups. If an AD removed working group chairs *in order to ensure that a specific determination were made*, that would clearly be contrary to the way the IETF is meant to work, no matter what the AD's baseline prerogatives for determining personnel would be. (Note that I am not saying that this what happened here, but this is a point where the issue raised would be salient). That action would be fundamentally a violation of the process for determining working group consensus, as the AD would be ensuring a specific consensus call by putting in someone willing to make that determination. An appeal response by the IESG that said that they did not believe that this is what happened in this case seems to be what you intended (at least based on Sam's response). I must repeat, however, that this response appeared to me to focus instead on the baseline prerogative of the AD over that issue. >You are correct that any action taken by an AD can be appealed. In particular, RFC 2026 states: > > All appeals must be initiated within two months of the public > knowledge of the action or decision to be challenged. > >In this particular appeal, there is a lot of background information that describes events that happened outside of the two month window. These can only be taken as context for the actions under appeal. I appreciate your restatement of the important point that any action taken by an AD can be appealed, as well as Sam's personal statement to the same effect. If you are not willing to consider re-stating this appeal, a short statement by the IESG to that effect would be welcome. As it stands, statements by individual IESG members have no binding effect on later IESGs and the community is not necessarily notified when the interpretations change. As a concrete suggestion: "The IESG re-affirms that its reading of RFC 2026 is that any action made by an Area Director or the IESG may by made the subject of the conflict resolution mechanisms set out in Section 6.5 of RFC 2026. The IESG further wishes to highlight that the primary aim of the appeals mechanism set out there is to resolve conflicts and move the IETF as a whole towards consensus, and it urges all participants to approach them in that light." regards, Ted >Russ > > >At 11:49 AM 9/21/2007, Ted Hardie wrote: >>I believe this response (I hope inadvertently) appears to remove a valuable >>principle by which the IESG acted on appeals. >> >>I urge the IESG to reconsider the formulation of its response to the appeal >>to clarify the issues raised below. >> >> >>At 2:01 PM -0400 9/20/07, The IESG wrote: >>>IESG Response to the Appeal Against the Removal of the Co-chairs of the >>>GEOPRIV Working Group >>> >>> >>>Introduction >>> >>> This is the IESG response to the appeal by Randall Gellens, Allison >>> Mankin, and Andy Newton posted at: >>> >>> http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf >>> >>> Cullen Jennings recused from all discussion of this appeal. >>> >>> The appeal raises three major points for the IESG to address: >>> >>> 1. The removal of the WG Chairs violates IETF process; >>> >>> 2. The actions taken interfered with the consensus process; and >>> >>> 3. There is a conflict of interest. >>> >>> The appeal also proposes a remedy. This response includes some >>> comments about the proposed remedy. >>> >>>1. The removal of the WG Chairs violates IETF process >>> >>> RFC 2418 says: >>> >>> Working groups require considerable care and feeding. In addition >>>to >>> general participation, successful working groups benefit from the >>> efforts of participants filling specific functional roles. The Area >>> >>> Director must agree to the specific people performing the WG Chair, >>> >>> and Working Group Consultant roles, and they serve at the >>>discretion >>> of the Area Director. >>> >>> Since all WG chairs "serve at the discretion of the Area Director," >>> they can be replaced at any time. The previous GEOPRIV WG co-chairs >>> were told about their removal in private before the public >>> announcement. This action was not required, but it is the most >>> polite way to handle the situation. Perhaps the public announcement >>> could have provided some rationale, but the authority to remove a WG >>> chair is clear. >> >>In this response, the IESG appears to have read the appeal to state that the >>removal of the chairs was not within the authority of the Area Director. >> >>The appeal statement: >> >>http://www3.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf >> >>does not support this reading. It does not say that Area Directors >>do not have the right to remove chairs, it says that the manner >>and timing by which this was done interfered with the consensus process >>inappropriately. The remainder of the IESG statement below appears >>to attempt to address the interference issue. But in choosing to highlight >>that all "WG chairs serve at the discretion of the Area Director", >>the IESG appears to be saying that the personnel decisions of >>an Area Director or the IESG are not subject to appeal. >> >>During the time I served on the IESG, it was a general guideline that >>*any decision* of an Area Director or the IESG was subject to appeal >>to the IESG. While this is a broad reading of RFC 2026, Section 6.5, >>I think it is an important point and a principle worth retaining. The >>appeals process in the IETF is not simply a mechanism for establishing >>who has what rights; it is a mechanism for conflict resolution. By >>making all decisions subject to it, we ensure that conflicts which arise >>are dealt with as early as possible and with as little process as possible. >> >>If members of the community believe that a personnel decision >>was made in a way the interfered with the proper operation of the >>IETF, I believe asking the IESG to attempt to resolve the conflict is >>an appropriate thing to do. This appeal response, which re-asserts the >>authority of the AD to make the original decision, does not seem >>to support this use of the IETF's normal conflict resolution mechanism. >>Further, this appeal response appears to say that the only conflict resolution >>mechanism open to those who disagree with a personnel decision >>is to invoke one of the removal mechanisms for those who made it. >> >>I hope that the IESG will re-structure its response to this appeal >>to re-affirm that the conflict resolution mechanisms of the IETF are >>available for this purpose. I also encourage the IESG (and, frankly, >>the IETF community as a whole) to try to see the appeals process >>as a way of resolving conflict, rather than a quasi-legal process for determining >>whether a remedy will be granted. I understand how previous appeals >>have pushed everyone in that direction, but it is something we must >>continue to resist. I have worked with Allison, Andy, and Randy for >>many years, as well as Cullen and Jon. They are all experienced >>IETF folks who have toiled for years to make things work; forcing them >>into even more adversarial positions when conflicts do need resolution >>is a mistake, at least I see it. >> >>My thanks for your attention, >> regards, >> Ted _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Krickemeyer@aectec.com Fri Sep 21 14:22:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYn8z-0002QJ-5o for geopriv-archive@lists.ietf.org; Fri, 21 Sep 2007 14:22:25 -0400 Received: from ip-175-95.sn3.eutelia.it ([213.136.175.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYn8s-0001q2-Mx for geopriv-archive@lists.ietf.org; Fri, 21 Sep 2007 14:22:25 -0400 Received: from enzo-r266ptw68o by aectec.com with ASMTP id A809B8FC for ; Thu, 20 Sep 2007 20:26:18 +0200 Received: from enzo-r266ptw68o ([157.166.155.71]) by aectec.com with ESMTP id 9E33D3C5D161 for ; Thu, 20 Sep 2007 20:26:18 +0200 Message-ID: <029560FC.5A27C6CD@aectec.com> Date: Thu, 20 Sep 2007 20:26:00 +0200 From: "naxx Krickemeyer" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: geopriv-archive@lists.ietf.org Subject: ovamente Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Ru-mor N,e_w s_: Oncol._ogy M_e.d,. I,n,c'. (OT.C: ON'CO) a C_ancer Treat'me_nt S-ol*utions Gr*oup is s+a i+d to h_a v-e expe*ri,enced o,v+e-r a 1 000% i ncrea.se in reve_nue.s f_o r t-h.e fisc'al 3*r d quart,er end_ing J.u_l y*, 2+0-0_7 compa_r_ed w i,t h t_h'e prio,r y*e a-r whil*e fisca-l fourt'h q uarter r,esults f'o.r 2'0'0 7 a+r.e on tra-ck to exc.eed t_h_i's ye,ar’s th-ird quar,ter result*s. O+N C*O addi.tionall+y p lans to increa_*se serv_ice offe.ri,ngs whi,ch a r'e current.l y under_w ay. Don*’t w_a_i-t f.o.r t,h,e n*e w+s to c+o.m e o_u_t a+n,d l+o.s+e t'h*e oppo-rt_unity to g_e-t in fron_t of the gener.al in'v'esting pub.lic. O'n_cology M,e,d is in a multibi_ll ion d.ollar in du stry w+h'e'r'e t,h.e,y a'r+e ga+ining marke,t s*hare rapid ly. C a+l+l y_o+u.r br oker n,o_w f.o+r O+N_C,O'. From geopriv-bounces@ietf.org Fri Sep 21 15:53:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYoYk-0003vw-2g; Fri, 21 Sep 2007 15:53:06 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYoXb-0002jz-3z for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 15:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYoXa-0002iq-Q3 for geopriv@ietf.org; Fri, 21 Sep 2007 15:51:54 -0400 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYoXV-0004YO-FO for geopriv@ietf.org; Fri, 21 Sep 2007 15:51:54 -0400 Received: (qmail 19261 invoked by uid 0); 21 Sep 2007 19:51:28 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.231.48.203) by woodstock.binhost.com with SMTP; 21 Sep 2007 19:51:28 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Sep 2007 15:49:01 -0400 To: Ted Hardie From: Russ Housley In-Reply-To: References: <68m7q1$3943n@gatewayhorse2.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Message-Id: X-Mailman-Approved-At: Fri, 21 Sep 2007 15:53:05 -0400 Cc: geopriv@ietf.org, andy@hxr.us, ietf@ietf.org, mankin@psg.com Subject: [Geopriv] Re: Response to appeal dated 22-June-2007 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Ted: To begin with, I want to say that I agree with your perception of the appeal process. It is an important conflict resolution tool. The first thing that was done in the drafting of the appeal response was to list each of the claims in the appeal. That is why the introduction lists them: 1. The removal of the WG Chairs violates IETF process; 2. The actions taken interfered with the consensus process; and 3. There is a conflict of interest. The appeal response addresses each of these points with much more attention to number 2. >I must repeat, however, that this response appeared to me to focus >instead on the >baseline prerogative of the AD over that issue. I agree, the response to the first point, which was focused on the sentence that I quoted from the appeal in my previous message, was a reading on whether the act of replacing the GEOPRIV WG co-chairs violated IETF process or not. However, the response to the second point, I believe, addresses the rest of the paragraph that you quoted. > >You are correct that any action taken by an AD can be appealed. > >I appreciate your restatement of the important point that any action >taken by an AD can be appealed, >as well as Sam's personal statement to the same effect. If you are >not willing to consider re-stating >this appeal, a short statement by the IESG to that effect would be >welcome. As it stands, statements >by individual IESG members have no binding effect on later IESGs and >the community is not necessarily >notified when the interpretations change. I'd like to know if this is a topic of concern to people. >As a concrete suggestion: > >"The IESG re-affirms that its reading of RFC 2026 is that any action >made by an Area >Director or the IESG may by made the subject of the conflict >resolution mechanisms >set out in Section 6.5 of RFC 2026. The IESG further wishes to >highlight that the primary >aim of the appeals mechanism set out there is to resolve conflicts >and move the IETF >as a whole towards consensus, and it urges all participants to >approach them in that light." I will put your proposed text on the IESG telechat agenda for consideration as an IESG statement. Russ _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 16:10:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYopJ-0003fE-Ql; Fri, 21 Sep 2007 16:10:13 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYopI-0003er-G2 for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 16:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYopI-0003ej-6C for geopriv@ietf.org; Fri, 21 Sep 2007 16:10:12 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYopG-0005C2-Ro for geopriv@ietf.org; Fri, 21 Sep 2007 16:10:12 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l8LK9sGX042798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Sep 2007 15:09:54 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <251DDC89-F2E9-45B7-B602-3EA90CC60D23@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV From: Robert Sparks Date: Fri, 21 Sep 2007 15:09:52 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Geopriv] Short LC on radius-lo X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Folks, The "Carrying Location Objects in RADIUS and Diameter" received a lot of expert review and polish after it was last discussed on this list (around -10). I'd like the GEOPRIV WG to take a quick look and make sure it still says what the group wants it to say before the IESG takes the next step with it and to leave a record in the archive that we did that review. Please review http://www.ietf.org/internet-drafts/draft-ietf-geopriv- radius-lo-16.txt Respond to this list after you've looked at it, even if that response is "I've looked at it and it's ready to go". Please have your comments in by Oct 1. Thanks, RjS _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 21 18:29:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYqyg-0007Ol-Ow; Fri, 21 Sep 2007 18:28:03 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IYqyf-0007NI-Ci for geopriv-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 18:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYqyf-0007N6-2E; Fri, 21 Sep 2007 18:28:01 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYqyY-0001C3-Qj; Fri, 21 Sep 2007 18:28:01 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8LMRleS004753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Sep 2007 15:27:47 -0700 Received: from [129.46.226.27] (vpn-10-50-0-190.qualcomm.com [10.50.0.190]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8LMRjYC016440; Fri, 21 Sep 2007 15:27:46 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <68m7q1$3943n@gatewayhorse2.qualcomm.com> Date: Fri, 21 Sep 2007 15:27:45 -0700 To: Russ Housley From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: geopriv@ietf.org, ietf@ietf.org, mankin@psg.com Subject: [Geopriv] Re: Response to appeal dated 22-June-2007 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org At 3:49 PM -0400 9/21/07, Russ Housley wrote: > >>As a concrete suggestion: >> >>"The IESG re-affirms that its reading of RFC 2026 is that any action made by an Area >>Director or the IESG may by made the subject of the conflict resolution mechanisms >>set out in Section 6.5 of RFC 2026. The IESG further wishes to highlight that the primary >>aim of the appeals mechanism set out there is to resolve conflicts and move the IETF >>as a whole towards consensus, and it urges all participants to approach them in that light." > >I will put your proposed text on the IESG telechat agenda for consideration as an IESG statement. > Thank you; I look forward to hearing the IESG's response. regards, Ted Hardie _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From sabedin@COPPOLA.IT Sat Sep 22 06:47:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ2Vs-0000rZ-0w for geopriv-archive@lists.ietf.org; Sat, 22 Sep 2007 06:47:04 -0400 Received: from [88.245.99.81] (helo=[88.245.99.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ2Vr-0008Jy-4H for geopriv-archive@lists.ietf.org; Sat, 22 Sep 2007 06:47:03 -0400 Received: from mevlut ([180.148.105.185]:17622 "EHLO mevlut" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [88.245.99.81] with ESMTP id S22OIDVRIAZCAWNB (ORCPT ); Sat, 22 Sep 2007 13:47:16 +0300 Message-ID: <000a01c7fd05$e7927f30$5163f558@mevlut> From: "oguz sabedin" To: Subject: diorupru Date: Sat, 22 Sep 2007 13:47:00 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FD1F.0CDFB730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0005_01C7FD1F.0CDFB730 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://modaoc.com/ Night geopriv-archive sex life boring??, im sure it would spice up again if you had that extra = 3 inches oguz sabedin ------=_NextPart_000_0005_01C7FD1F.0CDFB730 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://modaoc.com/
Night geopriv-archive
sex life boring??, im sure it would spice up = again if=20 you had that extra 3 inches
oguz sabedin
------=_NextPart_000_0005_01C7FD1F.0CDFB730-- From Jeighms-Kuijper@aryasux.com Sat Sep 22 08:29:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ46p-0001X6-8e for geopriv-archive@lists.ietf.org; Sat, 22 Sep 2007 08:29:19 -0400 Received: from host188-247-static.30-87-b.business.telecomitalia.it ([87.30.247.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZ46i-0004eJ-Kr for geopriv-archive@lists.ietf.org; Sat, 22 Sep 2007 08:29:19 -0400 Received: by 10.12.104.16 with SMTP id KrVgknGrnpzcX; Sat, 22 Sep 2007 14:29:23 +0200 (GMT) Received: by 192.168.214.206 with SMTP id MqZNXHrEQeLDhm.7205997348774; Sat, 22 Sep 2007 14:29:21 +0200 (GMT) Date: Sat, 22 Sep 2007 14:29:18 +0200 From: "Jeighms Kuijper" Reply-To: "Jeighms Kuijper" Message-ID: <658813779246.560473861313@aryasux.com> To: Subject: patistel MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Wazzup geopriv-archive The demand for these pills is so high .. prices will go up soon Jeighms Kuijper http://mothit.com/ From geopriv-bounces@ietf.org Sat Sep 22 12:40:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ81L-0007It-4X; Sat, 22 Sep 2007 12:39:55 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZ81K-0007Ig-FM for geopriv-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 12:39:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ81K-0007Hj-18 for geopriv@ietf.org; Sat, 22 Sep 2007 12:39:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ81J-0007wB-IU for geopriv@ietf.org; Sat, 22 Sep 2007 12:39:53 -0400 X-IronPort-AV: E=Sophos;i="4.20,287,1186372800"; d="scan'208";a="71802757" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Sep 2007 12:39:56 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8MGdrfG015726; Sat, 22 Sep 2007 12:39:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8MGdqYa017706; Sat, 22 Sep 2007 16:39:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Sep 2007 12:39:52 -0400 Received: from [10.5.0.226] ([10.82.241.126]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Sep 2007 12:39:52 -0400 In-Reply-To: <205E33A8-F6E9-4AEB-BF3D-79A90C8657D5@cs.columbia.edu> References: <46F39883.50704@gmx.net> <205E33A8-F6E9-4AEB-BF3D-79A90C8657D5@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EECE5D0-CD4E-4B5D-B4C4-6A261E0F4824@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Geopriv] Issue raised with Geolocation Policy Date: Sat, 22 Sep 2007 09:39:50 -0700 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Sep 2007 16:39:52.0242 (UTC) FILETIME=[32E7A920:01C7FD37] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=928; t=1190479193; x=1191343193; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Geopriv]=20Issue=20raised=20with=20Geolocation=20Pol icy |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=iMdJ+uIE3/vW5cgKztZek3CYqMmDM95k1RyWelYizbg=; b=gz5MUy345HKm7tE1wt61qBW8AEh8MUC1JkwlAgi2FOQWqCTWMsx6LGOkmxuTXAI7GI42cd9P H+92TJNfGc6MZuaEc6weQirKs7fIpXjolTBouGBuD/YCZxukOmemoahw; Authentication-Results: rtp-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Just thinking out loud here, no idea how to solve this yet ... If the random number was different each time you queried, then it seems like a bunch of quires would distribute across the regions and taking the average of them would give you a close estimate of the location. If the random number, once picked, was the same for all the queries until the target had moved enough that the answer was no long true, then something like that might be workable. It would be interesting to think about how much location information would be revealed by a a series of samples of someone driving on a highway across the country. Cullen On Sep 21, 2007, at 10:13 AM, Henning Schulzrinne wrote: > There would be a way to address this: you add a random number to > the position, with an absolute value of half the privacy region. > That way, movement doesn't much matter. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 22 13:11:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ8Vf-0000Da-68; Sat, 22 Sep 2007 13:11:15 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZ8Vd-0000DE-OD for geopriv-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 13:11:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ8Vd-00007m-3G for geopriv@ietf.org; Sat, 22 Sep 2007 13:11:13 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ8VY-0000DA-Io for geopriv@ietf.org; Sat, 22 Sep 2007 13:11:08 -0400 Received: from [10.0.44.126] (apc01.spektrum-hotspot.de [212.77.232.233]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8MHB2dG018069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Sep 2007 13:11:04 -0400 (EDT) In-Reply-To: <0EECE5D0-CD4E-4B5D-B4C4-6A261E0F4824@cisco.com> References: <46F39883.50704@gmx.net> <205E33A8-F6E9-4AEB-BF3D-79A90C8657D5@cs.columbia.edu> <0EECE5D0-CD4E-4B5D-B4C4-6A261E0F4824@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7192E745-679A-4119-86AC-CE46456A0E0D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Issue raised with Geolocation Policy Date: Sat, 22 Sep 2007 19:11:03 +0200 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org That's roughly what I was thinking of. This doesn't work for civic locations, at least not without a lot of knowledge about proximate streets and cities, or a civic-to-geo+noise- to-civic mapping. On Sep 22, 2007, at 6:39 PM, Cullen Jennings wrote: > > Just thinking out loud here, no idea how to solve this yet ... If > the random number was different each time you queried, then it > seems like a bunch of quires would distribute across the regions > and taking the average of them would give you a close estimate of > the location. If the random number, once picked, was the same for > all the queries until the target had moved enough that the answer > was no long true, then something like that might be workable. It > would be interesting to think about how much location information > would be revealed by a a series of samples of someone driving on a > highway across the country. > > Cullen > > On Sep 21, 2007, at 10:13 AM, Henning Schulzrinne wrote: > >> There would be a way to address this: you add a random number to >> the position, with an absolute value of half the privacy region. >> That way, movement doesn't much matter. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 22 14:11:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ9QB-0004Em-AG; Sat, 22 Sep 2007 14:09:39 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZ9Q9-0004Eh-TF for geopriv-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 14:09:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ9Q9-0004EZ-FN for geopriv@ietf.org; Sat, 22 Sep 2007 14:09:37 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ9Q8-0001lL-NA for geopriv@ietf.org; Sat, 22 Sep 2007 14:09:37 -0400 Received: from [10.0.44.126] (apc01.spektrum-hotspot.de [212.77.232.233]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8MI9WeO025458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Sep 2007 14:09:33 -0400 (EDT) In-Reply-To: <46F3A8C8.6040402@gmx.net> References: <46F3A8C8.6040402@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Date: Sat, 22 Sep 2007 20:09:34 +0200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Some quick comments inline. I appreciate the need to make the user interface manageable, and thus I'm in favor of dropping functionality if it is unlikely to be implemented consistently, or if users are likely to be confused by the decisions they have to make or the results. On Sep 21, 2007, at 1:19 PM, Hannes Tschofenig wrote: > Hi Lisa, > Hi all, > > Background: draft-ietf-geopriv-policy is currently in IESG > Evaluation and Lisa has put a DISCUSS > on the document. Here are Lisa's comments and I would like to > discuss them on the mailing list: > https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/ > comment/71788/? > https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/ > comment/71781/? > > > > It seems that geo-spatial policy creation requires some kind of > user interface that includes a map. Is that correct? Are devices > without maps then unable to modify or even read policies? > I don't think a map is required, although this is clearly helpful in some scenarios. For example, a reasonable user interface might provide the option "Hide my location if I'm within 50 miles from home", and then translate this into a polygon. A separate user agent would best render this as a polygon on a map. I'm not too concerned about the map issues. Maps are now widely available and geo coordinate information is, after all, best displayed on a map. I'm not sure if there's a suggestion for an alternative here. Conditions such as "within 50 miles of home" are more user-friendly, but seem much harder to implement consistently and correctly. > I am not sure that the polygons are as cut-and-dried as they > appear. I'd like to understand better: > - how one knows what is the inside of the polygon, and what is the > outside > - ... how that interacts with poles and other problems mapping 2D > to a sphere > - how the altitude stuff works at all with client GUIs My inclination would be to drop altitude altogether. The number of policies where altitude seems necessary seems rather small. "Only show my position if I'm not flying" seems cute, but not terribly likely. > - when is altitude known and unknown, independent of knowing a > rough long/lat position > - whether you can define a polygon for "Alberta" and one for > "Saskatchewan" and have any point be in one or the other or > completely outside both -- but not *inside* both, and not stuck in- > between I don't understand this particular item. > > When it comes to users viewing policies created in the past, the > lack of human-readable labels and comments is going to be a real > usability problem. Comments are helpful, but I suspect they can easily mislead, where the comment says one thing and the rule really does something else. I do think a general rule comment would be helpful and we should have added this to common-policy. > > What happens when a user or user-agent creates a non-sensical geo- > political or geo-spatial location? The UI should perform sanity checks. > Are all geo-political elements *really* allowed in conditions? One > possible non-sensical policy would be "Show my location unless I'm > in seat 32A". Aren't there any restrictions here? I think we should drop combined civic and geo rules. Civic conditions should have higher-level elements. Unfortunately, we can't specify all conditions, since not every civic address will need, for example, all A* levels. This depends on the country being described. Thus, in some cases, I can't see a way to avoid specifying addresses that make syntactic sense, but are somewhat peculiar. (Example: Main Street in all cities within a county.) > > How are user agents supposed to handle mixed geo-spatial and civic > location conditions? How would that be displayed or represented in > a list of policy elements? > As I noted above, I would drop this. It does seem to generate artificial complexity. Henning _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From lasisi.Padgett@tripinsurance.net Sat Sep 22 16:44:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZBpt-0007lc-9s for geopriv-archive@lists.ietf.org; Sat, 22 Sep 2007 16:44:21 -0400 Received: from 212-200-195-253.adsl.static.sezampro.yu ([212.200.195.253] helo=[212.200.219.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZBpM-0005Of-PD for geopriv-archive@lists.ietf.org; Sat, 22 Sep 2007 16:43:50 -0400 Received: by 10.124.175.223 with SMTP id QaquszLhtdrZm; Sat, 22 Sep 2007 22:43:59 +0200 (GMT) Received: by 192.168.67.13 with SMTP id lIrlOUaWQQXzkK.0429797636396; Sat, 22 Sep 2007 22:43:57 +0200 (GMT) Message-ID: <000e01c7fd59$4a3fcb80$4edbc8d4@racunar> From: "lasisi Padgett" To: Subject: uarmak Date: Sat, 22 Sep 2007 22:43:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C7FD6A.0DC89B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.7 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C7FD6A.0DC89B80 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable http://www.moblione.com/ Hi geopriv-archive how do you measure up to other men? lasisi Padgett ------=_NextPart_000_0005_01C7FD6A.0DC89B80 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
http://www.moblione.com/
Hi geopriv-archive
how do you measure up to other = men?
lasisi Padgett
------=_NextPart_000_0005_01C7FD6A.0DC89B80-- From geopriv-bounces@ietf.org Sun Sep 23 05:51:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZO70-0000R5-6b; Sun, 23 Sep 2007 05:50:50 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZO6y-0000L0-2F for geopriv-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 05:50:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZO6x-0000Jz-CT; Sun, 23 Sep 2007 05:50:47 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZO6w-0002Ov-Rn; Sun, 23 Sep 2007 05:50:47 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 26E21198670; Sun, 23 Sep 2007 12:50:46 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ADBE719865D; Sun, 23 Sep 2007 12:50:45 +0300 (EEST) Message-ID: <46F636F5.4090501@piuha.net> Date: Sun, 23 Sep 2007 12:50:45 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Sam Hartman , Ted Hardie Subject: Re: [Geopriv] Response to appeal dated 22-June-2007 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: geopriv@ietf.org, ietf@ietf.org, The IESG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Ted, Sam, I also agree with your points, and yes, even personnel decisions by AD can be appealed. The appeals process is not intended to merely inspect whether formal right to perform an action existed; such appeals would be very easily decided. In most cases, an appeal involves an action which is within the jurisdiction of the chair or AD in question but where we have to ask whether the decision was right. For instance, did the AD interpret Last Call discussion, WG situation, etc. correctly? Was the decision to approve the document or replace chairs reasonable or should these decisions be corrected in some way? This is the way I believe we dealt with this appeal too. Jari _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Tomi@infina.ch Sun Sep 23 06:08:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZOOR-0000nd-FX for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 06:08:51 -0400 Received: from host17-250-static.43-85-b.business.telecomitalia.it ([85.43.250.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZOOQ-0002dm-Ma for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 06:08:51 -0400 Received: from FILIPPO ([182.125.32.178]:26714 "EHLO FILIPPO" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [85.43.250.17] with ESMTP id S22IHIJQSDGQKCTJ (ORCPT ); Sun, 23 Sep 2007 12:09:05 +0200 Message-ID: <000301c7fdc9$bcd99b60$11fa2b55@FILIPPO> From: "Tomi muir" To: Subject: unuavikn Date: Sun, 23 Sep 2007 12:08:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C7FDDA.80626B60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.7 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0009_01C7FDDA.80626B60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.gronskan.com/ Night geopriv-archive Voted no.1 schlong enlargement product 2007 Tomi muir ------=_NextPart_000_0009_01C7FDDA.80626B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.gronskan.com/
Night geopriv-archive
Voted no.1 schlong enlargement product = 2007
Tomi muir
------=_NextPart_000_0009_01C7FDDA.80626B60-- From KaWahhatcher@57.asp020.com Sun Sep 23 09:33:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZRaK-0005jQ-OI for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 09:33:20 -0400 Received: from host33-1-static.14-79-b.business.telecomitalia.it ([79.14.1.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZRaJ-0006wn-Uk for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 09:33:20 -0400 Received: by 10.116.32.209 with SMTP id HZxVzCDnFKyFT; Sun, 23 Sep 2007 15:33:59 +0200 (GMT) Received: by 192.168.170.4 with SMTP id WZTrhmnnOrrJFd.5724797073664; Sun, 23 Sep 2007 15:33:57 +0200 (GMT) Message-ID: <000e01c7fde6$62c1ec50$21010e4f@pcmarta> From: "KaWah hatcher" To: Subject: netfols Date: Sun, 23 Sep 2007 15:33:54 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FDF7.264ABC50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.0 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0008_01C7FDF7.264ABC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.gtartner.com/ Evening geopriv-archive tired of being just mr average to the ladies? KaWah hatcher ------=_NextPart_000_0008_01C7FDF7.264ABC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.gtartner.com/
Evening geopriv-archive
tired of being just mr average to the = ladies?
KaWah hatcher
------=_NextPart_000_0008_01C7FDF7.264ABC50-- From Prevost@stphils.com Sun Sep 23 11:36:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZTVM-0004g4-C2 for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 11:36:20 -0400 Received: from 248.30.broadband5.iol.cz ([88.100.30.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZTVK-0001fW-L4 for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 11:36:20 -0400 Received: by 10.222.198.157 with SMTP id oxTfJacGslcDe; Sun, 23 Sep 2007 17:37:04 +0200 (GMT) Received: by 192.168.144.70 with SMTP id utmMNvlHBOOJKr.8031753451800; Sun, 23 Sep 2007 17:37:02 +0200 (GMT) Date: Sun, 23 Sep 2007 17:36:59 +0200 From: "Cayce Prevost" Reply-To: "Cayce Prevost" Message-ID: <242123490032.913924056001@stphils.com> To: Subject: surangue MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good evening geopriv-archive Do you use extra large condoms? Cayce Prevost http://gslipin.com/ From Mariana942@DGSHTS.com Sun Sep 23 15:55:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZXXl-0002td-77 for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 15:55:05 -0400 Received: from [151.63.137.124] (helo=[151.63.141.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZXXd-0000Q6-Lb for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 15:54:58 -0400 Received: by 10.4.62.181 with SMTP id RNIWHFWSLLxZE; Sun, 23 Sep 2007 21:56:25 +0200 (GMT) Received: by 192.168.125.156 with SMTP id YHUqPAwfIIiXvd.7224081496422; Sun, 23 Sep 2007 21:56:23 +0200 (GMT) Message-ID: <1D6B6AE0.FBC45A91@DGSHTS.com> Date: Sun, 23 Sep 2007 21:56:20 +0200 From: "Mariana Grams" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: geopriv-archive@lists.ietf.org Subject: erhufrov Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Regards geopriv-archive myspace recommends this website for all MEN looking to get 2-3" bigger cock Mariana Grams http://siadz.com/ From geopriv-bounces@ietf.org Sun Sep 23 16:48:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZYMX-0007zC-2y; Sun, 23 Sep 2007 16:47:33 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZ3rr-0007dS-T6 for geopriv-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 08:13:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ3rr-0007dK-Gl; Sat, 22 Sep 2007 08:13:51 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ3rr-0001jb-1b; Sat, 22 Sep 2007 08:13:51 -0400 X-IronPort-AV: E=Sophos;i="4.20,286,1186351200"; d="scan'208";a="153861173" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Sep 2007 14:13:48 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8MCDmvm003905; Sat, 22 Sep 2007 14:13:48 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp4257.cisco.com [10.61.80.160]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8MCDctV008841; Sat, 22 Sep 2007 12:13:42 GMT Message-ID: <46F506DE.3070307@cisco.com> Date: Sat, 22 Sep 2007 14:13:18 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Russ Housley References: <68m7q1$3943n@gatewayhorse2.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=191; t=1190463228; x=1191327228; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Response=20to=20appeal=20dated=2022-June-2007 |Sender:=20; bh=M65njZet8u8jgSdtx335+Llny/NDVcglvqwddNvMQjc=; b=M5/u9fKxrGajA8r1E5ljmj6PLw1jbQWrkyr3Dy8sJ1XaR29xn0EjcodCr+GWugZfOnF3SH3Y dGqhkyKVM7u11iS4HWSjUMEQZMox6JjiNF3UO9rAMNAWo76JbW1Sm7Od; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Sun, 23 Sep 2007 16:47:31 -0400 Cc: Ted Hardie , geopriv@ietf.org, ietf@ietf.org, mankin@psg.com Subject: [Geopriv] Re: Response to appeal dated 22-June-2007 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Russ Housley wrote: > I'd like to know if this is a topic of concern to people. I had not realized that IESG statements bound future IESGs. I find that in itself disturbing. Eliot _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Lonnie460@perlescalpe.com Sun Sep 23 18:37:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZa4o-0000up-UV for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 18:37:22 -0400 Received: from [201.240.94.10] (helo=client-201.240.94.10.speedy.net.pe) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZa4j-0002vA-GT for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 18:37:18 -0400 Received: from Milagros ([122.197.14.103] helo=Milagros) by client-201.240.94.10.speedy.net.pe ( sendmail 8.13.3/8.13.1) with esmtpa id 1btWvQ-000LQN-Yd for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 17:38:01 -0500 Message-ID: <000c01c7fe32$543f1a30$0a5ef0c9@Milagros> From: "Lonnie lorant" To: Subject: nsjouwde Date: Sun, 23 Sep 2007 17:37:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7FE08.6B691230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.0 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0007_01C7FE08.6B691230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://scrir.com/ greeting geopriv-archive my girl loves the new me. Lonnie lorant ------=_NextPart_000_0007_01C7FE08.6B691230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://scrir.com/
greeting geopriv-archive
my girl loves the new me.
Lonnie lorant
------=_NextPart_000_0007_01C7FE08.6B691230-- From EmersonpapuaBlanchard@researchbuzz.org Sun Sep 23 19:12:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZacO-0008IX-RI for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 19:12:04 -0400 Received: from pc-69-176-45-190.cm.vtr.net ([190.45.176.69] helo=rhino) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZacM-00053M-12 for geopriv-archive@lists.ietf.org; Sun, 23 Sep 2007 19:12:02 -0400 Message-ID: <623001c7fe37$285c6a30$6400a8c0@rhino> From: "Emory Joyce" To: Subject: Fwd: Thanks, we are ready to give a business loan for a low month payment Date: Sun, 23 Sep 2007 19:10:17 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_622C_01C7FE37.285C6A30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_622C_01C7FE37.285C6A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If you have your own business and wish IMMEDIATE money to spend ANY way = you like or need Extra money to give the company a boost or need A low = interest loan - NO STRINGS ATTACHED, here is our best deal we can offer = you TODAY (hurry, this deal will expire THIS NIGHT): $69,000+ loan Hurry, when the deal is gone, it is gone. Simply Call Us... Don't worry about approval, your credit will not disqualify you! Call Us Free on 877-292-6891 ------=_NextPart_000_622C_01C7FE37.285C6A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit doesn't matter to=20 us!
=20
 
If you have your own business and = wish=20 IMMEDIATE money to spend ANY way you like or need Extra money to give = the=20 company a boost or need A low interest loan - NO STRINGS ATTACHED, here = is our=20 best deal we can offer you TODAY (hurry, this deal will expire THIS=20 NIGHT):
=20
 
$69,000+ loan
 
Hurry, when the deal is gone, it = is gone.=20 Simply Call Us...
=20
 
Don't worry about approval, your = credit will=20 not disqualify you!
=20
 
Call Us Free on = 877-292-6891
------=_NextPart_000_622C_01C7FE37.285C6A30-- From geopriv-bounces@ietf.org Mon Sep 24 04:56:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjjC-0008OU-9X; Mon, 24 Sep 2007 04:55:42 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZjjA-0008NV-MN for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 04:55:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjjA-0008I8-5m for geopriv@ietf.org; Mon, 24 Sep 2007 04:55:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZjj4-0001wY-Pw for geopriv@ietf.org; Mon, 24 Sep 2007 04:55:35 -0400 Received: (qmail invoked by alias); 24 Sep 2007 08:55:33 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp003) with SMTP; 24 Sep 2007 10:55:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+lVg9O6CilYvmvpjvk9xfEsusTPMzqMa6ThfiQQF ddXiu8YDN5fDCy Message-ID: <46F77B84.8060702@gmx.net> Date: Mon, 24 Sep 2007 10:55:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy References: <46F3A8C8.6040402@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > Some quick comments inline. I appreciate the need to make the user > interface manageable, and thus I'm in favor of dropping functionality > if it is unlikely to be implemented consistently, or if users are > likely to be confused by the decisions they have to make or the results. > > On Sep 21, 2007, at 1:19 PM, Hannes Tschofenig wrote: > >> Hi Lisa, >> Hi all, >> >> Background: draft-ietf-geopriv-policy is currently in IESG Evaluation >> and Lisa has put a DISCUSS on the >> document. Here are Lisa's comments and I would like to discuss them >> on the mailing list: >> https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71788/? >> >> https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71781/? >> >> >> >> >> It seems that geo-spatial policy creation requires some kind of user >> interface that includes a map. Is that correct? Are devices without >> maps then unable to modify or even read policies? >> > > I don't think a map is required, although this is clearly helpful in > some scenarios. For example, a reasonable user interface might provide > the option "Hide my location if I'm within 50 miles from home", and > then translate this into a polygon. A separate user agent would best > render this as a polygon on a map. > > I'm not too concerned about the map issues. Maps are now widely > available and geo coordinate information is, after all, best displayed > on a map. > > I'm not sure if there's a suggestion for an alternative here. > Conditions such as "within 50 miles of home" are more user-friendly, > but seem much harder to implement consistently and correctly. Maybe the suggestion is to provide a mechanism to label a certain geographical region for later usage in policies. Assume that an end host would configure these policies then someone (like the enterprise administrator, the user with the help of a map tool, the operator) would provide pre-defined regions that are labeled. Currently, the user interface could provide this functionality but there are no protocol features to enable them, i.e., the user interface at the Rule Maker would have to know what "home" means and then translate that to a polygon. If I recall it correctly then GML provides these functionality even at a XML level. > >> I am not sure that the polygons are as cut-and-dried as they appear. >> I'd like to understand better: >> - how one knows what is the inside of the polygon, and what is the >> outside >> - ... how that interacts with poles and other problems mapping 2D to >> a sphere >> - how the altitude stuff works at all with client GUIs > > My inclination would be to drop altitude altogether. The number of > policies where altitude seems necessary seems rather small. "Only show > my position if I'm not flying" seems cute, but not terribly likely. That's fine for me as well. > >> - when is altitude known and unknown, independent of knowing a rough >> long/lat position >> - whether you can define a polygon for "Alberta" and one for >> "Saskatchewan" and have any point be in one or the other or >> completely outside both -- but not *inside* both, and not stuck >> in-between > > I don't understand this particular item. > Same for me. >> >> When it comes to users viewing policies created in the past, the lack >> of human-readable labels and comments is going to be a real usability >> problem. > > Comments are helpful, but I suspect they can easily mislead, where the > comment says one thing and the rule really does something else. I do > think a general rule comment would be helpful and we should have added > this to common-policy. Sounds reasonable to me. We could add an element to allow the Rule Maker to provide some human-readable text around the policy. > > >> >> What happens when a user or user-agent creates a non-sensical >> geo-political or geo-spatial location? > > The UI should perform sanity checks. > >> Are all geo-political elements *really* allowed in conditions? One >> possible non-sensical policy would be "Show my location unless I'm in >> seat 32A". Aren't there any restrictions here? > > I think we should drop combined civic and geo rules. Civic conditions > should have higher-level elements. Unfortunately, we can't specify all > conditions, since not every civic address will need, for example, all > A* levels. This depends on the country being described. Thus, in some > cases, I can't see a way to avoid specifying addresses that make > syntactic sense, but are somewhat peculiar. (Example: Main Street in > all cities within a county.) > The document does not allow compound location to be specified. One can only specific a condition with civic location and another condition with geodetic location information. You cannot mix the two. I also believe that we should not get rid of either the geodetic nor the civic location condition since both have their right to exist. As mentioned in the response to Tim I believe we should * clarify the usage of both in the document and * allow the Rule Maker to indicate that the server should do the translation into the other format. > >> >> How are user agents supposed to handle mixed geo-spatial and civic >> location conditions? How would that be displayed or represented in a >> list of policy elements? >> > > As I noted above, I would drop this. It does seem to generate > artificial complexity. Let us try to be specific. There is no compound location information provided in the document. We deleted this part some time ago. There is, however, the ability to specify a condition based on civic location information and another condition in geodetic format. Is there the suggestion to delete either civic or geodetic location information conditions entirely? Ciao Hannes > > > Henning _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 05:06:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjtD-0002xP-AO; Mon, 24 Sep 2007 05:06:03 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZjtC-0002tu-Pt for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 05:06:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjtC-0002sj-FW for geopriv@ietf.org; Mon, 24 Sep 2007 05:06:02 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZjt7-0000Vr-0c for geopriv@ietf.org; Mon, 24 Sep 2007 05:06:02 -0400 Received: from [192.168.0.41] (pool-70-21-185-251.nwrk.east.verizon.net [70.21.185.251]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8O95ctc015543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 24 Sep 2007 05:05:39 -0400 (EDT) In-Reply-To: <46F77B84.8060702@gmx.net> References: <46F3A8C8.6040402@gmx.net> <46F77B84.8060702@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Date: Mon, 24 Sep 2007 05:05:50 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Sep 24, 2007, at 4:55 AM, Hannes Tschofenig wrote: > Hi Henning, > > > Maybe the suggestion is to provide a mechanism to label a certain > geographical region for later usage in policies. Assume that an end > host would configure these policies then someone (like the > enterprise administrator, the user with the help of a map tool, the > operator) would provide pre-defined regions that are labeled. > > Currently, the user interface could provide this functionality but > there are no protocol features to enable them, i.e., the user > interface at the Rule Maker would have to know what "home" means > and then translate that to a polygon. > > If I recall it correctly then GML provides these functionality even > at a XML level. Labeling regions would require a separate data set, i.e., something outside the current common-policy framework. Also, this would have its own set of problems. If the operator changes such a region, the user would suddenly, and without notification, have a very different privacy policy. In addition, unless there is a guarantee that these regions are accessible by users and can be defined by users, it would be very difficult for one user to maintain the same set of privacy policies across multiple different service providers. Finally, I'm not sure how this would address the issue of having to have map displays. Almost all such regions would be either simple civic regions ("Bergen county") or would need a map to be unambiguous to most users ("New York metro area"). > > Sounds reasonable to me. > We could add an element to allow the Rule Maker to provide some > human-readable text around the policy. And maybe add a 'comment' attribute to the rule. This, however, seems more appropriate for the common-policy document, as a trivial extension, since it is by no means specific to geopriv-policy. > > Is there the suggestion to delete either civic or geodetic location > information conditions entirely? > I'm not suggesting this, but I'm sure Lisa can clarify her concerns. > > Ciao > Hannes > >> >> >> Henning > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 05:36:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkMM-0007Ja-Jy; Mon, 24 Sep 2007 05:36:10 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZkML-0007JV-OJ for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 05:36:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkML-00071n-AE for geopriv@ietf.org; Mon, 24 Sep 2007 05:36:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZkMA-0003E6-Af for geopriv@ietf.org; Mon, 24 Sep 2007 05:35:58 -0400 Received: (qmail invoked by alias); 24 Sep 2007 09:35:57 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp043) with SMTP; 24 Sep 2007 11:35:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1837W0pwPo3CcRGTcxrFCkTYxOu3vKyeN76k3P8+r bwZFmkPhF8lxMD Message-ID: <46F784FC.9020708@gmx.net> Date: Mon, 24 Sep 2007 11:35:56 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy References: <46F3A8C8.6040402@gmx.net> <46F77B84.8060702@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > > On Sep 24, 2007, at 4:55 AM, Hannes Tschofenig wrote: > >> Hi Henning, >> >> >> Maybe the suggestion is to provide a mechanism to label a certain >> geographical region for later usage in policies. Assume that an end >> host would configure these policies then someone (like the enterprise >> administrator, the user with the help of a map tool, the operator) >> would provide pre-defined regions that are labeled. >> >> Currently, the user interface could provide this functionality but >> there are no protocol features to enable them, i.e., the user >> interface at the Rule Maker would have to know what "home" means and >> then translate that to a polygon. >> >> If I recall it correctly then GML provides these functionality even >> at a XML level. > > Labeling regions would require a separate data set, i.e., something > outside the current common-policy framework. Also, this would have its > own set of problems. If the operator changes such a region, the user > would suddenly, and without notification, have a very different > privacy policy. In addition, unless there is a guarantee that these > regions are accessible by users and can be defined by users, it would > be very difficult for one user to maintain the same set of privacy > policies across multiple different service providers. Finally, I'm not > sure how this would address the issue of having to have map displays. > Almost all such regions would be either simple civic regions ("Bergen > county") or would need a map to be unambiguous to most users ("New > York metro area"). > > I agree. Hence, it seems that such a mechanism would actually require additional extensions and aspects that need to be brought into consideration. For the time being it might be better to deal with these aspects on a user interface level. Maybe that's something to investigate in the future... > >> >> Sounds reasonable to me. >> We could add an element to allow the Rule Maker to provide some >> human-readable text around the policy. > > And maybe add a 'comment' attribute to the rule. This, however, seems > more appropriate for the common-policy document, as a trivial > extension, since it is by no means specific to geopriv-policy. True; thereby one would inherit it to the geolocation and presence document as well. > > >> >> Is there the suggestion to delete either civic or geodetic location >> information conditions entirely? >> > > I'm not suggesting this, but I'm sure Lisa can clarify her concerns. Ciao Hannes > >> >> Ciao >> Hannes >> >>> >>> >>> Henning >> _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 06:13:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkvx-0001OQ-TI; Mon, 24 Sep 2007 06:12:57 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZkvw-0001O5-H6 for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 06:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkvw-0001Nt-7F; Mon, 24 Sep 2007 06:12:56 -0400 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZkvu-0002KI-S6; Mon, 24 Sep 2007 06:12:56 -0400 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8OACY5O004142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2007 12:12:34 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8OACY4V030958; Mon, 24 Sep 2007 12:12:34 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 12:12:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Sep 2007 12:12:33 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB1E5516@DEMUEXC012.nsn-intra.net> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF019E0D5F@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-geopriv-policy-12.txt Thread-Index: Acf6NwSJXtzoHQWJTfa5KTFy9wttCABeVOHQALeNslA= References: <46F03C1A.3020905@ericsson.com> <941D5DCD8C42014FAF70FB7424686DCF019E0D5F@eusrcmw721.eamcs.ericsson.se> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext Eric Gray" , "Henning Schulzrinne" , "John B Morris" , "Jorge Cuellar" , "General Area Review Team" X-OriginalArrivalTime: 24 Sep 2007 10:12:34.0935 (UTC) FILETIME=[6D378070:01C7FE93] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: geopriv@ietf.org Subject: [Geopriv] AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Eric,=20 thank you for your Gen-Art review of the geolocation policy document.=20 A few minor comments below:=20 > -----Urspr=FCngliche Nachricht----- > Von: ext Eric Gray [mailto:eric.gray@ericsson.com]=20 > Gesendet: Donnerstag, 20. September 2007 21:11 > An: Henning Schulzrinne; Tschofenig, Hannes (NSN - DE/Germany=20 > - MiniMD); John B Morris; Jorge Cuellar; General Area Review Team > Cc: Cullen Jennings (fluffy) > Betreff: Gen-ART review of draft-ietf-geopriv-policy-12.txt >=20 > =20 > I am the assigned Gen-ART reviewer for=20 > draft-ietf-geopriv-policy-12.txt >=20 > For background on Gen-ART, please see the FAQ at > . >=20 > Please resolve these comments along with any other comments you may=20 > receive. >=20 > Document: draft-ietf-geopriv-policy-12.txt >=20 > Summary: This draft is essentially ready for publication. >=20 > Comments/Questions: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The last sentence in the introduction (last sentence on page 5): where > do the authors anticipate actions will be defined? Same question also > would apply to section 5. The Common Policy framework does not require that every extension = defines child elements for=20 * actions * conditions, and=20 * transformations When actions are not relevant for a particular problem space then they = can be omitted. We believe it is the case for this document.=20 When this document is used in the context and in combination with the = presence authorization policies then the actions defined in the presence = authorization policy document would be found in a specific rule.=20 For the presence authorization policy document please look at:=20 http://tools.ietf.org/wg/simple/draft-ietf-simple-presence-rules/ Does this answer your question?=20 > ______________________________________________________________ > _________ >=20 > In the next-to-last paragraph in section 4.1 (on page 10), there is an > interesting (and interestingly confusing) discussion of a possibility > of supporting co-planar (but not necessarily constant altitude) and/or > nearly co-planar location polygons - which is then=20 > (apparently) negated > in the last sentence. Is it the intention - behind saying=20 > "two polygon > forms are permitted" - to assert that all other polygon forms are "not > permitted" (i.e. - disallowed/forbidden)? If that is the case, this > paragraph could probably be simplified. I would suggest=20 > something like: >=20 > In order for the notion of a location that is defined as within a > specific polygon to make sense, points specified for the polygon=20 > MUST be coplanar. To avoid implementation complexity, only two > polygon forms are permitted: polygons specified using EPSG 4326,=20 > and polygons specified using EPSG 4979 with a constant altitude=20 > value. We took the current text from the following OGC document=20 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification 06-142, Version: 0.0.9, December 2006. that is also used for other GEOPRIV documents, such as = http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-08= .txt We just wanted to make sure that there is no contradiction between this = work and the rest of the GEOPRIV work.=20 Still, your proposal sounds good to me. The difference between your text = and the text from the OGC document is only that the current text = indicates that an implementation may accept altitude values with a = different height.=20 Based on the current discussions I got the impression that we are going = to delete the altitude issue and hence this problem might go away = automatically. =20 >=20 > It is then possible to consider whether or not it makes sense=20 > to retain: >=20 > However, implementations SHOULD be prepared to accept small > variations=20 > that might occur depending on whether the the polygon is=20 > specified on >=20 > a plane in space, or only relative to the ellipsoid. =20 >=20 Correct.=20 >=20 > NITs: > =3D=3D=3D=3D >=20 > Towards the bottom of page 4, "evalation" should be > "evaluation"... Thanks.=20 _______________________________________________ __________ > ______________ >=20 > In section 12 (Security Considerations), there is what appears to be > an extra closing paren at the end of the next-to-last sentence. Correct. Thanks.=20 Ciao Hannes >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 09:40:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZoAM-0007YQ-4D; Mon, 24 Sep 2007 09:40:02 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZoAJ-0007Ur-98 for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 09:39:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZoAI-0007TL-Vo for geopriv@ietf.org; Mon, 24 Sep 2007 09:39:58 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZoAB-0007sw-Kq for geopriv@ietf.org; Mon, 24 Sep 2007 09:39:52 -0400 Received: (qmail invoked by alias); 24 Sep 2007 13:39:37 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp033) with SMTP; 24 Sep 2007 15:39:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8mdY7jOv8FSgDgVy85qxDnIjA1Z2FDgt6XawBYJ nQjtqTa6j5Z19L Message-ID: <46F7BE18.9090009@gmx.net> Date: Mon, 24 Sep 2007 15:39:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV References: <46F7912C.6090002@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Geopriv] What location does a PIDF-LO refer to? X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, Karl Heinz raised an interesting issue. So, here is what he wrote: " LLDP-MED has a "what" element, describing if the location of the client itself, of the DHCP server or of the network element closest to the client is provided. This seems to be useful information, but where to put this in a PIDF document? " Furthermore, in a discussion with Henning and James about the update of the PIDF-LO profile draft (aiming to reflect the feedback regarding the usage of RFC 4479) we came across two questions: (a) How do we indicate to what the location information refers to? (b) Where is the right place to put location information within a PIDF-LO? Regarding the later aspect we learned that location information should be placed into the element when a LIS creates it (rather than using or ). The element has a mandatory element, the , that has to contain a URN. Now, what information should we put in there? IP address, MAC address, anything else? What URN scheme should we use? For (a) we indicated that the 'entity' attribute inside the element, see Section 4.1.1 of RFC 3863, contains the entity to which the location refers to. So, how would we set these fields when the Target receives location information using LLDP-MED? Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 09:58:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZoRf-0003VP-D4; Mon, 24 Sep 2007 09:57:55 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZoRe-0003VE-C0 for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 09:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZoRe-0003V5-2Q for geopriv@ietf.org; Mon, 24 Sep 2007 09:57:54 -0400 Received: from fk-out-0910.google.com ([209.85.128.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZoRX-0008NZ-Sa for geopriv@ietf.org; Mon, 24 Sep 2007 09:57:54 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1736505fkz for ; Mon, 24 Sep 2007 06:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=JYy9bfCyxp1arBS/UGC4xsUhHBBdfM4v4defLHWy4qA=; b=uH5dw7VwUUSOwW8XNAjle8zSfVTExCMYPPxqiku3rIr+BT4sSSOgTh14NED05ke/nRbosOQUOK5XHwwxyPrz33jCjdO4IXsBq2eDUCNaMILiZVIvF4i2ervbRMmx/AlpOK3kilhHRfWNGzEolTHWUzl9qIp4rqvQLOifCOTNZR0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I3S0ptAMNGr0kWNKs6vO9nHe/8emyVMv/RiWlQPi8asnWepf//PNVkmyhn0aaqPT7B6Kg4ratRIR8dXoFZLeY0ChWVmPeVXMeCfVe9yoNTWLXnPUOVNBgdvvg8ihPyZ56PWNzYsn+sKbrjcrIEXLiLm2hFnMgMAcZK0+WZFlXyw= Received: by 10.82.175.17 with SMTP id x17mr7984300bue.1190642232978; Mon, 24 Sep 2007 06:57:12 -0700 (PDT) Received: by 10.82.165.16 with HTTP; Mon, 24 Sep 2007 06:57:12 -0700 (PDT) Message-ID: Date: Mon, 24 Sep 2007 15:57:12 +0200 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" In-Reply-To: <46F7BE18.9090009@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46F7912C.6090002@gmx.net> <46F7BE18.9090009@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: GEOPRIV Subject: [Geopriv] Re: What location does a PIDF-LO refer to? X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > LLDP-MED has a "what" element, describing if the location of the client > itself, of the DHCP server or of the network element closest to the > client is provided. This seems to be useful information, but where to > put this in a PIDF document? > " > > Furthermore, in a discussion with Henning and James about the update of > the PIDF-LO profile draft (aiming to reflect the feedback regarding the > usage of RFC 4479) we came across two questions: > (a) How do we indicate to what the location information refers to? > (b) Where is the right place to put location information within a PIDF-LO? > > Regarding the later aspect we learned that location information should > be placed into the element when a LIS creates it (rather than > using or ). > > The element has a mandatory element, the , that has > to contain a URN. Now, what information should we put in there? IP > address, MAC address, anything else? just one note: when LLDP-MED "what" reports "location of the network element believed closest to the client" no IP address of that network element is available anyway. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 10:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZoUQ-0005a4-00; Mon, 24 Sep 2007 10:00:46 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZoUO-0005Wr-FB for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 10:00:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZoUO-0005Sw-0U for geopriv@ietf.org; Mon, 24 Sep 2007 10:00:44 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZoUN-0001uk-0I for geopriv@ietf.org; Mon, 24 Sep 2007 10:00:43 -0400 Received: (qmail invoked by alias); 24 Sep 2007 14:00:42 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp018) with SMTP; 24 Sep 2007 16:00:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Oj3wK8WVOA0hn5FdbBCYX+2crVnjQTkbYwrOdsl JLDjjKQsiRljO7 Message-ID: <46F7C309.70709@gmx.net> Date: Mon, 24 Sep 2007 16:00:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karl Heinz Wolf References: <46F7912C.6090002@gmx.net> <46F7BE18.9090009@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: GEOPRIV Subject: [Geopriv] Re: What location does a PIDF-LO refer to? X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Karl Heinz Wolf wrote: >> LLDP-MED has a "what" element, describing if the location of the client >> itself, of the DHCP server or of the network element closest to the >> client is provided. This seems to be useful information, but where to >> put this in a PIDF document? >> " >> >> Furthermore, in a discussion with Henning and James about the update of >> the PIDF-LO profile draft (aiming to reflect the feedback regarding the >> usage of RFC 4479) we came across two questions: >> (a) How do we indicate to what the location information refers to? >> (b) Where is the right place to put location information within a PIDF-LO? >> >> Regarding the later aspect we learned that location information should >> be placed into the element when a LIS creates it (rather than >> using or ). >> >> The element has a mandatory element, the , that has >> to contain a URN. Now, what information should we put in there? IP >> address, MAC address, anything else? >> > > just one note: when LLDP-MED "what" reports "location of the network > element believed closest to the client" no IP address of that network > element is available anyway. > For LLDP-MED that's true. But when a LIS creates a PIDF-LO then there is the question whether the MAC address or another identifier would be put in there since there are more choices in the general case. ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 10:18:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZok3-0006UP-VP; Mon, 24 Sep 2007 10:16:55 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZok0-0006Qf-GJ for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 10:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZok0-0006Q6-5X; Mon, 24 Sep 2007 10:16:52 -0400 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZojt-0000Qg-IP; Mon, 24 Sep 2007 10:16:52 -0400 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8OEGAYA032725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2007 16:16:10 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8OEG5BL015452; Mon, 24 Sep 2007 16:16:05 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:16:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Sep 2007 16:16:04 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB32D06A@DEMUEXC012.nsn-intra.net> In-Reply-To: <941D5DCD8C42014FAF70FB7424686DCF01A0FB58@eusrcmw721.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-geopriv-policy-12.txt Thread-Index: Acf6NwSJXtzoHQWJTfa5KTFy9wttCABeVOHQALeNslAACNW/IAAA3mSw References: <46F03C1A.3020905@ericsson.com> <941D5DCD8C42014FAF70FB7424686DCF019E0D5F@eusrcmw721.eamcs.ericsson.se> <5FB585F183235B42A9E70095055136FB1E5516@DEMUEXC012.nsn-intra.net> <941D5DCD8C42014FAF70FB7424686DCF01A0FB58@eusrcmw721.eamcs.ericsson.se> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext Eric Gray" , "Henning Schulzrinne" , "John B Morris" , "Jorge Cuellar" , "General Area Review Team" X-OriginalArrivalTime: 24 Sep 2007 14:16:05.0506 (UTC) FILETIME=[71CBB620:01C7FEB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: geopriv@ietf.org Subject: [Geopriv] AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > Hannes, >=20 > Yes, I am satisfied with your answers. For the record, > they were as much for curiosity as for anything else - given > that my summary indicated the draft is ready to publish... Thanks, Eric.=20 Good to hear that.=20 Ciao Hannes >=20 > Thanks! >=20 > -- > Eric Gray > Principal Engineer > Ericsson =20 >=20 > > -----Original Message----- > > From: Tschofenig, Hannes (NSN - DE/Germany - MiniMD)=20 > > [mailto:hannes.tschofenig@nsn.com]=20 > > Sent: Monday, September 24, 2007 6:13 AM > > To: Eric Gray; Henning Schulzrinne; John B Morris; Jorge=20 > > Cuellar; General Area Review Team > > Cc: Cullen Jennings (fluffy); geopriv@ietf.org > > Subject: AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt > > Importance: High > >=20 > > Hi Eric,=20 > >=20 > > thank you for your Gen-Art review of the geolocation policy=20 > document.=20 > > A few minor comments below:=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: ext Eric Gray [mailto:eric.gray@ericsson.com]=20 > > > Gesendet: Donnerstag, 20. September 2007 21:11 > > > An: Henning Schulzrinne; Tschofenig, Hannes (NSN - DE/Germany=20 > > > - MiniMD); John B Morris; Jorge Cuellar; General Area Review Team > > > Cc: Cullen Jennings (fluffy) > > > Betreff: Gen-ART review of draft-ietf-geopriv-policy-12.txt > > >=20 > > > =20 > > > I am the assigned Gen-ART reviewer for=20 > > > draft-ietf-geopriv-policy-12.txt > > >=20 > > > For background on Gen-ART, please see the FAQ at > > > . > > >=20 > > > Please resolve these comments along with any other=20 > comments you may=20 > > > receive. > > >=20 > > > Document: draft-ietf-geopriv-policy-12.txt > > >=20 > > > Summary: This draft is essentially ready for publication. > > >=20 > > > Comments/Questions: > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > The last sentence in the introduction (last sentence on=20 > > page 5): where > > > do the authors anticipate actions will be defined? Same=20 > > question also > > > would apply to section 5. > >=20 > > The Common Policy framework does not require that every=20 > > extension defines child elements for=20 > > * actions > > * conditions, and=20 > > * transformations > >=20 > > When actions are not relevant for a particular problem space=20 > > then they can be omitted. We believe it is the case for this=20 > > document.=20 > >=20 > > When this document is used in the context and in combination=20 > > with the presence authorization policies then the actions=20 > > defined in the presence authorization policy document would=20 > > be found in a specific rule.=20 > >=20 > > For the presence authorization policy document please look at:=20 > > http://tools.ietf.org/wg/simple/draft-ietf-simple-presence-rules/ > >=20 > > Does this answer your question?=20 > >=20 > > > ______________________________________________________________ > > > _________ > > >=20 > > > In the next-to-last paragraph in section 4.1 (on page 10),=20 > > there is an > > > interesting (and interestingly confusing) discussion of a=20 > > possibility > > > of supporting co-planar (but not necessarily constant=20 > > altitude) and/or > > > nearly co-planar location polygons - which is then=20 > > > (apparently) negated > > > in the last sentence. Is it the intention - behind saying=20 > > > "two polygon > > > forms are permitted" - to assert that all other polygon=20 > > forms are "not > > > permitted" (i.e. - disallowed/forbidden)? If that is the=20 > case, this > > > paragraph could probably be simplified. I would suggest=20 > > > something like: > > >=20 > > > In order for the notion of a location that is defined=20 > as within a > > > specific polygon to make sense, points specified for=20 > the polygon=20 > > > MUST be coplanar. To avoid implementation complexity, only two > > > polygon forms are permitted: polygons specified using=20 > EPSG 4326,=20 > > > and polygons specified using EPSG 4979 with a constant=20 > altitude=20 > > > value. > >=20 > > We took the current text from the following OGC document=20 > >=20 > > Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape=20 > Application > > Schema for use by the Internet Engineering Task=20 > Force (IETF)", > > Candidate OpenGIS Implementation Specification=20 > > 06-142, Version: > > 0.0.9, December 2006. > >=20 > > that is also used for other GEOPRIV documents, such as=20 > > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo > -profile-08.txt > >=20 > > We just wanted to make sure that there is no contradiction=20 > > between this work and the rest of the GEOPRIV work.=20 > >=20 > > Still, your proposal sounds good to me. The difference=20 > > between your text and the text from the OGC document is only=20 > > that the current text indicates that an implementation may=20 > > accept altitude values with a different height.=20 > >=20 > > Based on the current discussions I got the impression that we=20 > > are going to delete the altitude issue and hence this problem=20 > > might go away automatically. =20 > >=20 > > >=20 > > > It is then possible to consider whether or not it makes sense=20 > > > to retain: > > >=20 > > > However, implementations SHOULD be prepared to accept small > > > variations=20 > > > that might occur depending on whether the the polygon is=20 > > > specified on > > >=20 > > > a plane in space, or only relative to the ellipsoid. =20 > > >=20 > > Correct.=20 > >=20 > > >=20 > > > NITs: > > > =3D=3D=3D=3D > > >=20 > > > Towards the bottom of page 4, "evalation" should be > > > "evaluation"... > > Thanks.=20 > >=20 > >=20 > > _______________________________________________ > > __________ > > > ______________ > > >=20 > > > In section 12 (Security Considerations), there is what=20 > appears to be > > > an extra closing paren at the end of the next-to-last sentence. > >=20 > > Correct. Thanks.=20 > >=20 > > Ciao > > Hannes > >=20 > > >=20 > >=20 >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 10:19:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZomI-0000Y8-5S; Mon, 24 Sep 2007 10:19:14 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZoNI-0001bL-9J for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 09:53:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZoNH-0001Wv-Ii; Mon, 24 Sep 2007 09:53:23 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZoN6-0008Gx-BO; Mon, 24 Sep 2007 09:53:18 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l8OE0BHG011812; Mon, 24 Sep 2007 09:00:11 -0500 Received: from eusrcmw721.eamcs.ericsson.se ([138.85.77.21]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 08:52:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Sep 2007 08:52:44 -0500 Message-ID: <941D5DCD8C42014FAF70FB7424686DCF01A0FB58@eusrcmw721.eamcs.ericsson.se> In-Reply-To: <5FB585F183235B42A9E70095055136FB1E5516@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-geopriv-policy-12.txt Thread-Index: Acf6NwSJXtzoHQWJTfa5KTFy9wttCABeVOHQALeNslAACNW/IA== References: <46F03C1A.3020905@ericsson.com> <941D5DCD8C42014FAF70FB7424686DCF019E0D5F@eusrcmw721.eamcs.ericsson.se> <5FB585F183235B42A9E70095055136FB1E5516@DEMUEXC012.nsn-intra.net> From: "Eric Gray" To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" , "Henning Schulzrinne" , "John B Morris" , "Jorge Cuellar" , "General Area Review Team" X-OriginalArrivalTime: 24 Sep 2007 13:52:47.0005 (UTC) FILETIME=[303964D0:01C7FEB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 X-Mailman-Approved-At: Mon, 24 Sep 2007 10:19:13 -0400 Cc: geopriv@ietf.org Subject: [Geopriv] RE: Gen-ART review of draft-ietf-geopriv-policy-12.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hannes, Yes, I am satisfied with your answers. For the record, they were as much for curiosity as for anything else - given that my summary indicated the draft is ready to publish... Thanks! -- Eric Gray Principal Engineer Ericsson =20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - DE/Germany - MiniMD)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: Monday, September 24, 2007 6:13 AM > To: Eric Gray; Henning Schulzrinne; John B Morris; Jorge=20 > Cuellar; General Area Review Team > Cc: Cullen Jennings (fluffy); geopriv@ietf.org > Subject: AW: Gen-ART review of draft-ietf-geopriv-policy-12.txt > Importance: High >=20 > Hi Eric,=20 >=20 > thank you for your Gen-Art review of the geolocation policy document.=20 > A few minor comments below:=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: ext Eric Gray [mailto:eric.gray@ericsson.com]=20 > > Gesendet: Donnerstag, 20. September 2007 21:11 > > An: Henning Schulzrinne; Tschofenig, Hannes (NSN - DE/Germany=20 > > - MiniMD); John B Morris; Jorge Cuellar; General Area Review Team > > Cc: Cullen Jennings (fluffy) > > Betreff: Gen-ART review of draft-ietf-geopriv-policy-12.txt > >=20 > > =20 > > I am the assigned Gen-ART reviewer for=20 > > draft-ietf-geopriv-policy-12.txt > >=20 > > For background on Gen-ART, please see the FAQ at > > . > >=20 > > Please resolve these comments along with any other comments you may=20 > > receive. > >=20 > > Document: draft-ietf-geopriv-policy-12.txt > >=20 > > Summary: This draft is essentially ready for publication. > >=20 > > Comments/Questions: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > The last sentence in the introduction (last sentence on=20 > page 5): where > > do the authors anticipate actions will be defined? Same=20 > question also > > would apply to section 5. >=20 > The Common Policy framework does not require that every=20 > extension defines child elements for=20 > * actions > * conditions, and=20 > * transformations >=20 > When actions are not relevant for a particular problem space=20 > then they can be omitted. We believe it is the case for this=20 > document.=20 >=20 > When this document is used in the context and in combination=20 > with the presence authorization policies then the actions=20 > defined in the presence authorization policy document would=20 > be found in a specific rule.=20 >=20 > For the presence authorization policy document please look at:=20 > http://tools.ietf.org/wg/simple/draft-ietf-simple-presence-rules/ >=20 > Does this answer your question?=20 >=20 > > ______________________________________________________________ > > _________ > >=20 > > In the next-to-last paragraph in section 4.1 (on page 10),=20 > there is an > > interesting (and interestingly confusing) discussion of a=20 > possibility > > of supporting co-planar (but not necessarily constant=20 > altitude) and/or > > nearly co-planar location polygons - which is then=20 > > (apparently) negated > > in the last sentence. Is it the intention - behind saying=20 > > "two polygon > > forms are permitted" - to assert that all other polygon=20 > forms are "not > > permitted" (i.e. - disallowed/forbidden)? If that is the case, this > > paragraph could probably be simplified. I would suggest=20 > > something like: > >=20 > > In order for the notion of a location that is defined as within a > > specific polygon to make sense, points specified for the polygon=20 > > MUST be coplanar. To avoid implementation complexity, only two > > polygon forms are permitted: polygons specified using EPSG 4326,=20 > > and polygons specified using EPSG 4979 with a constant altitude=20 > > value. >=20 > We took the current text from the following OGC document=20 >=20 > Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape Application > Schema for use by the Internet Engineering Task Force (IETF)", > Candidate OpenGIS Implementation Specification=20 > 06-142, Version: > 0.0.9, December 2006. >=20 > that is also used for other GEOPRIV documents, such as=20 > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo -profile-08.txt >=20 > We just wanted to make sure that there is no contradiction=20 > between this work and the rest of the GEOPRIV work.=20 >=20 > Still, your proposal sounds good to me. The difference=20 > between your text and the text from the OGC document is only=20 > that the current text indicates that an implementation may=20 > accept altitude values with a different height.=20 >=20 > Based on the current discussions I got the impression that we=20 > are going to delete the altitude issue and hence this problem=20 > might go away automatically. =20 >=20 > >=20 > > It is then possible to consider whether or not it makes sense=20 > > to retain: > >=20 > > However, implementations SHOULD be prepared to accept small > > variations=20 > > that might occur depending on whether the the polygon is=20 > > specified on > >=20 > > a plane in space, or only relative to the ellipsoid. =20 > >=20 > Correct.=20 >=20 > >=20 > > NITs: > > =3D=3D=3D=3D > >=20 > > Towards the bottom of page 4, "evalation" should be > > "evaluation"... > Thanks.=20 >=20 >=20 > _______________________________________________ > __________ > > ______________ > >=20 > > In section 12 (Security Considerations), there is what appears to be > > an extra closing paren at the end of the next-to-last sentence. >=20 > Correct. Thanks.=20 >=20 > Ciao > Hannes >=20 > >=20 >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Mon Sep 24 10:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZpIb-00041h-3D; Mon, 24 Sep 2007 10:52:37 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZpIZ-0003zZ-U9 for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 10:52:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZpIZ-0003y9-GF for geopriv@ietf.org; Mon, 24 Sep 2007 10:52:35 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZpIW-0003L3-Rw for geopriv@ietf.org; Mon, 24 Sep 2007 10:52:33 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8OEqUNC029187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 24 Sep 2007 10:52:30 -0400 (EDT) In-Reply-To: <46F7BE18.9090009@gmx.net> References: <46F7912C.6090002@gmx.net> <46F7BE18.9090009@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04B19C32-3407-4F90-801B-B482FC2D1C38@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] What location does a PIDF-LO refer to? Date: Mon, 24 Sep 2007 10:53:11 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org My general preference is to avoid overloading or implicit assumptions. There are three possibilities: (1) use the field in device for a human-readable description ("ethernet switch") (2) add a device type indication to the field, with the difficulty of enumerating devices (this differs a bit from draft-ietf- simple-prescaps-ext, as that is more meant to describe the communication device, not a network device) (3) add an indication to PIDF-LO that indicates the proximity to the user or end device (3) seems cleanest. For identifying the device, IP addresses are clearly not good, due to their lack of uniqueness and temporal stability. (I could easily have two devices that both answer to 192.168.0.1, such as a device in my office and at home.) A UUID seems most appropriate. Henning On Sep 24, 2007, at 9:39 AM, Hannes Tschofenig wrote: > Hi all, > > Karl Heinz raised an interesting issue. > > So, here is what he wrote: > > " > LLDP-MED has a "what" element, describing if the location of the > client itself, of the DHCP server or of the network element closest > to the client is provided. This seems to be useful information, but > where to put this in a PIDF document? > " > > Furthermore, in a discussion with Henning and James about the > update of the PIDF-LO profile draft (aiming to reflect the feedback > regarding the usage of RFC 4479) we came across two questions: > (a) How do we indicate to what the location information refers to? > (b) Where is the right place to put location information within a > PIDF-LO? > > Regarding the later aspect we learned that location information > should be placed into the element when a LIS creates it > (rather than using or ). > > The element has a mandatory element, the , that > has to contain a URN. Now, what information should we put in there? > IP address, MAC address, anything else? > > What URN scheme should we use? > > For (a) we indicated that the 'entity' attribute inside the > element, see Section 4.1.1 of RFC 3863, contains the > entity to which the location refers to. > > So, how would we set these fields when the Target receives location > information using LLDP-MED? > > Ciao > Hannes > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From First@SMHAOHIO.org Mon Sep 24 13:52:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZs72-0000Xu-Ky for geopriv-archive@lists.ietf.org; Mon, 24 Sep 2007 13:52:52 -0400 Received: from [202.57.8.168] (helo=[202.57.8.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZs6y-0001TT-FG for geopriv-archive@lists.ietf.org; Mon, 24 Sep 2007 13:52:49 -0400 Received: from RAHMAT ([105.181.145.138] helo=RAHMAT) by [202.57.8.4] ( sendmail 8.13.3/8.13.1) with esmtpa id 1BYuVd-000FJR-pE for geopriv-archive@lists.ietf.org; Tue, 25 Sep 2007 00:53:28 +0700 Message-ID: <000a01c7fed3$c9414140$040839ca@RAHMAT> From: "First McCool" To: Subject: seminary Date: Tue, 25 Sep 2007 00:53:17 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7FF0E.75A01940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0006_01C7FF0E.75A01940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://sfoas.com/ Night geopriv-archive my girl loves the new me. First McCool ------=_NextPart_000_0006_01C7FF0E.75A01940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://sfoas.com/
Night geopriv-archive
my girl loves the new me.
First McCool
------=_NextPart_000_0006_01C7FF0E.75A01940-- From pelletier@agensmedia.com Mon Sep 24 15:37:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZtkC-0005ql-A1 for geopriv-archive@lists.ietf.org; Mon, 24 Sep 2007 15:37:24 -0400 Received: from [62.123.10.1] (helo=STATIC-62-123-10-1.atlanet.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZtk6-0005G6-De for geopriv-archive@lists.ietf.org; Mon, 24 Sep 2007 15:37:18 -0400 Received: from PC001 ([182.123.19.39] helo=PC001) by STATIC-62-123-10-1.atlanet.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1cCITd-000XFE-TX for geopriv-archive@lists.ietf.org; Mon, 24 Sep 2007 21:38:20 +0200 Message-ID: <000701c7fee2$609ceef0$010a7b3e@PC001> From: "Cedrick pelletier" To: Subject: ezakanah Date: Mon, 24 Sep 2007 21:37:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FEF3.2425BEF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.0 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0004_01C7FEF3.2425BEF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.entrzdas.com/ Good day geopriv-archive the common problem today is difficulty in holding ejaculation for a long = time and the size of penis Cedrick pelletier ------=_NextPart_000_0004_01C7FEF3.2425BEF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://www.entrzdas.com/
Good day geopriv-archive
the common problem today is difficulty in = holding=20 ejaculation for a long time and the size of penis
Cedrick pelletier
------=_NextPart_000_0004_01C7FEF3.2425BEF0-- From geopriv-bounces@ietf.org Mon Sep 24 16:05:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuBS-0007GC-VV; Mon, 24 Sep 2007 16:05:34 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZuBR-0007G2-G4 for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 16:05:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuBR-0007E2-4Q for geopriv@ietf.org; Mon, 24 Sep 2007 16:05:33 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZuBK-0003pA-P2 for geopriv@ietf.org; Mon, 24 Sep 2007 16:05:33 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4426B142231; Mon, 24 Sep 2007 13:05:16 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5blheeL5qkdT; Mon, 24 Sep 2007 13:05:09 -0700 (PDT) Received: from [192.168.1.102] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7351F142229; Mon, 24 Sep 2007 13:05:09 -0700 (PDT) In-Reply-To: References: <46F3A8C8.6040402@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <426A537B-F898-4404-BC38-281739ECD4AF@osafoundation.org> From: Lisa Dusseault Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Date: Mon, 24 Sep 2007 13:05:06 -0700 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0159300251==" Errors-To: geopriv-bounces@ietf.org --===============0159300251== Content-Type: multipart/alternative; boundary=Apple-Mail-3--243774480 --Apple-Mail-3--243774480 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 22, 2007, at 11:09 AM, Henning Schulzrinne wrote: > > I don't think a map is required, although this is clearly helpful > in some scenarios. For example, a reasonable user interface might > provide the option "Hide my location if I'm within 50 miles from > home", and then translate this into a polygon. A separate user > agent would best render this as a polygon on a map. Yes, but how does this work in the other direction? If one user agent encourages me to draw a square (or more complicated polygon) around the location I'd like to keep private, how does the user agent without a map reasonably show me what my policy is when I'd like to check if I will have privacy? >> >> - whether you can define a polygon for "Alberta" and one for >> "Saskatchewan" and have any point be in one or the other or >> completely outside both -- but not *inside* both, and not stuck in- >> between >> > > I don't understand this particular item. I'm trying to understand how polygons work here, I'm not certain there's a problem. Assuming we know what the inside of a polygon is (that's a separate discussion), is the exact location of a border dependent on where the inside of a polygon is? If we define the border between Alberta and Saskatchewan as a straight line from A to B, and we use the same line in the definition of the Alberta polygon and the Saskatchewan polygon, then do the two polygons overlap or have a gap between them? I could imagine that they might, depending on how a flat square is mapped to a sphere. Will the border between Saskatchewan and the US necessarily follow the 49th parallel or might the line between the two south corners be interpreted as cutting into what's actually Saskatchewan? If we show a map to a user on a flat screen, typically large "rectangular" regions like Saskatchewan actually show up as a shape with two straight lines and two curved lines. (It may also be tilted: http://www.canadainfolink.ca/canada_fr.jpg). A user trying to cover Saskatchewan on this map with a rectangle would have to cover pieces of Alberta, Northwest Territories, Manitoba and USA with the rectangle to do so, unless the GUI was pretty complicated. That's why I'm not sure that different user agents and servers will necessarily interpret what's inside a polygon the same way. Lisa --Apple-Mail-3--243774480 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Sep 22, 2007, = at 11:09 AM, Henning Schulzrinne wrote:


I don't think a map is required, although this is clearly = helpful in some scenarios. For example, a reasonable user interface = might provide the option "Hide my location if I'm within 50 miles from = home",=A0 and then = translate this into a polygon. A separate user agent would best render = this as a polygon on a map.



Yes, but how does this work = in the other direction?=A0 If one user agent encourages me to draw a = square (or more complicated polygon)=A0 around the location I'd like to = keep private, how does the user agent without a map reasonably show me = what my policy is when I'd like to check if I will have = privacy?


- whether you can define a = polygon for "Alberta" and one for "Saskatchewan" and have any point be = in one or the other or completely outside both -- but not *inside* both, = and not stuck in-between


I don't = understand this particular item.

I'm trying to understand = how polygons work here, I'm not certain there's a problem.=A0 Assuming = we know what the inside of a polygon is (that's a separate discussion), = is the exact location of a border dependent on where the inside of a = polygon is?=A0 If we define the border between Alberta and Saskatchewan = as a straight line from A to B, and we use the same line in the = definition of the Alberta polygon and the Saskatchewan polygon, then do = the two polygons overlap or have a gap between them?=A0 I could imagine = that they might, depending on how a flat square is mapped to a sphere.=A0 = =A0Will the border between Saskatchewan and the US necessarily follow = the 49th parallel or might the line between the two south corners be = interpreted as cutting into what's actually Saskatchewan?

If we show a map to a user = on a flat screen, typically large "rectangular" regions like = Saskatchewan actually show up as a shape with two straight lines and two = curved lines. (It may also be tilted:=A0=A0http://www.canadainfol= ink.ca/canada_fr.jpg).=A0=A0=A0A user trying to cover Saskatchewan = on this map with a rectangle would have to cover pieces of Alberta, = Northwest Territories, Manitoba and USA with the rectangle to do so, = unless the GUI was pretty complicated. That's why I'm not sure that = different user agents and servers will necessarily interpret what's = inside a polygon the same way.=A0

Lisa
= --Apple-Mail-3--243774480-- --===============0159300251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0159300251==-- From geopriv-bounces@ietf.org Mon Sep 24 17:04:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZv61-000333-HA; Mon, 24 Sep 2007 17:04:01 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IZv60-0002y5-Ro for geopriv-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 17:04:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZv60-0002xc-Cj for geopriv@ietf.org; Mon, 24 Sep 2007 17:04:00 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZv5z-0007tC-N8 for geopriv@ietf.org; Mon, 24 Sep 2007 17:04:00 -0400 X-SEF-Processed: 5_0_0_910__2007_09_24_16_13_36 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 24 Sep 2007 16:13:36 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Sep 2007 16:03:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: What location does a PIDF-LO refer to? Date: Mon, 24 Sep 2007 16:03:56 -0500 Message-ID: In-Reply-To: <46F7C309.70709@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: What location does a PIDF-LO refer to? Thread-Index: Acf+s3/ZIazQB9KxRpqUfwjOrvUF1AAOi7+A References: <46F7912C.6090002@gmx.net> <46F7BE18.9090009@gmx.net> <46F7C309.70709@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "Karl Heinz Wolf" X-OriginalArrivalTime: 24 Sep 2007 21:03:58.0828 (UTC) FILETIME=[6D084AC0:01C7FEEE] X-Spam-Score: 1.8 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org The address that you can be sure the LIS gets in many cases will be the=0D=0A= IP address. For example if I am connected to an ATM over DSL service=0D=0At= hen I am using PPP, so MAC address is visible at the LIS, I absolutely=0D=0A= do not want to include the PPP user name in the or =0D=0Ae= lements.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message---= --=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>= Sent: Tuesday, 25 September 2007 12:01 AM=0D=0A> To: Karl Heinz Wolf=0D=0A= > Cc: GEOPRIV=0D=0A> Subject: [Geopriv] Re: What location does a PIDF-LO re= fer to=3F=0D=0A>=20=0D=0A> Hi=0D=0A>=20=0D=0A> Karl Heinz Wolf wrote:=0D=0A= > >> LLDP-MED has a "what" element, describing if the location of the=0D=0A= client=0D=0A> >> itself, of the DHCP server or of the network element close= st to the=0D=0A> >> client is provided. This seems to be useful information= , but where=0D=0Ato=0D=0A> >> put this in a PIDF document=3F=0D=0A> >> "=0D= =0A> >>=0D=0A> >> Furthermore, in a discussion with Henning and James about= the=0D=0Aupdate of=0D=0A> >> the PIDF-LO profile draft (aiming to reflect = the feedback regarding=0D=0Athe=0D=0A> >> usage of RFC 4479) we came across= two questions:=0D=0A> >> (a) How do we indicate to what the location info= rmation refers to=3F=0D=0A> >> (b) Where is the right place to put locatio= n information within a=0D=0A> PIDF-LO=3F=0D=0A> >>=0D=0A> >> Regarding the = later aspect we learned that location information=0D=0Ashould=0D=0A> >> be = placed into the element when a LIS creates it (rather=0D=0Athan=0D= =0A> >> using or ).=0D=0A> >>=0D=0A> >> The elemen= t has a mandatory element, the , that=0D=0Ahas=0D=0A> >> to conta= in a URN. Now, what information should we put in there=3F IP=0D=0A> >> addr= ess, MAC address, anything else=3F=0D=0A> >>=0D=0A> >=0D=0A> > just one not= e: when LLDP-MED "what" reports "location of the network=0D=0A> > element b= elieved closest to the client" no IP address of that=0D=0Anetwork=0D=0A> > = element is available anyway.=0D=0A> >=0D=0A>=20=0D=0A> For LLDP-MED that's = true. But when a LIS creates a PIDF-LO then there=0D=0Ais=0D=0A> the questi= on whether the MAC address or another identifier would be=0D=0Aput=0D=0A> i= n there since there are more choices in the general case.=0D=0A>=20=0D=0A> = ciao=0D=0A> Hannes=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>= _______________________________________________=0D=0A> Geopriv mailing lis= t=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geo= priv=0D=0A=0D=0A-----------------------------------------------------------= -------------------------------------=0D=0AThis message is for the designat= ed recipient only and may=0D=0Acontain privileged, proprietary, or otherwis= e private information. =20=0D=0AIf you have received it in error, please no= tify the sender=0D=0Aimmediately and delete the original. Any unauthorized= use of=0D=0Athis email is prohibited.=0D=0A-------------------------------= -----------------------------------------------------------------=0D=0A[mf2= ]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From mattscus@TORN.RU Tue Sep 25 04:52:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia69D-0004Hu-Vn for geopriv-archive@lists.ietf.org; Tue, 25 Sep 2007 04:52:04 -0400 Received: from host176-7-dynamic.7-87-r.retail.telecomitalia.it ([87.7.7.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia699-0000SW-V5 for geopriv-archive@lists.ietf.org; Tue, 25 Sep 2007 04:52:00 -0400 Received: from famiglia-f10b9b by TORN.RU with ASMTP id 5F42EF57 for ; Tue, 25 Sep 2007 10:53:16 +0200 Received: from famiglia-f10b9b ([134.163.88.139]) by TORN.RU with ESMTP id F654FC3C4FDC for ; Tue, 25 Sep 2007 10:53:16 +0200 Message-ID: <000d01c7ff51$71f51730$b0070757@famigliaf10b9b> From: "powers matts" To: Subject: enolg Date: Tue, 25 Sep 2007 10:52:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C7FF62.357DE730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0004_01C7FF62.357DE730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://eprie.com/ Wassup geopriv-archive Want a really big cock? powers matts ------=_NextPart_000_0004_01C7FF62.357DE730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://eprie.com/
Wassup geopriv-archive
Want a really big cock?
powers matts
------=_NextPart_000_0004_01C7FF62.357DE730-- From geopriv-bounces@ietf.org Tue Sep 25 05:16:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6Vw-00023j-5n; Tue, 25 Sep 2007 05:15:32 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ia6Vv-00023e-5P for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 05:15:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6Vu-000218-RJ for geopriv@ietf.org; Tue, 25 Sep 2007 05:15:30 -0400 Received: from andrew.triumf.ca ([142.90.106.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia6Vp-0001Lm-0Z for geopriv@ietf.org; Tue, 25 Sep 2007 05:15:25 -0400 Received: from localhost (localhost [127.0.0.1]) by andrew.triumf.ca (8.12.11.20060308/8.12.8) with ESMTP id l8P9FDsY007054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 02:15:14 -0700 Date: Tue, 25 Sep 2007 02:15:13 -0700 (PDT) From: Andrew Daviel X-X-Sender: andrew@andrew.triumf.ca To: Henning Schulzrinne Subject: Re: [Geopriv] Draft Updates "GEO TAGS for HTML" In-Reply-To: <4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu> Message-ID: References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu> <4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Apologies for apparently random timing of replies; I still have some vacation mail to deal with which I may have only skimmed earlier. On Fri, 10 Aug 2007, Henning Schulzrinne wrote: > I hope we're not having the discussion based on "existing software", as this > essentially means that you might as well stop asking this group for input. Well, no. It's not exactly a huge installed codebase. > >> >>> The space-only version simply conforms to the XML version. The semicolon >>> adds no particular value here. ... > > I think GEOPRIV is a pretty good example that the IETF has no good way to > determine majorities reliably :-) :-7 > My general concern is that inconsistency leads to mistakes. This working > group, at least, should try to stick to one way to encode data. True, everyone seems to do things a little bit differently. In the HTML draft, I'm not trying to define XML or RDF elements for the semantic Web. I'm trying to formalize a metadata element for legacy HTML 2/3/4. The specification of HTML META element I used is W3C's HTML 4.01. The value of the content field is character data without trailing or leading spaces but is otherwise fairly free. There has been an informal convention of using a comma or semicolon to separate subfields, ignoring whitespace, e.g. I happened to pick a semicolon, as used in RFC2731 (or RFC2426, RFC2445 which define a GEO element, admittedly not in HTML metadata) I guess I'm saying that in defining semantics of an HTML META element, that the relevant conventions to be followed are those of HTML META elements, familiar to Web authors, rather than the conventions of a newer language or protocol. On the other hand, the development of a new structured machine-parsable document format which includes geographic data is a worthwhile goal. But a different one. Andrew Daviel _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 06:44:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia7tF-00067U-V9; Tue, 25 Sep 2007 06:43:41 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ia7tE-000679-Gw for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 06:43:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia7tE-00066j-6D for geopriv@ietf.org; Tue, 25 Sep 2007 06:43:40 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia7t8-0003kO-PT for geopriv@ietf.org; Tue, 25 Sep 2007 06:43:35 -0400 Received: from [192.168.248.115] (static-70-21-119-250.res.east.verizon.net [70.21.119.250]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8PAhU3f019344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Sep 2007 06:43:33 -0400 (EDT) In-Reply-To: References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu> <4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Draft Updates "GEO TAGS for HTML" Date: Tue, 25 Sep 2007 06:43:29 -0400 To: Andrew Daviel X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org As pointed out before, nobody is suggesting that you define a new document format. The suggestion is to define civic and geo meta tags that have a one-to-one correspondence with PIDF-LO tags, as in This makes it trivial to create a PIDF-LO from such meta data and vice versa. (There may be some subsetting required for complicated geometric constructs.) On Sep 25, 2007, at 5:15 AM, Andrew Daviel wrote: > In the HTML draft, I'm not trying to define XML or RDF elements for > the semantic Web. I'm trying to formalize a metadata element for > legacy HTML 2/3/4. > The specification of HTML META element I used is W3C's HTML 4.01. > The value of the content field is character data without trailing > or leading spaces but is otherwise fairly free. There has been an > informal convention of using a comma or semicolon to separate > subfields, > ignoring whitespace, e.g. > > > > > > I happened to pick a semicolon, as used in RFC2731 (or RFC2426, > RFC2445 which define a GEO element, admittedly not in HTML metadata) > > > I guess I'm saying that in defining semantics of an HTML META > element, that the relevant conventions to be followed are those of > HTML META elements, familiar to Web authors, rather than the > conventions of a newer language or protocol. > > On the other hand, the development of a new structured machine- > parsable document format which includes geographic data is a > worthwhile goal. But a different one. > > > Andrew Daviel _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 07:04:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8Dk-0001dW-5O; Tue, 25 Sep 2007 07:04:52 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ia8Dg-0001QD-5V for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:04:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8Df-0000sB-RP for geopriv@ietf.org; Tue, 25 Sep 2007 07:04:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ia8DW-0001pF-A7 for geopriv@ietf.org; Tue, 25 Sep 2007 07:04:39 -0400 Received: (qmail invoked by alias); 25 Sep 2007 11:04:17 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp028) with SMTP; 25 Sep 2007 13:04:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+nyLEIhG2n+HHk945uLoOPKJ9HetjXwF5hLDdvkl KoyFP0532GqLxy Message-ID: <46F8EB30.4@gmx.net> Date: Tue, 25 Sep 2007 13:04:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Jari Arkko) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Here is Jari's DISCUSS: https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71837/ > However, > implementations SHOULD be prepared to accept small variations that > might occur depending on whether the the polygon is specified on a > plane in space, or only relative to the ellipsoid. I do not understand how to implement this. Please clarify _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 07:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8GS-0006Db-03; Tue, 25 Sep 2007 07:07:40 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ia8GP-0006CY-Tm for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:07:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8GP-0005uo-G8 for geopriv@ietf.org; Tue, 25 Sep 2007 07:07:37 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ia8GI-0004b0-Q8 for geopriv@ietf.org; Tue, 25 Sep 2007 07:07:31 -0400 Received: (qmail invoked by alias); 25 Sep 2007 11:07:27 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp025) with SMTP; 25 Sep 2007 13:07:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/5gZQb2nv5VaTPCmoWiURmqvDI690mQRuWeuB+UW z6ldLJBA07Lozv Message-ID: <46F8EBEE.1030507@gmx.net> Date: Tue, 25 Sep 2007 13:07:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "Peterson, Jon" Subject: [Geopriv] COMMENT on draft-ietf-geopriv-policy (Jon Peterson) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Here is Jon's COMMENT: https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71835/? " In section 6.5.2, does it make sense to have a practical maximum value for 'r', that is, before 'INF'? Nit Section 1, "does not allow to control access" does not allow what to control access? Nit Section 6.4, "allows to reference" allows what to reference? " _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 07:18:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8QZ-0007FX-Ul; Tue, 25 Sep 2007 07:18:07 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ia8QY-0007AI-US for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:18:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8QY-0007AA-KH for geopriv@ietf.org; Tue, 25 Sep 2007 07:18:06 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ia8QY-0004tt-35 for geopriv@ietf.org; Tue, 25 Sep 2007 07:18:06 -0400 Received: (qmail invoked by alias); 25 Sep 2007 11:18:04 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp019) with SMTP; 25 Sep 2007 13:18:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Y6q5COwrYDtKKWxGtqpx+1s6KIPH6f0jkJdKlrs SAeGQv0c/8W3mU Message-ID: <46F8EE6B.9040602@gmx.net> Date: Tue, 25 Sep 2007 13:18:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV Subject: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ Housley) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Russ Housley X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Here is Russ's DISCUSS: https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71948/ https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71949/ " In section 6.5.2, the values in the table for n=38.89868 do not seem right. Working through the most simple case, where r=1.0, I get: 39.39868 = n*r + 0.5 39.00000 = FLOOR(n*r + 0.5) 39.00000 = FLOOR(n*r + 0.5) * 1/r " " Consider a the four corners of Colorado. (Colorado is a rectangle.) Call the northeast corner A. Call the northwest corner B. Call the southwest corner C. Call the southeast corner D. It is pretty clear that ABCDA is a valid polygon. Is ACBDA a valid polygon? I do not see text that would tell me that such a polygon is not allowed, but such text could be in EPSG 4326 or EPSG 4979. I did not go look. I have writen algorithms to find a polygon that includes all of the provided coordinates, but that does not seem like the right thing to do here. The formula: n'=FLOOR(n*r + 0.5) * 1/r Can be simplified to: n'=FLOOR(n*r + 0.5)/r " _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 07:18:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8RE-0000qk-TQ; Tue, 25 Sep 2007 07:18:48 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ia8RD-0000i5-Hp for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8RD-0000hr-8I for geopriv@ietf.org; Tue, 25 Sep 2007 07:18:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ia8R3-0002Fm-Ss for geopriv@ietf.org; Tue, 25 Sep 2007 07:18:47 -0400 Received: (qmail invoked by alias); 25 Sep 2007 11:18:36 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp051) with SMTP; 25 Sep 2007 13:18:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+POkBP26CPHnLX5lCtcSeBQQ7xoi95SZwTaToeKw zri5DPmtKHBEyr Message-ID: <46F8EE8B.4070406@gmx.net> Date: Tue, 25 Sep 2007 13:18:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GEOPRIV Subject: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Chris Newman) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'Chris Newman' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Here is Chris's DISCUSS: https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71974/? " I share many of Lisa's concerns. It is my suspicion that if the polygon feature remains in the initial publication that it will have to be dropped to advance to draft. Might be better to drop it now to save time. Is there a use case where rectangles or civic information is not sufficient? We already have consumer map services that omit information related to military installations and similar high-security locations. Perhaps that sort of omission will simply be built-into geopriv system and not need a standardized policy language of this complexity? " _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 07:44:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8q3-0004Y7-3c; Tue, 25 Sep 2007 07:44:27 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ia8q1-0004Xe-Iq for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8q1-0004QT-9H for geopriv@ietf.org; Tue, 25 Sep 2007 07:44:25 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia8pq-0002pT-5G for geopriv@ietf.org; Tue, 25 Sep 2007 07:44:20 -0400 Received: from [192.168.248.115] (static-70-21-119-250.res.east.verizon.net [70.21.119.250]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8PBhoSZ028811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Sep 2007 07:43:51 -0400 (EDT) In-Reply-To: <46F8EE8B.4070406@gmx.net> References: <46F8EE8B.4070406@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Chris Newman) Date: Tue, 25 Sep 2007 07:43:50 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.0 (-) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: GEOPRIV , 'Chris Newman' X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I don't see why a polygon is significantly more complicated than a rectangle. The motivation was to easily create (reasonable) approximations to rules such as "don't show my location if I'm within 50 miles of my home". I do not know whether such location-dependent rules will actually be used; they clearly go beyond existing capabilities. I'm not opposed to dropping all such rules, including the civic ones, and create a - bis- version of the spec if there's market demand. Henning On Sep 25, 2007, at 7:18 AM, Hannes Tschofenig wrote: > Here is Chris's DISCUSS: > https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/ > comment/71974/? > > " > I share many of Lisa's concerns. It is my suspicion that if the > polygon > feature remains in the initial publication that it will have to be > dropped > to advance to draft. Might be better to drop it now to save time. > Is there a use case where rectangles or civic information is not > sufficient? > > We already have consumer map services that omit information related > to military installations and similar high-security locations. > Perhaps that sort of omission will simply be built-into geopriv > system and not need a standardized policy language of this complexity? > " > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 08:49:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9r9-0007Cf-5u; Tue, 25 Sep 2007 08:49:39 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ia9r7-00079c-F7 for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 08:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9r7-00079K-5G for geopriv@ietf.org; Tue, 25 Sep 2007 08:49:37 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia9qv-0004Nj-HL for geopriv@ietf.org; Tue, 25 Sep 2007 08:49:37 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6756F19867F; Tue, 25 Sep 2007 15:49:17 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2755619865D; Tue, 25 Sep 2007 15:49:17 +0300 (EEST) Message-ID: <46F8F1ED.9000303@piuha.net> Date: Tue, 25 Sep 2007 13:33:01 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Hannes Tschofenig References: <46F8EB30.4@gmx.net> In-Reply-To: <46F8EB30.4@gmx.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: GEOPRIV Subject: [Geopriv] Re: DISCUSS on draft-ietf-geopriv-policy (Jari Arkko) X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Right. Specifically, it is unclear to me what is a small variation that I should accept. Jari Hannes Tschofenig kirjoitti: > Here is Jari's DISCUSS: > https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71837/ > > > > However, > > implementations SHOULD be prepared to accept small variations that > > might occur depending on whether the the polygon is specified on a > > plane in space, or only relative to the ellipsoid. > > I do not understand how to implement this. Please clarify > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From raimond_Elias@fondazionemelazzini.it Tue Sep 25 09:34:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaAYX-0007GP-TV for geopriv-archive@lists.ietf.org; Tue, 25 Sep 2007 09:34:29 -0400 Received: from cpc3-runc1-0-0-cust521.bagu.cable.ntl.com ([86.4.2.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaAYX-0007zm-Fv for geopriv-archive@lists.ietf.org; Tue, 25 Sep 2007 09:34:29 -0400 Received: from mr-1078eb7c13a9 by fondazionemelazzini.it with ASMTP id 4A963E1A for ; Tue, 25 Sep 2007 14:35:10 +0100 Received: from mr-1078eb7c13a9 ([179.137.72.149]) by fondazionemelazzini.it with ESMTP id 38D09E945EDE for ; Tue, 25 Sep 2007 14:35:10 +0100 Message-ID: <000b01c7ff78$d0702f80$0a020456@mr1078eb7c13a9> From: "raimond Elias" To: Subject: debas Date: Tue, 25 Sep 2007 14:34:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7FF81.32361E20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C7FF81.32361E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://landleys.com/ Night geopriv-archive bigger than average, thats what i am now raimond Elias ------=_NextPart_000_0008_01C7FF81.32361E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://landleys.com/
Night geopriv-archive
bigger than average, thats what i am = now
raimond Elias
------=_NextPart_000_0008_01C7FF81.32361E20-- From geopriv-bounces@ietf.org Tue Sep 25 11:31:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCNk-0003eI-Sb; Tue, 25 Sep 2007 11:31:28 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaCNk-0003b3-8B for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:31:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCNj-0003Yz-SD for geopriv@ietf.org; Tue, 25 Sep 2007 11:31:27 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaCNj-0002kt-8w for geopriv@ietf.org; Tue, 25 Sep 2007 11:31:27 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9B17414222A; Tue, 25 Sep 2007 08:31:26 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0ij7ki+9Byf; Tue, 25 Sep 2007 08:31:20 -0700 (PDT) Received: from [192.168.1.102] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1A43F14220A; Tue, 25 Sep 2007 08:31:20 -0700 (PDT) In-Reply-To: References: <46F3A8C8.6040402@gmx.net> <46F77B84.8060702@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77EF1FA3-6A98-439E-8164-99E13FB5869F@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Date: Tue, 25 Sep 2007 08:31:17 -0700 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Sep 24, 2007, at 2:05 AM, Henning Schulzrinne wrote: > > On Sep 24, 2007, at 4:55 AM, Hannes Tschofenig wrote: > >> Hi Henning, >> >> >> Maybe the suggestion is to provide a mechanism to label a certain >> geographical region for later usage in policies. Assume that an >> end host would configure these policies then someone (like the >> enterprise administrator, the user with the help of a map tool, >> the operator) would provide pre-defined regions that are labeled. >> >> Currently, the user interface could provide this functionality but >> there are no protocol features to enable them, i.e., the user >> interface at the Rule Maker would have to know what "home" means >> and then translate that to a polygon. > > Labeling regions would require a separate data set, i.e., something > outside the current common-policy framework. Also, this would have > its own set of problems. If the operator changes such a region, the > user would suddenly, and without notification, have a very > different privacy policy. I think by "labels", Hannes & I meant what you call "comments" below. Generally-understood region names are already part of the civic location stuff, right? In the case of civic definitions, is it likely operators will go changing region definitions? I agree that would be a problem. > In addition, unless there is a guarantee that these regions are > accessible by users and can be defined by users, it would be very > difficult for one user to maintain the same set of privacy policies > across multiple different service providers. Finally, I'm not sure > how this would address the issue of having to have map displays. > Almost all such regions would be either simple civic regions > ("Bergen county") or would need a map to be unambiguous to most > users ("New York metro area"). >> >> Sounds reasonable to me. >> We could add an element to allow the Rule Maker to provide some >> human-readable text around the policy. > > And maybe add a 'comment' attribute to the rule. This, however, > seems more appropriate for the common-policy document, as a trivial > extension, since it is by no means specific to geopriv-policy. Since one reasonable place to put a comment is in the "gp:location" element defined in this document, I'm not sure geopriv-policy is an inappropriate document to define a comment. >> >> Is there the suggestion to delete either civic or geodetic >> location information conditions entirely? >> > > I'm not suggesting this, but I'm sure Lisa can clarify her concerns. I was not suggesting that either, but it would be one way to avoid the case where two user agents want to operate on the same privacy policy and one only understands civic and the other only geodetic. Another solution would be to require user agents to understand both. Lisa _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 11:34:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCQ7-0008Dr-5Y; Tue, 25 Sep 2007 11:33:55 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaCQ6-0008Dk-5Y for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCQ5-0008DF-Re for geopriv@ietf.org; Tue, 25 Sep 2007 11:33:53 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaCPz-00004w-IU for geopriv@ietf.org; Tue, 25 Sep 2007 11:33:53 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2120214222A; Tue, 25 Sep 2007 08:33:38 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf-QEtt2ORKa; Tue, 25 Sep 2007 08:33:31 -0700 (PDT) Received: from [192.168.1.102] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C08A814220A; Tue, 25 Sep 2007 08:33:31 -0700 (PDT) In-Reply-To: <426A537B-F898-4404-BC38-281739ECD4AF@osafoundation.org> References: <46F3A8C8.6040402@gmx.net> <426A537B-F898-4404-BC38-281739ECD4AF@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <28B1E857-B951-401D-9936-3D854B39ED01@osafoundation.org> From: Lisa Dusseault Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Date: Tue, 25 Sep 2007 08:33:28 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: GEOPRIV WG , Henning Schulzrinne X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2139093752==" Errors-To: geopriv-bounces@ietf.org --===============2139093752== Content-Type: multipart/alternative; boundary=Apple-Mail-1--173672608 --Apple-Mail-1--173672608 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 24, 2007, at 1:05 PM, Lisa Dusseault wrote: > Yes, but how does this work in the other direction? If one user > agent encourages me to draw a square (or more complicated polygon) > around the location I'd like to keep private, how does the user > agent without a map reasonably show me what my policy is when I'd > like to check if I will have privacy? > As long as we're talking about user agents here, are there any client developers in the room? Anybody willing to talk about what they envision as an interface and what things are and are not requirements for that particular project? thx, Lisa --Apple-Mail-1--173672608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Sep 24, 2007, = at 1:05 PM, Lisa Dusseault wrote:

Yes, but how = does this work in the other direction?=A0 If one user agent encourages = me to draw a square (or more complicated polygon)=A0 around the location = I'd like to keep private, how does the user agent without a map = reasonably show me what my policy is when I'd like to check if I will = have privacy?


As = long as we're talking about user agents here, are there any client = developers in the room?=A0 Anybody willing to talk about what they = envision as an interface and what things are and are not requirements = for that particular project?

thx,
Lisa
= --Apple-Mail-1--173672608-- --===============2139093752== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============2139093752==-- From geopriv-bounces@ietf.org Tue Sep 25 11:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCiI-0007W6-U9; Tue, 25 Sep 2007 11:52:42 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaCiH-0007Vh-Mo for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:52:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCiH-0007VY-9d for geopriv@ietf.org; Tue, 25 Sep 2007 11:52:41 -0400 Received: from demumfd002.nsn-inter.net ([217.115.75.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaCiA-0000un-V4 for geopriv@ietf.org; Tue, 25 Sep 2007 11:52:41 -0400 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8PFq7PF023506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2007 17:52:07 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8PFq6Gd000945; Tue, 25 Sep 2007 17:52:06 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 17:52:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Date: Tue, 25 Sep 2007 17:52:04 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB32D254@DEMUEXC012.nsn-intra.net> In-Reply-To: <77EF1FA3-6A98-439E-8164-99E13FB5869F@osafoundation.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Thread-Index: Acf/id0J6/0HwDLASjiUOr3ZUQbYngAAK8Tg References: <46F3A8C8.6040402@gmx.net><46F77B84.8060702@gmx.net> <77EF1FA3-6A98-439E-8164-99E13FB5869F@osafoundation.org> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext Lisa Dusseault" , "Henning Schulzrinne" X-OriginalArrivalTime: 25 Sep 2007 15:52:06.0790 (UTC) FILETIME=[0633A260:01C7FF8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Lisa,=20 > On Sep 24, 2007, at 2:05 AM, Henning Schulzrinne wrote: >=20 > > > > On Sep 24, 2007, at 4:55 AM, Hannes Tschofenig wrote: > > > >> Hi Henning, > >> > >> > >> Maybe the suggestion is to provide a mechanism to label a certain =20 > >> geographical region for later usage in policies. Assume that an =20 > >> end host would configure these policies then someone (like the =20 > >> enterprise administrator, the user with the help of a map tool, =20 > >> the operator) would provide pre-defined regions that are labeled. > >> > >> Currently, the user interface could provide this=20 > functionality but =20 > >> there are no protocol features to enable them, i.e., the user =20 > >> interface at the Rule Maker would have to know what "home" means =20 > >> and then translate that to a polygon. > > > > Labeling regions would require a separate data set, i.e.,=20 > something =20 > > outside the current common-policy framework. Also, this would have =20 > > its own set of problems. If the operator changes such a=20 > region, the =20 > > user would suddenly, and without notification, have a very =20 > > different privacy policy. >=20 > I think by "labels", Hannes & I meant what you call "comments" =20 > below. Generally-understood region names are already part of the =20 > civic location stuff, right? I am fine with the idea of adding comments to the rules.=20 The civic location work=20 http://www.ietf.org/rfc/rfc4119.txt http://www.ietf.org/internet-drafts/draft-ietf-geopriv-revised-civic-lo- 05.txt already provides XML elements with a semantic for commonly used civic addresses. For example:=20 +---------------+--------+----------------------------+-------------+ | New Civic | CAtype | Description | Example | | Field | | | | +---------------+--------+----------------------------+-------------+ | BLD | 25 | Building (structure) | Hope | | | | | Theatre | .... I see the labels as something different and I recall some concept in GML (when it comes to the protocol aspects) that allows you to associate a name to a specific geographical region. For example: I would would use the name "my-home" as a replacement for the civic address describing something I call my home.=20 >=20 > In the case of civic definitions, is it likely operators will go =20 > changing region definitions? I agree that would be a problem. Difficult to say in advance.=20 >=20 >=20 > > In addition, unless there is a guarantee that these regions are =20 > > accessible by users and can be defined by users, it would be very =20 > > difficult for one user to maintain the same set of privacy=20 > policies =20 > > across multiple different service providers. Finally, I'm not sure =20 > > how this would address the issue of having to have map displays. =20 > > Almost all such regions would be either simple civic regions =20 > > ("Bergen county") or would need a map to be unambiguous to most =20 > > users ("New York metro area"). > >> > >> Sounds reasonable to me. > >> We could add an element to allow the Rule Maker to provide some =20 > >> human-readable text around the policy. > > > > And maybe add a 'comment' attribute to the rule. This, however, =20 > > seems more appropriate for the common-policy document, as a=20 > trivial =20 > > extension, since it is by no means specific to geopriv-policy. >=20 > Since one reasonable place to put a comment is in the "gp:location" =20 > element defined in this document, I'm not sure geopriv-policy is an =20 > inappropriate document to define a comment. There is the possiblity to define it specifically for this document. Alternatively, it is also possible to define it as an extension to Common Policy and to make it available to all other extensions as well since it might be of general usage.=20 >=20 > >> > >> Is there the suggestion to delete either civic or geodetic =20 > >> location information conditions entirely? > >> > > > > I'm not suggesting this, but I'm sure Lisa can clarify her concerns. >=20 > I was not suggesting that either, but it would be one way to avoid =20 > the case where two user agents want to operate on the same privacy =20 > policy and one only understands civic and the other only geodetic. =20 > Another solution would be to require user agents to understand both. Need to think about it... Ciao Hannes >=20 > Lisa >=20 >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 15:00:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFdW-0001FT-EG; Tue, 25 Sep 2007 14:59:58 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaFdU-0001DH-FC for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 14:59:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFdU-0001Cb-48 for geopriv@ietf.org; Tue, 25 Sep 2007 14:59:56 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaFdO-0001Gj-9k for geopriv@ietf.org; Tue, 25 Sep 2007 14:59:50 -0400 Received: from SusieandCarl (c-24-8-177-87.hsd1.co.comcast.net [24.8.177.87]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l8PIxaBF000657 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Sep 2007 14:59:37 -0400 Message-ID: <008b01c7ffa6$34d4e510$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Hannes Tschofenig" , "GEOPRIV" References: <46F3A8C8.6040402@gmx.net> Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Date: Tue, 25 Sep 2007 12:59:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.91.2/4394/Tue Sep 25 13:08:25 2007 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I am not sure if this is germane - as I need to read the document being discussed - but just based on the discussion to date, I might suggest taking a look at an emerging OGC standard for handling geospatially based authentication and authorization that is also a potential profile of XACML . There may be some very useful hints in the OGC GeoXACML document that are relevant to location and privacy. The most recent public version of the document can be downloaded from http://www.opengeospatial.org/standards/requests/41 . The candidate standard has been through a public comment period, has been reviewed by the Chair of the XACML TC in OASIS, and is currently in revision based on the comments received. Regards Carl ----- Original Message ----- From: "Hannes Tschofenig" To: "GEOPRIV" Sent: Friday, September 21, 2007 5:19 AM Subject: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy > Hi Lisa, > Hi all, > > Background: draft-ietf-geopriv-policy is currently in IESG Evaluation > and Lisa has put a DISCUSS on the document. > Here are Lisa's comments and I would like to discuss them on the mailing > list: > https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71788/? > https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71781/? > > Lisa focused on the aspect of user interfaces in her feedback. Thank you > Lisa for giving the document so much thought. > > Here is a copy-and-paste from the comments from the tracker: > > " > This is very complicated (too flexible) for a privacy extension. I do not > expect clients from different vendors to be able to interoperate very well > over the same policy information. I expect the end result of this to be > cases where users believe they have privacy, or intend to have privacy, > but do not achieve their goals due to difficulty of getting clients to > interoperate with each other and with servers. > " > > " > These mechanisms are too complicated and don't give enough thought to how > different user-agents are going to interact. In particular, one should > imagine setting a privacy policy with one user agent and then trying to > edit it with another. > > It seems that geo-spatial policy creation requires some kind of user > interface that includes a map. Is that correct? Are devices without maps > then unable to modify or even read policies? > > I am not sure that the polygons are as cut-and-dried as they appear. I'd > like to understand better: > - how one knows what is the inside of the polygon, and what is the outside > - ... how that interacts with poles and other problems mapping 2D to a > sphere > - how the altitude stuff works at all with client GUIs > - when is altitude known and unknown, independent of knowing a rough > long/lat position > - whether you can define a polygon for "Alberta" and one for > "Saskatchewan" and have any point be in one or the other or completely > outside both -- but not *inside* both, and not stuck in-between > > When it comes to users viewing policies created in the past, the lack of > human-readable labels and comments is going to be a real usability > problem. > > What happens when a user or user-agent creates a non-sensical > geo-political or geo-spatial location? > Are all geo-political elements *really* allowed in conditions? One > possible non-sensical policy would be "Show my location unless I'm in seat > 32A". Aren't there any restrictions here? > > How are user agents supposed to handle mixed geo-spatial and civic > location conditions? How would that be displayed or represented in a list > of policy elements? > > With the dependency on geopriv-revised-civic-lo, this can't complete yet > anyway. > " > > Thoughts? > > Ciao > Hannes > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 15:11:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFoq-000618-4K; Tue, 25 Sep 2007 15:11:40 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaFop-00060u-Ls for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 15:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFop-00060m-C5 for geopriv@ietf.org; Tue, 25 Sep 2007 15:11:39 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaFoj-0006wm-8Q for geopriv@ietf.org; Tue, 25 Sep 2007 15:11:39 -0400 Received: from [131.171.30.56] ([131.171.30.56]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8PJBEdG021595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Sep 2007 15:11:15 -0400 (EDT) In-Reply-To: <5FB585F183235B42A9E70095055136FB32D254@DEMUEXC012.nsn-intra.net> References: <46F3A8C8.6040402@gmx.net><46F77B84.8060702@gmx.net> <77EF1FA3-6A98-439E-8164-99E13FB5869F@osafoundation.org> <5FB585F183235B42A9E70095055136FB32D254@DEMUEXC012.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: AW: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy Date: Tue, 25 Sep 2007 15:11:13 -0400 To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: GEOPRIV WG X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org >> >> I was not suggesting that either, but it would be one way to avoid >> the case where two user agents want to operate on the same privacy >> policy and one only understands civic and the other only geodetic. >> Another solution would be to require user agents to understand both. > > Need to think about it... In the interest of simplicity, could we just drop both for now? The more I think about it, the more attractive this sounds... Henning _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Tue Sep 25 15:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFv3-0000SP-94; Tue, 25 Sep 2007 15:18:05 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaFv2-0000Hq-06 for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 15:18:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFv1-0008O6-LB for geopriv@ietf.org; Tue, 25 Sep 2007 15:18:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IaFuq-000798-Gg for geopriv@ietf.org; Tue, 25 Sep 2007 15:17:59 -0400 Received: (qmail invoked by alias); 25 Sep 2007 19:17:34 -0000 Received: from p549849F7.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.73.247] by mail.gmx.net (mp030) with SMTP; 25 Sep 2007 21:17:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+JHUZGhXeJQcJZg/i+g9Hldu+h66NatArLI3ugtH u7uUAu08W+iWL6 Message-ID: <46F95ECC.5060807@gmx.net> Date: Tue, 25 Sep 2007 21:17:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Carl Reed OGC Account Subject: Re: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy References: <46F3A8C8.6040402@gmx.net> <008b01c7ffa6$34d4e510$6401a8c0@SusieandCarl> In-Reply-To: <008b01c7ffa6$34d4e510$6401a8c0@SusieandCarl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Carl, Hi all, it is interesting that you mention that document. In fact we once had a proposal in the group that used XACML. Then, we switched to something simpler because of concerns regarding complexity. This was obviously a long time before that work started. I read through that document some time back and it is far more complex that what we proposed. Hence, it does not help us directly with the comments we received for our document. We can only use it as an argument for more complex solutions being already specified successfully by other SDOs. The only feature that is not included is civic location information. That's not surprising given that OGC does not use civic location information in their standards (if I understood it correctly). There is obviously no reference to our work although it started much earlier. We do, however, not reference their work either. Ciao Hannes PS: I could imagine that the approach other SDOs follow is a bit different to the one in the IETF. When they think there is something useful then they just do it. There may be some disadvantages and open issues here and there but they just push a document out there for people to look at. Then, they collect the implementation feedback and revise their docs. Carl Reed OGC Account wrote: > I am not sure if this is germane - as I need to read the document > being discussed - but just based on the discussion to date, I might > suggest taking a look at an emerging OGC standard for handling > geospatially based authentication and authorization that is also a > potential profile of XACML . There may be some very useful hints in > the OGC GeoXACML document that are relevant to location and privacy. > > The most recent public version of the document can be downloaded from > http://www.opengeospatial.org/standards/requests/41 . The candidate > standard has been through a public comment period, has been reviewed > by the Chair of the XACML TC in OASIS, and is currently in revision > based on the comments received. > > Regards > > Carl > > ----- Original Message ----- From: "Hannes Tschofenig" > > To: "GEOPRIV" > Sent: Friday, September 21, 2007 5:19 AM > Subject: [Geopriv] Lisa's DISCUSS on draft-ietf-geopriv-policy > > >> Hi Lisa, >> Hi all, >> >> Background: draft-ietf-geopriv-policy is currently in IESG Evaluation >> and Lisa has put a DISCUSS on the >> document. Here are Lisa's comments and I would like to discuss them >> on the mailing list: >> https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71788/? >> >> https://datatracker.ietf.org/idtracker/draft-ietf-geopriv-policy/comment/71781/? >> >> >> Lisa focused on the aspect of user interfaces in her feedback. Thank >> you Lisa for giving the document so much thought. >> >> Here is a copy-and-paste from the comments from the tracker: >> >> " >> This is very complicated (too flexible) for a privacy extension. I >> do not expect clients from different vendors to be able to >> interoperate very well over the same policy information. I expect >> the end result of this to be cases where users believe they have >> privacy, or intend to have privacy, but do not achieve their goals >> due to difficulty of getting clients to interoperate with each other >> and with servers. >> " >> >> " >> These mechanisms are too complicated and don't give enough thought to >> how different user-agents are going to interact. In particular, one >> should imagine setting a privacy policy with one user agent and then >> trying to edit it with another. >> >> It seems that geo-spatial policy creation requires some kind of user >> interface that includes a map. Is that correct? Are devices without >> maps then unable to modify or even read policies? >> >> I am not sure that the polygons are as cut-and-dried as they appear. >> I'd like to understand better: >> - how one knows what is the inside of the polygon, and what is the >> outside >> - ... how that interacts with poles and other problems mapping 2D to >> a sphere >> - how the altitude stuff works at all with client GUIs >> - when is altitude known and unknown, independent of knowing a rough >> long/lat position >> - whether you can define a polygon for "Alberta" and one for >> "Saskatchewan" and have any point be in one or the other or >> completely outside both -- but not *inside* both, and not stuck >> in-between >> >> When it comes to users viewing policies created in the past, the lack >> of human-readable labels and comments is going to be a real usability >> problem. >> >> What happens when a user or user-agent creates a non-sensical >> geo-political or geo-spatial location? >> Are all geo-political elements *really* allowed in conditions? One >> possible non-sensical policy would be "Show my location unless I'm in >> seat 32A". Aren't there any restrictions here? >> >> How are user agents supposed to handle mixed geo-spatial and civic >> location conditions? How would that be displayed or represented in a >> list of policy elements? >> >> With the dependency on geopriv-revised-civic-lo, this can't complete >> yet anyway. >> " >> >> Thoughts? >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Garonzikwmgzo@itcalliance.com Tue Sep 25 18:14:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIfv-0001zY-RB for geopriv-archive@lists.ietf.org; Tue, 25 Sep 2007 18:14:39 -0400 Received: from pool-71-247-32-177.nycmny.east.verizon.net ([71.247.32.177] helo=pool-68-237-95-29.ny325.east.verizon.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaIfg-0007jb-6k for geopriv-archive@lists.ietf.org; Tue, 25 Sep 2007 18:14:24 -0400 Received: from user-w5lm0fz8vf ([106.185.46.171]:13832 "EHLO user-w5lm0fz8vf" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by pool-68-237-95-29.ny325.east.verizon.net with ESMTP id S22ILJXTCWBRQQJU (ORCPT ); Tue, 25 Sep 2007 15:14:47 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Sep 2007 15:14:24 -0700 To: geopriv-archive@lists.ietf.org From: "Mark Garonzik" Subject: honomics Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.6 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi geopriv-archive My cock is soooo big now, thanks to these doctors Mark Garonzik http://www.lanaiocn.com/ From geopriv-bounces@ietf.org Tue Sep 25 19:44:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaK4U-0003qc-5S; Tue, 25 Sep 2007 19:44:06 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaK4S-0003pe-9G for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 19:44:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaK4R-0003pW-UU for geopriv@ietf.org; Tue, 25 Sep 2007 19:44:03 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaK4R-0001qB-Df for geopriv@ietf.org; Tue, 25 Sep 2007 19:44:03 -0400 X-SEF-Processed: 5_0_0_910__2007_09_25_18_53_41 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 25 Sep 2007 18:53:41 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 18:44:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] Re: DISCUSS on draft-ietf-geopriv-policy (Jari Arkko) Date: Tue, 25 Sep 2007 18:44:01 -0500 Message-ID: In-Reply-To: <46F8F1ED.9000303@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: DISCUSS on draft-ietf-geopriv-policy (Jari Arkko) Thread-Index: Acf/cyVELgXqukuyT1eoAzWqtyxAiQAWkgbg References: <46F8EB30.4@gmx.net> <46F8F1ED.9000303@piuha.net> From: "Thomson, Martin" To: "Jari Arkko" , "Hannes Tschofenig" X-OriginalArrivalTime: 25 Sep 2007 23:44:02.0749 (UTC) FILETIME=[F3D416D0:01C7FFCD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0176710805==" Errors-To: geopriv-bounces@ietf.org --===============0176710805== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpc3N1ZSB3YXMgY292ZXJlZCBpbiBteSBnZW8tc2hhcGUgZG9jdW1lbnQsIHN1YnNlcXVl bnRseSBhbiBPR0MgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQ6DQoNCk9HQyAwNi0xNDJyMSwgR01M IFBJREYtTE8gR2VvbWV0cnkgU2hhcGUgQXBwbGljYXRpb24gU2NoZW1hIGZvciB1c2UgaW4gdGhl IElFVEYNCjxodHRwOi8vd3d3Lm9wZW5nZW9zcGF0aWFsLm9yZy9zdGFuZGFyZHMvYnA+DQoNClRo ZSByZWNvbW1lbmRhdGlvbiBJIG1hZGUgd2FzIHRvIGF2b2lkIHBvbHlnb25zIG9mIGV4Y2Vzc2l2 ZSBzaXplLiBHdWlkZWxpbmVzIG9uIHNpemUgd2VyZSBnaXZlbi4NCg0KQWxzbyBub3RlIHRoYXQg cG9seWdvbnMgYXJlIGZvcm1lZCBieSBzdHJhaWdodCBsaW5lcywgbm90IGdyZWF0IGNpcmNsZSBj dXJ2ZXMuICBBbGxvd2FuY2VzIGFyZSBtYWRlIGZvciBjdXJ2ZXMgc2luY2UgdGhvc2UgYXJlIHVz ZWQgaW4gc29tZSBhcHBsaWNhdGlvbnMgKGMuZi4gM0dQUCBHQUQpLg0KDQpPYnZpb3VzbHksIHRo aXMgc3RhdGVtZW50IHdhcyBpbnRlbmRlZCB0byBmb2xsb3cgc2ltaWxhciBsaW5lcy4gIFdvdWxk IHNvbWUgZ3VpZGFuY2Ugb24gc2l6ZSBhbmQgdGhlIGFtb3VudCBvZiBlcnJvciB0aGF0IGlzIGlu dm9sdmVkIGhlbHA/DQoNCkNoZWVycywNCk1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEphcmkgQXJra28gW21haWx0bzpqYXJpLmFya2tvQHBpdWhhLm5ldF0N Cj4gU2VudDogVHVlc2RheSwgMjUgU2VwdGVtYmVyIDIwMDcgOTozMyBQTQ0KPiBUbzogSGFubmVz IFRzY2hvZmVuaWcNCj4gQ2M6IEdFT1BSSVYNCj4gU3ViamVjdDogW0dlb3ByaXZdIFJlOiBESVND VVNTIG9uIGRyYWZ0LWlldGYtZ2VvcHJpdi1wb2xpY3kgKEphcmkgQXJra28pDQo+IA0KPiBSaWdo dC4gU3BlY2lmaWNhbGx5LCBpdCBpcyB1bmNsZWFyIHRvIG1lIHdoYXQgaXMgYSBzbWFsbCB2YXJp YXRpb24NCj4gdGhhdCBJIHNob3VsZCBhY2NlcHQuDQo+IA0KPiBKYXJpDQo+IA0KPiBIYW5uZXMg VHNjaG9mZW5pZyBraXJqb2l0dGk6DQo+ID4gSGVyZSBpcyBKYXJpJ3MgRElTQ1VTUzoNCj4gPiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lkdHJhY2tlci9kcmFmdC1pZXRmLWdlb3ByaXYt DQo+IHBvbGljeS9jb21tZW50LzcxODM3Lw0KPiA+DQo+ID4NCj4gPiA+IEhvd2V2ZXIsDQo+ID4g PiBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGJlIHByZXBhcmVkIHRvIGFjY2VwdCBzbWFsbCB2YXJp YXRpb25zIHRoYXQNCj4gPiA+IG1pZ2h0IG9jY3VyIGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZSB0 aGUgcG9seWdvbiBpcyBzcGVjaWZpZWQgb24gYQ0KPiA+ID4gcGxhbmUgaW4gc3BhY2UsIG9yIG9u bHkgcmVsYXRpdmUgdG8gdGhlIGVsbGlwc29pZC4NCj4gPg0KPiA+IEkgZG8gbm90IHVuZGVyc3Rh bmQgaG93IHRvIGltcGxlbWVudCB0aGlzLiBQbGVhc2UgY2xhcmlmeQ0KPiA+DQo+ID4NCj4gDQo+ IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IEdlb3ByaXYgbWFpbGluZyBsaXN0DQo+IEdlb3ByaXZAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VvcHJpdg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2ln bmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmll dGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJl Y2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5 IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMg ZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KW21mMl0NCg== --===============0176710805== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0176710805==-- From geopriv-bounces@ietf.org Tue Sep 25 19:57:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaKHO-0001Cm-Ax; Tue, 25 Sep 2007 19:57:26 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaKHN-0001Ch-5A for geopriv-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 19:57:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaKHM-0001CZ-QW for geopriv@ietf.org; Tue, 25 Sep 2007 19:57:24 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaKHM-00027A-EE for geopriv@ietf.org; Tue, 25 Sep 2007 19:57:24 -0400 X-SEF-Processed: 5_0_0_910__2007_09_25_19_07_03 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 25 Sep 2007 19:07:02 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 18:57:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ Housley) Date: Tue, 25 Sep 2007 18:57:21 -0500 Message-ID: In-Reply-To: <46F8EE6B.9040602@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ Housley) Thread-Index: Acf/Zg0d93VtxSd5RH6CpTsYUYsFrwAaFwXg References: <46F8EE6B.9040602@gmx.net> From: "Thomson, Martin" To: "Hannes Tschofenig" , "GEOPRIV" X-OriginalArrivalTime: 25 Sep 2007 23:57:24.0056 (UTC) FILETIME=[D171D580:01C7FFCF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Russ Housley X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0131893447==" Errors-To: geopriv-bounces@ietf.org --===============0131893447== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gdGhlIHNlY29uZCBjb21tZW50IG9ubHkgKCd0aG91Z2ggSSBhZ3JlZSB3aXRoIHRoZSBmaXJz dCkuLi4NCg0KPiAiDQo+ICAgQ29uc2lkZXIgYSB0aGUgZm91ciBjb3JuZXJzIG9mIENvbG9yYWRv LiAgKENvbG9yYWRvIGlzIGEgcmVjdGFuZ2xlLikNCj4gICBDYWxsIHRoZSBub3J0aGVhc3QgY29y bmVyIEEuICBDYWxsIHRoZSBub3J0aHdlc3QgY29ybmVyIEIuICBDYWxsIHRoZQ0KPiAgIHNvdXRo d2VzdCBjb3JuZXIgQy4gIENhbGwgdGhlIHNvdXRoZWFzdCBjb3JuZXIgRC4gIEl0IGlzIHByZXR0 eSBjbGVhcg0KPiAgIHRoYXQgQUJDREEgaXMgYSB2YWxpZCBwb2x5Z29uLiAgSXMgQUNCREEgYSB2 YWxpZCBwb2x5Z29uPyAgSSBkbyBub3QNCj4gICBzZWUgdGV4dCB0aGF0IHdvdWxkIHRlbGwgbWUg dGhhdCBzdWNoIGEgcG9seWdvbiBpcyBub3QgYWxsb3dlZCwgYnV0DQo+ICAgc3VjaCB0ZXh0IGNv dWxkIGJlIGluIEVQU0cgNDMyNiBvciBFUFNHIDQ5NzkuICBJIGRpZCBub3QgZ28gbG9vay4gIEkN Cj4gICBoYXZlIHdyaXRlbiBhbGdvcml0aG1zIHRvIGZpbmQgYSBwb2x5Z29uIHRoYXQgaW5jbHVk ZXMgYWxsIG9mIHRoZQ0KPiAgIHByb3ZpZGVkIGNvb3JkaW5hdGVzLCBidXQgdGhhdCBkb2VzIG5v dCBzZWVtIGxpa2UgdGhlIHJpZ2h0IHRoaW5nDQo+ICAgdG8gZG8gaGVyZS4NCj4gDQo8c25pcCBm b3JtdWxhIChmaXJzdCBjb21tZW50Pyk+DQo+ICINCg0KR29vZCBwaWNrLXVwLg0KDQpJIHRoaW5r IHRoYXQgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gcmVmZXJlbmNlIHBpZGYtbG8tcHJvZmls ZSBmb3IgcnVsZXMgb24gcG9seWdvbiBjb25zdHJ1Y3Rpb24uICBJIGJlbGlldmUgdGhhdCB0aGUg dGV4dCBoZXJlIGlzIGNsb25lZCB0byBhdm9pZCBhIGRlcGVuZGVuY3kgcHJvYmxlbS4gIEEgcmVm ZXJlbmNlIHdvdWxkIGF2b2lkIHRoaXMgcHJvYmxlbS4NCg0KSGVyZSBpcyB3aGF0IHBkaWYtbG8t cHJvZmlsZSAoc2ljKSBzYXlzOg0KDQoiDQogICBBIGNvbm5lY3RpbmcgbGluZSBTSEFMTCBOT1Qg Y3Jvc3MgYW5vdGhlciBjb25uZWN0aW5nIGxpbmUgb2YgdGhlIHNhbWUNCiAgIFBvbHlnb24uDQoN CiAgIFBvbHlnb25zIFNIT1VMRCBiZSBkZWZpbmVkIHdpdGggdGhlIHVwd2FyZCBub3JtYWwgcG9p bnRpbmcgdXAsIHRoaXMNCiAgIGlzIGFjY29tcGxpc2hlZCBieSBkZWZpbmluZyB0aGUgdmVydGlj ZXMgaW4gY291bnRlci1jbG9ja3dpc2UNCiAgIGRpcmVjdGlvbi4NCg0KICAgUG9pbnRzIHNwZWNp ZmllZCBpbiBhIHBvbHlnb24gTVVTVCBiZSBjb3BsYW5hciwgYW5kIGl0IGlzIFJFQ09NTUVOREVE DQogICB0aGF0IHdoZXJlIHBvaW50cyBhcmUgc3BlY2lmaWVkIGluIDMgZGltZW5zaW9ucyB0aGF0 IGFsbCBwb2ludHMNCiAgIG1haW50YWluIHRoZSBzYW1lIGFsdGl0dWRlLg0KIg0KDQpNYWtpbmcg dGhlIHNhbWUgYWx0aXR1ZGUgcmVzdHJpY3Rpb24gbWFuZGF0b3J5IGlzIHRoZSBvbmx5IGRpZmZl cmVuY2UgSSBjYW4gc2VlIGhlcmUuDQoNClJlZ2FyZHMsDQpNYXJ0aW4NCg0KcC5zLiBCeSBwZGlm LWxvLXByb2ZpbGUsIEFEQ0JBIGlzbid0IHJlY29tbWVuZGVkIGVpdGhlciBiZWNhdXNlIGl0IGlz IGluIGNsb2Nrd2lzZSBvcmRlci4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9u bHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNl IHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9y aWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRl ZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== --===============0131893447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0131893447==-- From obira-olague@espacom.net Wed Sep 26 04:04:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaRt2-0005Om-4I for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 04:04:48 -0400 Received: from [85.130.104.142] (helo=142.direct-130-104.bgcell.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaRsv-0002Zo-NX for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 04:04:43 -0400 Received: from apis-12a26e640c ([186.157.123.121] helo=apis-12a26e640c) by 142.direct-130-104.bgcell.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1VqqcL-000RZS-mT for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 11:05:08 +0300 Message-ID: <000901c80013$e279a260$8e688255@apis12a26e640c> From: "obira olague" To: Subject: gtkudorp Date: Wed, 26 Sep 2007 11:04:38 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8002D.07C6DA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C8002D.07C6DA60 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable http://lanaiocn.com/ Yo yo yo geopriv-archive My cock is soooo big now, thanks to these doctors obira olague ------=_NextPart_000_0007_01C8002D.07C6DA60 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
http://lanaiocn.com/
Yo yo yo geopriv-archive
My cock is soooo big now, thanks to these = doctors
obira olague
------=_NextPart_000_0007_01C8002D.07C6DA60-- From geopriv-bounces@ietf.org Wed Sep 26 05:48:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaTUi-0005Yw-IC; Wed, 26 Sep 2007 05:47:48 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaTUi-0005Yr-57 for geopriv-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 05:47:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaTUh-0005Yj-RK for geopriv@ietf.org; Wed, 26 Sep 2007 05:47:47 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaTUg-0004h6-Km for geopriv@ietf.org; Wed, 26 Sep 2007 05:47:47 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 02B6619865D; Wed, 26 Sep 2007 12:47:46 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id AA5BB19865C; Wed, 26 Sep 2007 12:47:45 +0300 (EEST) Message-ID: <46FA2ABE.6000700@piuha.net> Date: Wed, 26 Sep 2007 11:47:42 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Geopriv] Re: DISCUSS on draft-ietf-geopriv-policy (Jari Arkko) References: <46F8EB30.4@gmx.net> <46F8F1ED.9000303@piuha.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: GEOPRIV X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > > Would some guidance on size and the amount of error that is involved help? That would help, as would reference to another document that has the specific guidelines. Jari _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From preeper@bda.com.au Wed Sep 26 05:54:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaTb8-0000ib-Uh for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 05:54:26 -0400 Received: from [88.246.156.223] (helo=dsl88-246-40159.ttnet.net.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaTb7-0004pt-DJ for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 05:54:26 -0400 Received: from RAMAZANYILMAZ-7 ([169.164.20.10]:9038 "EHLO RAMAZANYILMAZ-7" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by dsl88-246-40159.ttnet.net.tr with ESMTP id S22HKKWPVAJRKRNY (ORCPT ); Wed, 26 Sep 2007 12:55:00 +0300 Message-ID: <000201c80023$3cb8ab90$df9cf658@RAMAZANYILMAZ7> From: "kirt preeper" To: Subject: svn-6916 Date: Wed, 26 Sep 2007 12:54:32 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8003C.62085490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C8003C.62085490 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable http://www.ghostorg.com/ Yo yo yo geopriv-archive Before Manster i had no women, now i have 3 going at once =3D ) kirt preeper ------=_NextPart_000_0007_01C8003C.62085490 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
http://www.ghostorg.com/
Yo yo yo geopriv-archive
Before Manster i had no women, now i have 3 = going at=20 once =3D )
kirt preeper
------=_NextPart_000_0007_01C8003C.62085490-- From Brock.marian@testpatternpictures.com Wed Sep 26 08:18:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVqa-00031Z-Vb for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 08:18:33 -0400 Received: from cpc3-belc2-0-0-cust881.belf.cable.ntl.com ([82.4.211.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaVqa-0005BJ-HO for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 08:18:32 -0400 Received: by 10.164.27.81 with SMTP id skmIPUKbCvBSi; Wed, 26 Sep 2007 13:18:37 +0100 (GMT) Received: by 192.168.131.200 with SMTP id gkhUSahjurLTva.1694307316892; Wed, 26 Sep 2007 13:18:35 +0100 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 26 Sep 2007 13:18:32 +0100 To: geopriv-archive@lists.ietf.org From: "Brock marian" Subject: starkdru Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi there geopriv-archive All i want for christmas is a big phat pe@nis to please my girl Brock marian http://www.goingles.com/ From Hazelekjrd@classic-togs.com Wed Sep 26 09:54:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXLS-0000Mr-EM for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 09:54:30 -0400 Received: from host123-10-dynamic.1-87-r.retail.telecomitalia.it ([87.1.10.123]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXLR-0007lo-QU for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 09:54:30 -0400 Received: by 10.25.214.170 with SMTP id kByLqmqNAokEK; Wed, 26 Sep 2007 15:55:46 +0200 (GMT) Received: by 192.168.169.66 with SMTP id ucbvfuWTOyNJjP.6151008782125; Wed, 26 Sep 2007 15:55:44 +0200 (GMT) Date: Wed, 26 Sep 2007 15:55:41 +0200 From: "LOCO Hazel" Reply-To: "LOCO Hazel" Message-ID: <925872784445.879637253538@classic-togs.com> To: Subject: ope'rion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 4.0 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Night geopriv-archive i am the most confident person in the world now.. LOCO Hazel http://www.goolyl.com/ From geopriv-bounces@ietf.org Wed Sep 26 12:20:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZbW-0001rO-Bd; Wed, 26 Sep 2007 12:19:14 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaZbU-0001oN-M7 for geopriv-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 12:19:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZbU-0001aH-Ah for geopriv@ietf.org; Wed, 26 Sep 2007 12:19:12 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaZbO-0004KQ-5g for geopriv@ietf.org; Wed, 26 Sep 2007 12:19:07 -0400 Received: from SusieandCarl (c-24-8-177-87.hsd1.co.comcast.net [24.8.177.87]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l8QGIgON032570 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Sep 2007 12:18:50 -0400 Message-ID: <018b01c80058$e976d3e0$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: Subject: Fw: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ Housley) Date: Wed, 26 Sep 2007 10:18:31 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Status: No, score=-95.6 required=5.0 tests=BAYES_50,HTML_30_40, HTML_MESSAGE,RCVD_IN_NJABL_DUL,RCVD_IN_PBL,RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.91.2/4404/Wed Sep 26 08:53:15 2007 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0430358699==" Errors-To: geopriv-bounces@ietf.org This is a multi-part message in MIME format. --===============0430358699== Content-Type: multipart/alternative; boundary="----=_NextPart_000_017E_01C80026.96546650" This is a multi-part message in MIME format. ------=_NextPart_000_017E_01C80026.96546650 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sent this yesterday but the mail was too large. Trying again without the = diagram. If anyone wishes to see the UML diagram for GM_Polygon, let me = know and I can email separately. Regards Carl ----- Original Message -----=20 From: Carl Reed OGC Account=20 To: Thomson, Martin ; Hannes Tschofenig ; GEOPRIV=20 Cc: Russ Housley=20 Sent: Tuesday, September 25, 2007 7:16 PM Subject: Re: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ = Housley) Martin - This is good guidance. Just to put things in context, the GML Polygon element is fairly = comprehensive. The abstract definition is documented in ISO 19107. To = wit: 6.4.36 GM_Polygon 6.4.36.1 Semantics A GM_Polygon (Figure 21) is a surface patch that is defined by a set of = boundary curves and an underlying surface to which these curves adhere. = The default is that the curves are coplanar and the polygon uses planar = interpolation in its interior. This definition is so comprehensive because there are many, many ways to = define a polygonal surface (both 2d and 3d). Simple coordinate lists are = the most elemental and primitive method of defining a polygon. This = method is what is used in the GML PIDF-LO application schema. I guess = that it should be noted that if we ever need to add additional methods = for defining a polygon, additional GML elements are available! And if one considers the UML diagram for GM_Polygon (below), it is = definitely best to be very clear what semantics we are using for polygon = in PIDF-LO :-) Cheers Carl ----- Original Message -----=20 From: "Thomson, Martin" To: "Hannes Tschofenig" ; "GEOPRIV" = Cc: "Russ Housley" Sent: Tuesday, September 25, 2007 5:57 PM Subject: RE: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ = Housley) > On the second comment only ('though I agree with the first)... >=20 >> " >> Consider a the four corners of Colorado. (Colorado is a = rectangle.) >> Call the northeast corner A. Call the northwest corner B. Call = the >> southwest corner C. Call the southeast corner D. It is pretty = clear >> that ABCDA is a valid polygon. Is ACBDA a valid polygon? I do not >> see text that would tell me that such a polygon is not allowed, but >> such text could be in EPSG 4326 or EPSG 4979. I did not go look. = I >> have writen algorithms to find a polygon that includes all of the >> provided coordinates, but that does not seem like the right thing >> to do here. >>=20 > >> " >=20 > Good pick-up. >=20 > I think that it would be a good idea to reference pidf-lo-profile for = rules on polygon construction. I believe that the text here is cloned = to avoid a dependency problem. A reference would avoid this problem. >=20 > Here is what pdif-lo-profile (sic) says: >=20 > " > A connecting line SHALL NOT cross another connecting line of the = same > Polygon. >=20 > Polygons SHOULD be defined with the upward normal pointing up, this > is accomplished by defining the vertices in counter-clockwise > direction. >=20 > Points specified in a polygon MUST be coplanar, and it is = RECOMMENDED > that where points are specified in 3 dimensions that all points > maintain the same altitude. > " >=20 > Making the same altitude restriction mandatory is the only difference = I can see here. >=20 > Regards, > Martin >=20 > p.s. By pdif-lo-profile, ADCBA isn't recommended either because it is = in clockwise order. >=20 >=20 > = -------------------------------------------------------------------------= ----------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > = -------------------------------------------------------------------------= ----------------------- > [mf2] >=20 -------------------------------------------------------------------------= ------- > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > ------=_NextPart_000_017E_01C80026.96546650 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Sent this yesterday but the mail was too large. Trying again = without the=20 diagram. If anyone wishes to see the UML diagram for GM_Polygon, let me = know and=20 I can email separately.
 
Regards
 
Carl
 
 
----- Original Message -----=20
From: Carl Reed=20 OGC Account
To: Thomson, Martin ; Hannes=20 Tschofenig ; GEOPRIV
Sent: Tuesday, September 25, 2007 7:16 PM
Subject: Re: [Geopriv] DISCUSS on draft-ietf-geopriv-policy = (Russ=20 Housley)

Martin -
 
This is good guidance.
 
Just to put things in context, the GML Polygon element is fairly=20 comprehensive. The abstract definition is documented = in ISO=20 19107. To wit:

6.4.36 GM_Polygon

6.4.36.1 Semantics

A GM_Polygon (Figure 21) is a surface patch that is = defined by=20 a set of boundary curves and an underlying surface to which these curves = adhere.=20 The default is that the curves are coplanar and the polygon uses planar=20 interpolation in its interior.

This definition is so comprehensive because there are = many, many=20 ways to define a polygonal surface (both 2d and 3d). Simple coordinate = lists are=20 the most elemental and primitive method of defining a polygon. This = method is=20 what is used in the GML PIDF-LO application schema. I guess that it = should be=20 noted that if we ever need to add additional methods for defining a = polygon,=20 additional GML elements are available!

And if one considers the UML diagram for GM_Polygon = (below), it is=20 definitely best to be very clear what semantics we are using for polygon = in=20 PIDF-LO :-)

Cheers

Carl

 

----- Original Message -----=20
From: "Thomson, Martin" <Martin.Thomson@andrew.com&g= t;
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net&g= t;;=20 "GEOPRIV" <geopriv@ietf.org>
Cc: "Russ Housley" <housley@vigilsec.com>
Sent: Tuesday, September 25, 2007 5:57 PM
Subject: RE: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ=20 Housley)

> On the second comment only ('though I agree with the = first)...
>
>> "
>>   Consider a the = four=20 corners of Colorado.  (Colorado is a = rectangle.)
>>  =20 Call the northeast corner A.  Call the northwest corner B.  = Call=20 the
>>   southwest corner C.  Call the southeast = corner=20 D.  It is pretty clear
>>   that ABCDA is a = valid=20 polygon.  Is ACBDA a valid polygon?  I do = not
>>  =20 see text that would tell me that such a polygon is not allowed,=20 but
>>   such text could be in EPSG 4326 or EPSG = 4979. =20 I did not go look.  I
>>   have writen = algorithms to=20 find a polygon that includes all of the
>>   provided = coordinates, but that does not seem like the right = thing
>>  =20 to do here.
>>
> <snip formula (first=20 comment?)>
>> "
>
> Good pick-up.
> =
> I=20 think that it would be a good idea to reference pidf-lo-profile for = rules on=20 polygon construction.  I believe that the text here is cloned to = avoid a=20 dependency problem.  A reference would avoid this problem.
> =
>=20 Here is what pdif-lo-profile (sic) says:
>
> = "
>  =20 A connecting line SHALL NOT cross another connecting line of the=20 same
>   Polygon.
>
>   Polygons = SHOULD=20 be defined with the upward normal pointing up, this
>   = is=20 accomplished by defining the vertices in = counter-clockwise
>  =20 direction.
>
>   Points specified in a polygon = MUST be=20 coplanar, and it is RECOMMENDED
>   that where points = are=20 specified in 3 dimensions that all points
>   maintain = the same=20 altitude.
> "
>
> Making the same altitude = restriction=20 mandatory is the only difference I can see here.
>
>=20 Regards,
> Martin
>
> p.s. By pdif-lo-profile, ADCBA = isn't=20 recommended either because it is in clockwise order.
>
> =
>=20 -------------------------------------------------------------------------= -----------------------
>=20 This message is for the designated recipient only and may
> = contain=20 privileged, proprietary, or otherwise private information.  =
> If you=20 have received it in error, please notify the sender
> immediately = and=20 delete the original.  Any unauthorized use of
> this email is = prohibited.
>=20 -------------------------------------------------------------------------= -----------------------
>=20 [mf2]
>=20

> _______________________________________________
> = Geopriv=20 mailing list
> Geopriv@ietf.org
> https://www1.ietf= .org/mailman/listinfo/geopriv
>=20 ------=_NextPart_000_017E_01C80026.96546650-- --===============0430358699== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --===============0430358699==-- From geopriv-bounces@ietf.org Wed Sep 26 12:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaa0v-0006Yj-Pa; Wed, 26 Sep 2007 12:45:29 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Iaa0u-0006Xf-3N for geopriv-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 12:45:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaa0s-0006PE-Uo for geopriv@ietf.org; Wed, 26 Sep 2007 12:45:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iaa0h-00056c-Vz for geopriv@ietf.org; Wed, 26 Sep 2007 12:45:16 -0400 Received: (qmail 1871 invoked by uid 0); 26 Sep 2007 16:45:14 -0000 Received: from 90.186.70.43 by www066.gmx.net with HTTP; Wed, 26 Sep 2007 18:45:14 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Sep 2007 18:45:14 +0200 From: "Hannes Tschofenig" In-Reply-To: <018b01c80058$e976d3e0$6401a8c0@SusieandCarl> Message-ID: <20070926164514.254020@gmx.net> MIME-Version: 1.0 References: <018b01c80058$e976d3e0$6401a8c0@SusieandCarl> Subject: Re: Fw: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ Housley) To: "Carl Reed OGC Account" , geopriv@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+coAoKwaicfPf3XgtOKw011a8wbwF0sr8cIVMx+E TzF6EVNT8vWJCY0xaq6vcLEdAamgjiaKTkyQ== Content-Transfer-Encoding: 7bit X-GMX-UID: rr7NcVMabGInY4oVr2VnprxvcmZ1Ztyx X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org http://www.tschofenig.priv.at/TEMP/GM_Polygon.JPG -------- Original-Nachricht -------- > Datum: Wed, 26 Sep 2007 10:18:31 -0600 > Von: "Carl Reed OGC Account" > An: geopriv@ietf.org > Betreff: Fw: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ Housley) > Sent this yesterday but the mail was too large. Trying again without the > diagram. If anyone wishes to see the UML diagram for GM_Polygon, let me know > and I can email separately. > > Regards > > Carl > > > ----- Original Message ----- > From: Carl Reed OGC Account > To: Thomson, Martin ; Hannes Tschofenig ; GEOPRIV > Cc: Russ Housley > Sent: Tuesday, September 25, 2007 7:16 PM > Subject: Re: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ Housley) > > > Martin - > > This is good guidance. > > Just to put things in context, the GML Polygon element is fairly > comprehensive. The abstract definition is documented in ISO 19107. To wit: > 6.4.36 GM_Polygon > > 6.4.36.1 Semantics > > A GM_Polygon (Figure 21) is a surface patch that is defined by a set of > boundary curves and an underlying surface to which these curves adhere. The > default is that the curves are coplanar and the polygon uses planar > interpolation in its interior. > > This definition is so comprehensive because there are many, many ways to > define a polygonal surface (both 2d and 3d). Simple coordinate lists are the > most elemental and primitive method of defining a polygon. This method is > what is used in the GML PIDF-LO application schema. I guess that it should > be noted that if we ever need to add additional methods for defining a > polygon, additional GML elements are available! > > And if one considers the UML diagram for GM_Polygon (below), it is > definitely best to be very clear what semantics we are using for polygon in > PIDF-LO :-) > > Cheers > > Carl > > > > ----- Original Message ----- > From: "Thomson, Martin" > To: "Hannes Tschofenig" ; "GEOPRIV" > > Cc: "Russ Housley" > Sent: Tuesday, September 25, 2007 5:57 PM > Subject: RE: [Geopriv] DISCUSS on draft-ietf-geopriv-policy (Russ Housley) > > > > On the second comment only ('though I agree with the first)... > > > >> " > >> Consider a the four corners of Colorado. (Colorado is a rectangle.) > >> Call the northeast corner A. Call the northwest corner B. Call the > >> southwest corner C. Call the southeast corner D. It is pretty clear > >> that ABCDA is a valid polygon. Is ACBDA a valid polygon? I do not > >> see text that would tell me that such a polygon is not allowed, but > >> such text could be in EPSG 4326 or EPSG 4979. I did not go look. I > >> have writen algorithms to find a polygon that includes all of the > >> provided coordinates, but that does not seem like the right thing > >> to do here. > >> > > > >> " > > > > Good pick-up. > > > > I think that it would be a good idea to reference pidf-lo-profile for > rules on polygon construction. I believe that the text here is cloned to > avoid a dependency problem. A reference would avoid this problem. > > > > Here is what pdif-lo-profile (sic) says: > > > > " > > A connecting line SHALL NOT cross another connecting line of the same > > Polygon. > > > > Polygons SHOULD be defined with the upward normal pointing up, this > > is accomplished by defining the vertices in counter-clockwise > > direction. > > > > Points specified in a polygon MUST be coplanar, and it is RECOMMENDED > > that where points are specified in 3 dimensions that all points > > maintain the same altitude. > > " > > > > Making the same altitude restriction mandatory is the only difference I > can see here. > > > > Regards, > > Martin > > > > p.s. By pdif-lo-profile, ADCBA isn't recommended either because it is in > clockwise order. > > > > > > > ------------------------------------------------------------------------------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------------------------------ > > [mf2] > > > > > -------------------------------------------------------------------------------- > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From SummersyrupWhalen@evolt.org Wed Sep 26 21:28:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaiAw-0004K6-A2 for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 21:28:22 -0400 Received: from 200-127-233-214.cab.prima.net.ar ([200.127.233.214] helo=pablo.ciudad.com.ar) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IaiAZ-0005pq-JZ for geopriv-archive@lists.ietf.org; Wed, 26 Sep 2007 21:27:59 -0400 Received: from [200.127.233.214] by ; Thu, 27 Sep 2007 -02:17:25 -0300 Message-ID: <01c800a5$a3e07820$d6e97fc8@SummersyrupWhalen> From: "Pete Person" To: Subject: [*]-+]- ]:[ ]-!+ ). Date: Thu, 27 Sep 2007 -02:17:25 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.2730.2 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Sy*m*b:oool F[D)E.G Close at 0.04 T!ar[ge t 0.12 From geopriv-bounces@ietf.org Thu Sep 27 05:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IapZe-00013O-N1; Thu, 27 Sep 2007 05:22:22 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IapZc-00010b-NT for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 05:22:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IapZc-00010S-6y for geopriv@ietf.org; Thu, 27 Sep 2007 05:22:20 -0400 Received: from andrew.triumf.ca ([142.90.106.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IapZb-0001L2-M2 for geopriv@ietf.org; Thu, 27 Sep 2007 05:22:20 -0400 Received: from localhost (localhost [127.0.0.1]) by andrew.triumf.ca (8.12.11.20060308/8.12.8) with ESMTP id l8R9MGkA023101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Sep 2007 02:22:16 -0700 Date: Thu, 27 Sep 2007 02:22:16 -0700 (PDT) From: Andrew Daviel X-X-Sender: andrew@andrew.triumf.ca To: geopriv@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [Geopriv] FYI - Google geocoding vs PIDF-LO X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org FYI (apologies if this has been already seen/discussed) : There are a few sites using Google's geocoding API to derive position data, plus geocoding information. So it may become a de facto standard simply because Google is popular and their API is freely available and easy to use. As per http://www.google.com/apis/maps/documentation/reference.html, http://www.developer.com/lang/jscript/article.php/3615681 Google PIDF-LO ------ ------- Thoroughfare A6,PRD,POD,STS,HNO Locality A3 SubAdministrativeArea A2 AdministrativeArea A1 PostalCode PC CountryNameCode country I fed a few addresses in Canada, England, France, USA to see what it came up with. Ironically, the US addresses I tried (presumably the first country that Google put online) did not work. For UK and Canadian addresses, the postcodes were fractional, which might be confusing if you tried to use it on a letter. E.g. "RH17 5" for "RH17 5QQ" (UK), or "V6T" for "V6T 2A3" (CA). Unlike the US, postcodes here are never split - at least not by ordinary people. In the UK, one would normally use a county as AdministrativeArea (e.g. Devon, Cornwall, Middlesex), but Google uses "England". Which makes a certain amount of sense - "Great Britain" (GB) as I recall is England, Scotland + Wales while adding Northern Ireland makes it "United Kingdom" (UK). It just seems odd at first glance. But then, the postal address of my old home in Britain never did make much sense - the "town" was about 5 miles away, while the mail was actually sorted in a different town about 20 miles in the other direction (its initials forming the first letters of the postcode, and the road name was usually left off the postal address altogether, so that physically finding it from the address was rather hard). Google's SubAdministrativeArea sometimes matches counties in the UK, sometimes not. In Vancouver it is "Greater Vancouver Regional District" - not the answer you get if you ask someone where they live. They'd just say "Vancouver", or maybe "Kerrisdale" if pressed (the "village" or district). Anyway, if I rid myself of the notion that geocoding ought to match postal addresses or common usage, Google's matches fairly well to the most significant PIDF-LO fields. Google postal 4004 Wesbrook Mall 4004 Wesbrook Mall Vancouver Vancouver GVRD BC BC V6T 2A3 V6T Canada CA Colwoon Ln Green Gables (not the actual name) Bolney Bolney West Sussex Haywards Heath England Sussex RH17 5 RH17 5QQ GB Great Britain -- Andrew Daviel, TRIUMF, Canada _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 05:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaptL-0004XF-G3; Thu, 27 Sep 2007 05:42:43 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IaptI-0004Tk-2W for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 05:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaptH-0004RO-3B for geopriv@ietf.org; Thu, 27 Sep 2007 05:42:39 -0400 Received: from andrew.triumf.ca ([142.90.106.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iapt9-0000Yr-Iw for geopriv@ietf.org; Thu, 27 Sep 2007 05:42:38 -0400 Received: from localhost (localhost [127.0.0.1]) by andrew.triumf.ca (8.12.11.20060308/8.12.8) with ESMTP id l8R9g9Gn023708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 02:42:09 -0700 Date: Thu, 27 Sep 2007 02:42:09 -0700 (PDT) From: Andrew Daviel X-X-Sender: andrew@andrew.triumf.ca To: Henning Schulzrinne Subject: Re: [Geopriv] Draft Updates "GEO TAGS for HTML" In-Reply-To: <66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu> Message-ID: References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu> <4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu> <66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Tue, 25 Sep 2007, Henning Schulzrinne wrote: > > As pointed out before, nobody is suggesting that you define a new document > format. The suggestion is to define civic and geo meta tags that have a > one-to-one correspondence with PIDF-LO tags, as in > > So, do I have this right ? : as per PIDF-LO from draft-ietf-geopriv-pidf-lo-03.txt or RFC 4776 as per ISO3166-1 matches ISO3166-2 for US, CA but seems less obscure than ISO elsewhere City (locality) Postcode/Zip etc. If I resubmit draft-daviel-html dropping geo.region and geo.placename and adding the PIDF fields as above, would this be acceptable? I could enumerate the fields from RFC4776, or simply refer to this RFC. I had some feedback that the totality of PIDF fields is too complex for the intended purpose of my draft (non-professional human authoring). But as I understand, the fields are optional and not all fields have values in any case. I could mention country and A1 specifically and the others by reference. Regarding "a new document format", I came across a piece by Berners-Lee et al. bemoaning the fact that people like me are still writing "quirks mode" HTML instead of fully embracing the XML semantic web http://www.w3.org/2007/03/vision I do wonder occasionally whether advances in artificial intelligence will render it all moot (except for industrial uses where communities can agree on a schema) But on the other hand I find the microformat community has been busy defining things like hCard while I've been asleep, which seems to be embeddable in XHTML/RSS (looks like they adopted GEO from RFC 2445) http://microformats.org/wiki/geo Andrew Daviel _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 05:51:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaq1S-0004m3-Gl; Thu, 27 Sep 2007 05:51:06 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Iaq1R-0004hH-A5 for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 05:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaq1Q-0004fu-Vr for geopriv@ietf.org; Thu, 27 Sep 2007 05:51:04 -0400 Received: from demumfd002.nsn-inter.net ([217.115.75.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iaq1L-0000ld-E0 for geopriv@ietf.org; Thu, 27 Sep 2007 05:51:04 -0400 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8R9oYog021287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 11:50:35 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8R9oXgC010793; Thu, 27 Sep 2007 11:50:34 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 11:50:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Geopriv] Draft Updates "GEO TAGS for HTML" Date: Thu, 27 Sep 2007 11:50:33 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Draft Updates "GEO TAGS for HTML" Thread-Index: AcgA60qT98PtXrXaS5aZdK3UAsUFwwAACZlQ References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu><4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu><66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu> From: "Tschofenig, Hannes (NSN - DE/Munich)" To: "ext Andrew Daviel" , "Henning Schulzrinne" X-OriginalArrivalTime: 27 Sep 2007 09:50:34.0142 (UTC) FILETIME=[D933BBE0:01C800EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Andrew,=20 > On Tue, 25 Sep 2007, Henning Schulzrinne wrote: >=20 > > > > As pointed out before, nobody is suggesting that you define=20 > a new document=20 > > format. The suggestion is to define civic and geo meta tags=20 > that have a=20 > > one-to-one correspondence with PIDF-LO tags, as in > > > > >=20 >=20 > So, do I have this right ? : >=20 > as per PIDF-LO from draft-ietf-geopriv-pidf-lo-03.txt or RFC 4776 >=20 > as per ISO3166-1 > matches ISO3166-2=20 > for US, CA > but seems less=20 > obscure than > ISO elsewhere >=20 > City (locality) > Postcode/Zip >=20 > etc. >=20 > If I resubmit draft-daviel-html dropping geo.region and=20 > geo.placename and > adding the PIDF fields as above, would this be acceptable? These change look promising to me.=20 > I could enumerate the fields from RFC4776, or simply refer to=20 > this RFC. >=20 You will have to add a reference to RFC 4776 anyway.=20 > I had some feedback that the totality of PIDF fields is too=20 > complex for=20 > the intended purpose of my draft (non-professional human=20 > authoring). But=20 > as I understand, the fields are optional and not all fields=20 > have values=20 > in any case. I could mention country and A1 specifically and=20 > the others=20 > by reference. Complexity for what exactly?=20 You might omit a few fields but you again have to be careful that you can still represent a location in, let's say, Japan.=20 Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 05:56:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaq6S-0002Ei-N1; Thu, 27 Sep 2007 05:56:16 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Iaq6Q-0001tm-DC for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 05:56:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaq6Q-0001sE-1H for geopriv@ietf.org; Thu, 27 Sep 2007 05:56:14 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaq6P-0002Mq-JF for geopriv@ietf.org; Thu, 27 Sep 2007 05:56:13 -0400 X-SEF-Processed: 5_0_0_910__2007_09_27_05_05_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 27 Sep 2007 05:05:53 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 04:56:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Draft Updates "GEO TAGS for HTML" Date: Thu, 27 Sep 2007 04:56:10 -0500 Message-ID: In-Reply-To: <5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Draft Updates "GEO TAGS for HTML" Thread-Index: AcgA60qT98PtXrXaS5aZdK3UAsUFwwAACZlQAABJVIA= References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu><4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu><66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu> <5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> From: "Winterbottom, James" To: "Tschofenig, Hannes \(NSN - DE/Munich\)" , "ext Andrew Daviel" , "Henning Schulzrinne" X-OriginalArrivalTime: 27 Sep 2007 09:56:12.0923 (UTC) FILETIME=[A3219CB0:01C800EC] X-Spam-Score: 1.8 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Or reference the revised civic specification.=0D=0A=0D=0A=0D=0A> -----Origi= nal Message-----=0D=0A> From: Tschofenig, Hannes (NSN - DE/Munich)=0D=0A> [= mailto:hannes.tschofenig@nsn.com]=0D=0A> Sent: Thursday, 27 September 2007 = 7:51 PM=0D=0A> To: ext Andrew Daviel; Henning Schulzrinne=0D=0A> Cc: geopri= v@ietf.org=0D=0A> Subject: AW: [Geopriv] Draft Updates "GEO TAGS for HTML"=0D= =0A>=20=0D=0A> Hi Andrew,=0D=0A>=20=0D=0A>=20=0D=0A> > On Tue, 25 Sep 2007,= Henning Schulzrinne wrote:=0D=0A> >=0D=0A> > >=0D=0A> > > As pointed out b= efore, nobody is suggesting that you define=0D=0A> > a new document=0D=0A> = > > format. The suggestion is to define civic and geo meta tags=0D=0A> > th= at have a=0D=0A> > > one-to-one correspondence with PIDF-LO tags, as in=0D=0A= > > >=0D=0A> > > =0D=0A> >=0D= =0A> >=0D=0A> > So, do I have this right =3F :=0D=0A> >=0D=0A> > as per PID= F-LO from draft-ietf-geopriv-pidf-lo-03.txt or RFC 4776=0D=0A> >=0D=0A> > <= meta name=3D"geo.country" content=3D"CA"> as per ISO3166-1=0D=0A> > matches ISO3166-2=0D=0A> > for = US, CA=0D=0A> > but seems less=0D= =0A> > obscure than=0D=0A> > IS= O elsewhere=0D=0A> >=0D=0A> > = City (locality)=0D=0A> > P= ostcode/Zip=0D=0A> >=0D=0A> > etc.=0D=0A> >=0D=0A> > If I resubmit draft-da= viel-html dropping geo.region and=0D=0A> > geo.placename and=0D=0A> > addin= g the PIDF fields as above, would this be acceptable=3F=0D=0A>=20=0D=0A> Th= ese change look promising to me.=0D=0A>=20=0D=0A>=20=0D=0A> > I could enume= rate the fields from RFC4776, or simply refer to=0D=0A> > this RFC.=0D=0A> = >=0D=0A>=20=0D=0A> You will have to add a reference to RFC 4776 anyway.=0D=0A= >=20=0D=0A>=20=0D=0A> > I had some feedback that the totality of PIDF field= s is too=0D=0A> > complex for=0D=0A> > the intended purpose of my draft (no= n-professional human=0D=0A> > authoring). But=0D=0A> > as I understand, the= fields are optional and not all fields=0D=0A> > have values=0D=0A> > in an= y case. I could mention country and A1 specifically and=0D=0A> > the others=0D= =0A> > by reference.=0D=0A>=20=0D=0A> Complexity for what exactly=3F=0D=0A>= =20=0D=0A> You might omit a few fields but you again have to be careful tha= t you=0D=0A> can still represent a location in, let's say, Japan.=0D=0A> =0D= =0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A>=20=0D=0A> ______________= _________________________________=0D=0A> Geopriv mailing list=0D=0A> Geopri= v@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Daryn_Phommachanh@abrasive.ru Thu Sep 27 05:59:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaq9P-0006Ts-8G for geopriv-archive@lists.ietf.org; Thu, 27 Sep 2007 05:59:19 -0400 Received: from host222-143-dynamic.13-79-r.retail.telecomitalia.it ([79.13.143.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaq9O-0002Rd-Lm for geopriv-archive@lists.ietf.org; Thu, 27 Sep 2007 05:59:19 -0400 Received: from oem ([155.121.2.164]:10392 "EHLO oem" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host222-143-dynamic.13-79-r.retail.telecomitalia.it with ESMTP id S22FTYPBTRVHKLNS (ORCPT ); Thu, 27 Sep 2007 11:59:23 +0200 Message-ID: <000901c800ed$0eab84f0$de8f0d4f@oem> From: "Daryn Phommachanh" To: Subject: antijaco Date: Thu, 27 Sep 2007 11:59:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C800FD.D23454F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000777-1, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C800FD.D23454F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://ckbooty.com/ Yo yo yo geopriv-archive ladies like em big, so i enlarged my cock just to please them.. Daryn Phommachanh ------=_NextPart_000_0007_01C800FD.D23454F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://ckbooty.com/
Yo yo yo geopriv-archive
ladies like em big, so i enlarged my cock just = to please them..
Daryn Phommachanh
------=_NextPart_000_0007_01C800FD.D23454F0-- From geopriv-bounces@ietf.org Thu Sep 27 07:40:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iarj8-0004Tl-MF; Thu, 27 Sep 2007 07:40:18 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Iarj6-0004Lu-IX for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 07:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iarj6-0004KU-7x for geopriv@ietf.org; Thu, 27 Sep 2007 07:40:16 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iarj0-0003Ch-TG for geopriv@ietf.org; Thu, 27 Sep 2007 07:40:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5B44F21477; Thu, 27 Sep 2007 13:40:05 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-45-46fb9695298d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4E70F21472; Thu, 27 Sep 2007 13:40:05 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:40:05 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:40:04 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 384D42336; Thu, 27 Sep 2007 13:34:56 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 00D2F4DC27; Thu, 27 Sep 2007 13:34:56 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A5C354DB52; Thu, 27 Sep 2007 13:34:55 +0300 (EEST) From: Salvatore Loreto To: rohan@ekabal.com Content-Type: text/plain Date: Thu, 27 Sep 2007 13:34:55 +0300 Message-Id: <1190889295.4448.68.camel@n85.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 27 Sep 2007 11:40:04.0842 (UTC) FILETIME=[25A4FCA0:01C800FB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: geopriv@ietf.org Subject: [Geopriv] loc-filters draft X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi, I have noted that the loc-filters draft it has been expired on September 5th. When a new version of the draft will be available? /sal _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From yuhang-Forden@bagno.no Thu Sep 27 11:51:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaveD-0004Kd-0W for geopriv-archive@lists.ietf.org; Thu, 27 Sep 2007 11:51:29 -0400 Received: from bzq-79-180-33-18.red.bezeqint.net ([79.180.33.18] helo=bzq-82-81-99-127.red.bezeqint.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iave7-0005lT-2l for geopriv-archive@lists.ietf.org; Thu, 27 Sep 2007 11:51:23 -0400 Received: from crow2004 ([170.163.16.127] helo=crow2004) by bzq-82-81-99-127.red.bezeqint.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1Bzerj-000TMK-fA for geopriv-archive@lists.ietf.org; Thu, 27 Sep 2007 17:49:37 +0200 Message-ID: Date: Thu, 27 Sep 2007 17:49:12 +0200 From: "yuhang Forden" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: geopriv-archive@lists.ietf.org Subject: entolism Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hello geopriv-archive Get your supply today before prices sky rocket yuhang Forden http://www.chbit.com/ From geopriv-bounces@ietf.org Thu Sep 27 11:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iavl7-00023f-Ac; Thu, 27 Sep 2007 11:58:37 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Iavl6-00023X-2G for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 11:58:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iavl5-0001zT-MD for geopriv@ietf.org; Thu, 27 Sep 2007 11:58:35 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iavl0-0005xV-Ve for geopriv@ietf.org; Thu, 27 Sep 2007 11:58:31 -0400 Received: from SusieandCarl (c-24-8-177-87.hsd1.co.comcast.net [24.8.177.87]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l8RFw09g011777 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Sep 2007 11:58:12 -0400 Message-ID: <02e301c8011f$352832e0$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Andrew Daviel" , References: Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO Date: Thu, 27 Sep 2007 09:56:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.91.2/4411/Wed Sep 26 17:43:35 2007 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Andrew - This is not entirely correct. Since KML version 2.0, addresses are able to be encoded in a KML document using the OASIS CIQ/xAL standard. Further, the Google geocoding response payload uses the same tags as defined in the OASIS CIQ/xAL standard and is therefore consistent with KML. So, Google has not invented a new set of tags or semantics for encoding address information and are instead relying on another international standard. Some other interesting tidbits. The latest version of CIQ/xAL that was recently posted for public comment has enhanced location elements. The new version will use geometry as specified in GeoRSS GML which by the way is totally consistent with the use of GML for expressing geodetics in the LO. Finally, KML 2.1 and KML 2.2 are now OGC Best Practices documents. Starting in October, the OGC membership will begin working on KML 2.2 to become an OGC international standard. Google is 100% in support of KML becoming an OGC standard. Which by reference means that this is a major endorsement of the OASIS CIQ/xAL approach to encoding addresses. Regards Carl ----- Original Message ----- From: "Andrew Daviel" To: Sent: Thursday, September 27, 2007 3:22 AM Subject: [Geopriv] FYI - Google geocoding vs PIDF-LO > > FYI (apologies if this has been already seen/discussed) : > > There are a few sites using Google's geocoding API to derive position > data, plus geocoding information. So it may become a de facto standard > simply because Google is popular and their API is freely available and > easy to use. > > As per http://www.google.com/apis/maps/documentation/reference.html, > http://www.developer.com/lang/jscript/article.php/3615681 > > Google PIDF-LO > ------ ------- > Thoroughfare A6,PRD,POD,STS,HNO > Locality A3 > SubAdministrativeArea A2 > AdministrativeArea A1 > PostalCode PC > CountryNameCode country > > I fed a few addresses in Canada, England, France, USA to see what it came > up with. Ironically, the US addresses I tried (presumably the first > country that Google put online) did not work. > > For UK and Canadian addresses, the postcodes were fractional, which might > be confusing if you tried to use it on a letter. E.g. "RH17 5" for > "RH17 5QQ" (UK), or "V6T" for "V6T 2A3" (CA). Unlike the US, postcodes > here are never split - at least not by ordinary people. > > In the UK, one would normally use a county as AdministrativeArea (e.g. > Devon, Cornwall, Middlesex), but Google uses "England". Which makes a > certain amount of sense - "Great Britain" (GB) as I recall is England, > Scotland + Wales while adding Northern Ireland makes it "United Kingdom" > (UK). It just seems odd at first glance. But then, the postal address of > my old home in Britain never did make much sense - the "town" was about > 5 miles away, while the mail was actually sorted in a different town about > 20 miles in the other direction (its initials forming the first > letters of the postcode, and the road name was usually left off the postal > address altogether, so that physically finding it from the address was > rather hard). > Google's SubAdministrativeArea sometimes matches counties in the UK, > sometimes not. In Vancouver it is "Greater Vancouver Regional District" - > not the answer you get if you ask someone where they live. They'd just say > "Vancouver", or maybe "Kerrisdale" if pressed (the "village" or district). > > Anyway, if I rid myself of the notion that geocoding ought to match postal > addresses or common usage, Google's matches fairly well to > the most significant PIDF-LO fields. > > > Google postal > 4004 Wesbrook Mall 4004 Wesbrook Mall > Vancouver Vancouver > GVRD BC > BC V6T 2A3 > V6T Canada > CA > > > Colwoon Ln Green Gables (not the actual name) > Bolney Bolney > West Sussex Haywards Heath > England Sussex > RH17 5 RH17 5QQ > GB Great Britain > > > > -- > Andrew Daviel, TRIUMF, Canada > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From McDougall@bizkits.de Thu Sep 27 12:08:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavuO-0005JE-EP for geopriv-archive@lists.ietf.org; Thu, 27 Sep 2007 12:08:12 -0400 Received: from host204-199-static.23-87-b.business.telecomitalia.it ([87.23.199.204]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IavuN-0006ET-Rz for geopriv-archive@lists.ietf.org; Thu, 27 Sep 2007 12:08:12 -0400 Received: by 10.112.164.31 with SMTP id kPuneJdiYoylw; Thu, 27 Sep 2007 18:22:12 +0200 (GMT) Received: by 192.168.183.148 with SMTP id nKIHnQUflUzyrc.5497847415333; Thu, 27 Sep 2007 18:22:10 +0200 (GMT) Message-ID: <000e01c80122$8c2af340$ccc71757@Mediapc2> From: "Inna McDougall" To: Subject: kenbrief Date: Thu, 27 Sep 2007 18:22:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C80133.4FB3C340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C80133.4FB3C340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://gofernor.com/ Yo yo yo geopriv-archive I have a successful career, great friends, and own my own home. My sex = life was the only area where I was lacking Inna McDougall ------=_NextPart_000_0009_01C80133.4FB3C340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://gofernor.com/
Yo yo yo geopriv-archive
I have a successful career, great friends, and = own my=20 own home. My sex life was the only area where I was lacking
Inna McDougall
------=_NextPart_000_0009_01C80133.4FB3C340-- From geopriv-bounces@ietf.org Thu Sep 27 12:11:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavxY-0002h0-IZ; Thu, 27 Sep 2007 12:11:28 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IavxW-0002fG-Uc for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 12:11:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavxV-0002ef-I0 for geopriv@ietf.org; Thu, 27 Sep 2007 12:11:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IavxN-000308-CD for geopriv@ietf.org; Thu, 27 Sep 2007 12:11:25 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Iavx4-0006ji-SP; Thu, 27 Sep 2007 11:10:59 -0500 From: "Brian Rosen" To: "'Carl Reed OGC Account'" , "'Andrew Daviel'" , References: <02e301c8011f$352832e0$6401a8c0@SusieandCarl> Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO Date: Thu, 27 Sep 2007 12:11:07 -0400 Message-ID: <04e701c80121$0526da40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <02e301c8011f$352832e0$6401a8c0@SusieandCarl> Thread-Index: AcgBH1YW0OwRWNPPTDCMM7eXaU9PFQAAZH4A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Is there a way to make KML and PIDF-LO say the same thing for all tags that intersect? Is there some reason we can't? Brian > -----Original Message----- > From: Carl Reed OGC Account [mailto:creed@opengeospatial.org] > Sent: Thursday, September 27, 2007 11:56 AM > To: Andrew Daviel; geopriv@ietf.org > Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO > > Andrew - > > This is not entirely correct. > > Since KML version 2.0, addresses are able to be encoded in a KML document > using the OASIS CIQ/xAL standard. > > Further, the Google geocoding response payload uses the same tags as > defined > in the OASIS CIQ/xAL standard and is therefore consistent with KML. > > So, Google has not invented a new set of tags or semantics for encoding > address information and are instead relying on another international > standard. > > Some other interesting tidbits. > > The latest version of CIQ/xAL that was recently posted for public comment > has enhanced location elements. The new version will use geometry as > specified in GeoRSS GML which by the way is totally consistent with the > use > of GML for expressing geodetics in the LO. > > Finally, KML 2.1 and KML 2.2 are now OGC Best Practices documents. > Starting > in October, the OGC membership will begin working on KML 2.2 to become an > OGC international standard. Google is 100% in support of KML becoming an > OGC > standard. Which by reference means that this is a major endorsement of the > OASIS CIQ/xAL approach to encoding addresses. > > Regards > > Carl > > > > ----- Original Message ----- > From: "Andrew Daviel" > To: > Sent: Thursday, September 27, 2007 3:22 AM > Subject: [Geopriv] FYI - Google geocoding vs PIDF-LO > > > > > > FYI (apologies if this has been already seen/discussed) : > > > > There are a few sites using Google's geocoding API to derive position > > data, plus geocoding information. So it may become a de facto standard > > simply because Google is popular and their API is freely available and > > easy to use. > > > > As per http://www.google.com/apis/maps/documentation/reference.html, > > http://www.developer.com/lang/jscript/article.php/3615681 > > > > Google PIDF-LO > > ------ ------- > > Thoroughfare A6,PRD,POD,STS,HNO > > Locality A3 > > SubAdministrativeArea A2 > > AdministrativeArea A1 > > PostalCode PC > > CountryNameCode country > > > > I fed a few addresses in Canada, England, France, USA to see what it > came > > up with. Ironically, the US addresses I tried (presumably the first > > country that Google put online) did not work. > > > > For UK and Canadian addresses, the postcodes were fractional, which > might > > be confusing if you tried to use it on a letter. E.g. "RH17 5" for > > "RH17 5QQ" (UK), or "V6T" for "V6T 2A3" (CA). Unlike the US, postcodes > > here are never split - at least not by ordinary people. > > > > In the UK, one would normally use a county as AdministrativeArea (e.g. > > Devon, Cornwall, Middlesex), but Google uses "England". Which makes a > > certain amount of sense - "Great Britain" (GB) as I recall is England, > > Scotland + Wales while adding Northern Ireland makes it "United Kingdom" > > (UK). It just seems odd at first glance. But then, the postal address of > > my old home in Britain never did make much sense - the "town" was about > > 5 miles away, while the mail was actually sorted in a different town > about > > 20 miles in the other direction (its initials forming the first > > letters of the postcode, and the road name was usually left off the > postal > > address altogether, so that physically finding it from the address was > > rather hard). > > Google's SubAdministrativeArea sometimes matches counties in the UK, > > sometimes not. In Vancouver it is "Greater Vancouver Regional District" > - > > not the answer you get if you ask someone where they live. They'd just > say > > "Vancouver", or maybe "Kerrisdale" if pressed (the "village" or > district). > > > > Anyway, if I rid myself of the notion that geocoding ought to match > postal > > addresses or common usage, Google's matches fairly well to > > the most significant PIDF-LO fields. > > > > > > Google postal > > 4004 Wesbrook Mall 4004 Wesbrook Mall > > Vancouver Vancouver > > GVRD BC > > BC V6T 2A3 > > V6T Canada > > CA > > > > > > Colwoon Ln Green Gables (not the actual name) > > Bolney Bolney > > West Sussex Haywards Heath > > England Sussex > > RH17 5 RH17 5QQ > > GB Great Britain > > > > > > > > -- > > Andrew Daviel, TRIUMF, Canada > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 14:44:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayLB-0003Pp-TM; Thu, 27 Sep 2007 14:44:01 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IayLA-0003Lx-Ri for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 14:44:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayLA-0003Hc-DM for geopriv@ietf.org; Thu, 27 Sep 2007 14:44:00 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IayL9-0002y2-Ia for geopriv@ietf.org; Thu, 27 Sep 2007 14:44:00 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IayKo-0003iH-Rp; Thu, 27 Sep 2007 13:43:39 -0500 From: "Brian Rosen" To: "'Brian Rosen'" , "'Carl Reed OGC Account'" , "'Andrew Daviel'" , References: <02e301c8011f$352832e0$6401a8c0@SusieandCarl> <04e701c80121$0526da40$640fa8c0@cis.neustar.com> Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO Date: Thu, 27 Sep 2007 14:43:48 -0400 Message-ID: <055601c80136$59d76810$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <04e701c80121$0526da40$640fa8c0@cis.neustar.com> Thread-Index: AcgBH1YW0OwRWNPPTDCMM7eXaU9PFQAAZH4AAAB4n+A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I'm going to answer my own question. The KML is derived from CIQ/AL, which uses RMCommonTypes, which comes from EDXL, which comes from OASIS UBL, a business language. I think it's inadequate to describe locations all over the world. The PIDF fields are much more appropriate for an international standard. Brian > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, September 27, 2007 12:11 PM > To: 'Carl Reed OGC Account'; 'Andrew Daviel'; geopriv@ietf.org > Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO > > Is there a way to make KML and PIDF-LO say the same thing for all tags > that > intersect? > > Is there some reason we can't? > > Brian > > > -----Original Message----- > > From: Carl Reed OGC Account [mailto:creed@opengeospatial.org] > > Sent: Thursday, September 27, 2007 11:56 AM > > To: Andrew Daviel; geopriv@ietf.org > > Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO > > > > Andrew - > > > > This is not entirely correct. > > > > Since KML version 2.0, addresses are able to be encoded in a KML > document > > using the OASIS CIQ/xAL standard. > > > > Further, the Google geocoding response payload uses the same tags as > > defined > > in the OASIS CIQ/xAL standard and is therefore consistent with KML. > > > > So, Google has not invented a new set of tags or semantics for encoding > > address information and are instead relying on another international > > standard. > > > > Some other interesting tidbits. > > > > The latest version of CIQ/xAL that was recently posted for public > comment > > has enhanced location elements. The new version will use geometry as > > specified in GeoRSS GML which by the way is totally consistent with the > > use > > of GML for expressing geodetics in the LO. > > > > Finally, KML 2.1 and KML 2.2 are now OGC Best Practices documents. > > Starting > > in October, the OGC membership will begin working on KML 2.2 to become > an > > OGC international standard. Google is 100% in support of KML becoming an > > OGC > > standard. Which by reference means that this is a major endorsement of > the > > OASIS CIQ/xAL approach to encoding addresses. > > > > Regards > > > > Carl > > > > > > > > ----- Original Message ----- > > From: "Andrew Daviel" > > To: > > Sent: Thursday, September 27, 2007 3:22 AM > > Subject: [Geopriv] FYI - Google geocoding vs PIDF-LO > > > > > > > > > > FYI (apologies if this has been already seen/discussed) : > > > > > > There are a few sites using Google's geocoding API to derive position > > > data, plus geocoding information. So it may become a de facto standard > > > simply because Google is popular and their API is freely available and > > > easy to use. > > > > > > As per http://www.google.com/apis/maps/documentation/reference.html, > > > http://www.developer.com/lang/jscript/article.php/3615681 > > > > > > Google PIDF-LO > > > ------ ------- > > > Thoroughfare A6,PRD,POD,STS,HNO > > > Locality A3 > > > SubAdministrativeArea A2 > > > AdministrativeArea A1 > > > PostalCode PC > > > CountryNameCode country > > > > > > I fed a few addresses in Canada, England, France, USA to see what it > > came > > > up with. Ironically, the US addresses I tried (presumably the first > > > country that Google put online) did not work. > > > > > > For UK and Canadian addresses, the postcodes were fractional, which > > might > > > be confusing if you tried to use it on a letter. E.g. "RH17 5" for > > > "RH17 5QQ" (UK), or "V6T" for "V6T 2A3" (CA). Unlike the US, > postcodes > > > here are never split - at least not by ordinary people. > > > > > > In the UK, one would normally use a county as AdministrativeArea (e.g. > > > Devon, Cornwall, Middlesex), but Google uses "England". Which makes a > > > certain amount of sense - "Great Britain" (GB) as I recall is England, > > > Scotland + Wales while adding Northern Ireland makes it "United > Kingdom" > > > (UK). It just seems odd at first glance. But then, the postal address > of > > > my old home in Britain never did make much sense - the "town" was > about > > > 5 miles away, while the mail was actually sorted in a different town > > about > > > 20 miles in the other direction (its initials forming the first > > > letters of the postcode, and the road name was usually left off the > > postal > > > address altogether, so that physically finding it from the address was > > > rather hard). > > > Google's SubAdministrativeArea sometimes matches counties in the UK, > > > sometimes not. In Vancouver it is "Greater Vancouver Regional > District" > > - > > > not the answer you get if you ask someone where they live. They'd just > > say > > > "Vancouver", or maybe "Kerrisdale" if pressed (the "village" or > > district). > > > > > > Anyway, if I rid myself of the notion that geocoding ought to match > > postal > > > addresses or common usage, Google's matches fairly well to > > > the most significant PIDF-LO fields. > > > > > > > > > Google postal > > > 4004 Wesbrook Mall 4004 Wesbrook Mall > > > Vancouver Vancouver > > > GVRD BC > > > BC V6T 2A3 > > > V6T Canada > > > CA > > > > > > > > > Colwoon Ln Green Gables (not the actual name) > > > Bolney Bolney > > > West Sussex Haywards Heath > > > England Sussex > > > RH17 5 RH17 5QQ > > > GB Great Britain > > > > > > > > > > > > -- > > > Andrew Daviel, TRIUMF, Canada > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 14:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayWr-00060v-RY; Thu, 27 Sep 2007 14:56:05 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IayWq-0005xW-Nr for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 14:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayWq-0005xO-EE for geopriv@ietf.org; Thu, 27 Sep 2007 14:56:04 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IayWh-0007oX-Lz for geopriv@ietf.org; Thu, 27 Sep 2007 14:56:04 -0400 Received: from SusieandCarl (c-24-8-177-87.hsd1.co.comcast.net [24.8.177.87]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l8RItVc4010942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Sep 2007 14:55:34 -0400 Message-ID: <00e101c80137$f8b9bbd0$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Brian Rosen" , "'Andrew Daviel'" , References: <02e301c8011f$352832e0$6401a8c0@SusieandCarl> <04e701c80121$0526da40$640fa8c0@cis.neustar.com> <055601c80136$59d76810$640fa8c0@cis.neustar.com> Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO Date: Thu, 27 Sep 2007 12:54:06 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.91.2/4414/Thu Sep 27 14:04:10 2007 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Brian - I have been involved in a variety of EDXL discussions in the OASIS EM TC. As far as I am aware, CIQ predates EDXL by a number of years. xAL also predates EDXL (which is very US centric). From what I know, xAL resulted from an analysis of many different addressing systems but I can check with the xAL editor. Regards Carl ----- Original Message ----- From: "Brian Rosen" To: "'Brian Rosen'" ; "'Carl Reed OGC Account'" ; "'Andrew Daviel'" ; Sent: Thursday, September 27, 2007 12:43 PM Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO > I'm going to answer my own question. The KML is derived from CIQ/AL, > which > uses RMCommonTypes, which comes from EDXL, which comes from OASIS UBL, a > business language. > > I think it's inadequate to describe locations all over the world. The > PIDF > fields are much more appropriate for an international standard. > > Brian > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, September 27, 2007 12:11 PM >> To: 'Carl Reed OGC Account'; 'Andrew Daviel'; geopriv@ietf.org >> Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO >> >> Is there a way to make KML and PIDF-LO say the same thing for all tags >> that >> intersect? >> >> Is there some reason we can't? >> >> Brian >> >> > -----Original Message----- >> > From: Carl Reed OGC Account [mailto:creed@opengeospatial.org] >> > Sent: Thursday, September 27, 2007 11:56 AM >> > To: Andrew Daviel; geopriv@ietf.org >> > Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO >> > >> > Andrew - >> > >> > This is not entirely correct. >> > >> > Since KML version 2.0, addresses are able to be encoded in a KML >> document >> > using the OASIS CIQ/xAL standard. >> > >> > Further, the Google geocoding response payload uses the same tags as >> > defined >> > in the OASIS CIQ/xAL standard and is therefore consistent with KML. >> > >> > So, Google has not invented a new set of tags or semantics for encoding >> > address information and are instead relying on another international >> > standard. >> > >> > Some other interesting tidbits. >> > >> > The latest version of CIQ/xAL that was recently posted for public >> comment >> > has enhanced location elements. The new version will use geometry as >> > specified in GeoRSS GML which by the way is totally consistent with the >> > use >> > of GML for expressing geodetics in the LO. >> > >> > Finally, KML 2.1 and KML 2.2 are now OGC Best Practices documents. >> > Starting >> > in October, the OGC membership will begin working on KML 2.2 to become >> an >> > OGC international standard. Google is 100% in support of KML becoming >> > an >> > OGC >> > standard. Which by reference means that this is a major endorsement of >> the >> > OASIS CIQ/xAL approach to encoding addresses. >> > >> > Regards >> > >> > Carl >> > >> > >> > >> > ----- Original Message ----- >> > From: "Andrew Daviel" >> > To: >> > Sent: Thursday, September 27, 2007 3:22 AM >> > Subject: [Geopriv] FYI - Google geocoding vs PIDF-LO >> > >> > >> > > >> > > FYI (apologies if this has been already seen/discussed) : >> > > >> > > There are a few sites using Google's geocoding API to derive position >> > > data, plus geocoding information. So it may become a de facto >> > > standard >> > > simply because Google is popular and their API is freely available >> > > and >> > > easy to use. >> > > >> > > As per http://www.google.com/apis/maps/documentation/reference.html, >> > > http://www.developer.com/lang/jscript/article.php/3615681 >> > > >> > > Google PIDF-LO >> > > ------ ------- >> > > Thoroughfare A6,PRD,POD,STS,HNO >> > > Locality A3 >> > > SubAdministrativeArea A2 >> > > AdministrativeArea A1 >> > > PostalCode PC >> > > CountryNameCode country >> > > >> > > I fed a few addresses in Canada, England, France, USA to see what it >> > came >> > > up with. Ironically, the US addresses I tried (presumably the first >> > > country that Google put online) did not work. >> > > >> > > For UK and Canadian addresses, the postcodes were fractional, which >> > might >> > > be confusing if you tried to use it on a letter. E.g. "RH17 5" for >> > > "RH17 5QQ" (UK), or "V6T" for "V6T 2A3" (CA). Unlike the US, >> postcodes >> > > here are never split - at least not by ordinary people. >> > > >> > > In the UK, one would normally use a county as AdministrativeArea >> > > (e.g. >> > > Devon, Cornwall, Middlesex), but Google uses "England". Which makes a >> > > certain amount of sense - "Great Britain" (GB) as I recall is >> > > England, >> > > Scotland + Wales while adding Northern Ireland makes it "United >> Kingdom" >> > > (UK). It just seems odd at first glance. But then, the postal address >> of >> > > my old home in Britain never did make much sense - the "town" was >> about >> > > 5 miles away, while the mail was actually sorted in a different town >> > about >> > > 20 miles in the other direction (its initials forming the first >> > > letters of the postcode, and the road name was usually left off the >> > postal >> > > address altogether, so that physically finding it from the address >> > > was >> > > rather hard). >> > > Google's SubAdministrativeArea sometimes matches counties in the UK, >> > > sometimes not. In Vancouver it is "Greater Vancouver Regional >> District" >> > - >> > > not the answer you get if you ask someone where they live. They'd >> > > just >> > say >> > > "Vancouver", or maybe "Kerrisdale" if pressed (the "village" or >> > district). >> > > >> > > Anyway, if I rid myself of the notion that geocoding ought to match >> > postal >> > > addresses or common usage, Google's matches fairly well to >> > > the most significant PIDF-LO fields. >> > > >> > > >> > > Google postal >> > > 4004 Wesbrook Mall 4004 Wesbrook Mall >> > > Vancouver Vancouver >> > > GVRD BC >> > > BC V6T 2A3 >> > > V6T Canada >> > > CA >> > > >> > > >> > > Colwoon Ln Green Gables (not the actual name) >> > > Bolney Bolney >> > > West Sussex Haywards Heath >> > > England Sussex >> > > RH17 5 RH17 5QQ >> > > GB Great Britain >> > > >> > > >> > > >> > > -- >> > > Andrew Daviel, TRIUMF, Canada >> > > >> > > >> > > _______________________________________________ >> > > Geopriv mailing list >> > > Geopriv@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/geopriv >> > >> > >> > >> > _______________________________________________ >> > Geopriv mailing list >> > Geopriv@ietf.org >> > https://www1.ietf.org/mailman/listinfo/geopriv >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 16:57:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0QV-000593-1l; Thu, 27 Sep 2007 16:57:39 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ib0QT-00058P-5b for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 16:57:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0QS-00057R-Q3 for geopriv@ietf.org; Thu, 27 Sep 2007 16:57:36 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib0QO-0006dS-SD for geopriv@ietf.org; Thu, 27 Sep 2007 16:57:33 -0400 Received: from SusieandCarl (c-24-8-177-87.hsd1.co.comcast.net [24.8.177.87]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l8RKujB2018943 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Sep 2007 16:56:51 -0400 Message-ID: <038c01c80148$efd62100$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Brian Rosen" , "'Andrew Daviel'" , References: <02e301c8011f$352832e0$6401a8c0@SusieandCarl> <04e701c80121$0526da40$640fa8c0@cis.neustar.com> <055601c80136$59d76810$640fa8c0@cis.neustar.com> Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO Date: Thu, 27 Sep 2007 14:56:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.91.2/4415/Thu Sep 27 16:02:21 2007 on mail.opengeospatial.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Brian - Further clarification on the background of CIQ/xAL. This from the CIQ TC Chair: CIQ was started in 1999-2000 when there were no XML specifications for Party name and address. UBL was started in 2002-2003 and their address semantics which they started by using the work of CIQ on addresses. CIQ comes from the original work done by Mastersoft in 1998-1999 called Name and Address Markup Language and by AND International in 1998-99 called Global Address Specifications in XML. So, CIQ has a long history years before EDXL came on board . Regards Carl ----- Original Message ----- From: "Brian Rosen" To: "'Brian Rosen'" ; "'Carl Reed OGC Account'" ; "'Andrew Daviel'" ; Sent: Thursday, September 27, 2007 12:43 PM Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO > I'm going to answer my own question. The KML is derived from CIQ/AL, > which > uses RMCommonTypes, which comes from EDXL, which comes from OASIS UBL, a > business language. > > I think it's inadequate to describe locations all over the world. The > PIDF > fields are much more appropriate for an international standard. > > Brian > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Thursday, September 27, 2007 12:11 PM >> To: 'Carl Reed OGC Account'; 'Andrew Daviel'; geopriv@ietf.org >> Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO >> >> Is there a way to make KML and PIDF-LO say the same thing for all tags >> that >> intersect? >> >> Is there some reason we can't? >> >> Brian >> >> > -----Original Message----- >> > From: Carl Reed OGC Account [mailto:creed@opengeospatial.org] >> > Sent: Thursday, September 27, 2007 11:56 AM >> > To: Andrew Daviel; geopriv@ietf.org >> > Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO >> > >> > Andrew - >> > >> > This is not entirely correct. >> > >> > Since KML version 2.0, addresses are able to be encoded in a KML >> document >> > using the OASIS CIQ/xAL standard. >> > >> > Further, the Google geocoding response payload uses the same tags as >> > defined >> > in the OASIS CIQ/xAL standard and is therefore consistent with KML. >> > >> > So, Google has not invented a new set of tags or semantics for encoding >> > address information and are instead relying on another international >> > standard. >> > >> > Some other interesting tidbits. >> > >> > The latest version of CIQ/xAL that was recently posted for public >> comment >> > has enhanced location elements. The new version will use geometry as >> > specified in GeoRSS GML which by the way is totally consistent with the >> > use >> > of GML for expressing geodetics in the LO. >> > >> > Finally, KML 2.1 and KML 2.2 are now OGC Best Practices documents. >> > Starting >> > in October, the OGC membership will begin working on KML 2.2 to become >> an >> > OGC international standard. Google is 100% in support of KML becoming >> > an >> > OGC >> > standard. Which by reference means that this is a major endorsement of >> the >> > OASIS CIQ/xAL approach to encoding addresses. >> > >> > Regards >> > >> > Carl >> > >> > >> > >> > ----- Original Message ----- >> > From: "Andrew Daviel" >> > To: >> > Sent: Thursday, September 27, 2007 3:22 AM >> > Subject: [Geopriv] FYI - Google geocoding vs PIDF-LO >> > >> > >> > > >> > > FYI (apologies if this has been already seen/discussed) : >> > > >> > > There are a few sites using Google's geocoding API to derive position >> > > data, plus geocoding information. So it may become a de facto >> > > standard >> > > simply because Google is popular and their API is freely available >> > > and >> > > easy to use. >> > > >> > > As per http://www.google.com/apis/maps/documentation/reference.html, >> > > http://www.developer.com/lang/jscript/article.php/3615681 >> > > >> > > Google PIDF-LO >> > > ------ ------- >> > > Thoroughfare A6,PRD,POD,STS,HNO >> > > Locality A3 >> > > SubAdministrativeArea A2 >> > > AdministrativeArea A1 >> > > PostalCode PC >> > > CountryNameCode country >> > > >> > > I fed a few addresses in Canada, England, France, USA to see what it >> > came >> > > up with. Ironically, the US addresses I tried (presumably the first >> > > country that Google put online) did not work. >> > > >> > > For UK and Canadian addresses, the postcodes were fractional, which >> > might >> > > be confusing if you tried to use it on a letter. E.g. "RH17 5" for >> > > "RH17 5QQ" (UK), or "V6T" for "V6T 2A3" (CA). Unlike the US, >> postcodes >> > > here are never split - at least not by ordinary people. >> > > >> > > In the UK, one would normally use a county as AdministrativeArea >> > > (e.g. >> > > Devon, Cornwall, Middlesex), but Google uses "England". Which makes a >> > > certain amount of sense - "Great Britain" (GB) as I recall is >> > > England, >> > > Scotland + Wales while adding Northern Ireland makes it "United >> Kingdom" >> > > (UK). It just seems odd at first glance. But then, the postal address >> of >> > > my old home in Britain never did make much sense - the "town" was >> about >> > > 5 miles away, while the mail was actually sorted in a different town >> > about >> > > 20 miles in the other direction (its initials forming the first >> > > letters of the postcode, and the road name was usually left off the >> > postal >> > > address altogether, so that physically finding it from the address >> > > was >> > > rather hard). >> > > Google's SubAdministrativeArea sometimes matches counties in the UK, >> > > sometimes not. In Vancouver it is "Greater Vancouver Regional >> District" >> > - >> > > not the answer you get if you ask someone where they live. They'd >> > > just >> > say >> > > "Vancouver", or maybe "Kerrisdale" if pressed (the "village" or >> > district). >> > > >> > > Anyway, if I rid myself of the notion that geocoding ought to match >> > postal >> > > addresses or common usage, Google's matches fairly well to >> > > the most significant PIDF-LO fields. >> > > >> > > >> > > Google postal >> > > 4004 Wesbrook Mall 4004 Wesbrook Mall >> > > Vancouver Vancouver >> > > GVRD BC >> > > BC V6T 2A3 >> > > V6T Canada >> > > CA >> > > >> > > >> > > Colwoon Ln Green Gables (not the actual name) >> > > Bolney Bolney >> > > West Sussex Haywards Heath >> > > England Sussex >> > > RH17 5 RH17 5QQ >> > > GB Great Britain >> > > >> > > >> > > >> > > -- >> > > Andrew Daviel, TRIUMF, Canada >> > > >> > > >> > > _______________________________________________ >> > > Geopriv mailing list >> > > Geopriv@ietf.org >> > > https://www1.ietf.org/mailman/listinfo/geopriv >> > >> > >> > >> > _______________________________________________ >> > Geopriv mailing list >> > Geopriv@ietf.org >> > https://www1.ietf.org/mailman/listinfo/geopriv >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 17:34:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib10T-0004AL-F5; Thu, 27 Sep 2007 17:34:49 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ib10S-00043E-9j for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 17:34:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib10R-0003yz-UK for geopriv@ietf.org; Thu, 27 Sep 2007 17:34:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib10L-0007Xo-V1 for geopriv@ietf.org; Thu, 27 Sep 2007 17:34:42 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ib0zy-0006MD-Bf; Thu, 27 Sep 2007 16:34:18 -0500 From: "Brian Rosen" To: "'Carl Reed OGC Account'" , "'Andrew Daviel'" , References: <02e301c8011f$352832e0$6401a8c0@SusieandCarl> <04e701c80121$0526da40$640fa8c0@cis.neustar.com> <055601c80136$59d76810$640fa8c0@cis.neustar.com> <038c01c80148$efd62100$6401a8c0@SusieandCarl> Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO Date: Thu, 27 Sep 2007 17:34:31 -0400 Message-ID: <059201c8014e$3224d290$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <038c01c80148$efd62100$6401a8c0@SusieandCarl> Thread-Index: AcgBSPdmzdGBGsKGRT2Dk4uT+Xkq6wABNF2g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I stand corrected. However, the inability of the system to express, for example, Chinese and Japanese addresses, is a problem. You need more "A" levels, and as we have found, you can't give them restrictive names, because the form of address really does vary quite a bit in the space between state/province and street name. Brian > -----Original Message----- > From: Carl Reed OGC Account [mailto:creed@opengeospatial.org] > Sent: Thursday, September 27, 2007 4:56 PM > To: Brian Rosen; 'Andrew Daviel'; geopriv@ietf.org > Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO > > Brian - > > Further clarification on the background of CIQ/xAL. This from the CIQ TC > Chair: > > CIQ was started in 1999-2000 when there were no XML specifications for > Party > name and address. UBL was started in 2002-2003 and their address semantics > which they started by using the work of CIQ on addresses. CIQ comes from > the original work done by Mastersoft in 1998-1999 called Name and Address > Markup Language and by AND International in 1998-99 called Global Address > Specifications in XML. So, CIQ has a long history years before EDXL came > on > board . > > Regards > > Carl > > ----- Original Message ----- > From: "Brian Rosen" > To: "'Brian Rosen'" ; "'Carl Reed OGC Account'" > ; "'Andrew Daviel'" ; > > Sent: Thursday, September 27, 2007 12:43 PM > Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO > > > > I'm going to answer my own question. The KML is derived from CIQ/AL, > > which > > uses RMCommonTypes, which comes from EDXL, which comes from OASIS UBL, a > > business language. > > > > I think it's inadequate to describe locations all over the world. The > > PIDF > > fields are much more appropriate for an international standard. > > > > Brian > > > > > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net] > >> Sent: Thursday, September 27, 2007 12:11 PM > >> To: 'Carl Reed OGC Account'; 'Andrew Daviel'; geopriv@ietf.org > >> Subject: RE: [Geopriv] FYI - Google geocoding vs PIDF-LO > >> > >> Is there a way to make KML and PIDF-LO say the same thing for all tags > >> that > >> intersect? > >> > >> Is there some reason we can't? > >> > >> Brian > >> > >> > -----Original Message----- > >> > From: Carl Reed OGC Account [mailto:creed@opengeospatial.org] > >> > Sent: Thursday, September 27, 2007 11:56 AM > >> > To: Andrew Daviel; geopriv@ietf.org > >> > Subject: Re: [Geopriv] FYI - Google geocoding vs PIDF-LO > >> > > >> > Andrew - > >> > > >> > This is not entirely correct. > >> > > >> > Since KML version 2.0, addresses are able to be encoded in a KML > >> document > >> > using the OASIS CIQ/xAL standard. > >> > > >> > Further, the Google geocoding response payload uses the same tags as > >> > defined > >> > in the OASIS CIQ/xAL standard and is therefore consistent with KML. > >> > > >> > So, Google has not invented a new set of tags or semantics for > encoding > >> > address information and are instead relying on another international > >> > standard. > >> > > >> > Some other interesting tidbits. > >> > > >> > The latest version of CIQ/xAL that was recently posted for public > >> comment > >> > has enhanced location elements. The new version will use geometry as > >> > specified in GeoRSS GML which by the way is totally consistent with > the > >> > use > >> > of GML for expressing geodetics in the LO. > >> > > >> > Finally, KML 2.1 and KML 2.2 are now OGC Best Practices documents. > >> > Starting > >> > in October, the OGC membership will begin working on KML 2.2 to > become > >> an > >> > OGC international standard. Google is 100% in support of KML becoming > >> > an > >> > OGC > >> > standard. Which by reference means that this is a major endorsement > of > >> the > >> > OASIS CIQ/xAL approach to encoding addresses. > >> > > >> > Regards > >> > > >> > Carl > >> > > >> > > >> > > >> > ----- Original Message ----- > >> > From: "Andrew Daviel" > >> > To: > >> > Sent: Thursday, September 27, 2007 3:22 AM > >> > Subject: [Geopriv] FYI - Google geocoding vs PIDF-LO > >> > > >> > > >> > > > >> > > FYI (apologies if this has been already seen/discussed) : > >> > > > >> > > There are a few sites using Google's geocoding API to derive > position > >> > > data, plus geocoding information. So it may become a de facto > >> > > standard > >> > > simply because Google is popular and their API is freely available > >> > > and > >> > > easy to use. > >> > > > >> > > As per > http://www.google.com/apis/maps/documentation/reference.html, > >> > > http://www.developer.com/lang/jscript/article.php/3615681 > >> > > > >> > > Google PIDF-LO > >> > > ------ ------- > >> > > Thoroughfare A6,PRD,POD,STS,HNO > >> > > Locality A3 > >> > > SubAdministrativeArea A2 > >> > > AdministrativeArea A1 > >> > > PostalCode PC > >> > > CountryNameCode country > >> > > > >> > > I fed a few addresses in Canada, England, France, USA to see what > it > >> > came > >> > > up with. Ironically, the US addresses I tried (presumably the first > >> > > country that Google put online) did not work. > >> > > > >> > > For UK and Canadian addresses, the postcodes were fractional, which > >> > might > >> > > be confusing if you tried to use it on a letter. E.g. "RH17 5" for > >> > > "RH17 5QQ" (UK), or "V6T" for "V6T 2A3" (CA). Unlike the US, > >> postcodes > >> > > here are never split - at least not by ordinary people. > >> > > > >> > > In the UK, one would normally use a county as AdministrativeArea > >> > > (e.g. > >> > > Devon, Cornwall, Middlesex), but Google uses "England". Which makes > a > >> > > certain amount of sense - "Great Britain" (GB) as I recall is > >> > > England, > >> > > Scotland + Wales while adding Northern Ireland makes it "United > >> Kingdom" > >> > > (UK). It just seems odd at first glance. But then, the postal > address > >> of > >> > > my old home in Britain never did make much sense - the "town" was > >> about > >> > > 5 miles away, while the mail was actually sorted in a different > town > >> > about > >> > > 20 miles in the other direction (its initials forming the first > >> > > letters of the postcode, and the road name was usually left off the > >> > postal > >> > > address altogether, so that physically finding it from the address > >> > > was > >> > > rather hard). > >> > > Google's SubAdministrativeArea sometimes matches counties in the > UK, > >> > > sometimes not. In Vancouver it is "Greater Vancouver Regional > >> District" > >> > - > >> > > not the answer you get if you ask someone where they live. They'd > >> > > just > >> > say > >> > > "Vancouver", or maybe "Kerrisdale" if pressed (the "village" or > >> > district). > >> > > > >> > > Anyway, if I rid myself of the notion that geocoding ought to match > >> > postal > >> > > addresses or common usage, Google's matches fairly well to > >> > > the most significant PIDF-LO fields. > >> > > > >> > > > >> > > Google postal > >> > > 4004 Wesbrook Mall 4004 Wesbrook Mall > >> > > Vancouver Vancouver > >> > > GVRD BC > >> > > BC V6T 2A3 > >> > > V6T Canada > >> > > CA > >> > > > >> > > > >> > > Colwoon Ln Green Gables (not the actual name) > >> > > Bolney Bolney > >> > > West Sussex Haywards Heath > >> > > England Sussex > >> > > RH17 5 RH17 5QQ > >> > > GB Great Britain > >> > > > >> > > > >> > > > >> > > -- > >> > > Andrew Daviel, TRIUMF, Canada > >> > > > >> > > > >> > > _______________________________________________ > >> > > Geopriv mailing list > >> > > Geopriv@ietf.org > >> > > https://www1.ietf.org/mailman/listinfo/geopriv > >> > > >> > > >> > > >> > _______________________________________________ > >> > Geopriv mailing list > >> > Geopriv@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/geopriv > >> > >> > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 19:20:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib2eY-0000Vc-LE; Thu, 27 Sep 2007 19:20:18 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ib2eY-0000VV-5K for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 19:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib2eX-0000VM-Ro for geopriv@ietf.org; Thu, 27 Sep 2007 19:20:17 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib2eW-0005IX-F5 for geopriv@ietf.org; Thu, 27 Sep 2007 19:20:17 -0400 Received: from [192.168.2.235] (pool-71-164-172-176.dllstx.fios.verizon.net [71.164.172.176]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l8RNJto3074701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 27 Sep 2007 18:20:00 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: GEOPRIV From: Robert Sparks Date: Thu, 27 Sep 2007 18:19:50 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Geopriv] Updating the GEOPRIV milestones X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Folks - GEOPRIVs chartered milestone list needs to be updated to reflect what we as a group believe we can achieve. That's going to involve resetting or replacing all the milestones that are not marked "Done" on the current charter page. Here's my proposal for the set of goals we set for ourselves initially, and the list of those I know about that might be good goals to add as these complete. The dates and hence order here are only strawmen. Oct 2007 Submit Additional Civic PIDF-LO types (updating 4119) to the IESG for publication as PS (see postscript below) Oct 2007 Resubmit Conveying Location Objects in RADIUS and Diameter to the IESG for publication as PS Nov 2007 Resubmit Geolocation Policy to the IESG for publication as PS Dec 2007 Submit Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as Informational Dec 2007 Submit Requirements for Location by Reference Protocols to the IESG for publication as Informational Jan 2007 Submit PIDF-LO Usage Clarifications and Recommendations (updating 4119) to the IESG for publication as PS Feb 2007 Submit minimal HTTP based protocol satisfying baseline requirements specified in the Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as PS Once we start knocking those down, we could shift our focus to address (in no particular order) * Location by Reference dereferencing mechanisms * Carrying Location by Reference in DHCP * Extending the HTTP location conveyance protocol * Finishing the binary-lci/3825bis discussions (does this need to be earlier?) * LIS Discovery * Location Signing * Finishing the Location Filters work So, please respond on-list answering these questions: 1) What did I miss? 2) What should those milestone dates really be? 3) Is there anything here we should agree NOT to do? Thanks, RjS _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Thu Sep 27 19:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib2nM-0004nM-Eg; Thu, 27 Sep 2007 19:29:24 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ib2nL-0004lb-DZ for geopriv-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 19:29:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib2nL-0004lN-45 for geopriv@ietf.org; Thu, 27 Sep 2007 19:29:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib2nE-0005U8-VQ for geopriv@ietf.org; Thu, 27 Sep 2007 19:29:23 -0400 X-SEF-Processed: 5_0_0_910__2007_09_27_18_38_42 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 27 Sep 2007 18:38:42 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 18:29:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Updating the GEOPRIV milestones Date: Thu, 27 Sep 2007 18:28:59 -0500 Message-ID: In-Reply-To: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Updating the GEOPRIV milestones Thread-Index: AcgBXX6BYz3bt8YySUyc6u596zpSLAAAEEog References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> From: "Winterbottom, James" To: "Robert Sparks" , "GEOPRIV" X-OriginalArrivalTime: 27 Sep 2007 23:29:01.0417 (UTC) FILETIME=[2F6B3D90:01C8015E] X-Spam-Score: 1.8 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Robert,=0D=0A=0D=0AI think that we need to have LIS Discovery and HELD a= t about the same=0D=0Atime.=0D=0A=0D=0AWe also have:=0D=0A=0D=0AHTTP/HELD d= ereference protocol and LIS to LIS requirements, or do you=0D=0Asee these a= s HELD extensions=3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0APS LCP is loca= tion configuration protocol.. ;)=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Robert Sparks [mailto:rjsparks@estacado.net]=0D=0A> Sent: Friday= , 28 September 2007 9:20 AM=0D=0A> To: GEOPRIV=0D=0A> Subject: [Geopriv] Up= dating the GEOPRIV milestones=0D=0A>=20=0D=0A> Folks -=0D=0A>=20=0D=0A> GEO= PRIVs chartered milestone list needs to be updated to reflect what=0D=0A> w= e as a group believe we can achieve.=0D=0A> That's going to involve resetti= ng or replacing all the milestones=0D=0A> that are not marked "Done" on the= current charter page.=0D=0A>=20=0D=0A> Here's my proposal for the set of g= oals we set for ourselves=0D=0A> initially, and the list of those I know ab= out that might be good=0D=0A> goals to add as these complete. The dates and= hence order here are=0D=0A> only strawmen.=0D=0A>=20=0D=0A> Oct 2007=09Sub= mit Additional Civic PIDF-LO types (updating 4119) to=0D=0Athe=0D=0A> IESG = for publication as PS (see postscript below)=0D=0A> Oct 2007=09Resubmit Con= veying Location Objects in RADIUS and=0D=0ADiameter=0D=0A> to the IESG for = publication as PS=0D=0A> Nov 2007=09Resubmit Geolocation Policy to the IESG= for publication=0D=0Aas PS=0D=0A> Dec 2007=09Submit Layer 7 Location Conve= yance Protocol Problem=0D=0A> Statement and Requirements to the IESG for pu= blication as=0D=0AInformational=0D=0A> Dec 2007=09Submit Requirements for L= ocation by Reference Protocols=0D=0Ato=0D=0A> the IESG for publication as I= nformational=0D=0A> Jan 2007=09Submit PIDF-LO Usage Clarifications and Reco= mmendations=0D=0A> (updating 4119) to the IESG for publication as PS=0D=0A>= Feb 2007=09Submit minimal HTTP based protocol satisfying baseline=0D=0A> r= equirements specified in the Layer 7 Location Conveyance Protocol=0D=0A> Pr= oblem Statement and Requirements to the IESG for publication as PS=0D=0A> =0D= =0A> Once we start knocking those down, we could shift our focus to=0D=0A> = address (in no particular order)=0D=0A> * Location by Reference dereferenci= ng mechanisms=0D=0A> * Carrying Location by Reference in DHCP=0D=0A> * Exte= nding the HTTP location conveyance protocol=0D=0A> * Finishing the binary-l= ci/3825bis discussions (does this need to be=0D=0A> earlier=3F)=0D=0A> * LI= S Discovery=0D=0A> * Location Signing=0D=0A> * Finishing the Location Filte= rs work=0D=0A>=20=0D=0A> So, please respond on-list answering these questio= ns:=0D=0A>=20=0D=0A> 1) What did I miss=3F=0D=0A>=20=0D=0A> 2) What should = those milestone dates really be=3F=0D=0A>=20=0D=0A> 3) Is there anything he= re we should agree NOT to do=3F=0D=0A>=20=0D=0A> Thanks,=0D=0A>=20=0D=0A> R= jS=0D=0A>=20=0D=0A>=20=0D=0A> _____________________________________________= __=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.= ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A------------------------------= ------------------------------------------------------------------=0D=0AThi= s message is for the designated recipient only and may=0D=0Acontain privile= ged, proprietary, or otherwise private information. =20=0D=0AIf you have re= ceived it in error, please notify the sender=0D=0Aimmediately and delete th= e original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--= ---------------------------------------------------------------------------= -------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 03:26:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbAF4-0001qU-C1; Fri, 28 Sep 2007 03:26:30 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbAF2-0001q6-Vl for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 03:26:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbAF2-0001p6-L5 for geopriv@ietf.org; Fri, 28 Sep 2007 03:26:28 -0400 Received: from andrew.triumf.ca ([142.90.106.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbAF2-0005Am-7y for geopriv@ietf.org; Fri, 28 Sep 2007 03:26:28 -0400 Received: from localhost (localhost [127.0.0.1]) by andrew.triumf.ca (8.12.11.20060308/8.12.8) with ESMTP id l8S7QRC2016256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 00:26:27 -0700 Date: Fri, 28 Sep 2007 00:26:27 -0700 (PDT) From: Andrew Daviel X-X-Sender: andrew@andrew.triumf.ca To: "Tschofenig, Hannes (NSN - DE/Munich)" Subject: Re: AW: [Geopriv] Draft Updates "GEO TAGS for HTML" In-Reply-To: <5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> Message-ID: References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu><4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu><66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu> <5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Thu, 27 Sep 2007, Tschofenig, Hannes (NSN - DE/Munich) wrote: >> I had some feedback that the totality of PIDF fields is too >> complex ... > Complexity for what exactly? "ordinary mortals to comprehend", basically. I had originally intended just a single "region" field as a check against lat/long quadrant goofups, but with the online tools like Google maps that is not so much of an issue now. For the kind of use I envisage, it has to at least appear simple or people won't use it. Witness the penetration of Dublin Core metadata vs. "keywords". However, if most fields are optional, an application may use only a preferred few. So I guess it's not really an issue. James Winterbottom writes: > Or reference the revised civic specification. That would be draft-ietf-geopriv-revised-civic-lo-05.txt ? If I understand right, you aren't supposed to refer to IDs as normative. Unless they go to RFC in tandem. But in principle, yes. Or RFC4119 and revise it later. -- Andrew Daviel, TRIUMF, Canada _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 03:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbAU1-0005X4-3V; Fri, 28 Sep 2007 03:41:57 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbATz-0005Wp-Tr for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 03:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbATz-0005Tq-KK for geopriv@ietf.org; Fri, 28 Sep 2007 03:41:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbATp-00088g-PM for geopriv@ietf.org; Fri, 28 Sep 2007 03:41:52 -0400 Received: (qmail 2471 invoked by uid 0); 28 Sep 2007 07:41:24 -0000 Received: from 195.3.113.73 by www159.gmx.net with HTTP; Fri, 28 Sep 2007 09:41:24 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Sep 2007 09:41:24 +0200 From: "Hannes Tschofenig" In-Reply-To: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> Message-ID: <20070928074124.69330@gmx.net> MIME-Version: 1.0 References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> Subject: Re: [Geopriv] Updating the GEOPRIV milestones To: Robert Sparks , geopriv@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+b9qhxUyGbau49R6ilBXOsxkbThO9ylXiwQgdzVu GIEu8v/mVN2pX5bV6lt3kcU24v1DOHEw6Acw== Content-Transfer-Encoding: 7bit X-GMX-UID: EoXOfiIoPjl+HMZX9DQ2Ubk7MTE2Nckw X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Robert, I am fine with the proposed milestones (even though you drop some of the current items from the charter). Only a few minor comments: * Revised Civic: I thought that this document was sent the IESG a long time ago. In fact the tracker indicates that this document is already in IESG processing. * LIS discovery: We cannot delay this item; This is extremely important for the document and should be sent to the IESG at the same time as the base HELD specification is sent to the IESG. * draft-ietf-geopriv-loc-filters: I thought that this document reached a status in the working group so that it could be sent to the IESG immediately. The list of items that can be done once the listed items are finished can obviously be extended. But that's probably not that important right now. I believe the listed milestones are realistic. Ciao Hannes -------- Original-Nachricht -------- > Datum: Thu, 27 Sep 2007 18:19:50 -0500 > Von: Robert Sparks > An: GEOPRIV > Betreff: [Geopriv] Updating the GEOPRIV milestones > Folks - > > GEOPRIVs chartered milestone list needs to be updated to reflect what > we as a group believe we can achieve. > That's going to involve resetting or replacing all the milestones > that are not marked "Done" on the current charter page. > > Here's my proposal for the set of goals we set for ourselves > initially, and the list of those I know about that might be good > goals to add as these complete. The dates and hence order here are > only strawmen. > > Oct 2007 Submit Additional Civic PIDF-LO types (updating 4119) to the > IESG for publication as PS (see postscript below) > Oct 2007 Resubmit Conveying Location Objects in RADIUS and Diameter > to the IESG for publication as PS > Nov 2007 Resubmit Geolocation Policy to the IESG for publication as PS > Dec 2007 Submit Layer 7 Location Conveyance Protocol Problem > Statement and Requirements to the IESG for publication as Informational > Dec 2007 Submit Requirements for Location by Reference Protocols to > the IESG for publication as Informational > Jan 2007 Submit PIDF-LO Usage Clarifications and Recommendations > (updating 4119) to the IESG for publication as PS > Feb 2007 Submit minimal HTTP based protocol satisfying baseline > requirements specified in the Layer 7 Location Conveyance Protocol > Problem Statement and Requirements to the IESG for publication as PS > > Once we start knocking those down, we could shift our focus to > address (in no particular order) > * Location by Reference dereferencing mechanisms > * Carrying Location by Reference in DHCP > * Extending the HTTP location conveyance protocol > * Finishing the binary-lci/3825bis discussions (does this need to be > earlier?) > * LIS Discovery > * Location Signing > * Finishing the Location Filters work > > So, please respond on-list answering these questions: > > 1) What did I miss? > > 2) What should those milestone dates really be? > > 3) Is there anything here we should agree NOT to do? > > Thanks, > > RjS > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 03:43:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbAVJ-0004lE-Ax; Fri, 28 Sep 2007 03:43:17 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbAVH-0004eV-3x for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 03:43:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbAVG-0004e3-Ku for geopriv@ietf.org; Fri, 28 Sep 2007 03:43:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbAVF-0005kp-VY for geopriv@ietf.org; Fri, 28 Sep 2007 03:43:14 -0400 Received: (qmail 15157 invoked by uid 0); 28 Sep 2007 07:43:13 -0000 Received: from 195.3.113.74 by www110.gmx.net with HTTP; Fri, 28 Sep 2007 09:43:13 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Sep 2007 09:43:13 +0200 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20070928074313.69340@gmx.net> MIME-Version: 1.0 References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> Subject: Re: RE: [Geopriv] Updating the GEOPRIV milestones To: "Winterbottom, James" , geopriv@ietf.org, rjsparks@estacado.net X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18k5JUIZHokID4WquJUSPZ9cc3HtK76G/iAySVHHR NO/Aek9wOpg8aHdBlihYnaeIjhHTgJEiGm9w== Content-Transfer-Encoding: 7bit X-GMX-UID: o8rJLn1xZDIrGJ1QuGc2/ex5emhmY4GK X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi James, Hi Robert, > Hi Robert, > > I think that we need to have LIS Discovery and HELD at about the same > time. > > We also have: > > HTTP/HELD dereference protocol and LIS to LIS requirements, or do you > see these as HELD extensions? that's a good point. I believe we need to have the dereferencing part in place since otherwise the location-by-reference story is a bit questionable (at least for HTTP). Ciao Hannes > > Cheers > James > > PS LCP is location configuration protocol.. ;) > > > -----Original Message----- > > From: Robert Sparks [mailto:rjsparks@estacado.net] > > Sent: Friday, 28 September 2007 9:20 AM > > To: GEOPRIV > > Subject: [Geopriv] Updating the GEOPRIV milestones > > > > Folks - > > > > GEOPRIVs chartered milestone list needs to be updated to reflect what > > we as a group believe we can achieve. > > That's going to involve resetting or replacing all the milestones > > that are not marked "Done" on the current charter page. > > > > Here's my proposal for the set of goals we set for ourselves > > initially, and the list of those I know about that might be good > > goals to add as these complete. The dates and hence order here are > > only strawmen. > > > > Oct 2007 Submit Additional Civic PIDF-LO types (updating 4119) to > the > > IESG for publication as PS (see postscript below) > > Oct 2007 Resubmit Conveying Location Objects in RADIUS and > Diameter > > to the IESG for publication as PS > > Nov 2007 Resubmit Geolocation Policy to the IESG for publication > as PS > > Dec 2007 Submit Layer 7 Location Conveyance Protocol Problem > > Statement and Requirements to the IESG for publication as > Informational > > Dec 2007 Submit Requirements for Location by Reference Protocols > to > > the IESG for publication as Informational > > Jan 2007 Submit PIDF-LO Usage Clarifications and Recommendations > > (updating 4119) to the IESG for publication as PS > > Feb 2007 Submit minimal HTTP based protocol satisfying baseline > > requirements specified in the Layer 7 Location Conveyance Protocol > > Problem Statement and Requirements to the IESG for publication as PS > > > > Once we start knocking those down, we could shift our focus to > > address (in no particular order) > > * Location by Reference dereferencing mechanisms > > * Carrying Location by Reference in DHCP > > * Extending the HTTP location conveyance protocol > > * Finishing the binary-lci/3825bis discussions (does this need to be > > earlier?) > > * LIS Discovery > > * Location Signing > > * Finishing the Location Filters work > > > > So, please respond on-list answering these questions: > > > > 1) What did I miss? > > > > 2) What should those milestone dates really be? > > > > 3) Is there anything here we should agree NOT to do? > > > > Thanks, > > > > RjS > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 04:29:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbBDc-0001dd-47; Fri, 28 Sep 2007 04:29:04 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbBDb-0001cH-81 for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 04:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbBDa-0001c9-UZ for geopriv@ietf.org; Fri, 28 Sep 2007 04:29:02 -0400 Received: from fk-out-0910.google.com ([209.85.128.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbBDU-00019c-GV for geopriv@ietf.org; Fri, 28 Sep 2007 04:29:02 -0400 Received: by fk-out-0910.google.com with SMTP id z23so2986556fkz for ; Fri, 28 Sep 2007 01:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:cc:references:in-reply-to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language:message-id; bh=QA2YqM/7LgLA6ejCLpqUL+uKlpvBHnqc17oH9LeQ5Oo=; b=f0lE+v0Esg+XtZ8LFqntf6WKvBWXJphpbRL0nw5XmZrFQKjCEiSmftXABd+YUAnRMaKBDYLbo1tetY5SgVp2k2z+tCpj22WMT31ojxq1qbcGc186EHVYbxAyYm6Uhf/YQHrRxqH0G9K7+y0+H+nIdfw64S10EEAiYCHZA4NDqDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:cc:references:in-reply-to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:content-language:message-id; b=uFfnBumFSAbvfqyifQRqoMczGRCraFJYxnE/TPl7c0msPQB/8t6I1JBDwXhhG8+QhoxTEulN8CP9DWrnzJnufXJx8LRw7EiGZr5U5o2BkxdDJHeN+pz7wdw9Qm3MySLaBAEOzhNokumKKe1W3M86rybBuowrZnwGut35jBSmexE= Received: by 10.82.190.2 with SMTP id n2mr6888720buf.1190968119452; Fri, 28 Sep 2007 01:28:39 -0700 (PDT) Received: from enigma ( [80.218.143.134]) by mx.google.com with ESMTPS id d2sm3468652nfc.2007.09.28.01.28.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Sep 2007 01:28:37 -0700 (PDT) From: "Felix Kaegi" To: "'Tschofenig, Hannes \(NSN - DE/Munich\)'" , "'ext Andrew Daviel'" , "'Henning Schulzrinne'" References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu><4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu><66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu> <5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> In-Reply-To: <5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> Subject: AW: [Geopriv] Draft Updates "GEO TAGS for HTML" Date: Fri, 28 Sep 2007 10:28:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgA60qT98PtXrXaS5aZdK3UAsUFwwAACZlQABYj8CA= Content-Language: de-ch Message-ID: <46fcbb35.0269300a.38b7.ffffc676@mx.google.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Gentlemen To fulfill everybody' expectation I'd like to suggest following; Defining both elements (the proposed author friendly HTML META tags and = new an HTML reference to a machine processable XML file implementing any = location specific schema to map an address or an area) shall be optional. If a valid coordinate in the META TAG geo.position is defined this shall = be the preferred location definition for HTML location specification. Advantage of this suggestion: As the number of HTML META tags would rise enormously to map PIDF-LO or other Address schemas and the further chances that HTML authors would = use them are very low, it would make more sense to reference an XML file describing a location or area. Such a file may use any XML schema and = also may map RFC 4776 or any other location specification. This would further rise the door to describe complex geometric areas as it was not yet = possible and would therefore also fit future specifications and needs. Also the Google location specification may be used then. Would this suggestions meet everybody' expectation to a simple, global, language and culture independent, accurate enough definition to GEO TAGS for HTML Docs? felix -----Urspr=FCngliche Nachricht----- Von: Tschofenig, Hannes (NSN - DE/Munich) = [mailto:hannes.tschofenig@nsn.com] Gesendet: Donnerstag, 27. September 2007 11:51 An: ext Andrew Daviel; Henning Schulzrinne Cc: geopriv@ietf.org Betreff: AW: [Geopriv] Draft Updates "GEO TAGS for HTML" Hi Andrew,=20 > On Tue, 25 Sep 2007, Henning Schulzrinne wrote: >=20 > > > > As pointed out before, nobody is suggesting that you define=20 > a new document=20 > > format. The suggestion is to define civic and geo meta tags=20 > that have a=20 > > one-to-one correspondence with PIDF-LO tags, as in > > > > >=20 >=20 > So, do I have this right ? : >=20 > as per PIDF-LO from draft-ietf-geopriv-pidf-lo-03.txt or RFC 4776 >=20 > as per ISO3166-1 > matches ISO3166-2=20 > for US, CA > but seems less=20 > obscure than > ISO elsewhere >=20 > City (locality) > Postcode/Zip >=20 > etc. >=20 > If I resubmit draft-daviel-html dropping geo.region and=20 > geo.placename and > adding the PIDF fields as above, would this be acceptable? These change look promising to me.=20 > I could enumerate the fields from RFC4776, or simply refer to=20 > this RFC. >=20 You will have to add a reference to RFC 4776 anyway.=20 > I had some feedback that the totality of PIDF fields is too=20 > complex for=20 > the intended purpose of my draft (non-professional human=20 > authoring). But=20 > as I understand, the fields are optional and not all fields=20 > have values=20 > in any case. I could mention country and A1 specifically and=20 > the others=20 > by reference. Complexity for what exactly?=20 You might omit a few fields but you again have to be careful that you can still represent a location in, let's say, Japan.=20 Ciao Hannes _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Hommand@alliedcrane.net Fri Sep 28 05:00:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbBhm-0002bs-J8 for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 05:00:14 -0400 Received: from host181-9-dynamic.0-79-r.retail.telecomitalia.it ([79.0.9.181] helo=host11-135-dynamic.3-87-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbBhl-0001wZ-0N for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 05:00:14 -0400 Received: from antonio-xbpk3a7 ([149.184.149.20] helo=antonio-xbpk3a7) by host11-135-dynamic.3-87-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1qMWbn-000NHB-zu for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 11:04:45 +0200 Message-ID: <000b01c801ae$945d7830$0b870357@antonioxbpk3a7> From: "Hom mand" To: Subject: astro Date: Fri, 28 Sep 2007 11:04:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C801BF.57E64830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.6 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 ------=_NextPart_000_0006_01C801BF.57E64830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mining Sector --- Delta Mining UPDATE HOT SECTOR: Additional information on (O_T_C: D M X C) D M X C is = expected to arrive soon. For those of you who currently own this company this will be great news. For those that don't currently own this company, you need to get in on = this now. The company recently traded as high as .13 and with any significant news = should be able to see (if not exceed) those prices again. Contact your broker now, = don't miss this opportunity in D M X C! ------=_NextPart_000_0006_01C801BF.57E64830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mining Sector --- Delta Mining = UPDATE
HOT SECTOR: Additional information on (O_T_C: = D M X C) D=20 M X C is expected to arrive soon.
For those of you who currently own this = company this=20 will be great news.
For those that don't currently own this = company, you=20 need to get in on this now.
The company recently traded as high as .13 and = with any=20 significant news should be able
to see (if not exceed) those prices again. = Contact your=20 broker now, don't miss this
opportunity in D M X = C!
------=_NextPart_000_0006_01C801BF.57E64830-- From Toth-Ohlund@alliedcrane.net Fri Sep 28 05:06:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbBnn-0006ih-S4 for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 05:06:27 -0400 Received: from host29-31-dynamic.3-87-r.retail.telecomitalia.it ([87.3.31.29] helo=host11-135-dynamic.3-87-r.retail.telecomitalia.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbBnm-000270-8g for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 05:06:27 -0400 Received: from antonio-xbpk3a7 by alliedcrane.net with ASMTP id B75EBCA5 for ; Fri, 28 Sep 2007 11:10:54 +0200 Received: from antonio-xbpk3a7 ([192.189.25.3]) by alliedcrane.net with ESMTP id 3AED4CDE2E5C for ; Fri, 28 Sep 2007 11:10:54 +0200 Message-ID: <000a01c801af$72e08340$0b870357@antonioxbpk3a7> From: "Toth Ohlund" To: Subject: atagirri Date: Fri, 28 Sep 2007 11:10:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C801C0.36695340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 ------=_NextPart_000_0006_01C801C0.36695340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mining Sector --- Delta Mining UPDATE HOT SECTOR: Additional information on (O_T_C: D M X C) D M X C is = expected to arrive soon. For those of you who currently own this company this will be great news. For those that don't currently own this company, you need to get in on = this now. The company recently traded as high as .13 and with any significant news = should be able to see (if not exceed) those prices again. Contact your broker now, = don't miss this opportunity in D M X C! ------=_NextPart_000_0006_01C801C0.36695340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mining Sector --- Delta Mining = UPDATE
HOT SECTOR: Additional information on (O_T_C: = D M X C) D=20 M X C is expected to arrive soon.
For those of you who currently own this = company this=20 will be great news.
For those that don't currently own this = company, you=20 need to get in on this now.
The company recently traded as high as .13 and = with any=20 significant news should be able
to see (if not exceed) those prices again. = Contact your=20 broker now, don't miss this
opportunity in D M X = C!
------=_NextPart_000_0006_01C801C0.36695340-- From geopriv-bounces@ietf.org Fri Sep 28 05:25:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbC5L-0007vz-5L; Fri, 28 Sep 2007 05:24:35 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbC5J-0007tJ-SN for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 05:24:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbC5J-0007tB-Hb for geopriv@ietf.org; Fri, 28 Sep 2007 05:24:33 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbC5J-0000BU-4c for geopriv@ietf.org; Fri, 28 Sep 2007 05:24:33 -0400 X-SEF-Processed: 5_0_0_910__2007_09_28_04_34_14 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 28 Sep 2007 04:34:14 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 04:24:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Geopriv] Draft Updates "GEO TAGS for HTML" Date: Fri, 28 Sep 2007 04:24:30 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Geopriv] Draft Updates "GEO TAGS for HTML" Thread-Index: AcgBoXJDJL5PbnH0Tmm288fCv/2KeQAD9+Sg References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu><4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu><66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu><5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> From: "Winterbottom, James" To: "Andrew Daviel" , "Tschofenig, Hannes \(NSN - DE/Munich\)" X-OriginalArrivalTime: 28 Sep 2007 09:24:32.0606 (UTC) FILETIME=[60DDFFE0:01C801B1] X-Spam-Score: 1.8 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I fully expect Revised civic to go RFC before HTML Tags.. ;)=0D=0A=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Andrew Daviel [mailto:advax@tr= iumf.ca]=0D=0A> Sent: Friday, 28 September 2007 5:26 PM=0D=0A> To: Tschofen= ig, Hannes (NSN - DE/Munich)=0D=0A> Cc: geopriv@ietf.org=0D=0A> Subject: Re= : AW: [Geopriv] Draft Updates "GEO TAGS for HTML"=0D=0A>=20=0D=0A> On Thu, = 27 Sep 2007, Tschofenig, Hannes (NSN - DE/Munich) wrote:=0D=0A>=20=0D=0A> >= > I had some feedback that the totality of PIDF fields is too=0D=0A> >> com= plex ...=0D=0A>=20=0D=0A> > Complexity for what exactly=3F=0D=0A>=20=0D=0A>= "ordinary mortals to comprehend", basically. I had originally intended=0D=0A= > just a single "region" field as a check against lat/long quadrant=0D=0A> = goofups, but with the online tools like Google maps that is not so=0D=0Amuc= h=0D=0A> of an issue now.=0D=0A>=20=0D=0A> For the kind of use I envisage, = it has to at least appear simple or=0D=0A> people won't use it. Witness the= penetration of Dublin Core metadata=0D=0Avs.=0D=0A> "keywords". However, i= f most fields are optional, an application may=0D=0Ause=0D=0A> only a prefe= rred few. So I guess it's not really an issue.=0D=0A>=20=0D=0A> James Winte= rbottom writes:=0D=0A> > Or reference the revised civic specification.=0D=0A= >=20=0D=0A> That would be draft-ietf-geopriv-revised-civic-lo-05.txt =3F=0D= =0A> If I understand right, you aren't supposed to refer to=0D=0A> IDs as n= ormative. Unless they go to RFC in tandem.=0D=0A> But in principle, yes. Or= RFC4119 and revise it later.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> --=0D=0A= > Andrew Daviel, TRIUMF, Canada=0D=0A>=20=0D=0A>=20=0D=0A> ________________= _______________________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@= ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0AThis message is for the designated recipient only= and may=0D=0Acontain privileged, proprietary, or otherwise private informa= tion. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From thoa934@mcskins.com Fri Sep 28 07:04:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbDdw-0004CU-7R for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 07:04:24 -0400 Received: from [217.175.154.61] (helo=[217.175.154.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbDdh-0004eg-SK for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 07:04:11 -0400 Received: by 10.235.220.147 with SMTP id eJetzjRNUMPNZ; Fri, 28 Sep 2007 15:04:01 +0400 (GMT) Received: by 192.168.171.236 with SMTP id BxdRvPfFfPeAaI.7659046771940; Fri, 28 Sep 2007 15:03:59 +0400 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Sep 2007 15:03:56 +0400 To: geopriv-archive@lists.ietf.org From: "thoa Crum" Subject: engerebu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Mining Sector --- Delta Mining UPDATE HOT SECTOR: Additional information on (O_T_C: D M X C) D M X C is expected to arrive soon. For those of you who currently own this company this will be great news. For those that don't currently own this company, you need to get in on this now. The company recently traded as high as .13 and with any significant news should be able to see (if not exceed) those prices again. Contact your broker now, don't miss this opportunity in D M X C! From geopriv-bounces@ietf.org Fri Sep 28 07:38:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEAE-0002Vb-9V; Fri, 28 Sep 2007 07:37:46 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbEAC-0002Sx-Un for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 07:37:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEAC-00021Z-Ij for geopriv@ietf.org; Fri, 28 Sep 2007 07:37:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbEA7-0003VS-QS for geopriv@ietf.org; Fri, 28 Sep 2007 07:37:40 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EC21921718; Fri, 28 Sep 2007 13:37:38 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-b0-46fce7825361 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D038C2171D; Fri, 28 Sep 2007 13:37:38 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 13:37:38 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 13:37:38 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D89352465; Fri, 28 Sep 2007 14:37:37 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5CE7E4DB8A; Fri, 28 Sep 2007 14:37:37 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E0A9C4DB1C; Fri, 28 Sep 2007 14:37:36 +0300 (EEST) Subject: Re: [Geopriv] Updating the GEOPRIV milestones From: Salvatore Loreto To: Hannes Tschofenig In-Reply-To: <20070928074124.69330@gmx.net> References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> <20070928074124.69330@gmx.net> Content-Type: text/plain Date: Fri, 28 Sep 2007 14:37:36 +0300 Message-Id: <1190979456.8885.58.camel@n85.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 28 Sep 2007 11:37:38.0156 (UTC) FILETIME=[F8A03AC0:01C801C3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: geopriv@ietf.org, Robert Sparks X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think Hannes is right, the draft-ietf-geopriv-loc-filters require a very few effort to be finished, so I think it should worth to keep it. Sal On Fri, 2007-09-28 at 09:41 +0200, Hannes Tschofenig wrote: > Hi Robert, > > I am fine with the proposed milestones (even though you drop some of the current items from the charter). > > Only a few minor comments: > > * Revised Civic: I thought that this document was sent the IESG a long time ago. In fact the tracker indicates that this document is already in IESG processing. > > * LIS discovery: We cannot delay this item; This is extremely important for the document and should be sent to the IESG at the same time as the base HELD specification is sent to the IESG. > > * draft-ietf-geopriv-loc-filters: I thought that this document reached a status in the working group so that it could be sent to the IESG immediately. > > The list of items that can be done once the listed items are finished can obviously be extended. But that's probably not that important right now. > > I believe the listed milestones are realistic. > > Ciao > Hannes > > -------- Original-Nachricht -------- > > Datum: Thu, 27 Sep 2007 18:19:50 -0500 > > Von: Robert Sparks > > An: GEOPRIV > > Betreff: [Geopriv] Updating the GEOPRIV milestones > > > Folks - > > > > GEOPRIVs chartered milestone list needs to be updated to reflect what > > we as a group believe we can achieve. > > That's going to involve resetting or replacing all the milestones > > that are not marked "Done" on the current charter page. > > > > Here's my proposal for the set of goals we set for ourselves > > initially, and the list of those I know about that might be good > > goals to add as these complete. The dates and hence order here are > > only strawmen. > > > > Oct 2007 Submit Additional Civic PIDF-LO types (updating 4119) to the > > IESG for publication as PS (see postscript below) > > Oct 2007 Resubmit Conveying Location Objects in RADIUS and Diameter > > to the IESG for publication as PS > > Nov 2007 Resubmit Geolocation Policy to the IESG for publication as PS > > Dec 2007 Submit Layer 7 Location Conveyance Protocol Problem > > Statement and Requirements to the IESG for publication as Informational > > Dec 2007 Submit Requirements for Location by Reference Protocols to > > the IESG for publication as Informational > > Jan 2007 Submit PIDF-LO Usage Clarifications and Recommendations > > (updating 4119) to the IESG for publication as PS > > Feb 2007 Submit minimal HTTP based protocol satisfying baseline > > requirements specified in the Layer 7 Location Conveyance Protocol > > Problem Statement and Requirements to the IESG for publication as PS > > > > Once we start knocking those down, we could shift our focus to > > address (in no particular order) > > * Location by Reference dereferencing mechanisms > > * Carrying Location by Reference in DHCP > > * Extending the HTTP location conveyance protocol > > * Finishing the binary-lci/3825bis discussions (does this need to be > > earlier?) > > * LIS Discovery > > * Location Signing > > * Finishing the Location Filters work > > > > So, please respond on-list answering these questions: > > > > 1) What did I miss? > > > > 2) What should those milestone dates really be? > > > > 3) Is there anything here we should agree NOT to do? > > > > Thanks, > > > > RjS > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 08:45:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFDw-0002N6-An; Fri, 28 Sep 2007 08:45:40 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbFDv-0002Lt-Gc for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 08:45:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFDu-0002Ir-3L for geopriv@ietf.org; Fri, 28 Sep 2007 08:45:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbFDo-0005Kw-5P for geopriv@ietf.org; Fri, 28 Sep 2007 08:45:32 -0400 Received: (qmail 3363 invoked by uid 0); 28 Sep 2007 12:45:30 -0000 Received: from 90.186.186.121 by www045.gmx.net with HTTP; Fri, 28 Sep 2007 14:45:31 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Sep 2007 14:45:30 +0200 From: "Hannes Tschofenig" In-Reply-To: <1190979456.8885.58.camel@n85.nomadiclab.com> Message-ID: <20070928124530.69280@gmx.net> MIME-Version: 1.0 References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> <20070928074124.69330@gmx.net> <1190979456.8885.58.camel@n85.nomadiclab.com> Subject: Re: [Geopriv] Updating the GEOPRIV milestones To: Salvatore Loreto X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/QpKhNhqrQ7H0p9Ikc/LcrNMxKXU0OG1AO1+msXb zsnvnyqTYEpzle2Nt36lzURAiIt90d5VMZqw== Content-Transfer-Encoding: 7bit X-GMX-UID: Dp6ZB35vfW47W8k5tWRohuBudmllckWV X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: geopriv@ietf.org, rjsparks@estacado.net X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I would even argue that there are no known open issues with the document. Let's ship it. -------- Original-Nachricht -------- > Datum: Fri, 28 Sep 2007 14:37:36 +0300 > Von: Salvatore Loreto > An: Hannes Tschofenig > CC: Robert Sparks , geopriv@ietf.org > Betreff: Re: [Geopriv] Updating the GEOPRIV milestones > I think Hannes is right, the draft-ietf-geopriv-loc-filters require a > very few effort to be finished, so I think it should worth to keep it. > > Sal > > > On Fri, 2007-09-28 at 09:41 +0200, Hannes Tschofenig wrote: > > Hi Robert, > > > > I am fine with the proposed milestones (even though you drop some of the > current items from the charter). > > > > Only a few minor comments: > > > > * Revised Civic: I thought that this document was sent the IESG a long > time ago. In fact the tracker indicates that this document is already in > IESG processing. > > > > * LIS discovery: We cannot delay this item; This is extremely important > for the document and should be sent to the IESG at the same time as the > base HELD specification is sent to the IESG. > > > > * draft-ietf-geopriv-loc-filters: I thought that this document reached a > status in the working group so that it could be sent to the IESG > immediately. > > > > The list of items that can be done once the listed items are finished > can obviously be extended. But that's probably not that important right now. > > > > I believe the listed milestones are realistic. > > > > Ciao > > Hannes > > > > -------- Original-Nachricht -------- > > > Datum: Thu, 27 Sep 2007 18:19:50 -0500 > > > Von: Robert Sparks > > > An: GEOPRIV > > > Betreff: [Geopriv] Updating the GEOPRIV milestones > > > > > Folks - > > > > > > GEOPRIVs chartered milestone list needs to be updated to reflect what > > > we as a group believe we can achieve. > > > That's going to involve resetting or replacing all the milestones > > > that are not marked "Done" on the current charter page. > > > > > > Here's my proposal for the set of goals we set for ourselves > > > initially, and the list of those I know about that might be good > > > goals to add as these complete. The dates and hence order here are > > > only strawmen. > > > > > > Oct 2007 Submit Additional Civic PIDF-LO types (updating 4119) to the > > > IESG for publication as PS (see postscript below) > > > Oct 2007 Resubmit Conveying Location Objects in RADIUS and Diameter > > > to the IESG for publication as PS > > > Nov 2007 Resubmit Geolocation Policy to the IESG for publication as PS > > > Dec 2007 Submit Layer 7 Location Conveyance Protocol Problem > > > Statement and Requirements to the IESG for publication as > Informational > > > Dec 2007 Submit Requirements for Location by Reference Protocols to > > > the IESG for publication as Informational > > > Jan 2007 Submit PIDF-LO Usage Clarifications and Recommendations > > > (updating 4119) to the IESG for publication as PS > > > Feb 2007 Submit minimal HTTP based protocol satisfying baseline > > > requirements specified in the Layer 7 Location Conveyance Protocol > > > Problem Statement and Requirements to the IESG for publication as PS > > > > > > Once we start knocking those down, we could shift our focus to > > > address (in no particular order) > > > * Location by Reference dereferencing mechanisms > > > * Carrying Location by Reference in DHCP > > > * Extending the HTTP location conveyance protocol > > > * Finishing the binary-lci/3825bis discussions (does this need to be > > > earlier?) > > > * LIS Discovery > > > * Location Signing > > > * Finishing the Location Filters work > > > > > > So, please respond on-list answering these questions: > > > > > > 1) What did I miss? > > > > > > 2) What should those milestone dates really be? > > > > > > 3) Is there anything here we should agree NOT to do? > > > > > > Thanks, > > > > > > RjS > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 08:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFQE-00088C-Fp; Fri, 28 Sep 2007 08:58:22 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbFQD-00083v-5X for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 08:58:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFQC-00081Y-OO for geopriv@ietf.org; Fri, 28 Sep 2007 08:58:20 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbFQC-0005cR-4A for geopriv@ietf.org; Fri, 28 Sep 2007 08:58:20 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IbFQ2-0003po-0h; Fri, 28 Sep 2007 07:58:10 -0500 From: "Brian Rosen" To: "'Felix Kaegi'" , "'Tschofenig, Hannes \(NSN - DE/Munich\)'" , "'ext Andrew Daviel'" , "'Henning Schulzrinne'" References: <5D2DEB45-77C6-4BD6-99D1-AD23F759E2B1@cs.columbia.edu><4EE6A226-D6B5-48DC-91E7-38A2BBD37245@cs.columbia.edu><66919DCE-BAD2-4EAF-B46B-456E0809804B@cs.columbia.edu> <5FB585F183235B42A9E70095055136FB32D4CB@DEMUEXC012.nsn-intra.net> <46fcbb35.0269300a.38b7.ffffc676@mx.google.com> Subject: RE: [Geopriv] Draft Updates "GEO TAGS for HTML" Date: Fri, 28 Sep 2007 08:58:14 -0400 Message-ID: <062f01c801cf$3d0d50c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46fcbb35.0269300a.38b7.ffffc676@mx.google.com> Thread-Index: AcgA60qT98PtXrXaS5aZdK3UAsUFwwAACZlQABYj8CAAIrfMMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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 X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I think your problem here is "global and culture independent". The = proposed "author friendly" tags are not global or culture independent. The PIDF = tags are. We worked pretty hard on that. One of the reasons that the tags = are labled "A1", etc is "culture independent".=20 Brian > -----Original Message----- > From: Felix Kaegi [mailto:felix.kaegi@gmail.com] > Sent: Friday, September 28, 2007 4:29 AM > To: 'Tschofenig, Hannes (NSN - DE/Munich)'; 'ext Andrew Daviel'; = 'Henning > Schulzrinne' > Cc: geopriv@ietf.org > Subject: AW: [Geopriv] Draft Updates "GEO TAGS for HTML" >=20 > Gentlemen >=20 > To fulfill everybody' expectation I'd like to suggest following; >=20 > Defining both elements (the proposed author friendly HTML META tags = and > new > an > HTML reference to a machine processable XML file implementing any = location > specific schema to map an address or an area) shall be optional. > If a valid coordinate in the META TAG geo.position is defined this = shall > be > the preferred > location definition for HTML location specification. >=20 > Advantage of this suggestion: > As the number of HTML META tags would rise enormously to map PIDF-LO = or > other Address schemas and the further chances that HTML authors would = use > them are very low, it would make more sense to reference an XML file > describing a location or area. Such a file may use any XML schema and = also > may map RFC 4776 or any other location specification. This would = further > rise the door to describe complex geometric areas as it was not yet > possible > and would therefore also fit future specifications and needs. Also the > Google location specification may be used then. >=20 > Would this suggestions meet everybody' expectation to a simple, = global, > language and culture independent, > accurate enough definition to GEO TAGS for HTML Docs? >=20 > felix >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Tschofenig, Hannes (NSN - DE/Munich) > [mailto:hannes.tschofenig@nsn.com] >=20 > Gesendet: Donnerstag, 27. September 2007 11:51 > An: ext Andrew Daviel; Henning Schulzrinne > Cc: geopriv@ietf.org > Betreff: AW: [Geopriv] Draft Updates "GEO TAGS for HTML" >=20 > Hi Andrew, >=20 >=20 > > On Tue, 25 Sep 2007, Henning Schulzrinne wrote: > > > > > > > > As pointed out before, nobody is suggesting that you define > > a new document > > > format. The suggestion is to define civic and geo meta tags > > that have a > > > one-to-one correspondence with PIDF-LO tags, as in > > > > > > > > > > > > So, do I have this right ? : > > > > as per PIDF-LO from draft-ietf-geopriv-pidf-lo-03.txt or RFC 4776 > > > > as per ISO3166-1 > > matches ISO3166-2 > > for US, CA > > but seems less > > obscure than > > ISO elsewhere > > > > City (locality) > > Postcode/Zip > > > > etc. > > > > If I resubmit draft-daviel-html dropping geo.region and > > geo.placename and > > adding the PIDF fields as above, would this be acceptable? >=20 > These change look promising to me. >=20 >=20 > > I could enumerate the fields from RFC4776, or simply refer to > > this RFC. > > >=20 > You will have to add a reference to RFC 4776 anyway. >=20 >=20 > > I had some feedback that the totality of PIDF fields is too > > complex for > > the intended purpose of my draft (non-professional human > > authoring). But > > as I understand, the fields are optional and not all fields > > have values > > in any case. I could mention country and A1 specifically and > > the others > > by reference. >=20 > Complexity for what exactly? >=20 > You might omit a few fields but you again have to be careful that you > can still represent a location in, let's say, Japan. >=20 >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 08:58:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFQl-00010N-3r; Fri, 28 Sep 2007 08:58:55 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbFQh-0000qh-Ij for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 08:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFQh-0000qX-96 for geopriv@ietf.org; Fri, 28 Sep 2007 08:58:51 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbFQb-0007WA-R0 for geopriv@ietf.org; Fri, 28 Sep 2007 08:58:51 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3756B216D4; Fri, 28 Sep 2007 14:58:13 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-20-46fcfa6504ee Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 185BF21696; Fri, 28 Sep 2007 14:58:13 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 14:58:12 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 14:58:12 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6B2AC2465; Fri, 28 Sep 2007 15:58:12 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EC48C4DB8A; Fri, 28 Sep 2007 15:58:11 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 90E7E4DB1C; Fri, 28 Sep 2007 15:58:11 +0300 (EEST) Subject: Re: [Geopriv] Updating the GEOPRIV milestones From: Salvatore Loreto To: Hannes Tschofenig In-Reply-To: <20070928124530.69280@gmx.net> References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> <20070928074124.69330@gmx.net> <1190979456.8885.58.camel@n85.nomadiclab.com> <20070928124530.69280@gmx.net> Content-Type: text/plain Date: Fri, 28 Sep 2007 15:58:11 +0300 Message-Id: <1190984291.8885.66.camel@n85.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 28 Sep 2007 12:58:12.0722 (UTC) FILETIME=[3A407520:01C801CF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: geopriv@ietf.org, rjsparks@estacado.net X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org for example, "speed" is not defined as PIDF-LO element (draft-singh-geopriv-pidf-lo-dynamic-01.txt suggests adding this, but it is expired). Maybe we can let this draft as it is, but we should define speed as PIDF-LO element. On Fri, 2007-09-28 at 14:45 +0200, Hannes Tschofenig wrote: > I would even argue that there are no known open issues with the document. > Let's ship it. > > -------- Original-Nachricht -------- > > Datum: Fri, 28 Sep 2007 14:37:36 +0300 > > Von: Salvatore Loreto > > An: Hannes Tschofenig > > CC: Robert Sparks , geopriv@ietf.org > > Betreff: Re: [Geopriv] Updating the GEOPRIV milestones > > > I think Hannes is right, the draft-ietf-geopriv-loc-filters require a > > very few effort to be finished, so I think it should worth to keep it. > > > > Sal > > > > > > On Fri, 2007-09-28 at 09:41 +0200, Hannes Tschofenig wrote: > > > Hi Robert, > > > > > > I am fine with the proposed milestones (even though you drop some of the > > current items from the charter). > > > > > > Only a few minor comments: > > > > > > * Revised Civic: I thought that this document was sent the IESG a long > > time ago. In fact the tracker indicates that this document is already in > > IESG processing. > > > > > > * LIS discovery: We cannot delay this item; This is extremely important > > for the document and should be sent to the IESG at the same time as the > > base HELD specification is sent to the IESG. > > > > > > * draft-ietf-geopriv-loc-filters: I thought that this document reached a > > status in the working group so that it could be sent to the IESG > > immediately. > > > > > > The list of items that can be done once the listed items are finished > > can obviously be extended. But that's probably not that important right now. > > > > > > I believe the listed milestones are realistic. > > > > > > Ciao > > > Hannes > > > > > > -------- Original-Nachricht -------- > > > > Datum: Thu, 27 Sep 2007 18:19:50 -0500 > > > > Von: Robert Sparks > > > > An: GEOPRIV > > > > Betreff: [Geopriv] Updating the GEOPRIV milestones > > > > > > > Folks - > > > > > > > > GEOPRIVs chartered milestone list needs to be updated to reflect what > > > > we as a group believe we can achieve. > > > > That's going to involve resetting or replacing all the milestones > > > > that are not marked "Done" on the current charter page. > > > > > > > > Here's my proposal for the set of goals we set for ourselves > > > > initially, and the list of those I know about that might be good > > > > goals to add as these complete. The dates and hence order here are > > > > only strawmen. > > > > > > > > Oct 2007 Submit Additional Civic PIDF-LO types (updating 4119) to the > > > > IESG for publication as PS (see postscript below) > > > > Oct 2007 Resubmit Conveying Location Objects in RADIUS and Diameter > > > > to the IESG for publication as PS > > > > Nov 2007 Resubmit Geolocation Policy to the IESG for publication as PS > > > > Dec 2007 Submit Layer 7 Location Conveyance Protocol Problem > > > > Statement and Requirements to the IESG for publication as > > Informational > > > > Dec 2007 Submit Requirements for Location by Reference Protocols to > > > > the IESG for publication as Informational > > > > Jan 2007 Submit PIDF-LO Usage Clarifications and Recommendations > > > > (updating 4119) to the IESG for publication as PS > > > > Feb 2007 Submit minimal HTTP based protocol satisfying baseline > > > > requirements specified in the Layer 7 Location Conveyance Protocol > > > > Problem Statement and Requirements to the IESG for publication as PS > > > > > > > > Once we start knocking those down, we could shift our focus to > > > > address (in no particular order) > > > > * Location by Reference dereferencing mechanisms > > > > * Carrying Location by Reference in DHCP > > > > * Extending the HTTP location conveyance protocol > > > > * Finishing the binary-lci/3825bis discussions (does this need to be > > > > earlier?) > > > > * LIS Discovery > > > > * Location Signing > > > > * Finishing the Location Filters work > > > > > > > > So, please respond on-list answering these questions: > > > > > > > > 1) What did I miss? > > > > > > > > 2) What should those milestone dates really be? > > > > > > > > 3) Is there anything here we should agree NOT to do? > > > > > > > > Thanks, > > > > > > > > RjS > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 09:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFlf-0000Nn-2d; Fri, 28 Sep 2007 09:20:31 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbFld-0000Nh-KT for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFld-0000I2-Ap for geopriv@ietf.org; Fri, 28 Sep 2007 09:20:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbFlR-0008RA-SI for geopriv@ietf.org; Fri, 28 Sep 2007 09:20:24 -0400 Received: (qmail 23548 invoked by uid 0); 28 Sep 2007 13:20:02 -0000 Received: from 90.186.186.121 by www008.gmx.net with HTTP; Fri, 28 Sep 2007 15:20:01 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Sep 2007 15:20:01 +0200 From: "Hannes Tschofenig" In-Reply-To: <1190984291.8885.66.camel@n85.nomadiclab.com> Message-ID: <20070928132001.69270@gmx.net> MIME-Version: 1.0 References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> <20070928074124.69330@gmx.net> <1190979456.8885.58.camel@n85.nomadiclab.com> <20070928124530.69280@gmx.net> <1190984291.8885.66.camel@n85.nomadiclab.com> Subject: Re: [Geopriv] Updating the GEOPRIV milestones To: Salvatore Loreto X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+E2YNlFIqE5bk+i4GoLYuwLEeBakoKRy+kunKHLq 2P3RyioLroBnT642xwlN/R/+8L4d9p7V5uIg== Content-Transfer-Encoding: 7bit X-GMX-UID: sIXJLmRxZDIrGZ1QuGc2Evl5emhmY4GS X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: geopriv@ietf.org, rjsparks@estacado.net X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org I am actually going to re-submit draft-singh-geopriv-pidf-lo-dynamic. You are right. We might want to remove speed from draft-ietf-geopriv-loc-filters since it will take some time for draft-singh-geopriv-pidf-lo-dynamic to become RFC. Ciao Hannes -------- Original-Nachricht -------- > Datum: Fri, 28 Sep 2007 15:58:11 +0300 > Von: Salvatore Loreto > An: Hannes Tschofenig > CC: geopriv@ietf.org, rjsparks@estacado.net > Betreff: Re: [Geopriv] Updating the GEOPRIV milestones > > > for example, "speed" is not defined as PIDF-LO element > (draft-singh-geopriv-pidf-lo-dynamic-01.txt suggests adding this, but it > is expired). > > Maybe we can let this draft as it is, but we should define speed as > PIDF-LO element. > > > > On Fri, 2007-09-28 at 14:45 +0200, Hannes Tschofenig wrote: > > I would even argue that there are no known open issues with the > document. > > Let's ship it. > > > > -------- Original-Nachricht -------- > > > Datum: Fri, 28 Sep 2007 14:37:36 +0300 > > > Von: Salvatore Loreto > > > An: Hannes Tschofenig > > > CC: Robert Sparks , geopriv@ietf.org > > > Betreff: Re: [Geopriv] Updating the GEOPRIV milestones > > > > > I think Hannes is right, the draft-ietf-geopriv-loc-filters require a > > > very few effort to be finished, so I think it should worth to keep it. > > > > > > Sal > > > > > > > > > On Fri, 2007-09-28 at 09:41 +0200, Hannes Tschofenig wrote: > > > > Hi Robert, > > > > > > > > I am fine with the proposed milestones (even though you drop some of > the > > > current items from the charter). > > > > > > > > Only a few minor comments: > > > > > > > > * Revised Civic: I thought that this document was sent the IESG a > long > > > time ago. In fact the tracker indicates that this document is already > in > > > IESG processing. > > > > > > > > * LIS discovery: We cannot delay this item; This is extremely > important > > > for the document and should be sent to the IESG at the same time as > the > > > base HELD specification is sent to the IESG. > > > > > > > > * draft-ietf-geopriv-loc-filters: I thought that this document > reached a > > > status in the working group so that it could be sent to the IESG > > > immediately. > > > > > > > > The list of items that can be done once the listed items are > finished > > > can obviously be extended. But that's probably not that important > right now. > > > > > > > > I believe the listed milestones are realistic. > > > > > > > > Ciao > > > > Hannes > > > > > > > > -------- Original-Nachricht -------- > > > > > Datum: Thu, 27 Sep 2007 18:19:50 -0500 > > > > > Von: Robert Sparks > > > > > An: GEOPRIV > > > > > Betreff: [Geopriv] Updating the GEOPRIV milestones > > > > > > > > > Folks - > > > > > > > > > > GEOPRIVs chartered milestone list needs to be updated to reflect > what > > > > > we as a group believe we can achieve. > > > > > That's going to involve resetting or replacing all the milestones > > > > > that are not marked "Done" on the current charter page. > > > > > > > > > > Here's my proposal for the set of goals we set for ourselves > > > > > initially, and the list of those I know about that might be good > > > > > goals to add as these complete. The dates and hence order here are > > > > > > only strawmen. > > > > > > > > > > Oct 2007 Submit Additional Civic PIDF-LO types (updating 4119) to > the > > > > > IESG for publication as PS (see postscript below) > > > > > Oct 2007 Resubmit Conveying Location Objects in RADIUS and > Diameter > > > > > to the IESG for publication as PS > > > > > Nov 2007 Resubmit Geolocation Policy to the IESG for publication > as PS > > > > > Dec 2007 Submit Layer 7 Location Conveyance Protocol Problem > > > > > Statement and Requirements to the IESG for publication as > > > Informational > > > > > Dec 2007 Submit Requirements for Location by Reference Protocols > to > > > > > the IESG for publication as Informational > > > > > Jan 2007 Submit PIDF-LO Usage Clarifications and Recommendations > > > > > (updating 4119) to the IESG for publication as PS > > > > > Feb 2007 Submit minimal HTTP based protocol satisfying baseline > > > > > requirements specified in the Layer 7 Location Conveyance Protocol > > > > > > Problem Statement and Requirements to the IESG for publication as > PS > > > > > > > > > > Once we start knocking those down, we could shift our focus to > > > > > address (in no particular order) > > > > > * Location by Reference dereferencing mechanisms > > > > > * Carrying Location by Reference in DHCP > > > > > * Extending the HTTP location conveyance protocol > > > > > * Finishing the binary-lci/3825bis discussions (does this need to > be > > > > > earlier?) > > > > > * LIS Discovery > > > > > * Location Signing > > > > > * Finishing the Location Filters work > > > > > > > > > > So, please respond on-list answering these questions: > > > > > > > > > > 1) What did I miss? > > > > > > > > > > 2) What should those milestone dates really be? > > > > > > > > > > 3) Is there anything here we should agree NOT to do? > > > > > > > > > > Thanks, > > > > > > > > > > RjS > > > > > > > > > > > > > > > _______________________________________________ > > > > > Geopriv mailing list > > > > > Geopriv@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Lien@celestia.us Fri Sep 28 09:31:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFvy-00026F-BP for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 09:31:10 -0400 Received: from [201.57.184.11] (helo=[201.57.184.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbFvm-0000BG-D5 for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 09:31:07 -0400 Received: from P4 ([124.183.41.175] helo=P4) by [201.57.184.11] ( sendmail 8.13.3/8.13.1) with esmtpa id 1WcqWc-000ROP-iR for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 10:30:54 -0300 Message-ID: <000301c801d3$c0f925e0$0bb839c9@P4> From: "Lien Hillrey" To: Subject: sareugir Date: Fri, 28 Sep 2007 10:30:36 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C801BA.9BABEDE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 ------=_NextPart_000_0004_01C801BA.9BABEDE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mining Sector --- Delta Mining UPDATE HOT SECTOR: Additional information on (O_T_C: D M X C) D M X C is = expected to arrive soon. For those of you who currently own this company this will be great news. For those that don't currently own this company, you need to get in on = this now. The company recently traded as high as .13 and with any significant news = should be able to see (if not exceed) those prices again. Contact your broker now, = don't miss this opportunity in D M X C! ------=_NextPart_000_0004_01C801BA.9BABEDE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Mining Sector --- Delta Mining = UPDATE
HOT SECTOR: Additional information on (O_T_C: = D M X C) D=20 M X C is expected to arrive soon.
For those of you who currently own this = company this=20 will be great news.
For those that don't currently own this = company, you=20 need to get in on this now.
The company recently traded as high as .13 and = with any=20 significant news should be able
to see (if not exceed) those prices again. = Contact your=20 broker now, don't miss this
opportunity in D M X = C!
------=_NextPart_000_0004_01C801BA.9BABEDE0-- From geopriv-bounces@ietf.org Fri Sep 28 09:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGMf-0003YD-3k; Fri, 28 Sep 2007 09:58:45 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbGMd-0003Y2-Gm for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:58:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGMd-0003Xt-2u for geopriv@ietf.org; Fri, 28 Sep 2007 09:58:43 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbGMb-0000gM-OP for geopriv@ietf.org; Fri, 28 Sep 2007 09:58:43 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l8SDwO7l079092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Sep 2007 08:58:24 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <20070928074124.69330@gmx.net> References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> <20070928074124.69330@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92575694-645C-422C-8BCB-D6ED6E9F245F@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Geopriv] Updating the GEOPRIV milestones Date: Fri, 28 Sep 2007 08:58:20 -0500 To: "Hannes Tschofenig" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Sep 28, 2007, at 2:41 AM, Hannes Tschofenig wrote: > > Only a few minor comments: > > * Revised Civic: I thought that this document was sent the IESG a > long time ago. In fact the tracker indicates that this document is > already in IESG processing. Well - I intended to explain that in the first message, but I see I didn't attach the postscript I called out next to this item. It should have said: ps: revised-civic-lo is mostly already submitted - I'll be putting together a PROTO writeup around it for the group to double-check, then this milestone will be complete. RjS _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 10:27:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGo2-0002i1-Ec; Fri, 28 Sep 2007 10:27:02 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbGo0-0002eq-NG for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 10:27:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGo0-000294-D6 for geopriv@ietf.org; Fri, 28 Sep 2007 10:27:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbGnp-0007tJ-O9 for geopriv@ietf.org; Fri, 28 Sep 2007 10:26:50 -0400 Received: (qmail 31735 invoked by uid 0); 28 Sep 2007 14:26:48 -0000 Received: from 90.186.13.19 by www116.gmx.net with HTTP; Fri, 28 Sep 2007 16:26:48 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Sep 2007 16:26:48 +0200 From: "Hannes Tschofenig" In-Reply-To: <92575694-645C-422C-8BCB-D6ED6E9F245F@estacado.net> Message-ID: <20070928142648.188260@gmx.net> MIME-Version: 1.0 References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> <20070928074124.69330@gmx.net> <92575694-645C-422C-8BCB-D6ED6E9F245F@estacado.net> Subject: Re: [Geopriv] Updating the GEOPRIV milestones To: Robert Sparks X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+ZVdBUJz+ZFYJeIWXRcuzq8leqKk9EoRcTb5YdK5 ltmzYYw8je8zpGMO9pYqi7ypEBmguz8x9ngA== Content-Transfer-Encoding: 7bit X-GMX-UID: f0u3AcIua2AoTpdV9XUyI4Y6OWhhagf1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org > ps: revised-civic-lo is mostly already submitted - I'll be putting > together a PROTO writeup around it for the group to double-check, > then this milestone will be complete. ... and that's something I am curious about. Typically, the PROTO writeup is attached to the draft that leaves the working group after a successful WGLC. So, that should have been done already a long time ago. What went wrong? _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 10:36:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGwq-0004BY-JO; Fri, 28 Sep 2007 10:36:08 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbGwp-00048Q-Og for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 10:36:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGwp-00048A-Es for geopriv@ietf.org; Fri, 28 Sep 2007 10:36:07 -0400 Received: from estacado-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:266::2] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbGwn-0001Lr-OW for geopriv@ietf.org; Fri, 28 Sep 2007 10:36:07 -0400 Received: from [172.17.1.65] ([172.17.1.65]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l8SEa2AZ083237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Sep 2007 09:36:02 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <20070928142648.188260@gmx.net> References: <02D12775-6776-4E59-8DDF-3F95CFF63DAB@estacado.net> <20070928074124.69330@gmx.net> <92575694-645C-422C-8BCB-D6ED6E9F245F@estacado.net> <20070928142648.188260@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Geopriv] Updating the GEOPRIV milestones Date: Fri, 28 Sep 2007 09:35:57 -0500 To: "Hannes Tschofenig" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: geopriv@ietf.org X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org On Sep 28, 2007, at 9:26 AM, Hannes Tschofenig wrote: > >> ps: revised-civic-lo is mostly already submitted - I'll be putting >> together a PROTO writeup around it for the group to double-check, >> then this milestone will be complete. > > ... and that's something I am curious about. Typically, the PROTO > writeup is attached to the draft that leaves the working group > after a successful WGLC. So, that should have been done already a > long time ago. > > What went wrong? > Agreed it should have been around, but its not. This is an isolated incident and is fairly straightforward to correct. RjS _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 12:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIQE-0002gi-Hy; Fri, 28 Sep 2007 12:10:34 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbIQD-0002gB-6w for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:10:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIQC-0002g3-S4; Fri, 28 Sep 2007 12:10:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbIQC-0004SW-GC; Fri, 28 Sep 2007 12:10:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 6B9182AC5E; Fri, 28 Sep 2007 16:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbIPi-0004xz-3E; Fri, 28 Sep 2007 12:10:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 28 Sep 2007 12:10:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-http-location-delivery-02.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org --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 : HTTP Enabled Location Delivery (HELD) Author(s) : M. Barnes, et al. Filename : draft-ietf-geopriv-http-location-delivery-02.txt Pages : 36 Date : 2007-09-28 A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol is an application-layer protocol that is independent of session- layer; an HTTP, web services binding is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-http-location-delivery-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-geopriv-http-location-delivery-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-28120835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-geopriv-http-location-delivery-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-geopriv-http-location-delivery-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-28120835.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --NextPart-- From geopriv-bounces@ietf.org Fri Sep 28 12:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJ1o-0000wx-Nb; Fri, 28 Sep 2007 12:49:24 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbJ1n-0000uT-A7 for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:49:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJ1m-0000u7-Vq for geopriv@ietf.org; Fri, 28 Sep 2007 12:49:23 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbJ1c-0006Xn-Th for geopriv@ietf.org; Fri, 28 Sep 2007 12:49:22 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8SGkQp03182 for ; Fri, 28 Sep 2007 16:46:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] I-D Action:draft-ietf-geopriv-http-location-delivery-02.txt Date: Fri, 28 Sep 2007 11:46:51 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] I-D Action:draft-ietf-geopriv-http-location-delivery-02.txt Thread-Index: AcgB6nxn7wFz08p3SM6uFwub+9tTtAAAt3cg References: From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi all, The changes to the document reflect the conclusions/consensus on the responseTime and the locationType. The following summarizes the changes: 1) Updated description and definition for responseTime to include type of service (emergencyRouting or emergencyDispatch). One important note here is that the current definition is not easily extensible. =20 2) Removed jurisdicationalCivic and postalCivic from the locationType, leaving just civic. 3) Simplified the error processing. Rather than the error and locationResponse sharing the same type, a new errorType has been defined, thus there's no longer a code for "success" nor does the locationResponse contain a code. =20 4) Clarified that locationType is optional with "any" being the default - there were some inconsistencies between table 1 and sections 5.2 and 6.2. =20 5) Updated terminology (i.e., using "LIS" rather than "LCS") and removed all duplicate definitions, which resulted in no new terms defined in this document, since they're defined and/or commonly used elsewhere. =20 6) Updated the schema and examples based on all the other changes. 7) Updated the appendix A to reflect the last requirements and problem statement document (specifically A.1, A.3 and adding A.10).=20 8) Lots of miscellaneous editorial changes/clarifications based on detailed WG feedback (Hannes, Barbara, Carl and Shida). If I missed anyone's comments let me know. I made the mistake of caching those emails in the same folder as the debate on responseTime and locationType, thus I may have missed some.=20 Mary. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, September 28, 2007 11:10 AM To: i-d-announce@ietf.org Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-http-location-delivery-02.txt 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 : HTTP Enabled Location Delivery (HELD) Author(s) : M. Barnes, et al. Filename : draft-ietf-geopriv-http-location-delivery-02.txt Pages : 36 Date : 2007-09-28 A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol is an application-layer protocol that is independent of session- layer; an HTTP, web services binding is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-del ivery-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-http-location-delivery-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-geopriv-http-location-delivery-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Fri Sep 28 13:28:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJdQ-00016H-Gi; Fri, 28 Sep 2007 13:28:16 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbIOq-00051w-V5 for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:09:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIOq-0004xd-Gi for geopriv@ietf.org; Fri, 28 Sep 2007 12:09:08 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbIOq-0004Qg-9j for geopriv@ietf.org; Fri, 28 Sep 2007 12:09:08 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 1BDEB2AC5E; Fri, 28 Sep 2007 16:08:38 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IbIOL-000236-Rq; Fri, 28 Sep 2007 12:08:37 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: mary.barnes@nortel.com From: IETF I-D Submission Tool Message-Id: Date: Fri, 28 Sep 2007 12:08:37 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Fri, 28 Sep 2007 13:28:15 -0400 Cc: geopriv@ietf.org, barbara.stark@bellsouth.com, james.winterbottom@andrew.com Subject: [Geopriv] New Version Notification for draft-ietf-geopriv-http-location-delivery-02 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org A new version of I-D, draft-ietf-geopriv-http-location-delivery-02.txt has been successfuly submitted by Mary Barnes and posted to the IETF repository. Filename: draft-ietf-geopriv-http-location-delivery Revision: 02 Title: HTTP Enabled Location Delivery (HELD) Creation_date: 2007-09-27 WG ID: geopriv Number_of_pages: 36 Abstract: A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol is an application-layer protocol that is independent of session- layer; an HTTP, web services binding is specified. The IETF Secretariat. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From baffles@andreusotorra.com Fri Sep 28 14:51:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKvu-0005To-6F for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 14:51:26 -0400 Received: from [89.156.107.171] (helo=089156107171.chello.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbKvo-0001PC-6Y for geopriv-archive@lists.ietf.org; Fri, 28 Sep 2007 14:51:22 -0400 Received: from [89.156.107.171] by mail.andreusotorra.com; Fri, 28 Sep 2007 19:33:02 +0100 From: "Iris Seals" To: Subject: Look like 1 million Date: Fri, 28 Sep 2007 19:33:02 +0100 Message-ID: <01c801fe$008c3a10$ab6b9c59@baffles> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Have you ever hoped to have a pricey Watch? We have the piece for you! We carry all the top quality for a very small precentage of the price. www.arriehuu.com From geopriv-bounces@ietf.org Fri Sep 28 17:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbMzR-0005Vs-4P; Fri, 28 Sep 2007 17:03:13 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbMzP-0005Ub-Qs for geopriv-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:03:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbMzP-0005Qn-G6 for geopriv@ietf.org; Fri, 28 Sep 2007 17:03:11 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbMzL-0006b0-7V for geopriv@ietf.org; Fri, 28 Sep 2007 17:03:07 -0400 X-SEF-Processed: 5_0_0_910__2007_09_28_16_12_46 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 28 Sep 2007 16:12:46 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 16:03:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv]I-D Action:draft-ietf-geopriv-http-location-delivery-02.txt Date: Fri, 28 Sep 2007 16:03:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]I-D Action:draft-ietf-geopriv-http-location-delivery-02.txt Thread-Index: AcgB6nxn7wFz08p3SM6uFwub+9tTtAAAt3cgAAlk6OA= References: From: "Winterbottom, James" To: "Mary Barnes" , X-OriginalArrivalTime: 28 Sep 2007 21:03:04.0254 (UTC) FILETIME=[F627F5E0:01C80212] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Thanks Mary.=0D=0A=0D=0A=0D=0A=0D=0A---------------------------------------= ---------------------------------------------------------=0D=0AThis message= is for the designated recipient only and may=0D=0Acontain privileged, prop= rietary, or otherwise private information. =20=0D=0AIf you have received it= in error, please notify the sender=0D=0Aimmediately and delete the origina= l. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------= ---------------------------------------------------------------------------= ----------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From meyrecxgum@amir.com Sat Sep 29 08:32:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbbUM-000268-R3 for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 08:32:06 -0400 Received: from host64-72-dynamic.17-87-r.retail.telecomitalia.it ([87.17.72.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbbUB-0002WU-AI for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 08:32:01 -0400 Received: from acer-tuy99xj2wa by amir.com with ASMTP id 016DAB69 for ; Sat, 29 Sep 2007 14:32:21 +0200 Received: from acer-tuy99xj2wa ([138.124.63.63]) by amir.com with ESMTP id 84DFCFC0C628 for ; Sat, 29 Sep 2007 14:32:21 +0200 Message-ID: <000301c80294$b40cc410$40481157@acertuy99xj2wa> From: "GABRIEL meyre" To: Subject: ittudhav Date: Sat, 29 Sep 2007 14:31:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C802A5.77980510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ------=_NextPart_000_0008_01C802A5.77980510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi To geopriv-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 ------=_NextPart_000_0008_01C802A5.77980510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi To geopriv-archive
Emergency report. Check DMXC!
Price up 21% in 30 minutes!
5 day price: ~$0.50
------=_NextPart_000_0008_01C802A5.77980510-- From samantha-Edis@achamo.net Sat Sep 29 09:07:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibc2M-0005pV-Ck for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 09:07:15 -0400 Received: from bya58.neoplus.adsl.tpnet.pl ([83.30.20.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibc2L-0008PH-Qg for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 09:07:14 -0400 Received: from stas ([150.191.3.152] helo=stas) by [83.30.20.58] ( sendmail 8.13.3/8.13.1) with esmtpa id 1jpvdt-000ZNY-oG for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 15:07:55 +0200 Message-ID: <000b01c80299$ac2273d0$3a141e53@stas> From: "samantha Edis" To: Subject: ourirait Date: Sat, 29 Sep 2007 15:07:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C802AA.6FAB43D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ------=_NextPart_000_0009_01C802AA.6FAB43D0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hi To geopriv-archive Emergency report. Check DMXC! Price up 21% in 30 minutes! 5 day price: ~$0.50 ------=_NextPart_000_0009_01C802AA.6FAB43D0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Hi To geopriv-archive
Emergency report. Check DMXC!
Price up 21% in 30 minutes!
5 day price: ~$0.50
------=_NextPart_000_0009_01C802AA.6FAB43D0-- From Raney@altopara.cz Sat Sep 29 10:09:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibd0U-0004yO-O5 for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 10:09:22 -0400 Received: from [83.168.75.9] (helo=[83.168.75.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ibd0T-0005y8-Cr for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 10:09:22 -0400 Received: from home-3799597d3d by altopara.cz with ASMTP id 39D44EEB for ; Sat, 29 Sep 2007 16:10:40 +0200 Received: from home-3799597d3d ([115.191.139.66]) by altopara.cz with ESMTP id 3E792BE4DAB0 for ; Sat, 29 Sep 2007 16:10:40 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 29 Sep 2007 16:10:29 +0200 To: geopriv-archive@lists.ietf.org From: "Raney derick" Subject: nedehdle Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Hi geopriv-archive Emergency report. Check DMXC! 5 day price: ~$0.50 From liasauers@anlagen.com.br Sat Sep 29 10:18:44 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibd9Y-0004VI-Ad for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 10:18:44 -0400 Received: from mvx-200-196-60-71.mundivox.com ([200.196.60.71]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ibd9M-000446-4w for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 10:18:32 -0400 Received: by 10.239.165.18 with SMTP id KiKMEZkngxgSP; Sat, 29 Sep 2007 11:18:34 -0300 (GMT) Received: by 192.168.100.130 with SMTP id OkgIyNdmZuBpXf.4512113657361; Sat, 29 Sep 2007 11:18:32 -0300 (GMT) Date: Sat, 29 Sep 2007 11:18:29 -0300 From: "lia sauers" Reply-To: "lia sauers" Message-ID: <148434090709.841420524135@anlagen.com.br> To: Subject: tomomihs MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 4.4 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Hi geopriv-archive Emergency report. Check DMXC! 5 day price: ~$0.50 From geopriv-bounces@ietf.org Sat Sep 29 16:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibj7P-0007Xw-3A; Sat, 29 Sep 2007 16:40:55 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1Ibj7O-0007Xq-Ky for geopriv-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 16:40:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibj7O-0007G5-BM for geopriv@ietf.org; Sat, 29 Sep 2007 16:40:54 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ibj7B-0001rf-4o for geopriv@ietf.org; Sat, 29 Sep 2007 16:40:47 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8TKe0U12323; Sat, 29 Sep 2007 20:40:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] GC Comments on draft-ietf-geopriv-http-location-delivery-01.txt Date: Sat, 29 Sep 2007 15:37:56 -0500 Message-ID: In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30AFE184E@toroondc912> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GC Comments on draft-ietf-geopriv-http-location-delivery-01.txt Thread-Index: AcfEqJY2vYEEHK0pTX+StZhhluVtXwJWuhSQDTQuUCA= References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30AFE184E@toroondc912> From: "Mary Barnes" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Hi Guy, Again, apologies for never having responded to these comments. = Responses are embedded below [MB]. =20 Thanks, Mary.=20 -----Original Message----- From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 Sent: Tuesday, July 24, 2007 3:20 PM To: Barnes, Mary (RICH2:AR00); geopriv@ietf.org Subject: RE: [Geopriv] GC Comments on = draft-ietf-geopriv-http-location-delivery-01.txt Hi Mary, Hi geopriv, Please find below a few comments after reviewing this document. They are = tagged as "Editorial" or "Technical". >From a general point of view, I think the basic functions for location = acquisition are well captured with this draft. Since a lot of the comments have been provided already by other = reviewers, my list is rather short. Note well: My comments are influenced by the nature of my interests: = Emergency services. Section by section comments: Abstract: c1. The last sentence doesn't read right. Either add "the" = before "session-layer" or an "s" at "layer". I would replace the = semi-colon by a period after "layer". [MB] Agreed. I'll break that into two sentences (i.e., replace the = semi-colon).=20 Section 7 - Protocol Paramaters c2. Table 1: The "expires" parameter should be labeled = "conditional" instead of "mandatory" as it is only relevant in presence = of the LocationURI parameter. If accepted, the term "conditional" should = be added to the paragraph just above the table. [MB] I'll just note that it is optional (I'm reluctant to add that = "conditional" concept although it applies based on past experiences with = tables that try to include too much info - there's one of those in SIP = that always causes grief) and update the text appropriately (i.e., I = think it's more important the text be accurate), so I'll add something = like the following to section 6.5.1: OLD: The "expires" attribute indicates the time at which the Location URI provided by the LIS will expire. This attribute is included in the "locationResponse" message only. NEW: The "expires" attribute is optional and is only included in a = "locationResponse" message when a Location URI is included. The "expires" attribute indicates = the time at which the=20 Location URI provided by the LIS will expire.=20 [/MB] =20 Section 7.1 - "responseTime" Parameter c3. 1st para., 1st sentence: Replace "attribute" by = "parameter". [MB] Okay. c4. "If this parameter is absent, then the LCS MUST return = the most precise LI it is capable of determining". I find this statement = a bit confusing. Should I read this as, when the parameter is absent, = the LCS will provide the most precise LI available at this very moment = (not waiting for any LI computing at all) so possibly a coarse location? = This is what I want but I'm not sure the text exactly says that (it may = be completely the reverse actually). [MB] If I've accurately interpreted the conclusion to the responseTime = debate, it should be the "most precise at that point in time". Is = everyone okay with adding that clarification to the text? [/MB] Section 7.2.1 - "exact" Attribute My assumption here is that the device does not have prior knowledge of = which application the LI will be eventually used for. [MB] Again, based on my understanding of the conclusion/consensus to the = responseTime debate, I think the device does have prior knowledge of = which appliation the LI will be eventually used for (at least in the = case of Emergency Services), per the addition of that service type to = the responseTime. [/MB] c5. Should a statement be added to cover the following case: = When only one specific LocationType is requested (exact=3Dtrue), the LCS = SHOULD return location information in THE form that is suited for = routing and responding to an emergency call in its jurisdiction even if = different than the one requested? [MB] That's been done with the -02 changes. [/MB] Alternatively, should a caveat be added to the use of this attribute = stating it could impede the routing of emergency calls? Section 7.3 - "code" Parameter c6. 2nd par., 1st sentence: I suggest replacing "error" by = "code". This would allow including "success" in the list of valid = responses (success is not an error code). [MB] Per the -02, the error processing has been separated from a normal = response, thus "success" has been removed. [/MB] The assumption for my comments in this section hereinafter is that all = defined error codes will result in no LI being provided to the Device. c7. Should the timeout error code by accompanied with an = "expected time" for a successful response? What I would like to avoid is having a Device location-less when this = information is required for emergency situations. [MB] I'm hoping that the resolution to "responseTime" and having an = indicator for emergency situations resolves this concern. If not, = please let us know. [/MB] c8. Considering comment #c5 above, would it be seen helpful = to have the cannotProvideLiType error response by accompanied with a = list of available LocationType(s)? At least, this would give a hint to = the device as to what to do next. [MB] I think this comment relates to a point of discussion in Chicago = where we had been proposing to include a list of locationTypes included = in a response. There did not seem to be interest in doing that and if = we were to do that, I think it would facilitate the functionality you're = asking for. However, it would seem that this functionality is only = useful in the case of "exact". And, it's not clear to me, in that case, = why knowing what ones are available would be useful. It would seem that = if that information is useful, then a device would just request all the = types that it might be able to use and not use "exact". Or perhaps I'm = missing your point altogether and we should discuss this one further? = [/MB] Section 9 - HTTP Binding c9. "This binding MUST use TLS...".Shall I risk asking to = soften this requirement a bit to a "RECOMMEND"? My motivation is that, = under very specific implementation of trusted network nodes and private, = secure network links, TLS may not be required. Consider an Enterprise = running its LCS over its private LAN. Here is suggested wording: "This = binding MUST use a secure mean of transporting data between the endpoint = and the LCS. The use TLS is RECOMMENDED." [MB] My understanding is that the MUST is a MUST implement and certainly = doesn't preclude the situation you describe. I don't have problem with = the rewording you suggest, if that doesn't cause anyone else grief = (i.e., I do think your suggestion captures the spirit of the MUST = implement). Although, the caveat is that my experience with the = security sections (and this text being okay) might be dated (i.e., it's = been a couple years since I got a doc approved with similar wording. = [/MB] Section 10.2 - Transaction Layer Security c10. Same comment = as #c9 above for the HTTP binding. [MB] Ditto, my comment above. I can make the proposed change, unless = someone sees an issue. [/MB] Section Appendix A - HELD Compliance to IETF LCP requirements c11. = The whole appendix seems to refer to an older version of the = LCP requirements document (prior to -02). The requirements' text should = be updated. [MB] This has been addressed in the -02. [/MB] That's it. Best regards! Guy Caron -----Message d'origine----- De=A0: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] = Envoy=E9=A0: 12 juillet 2007 13:17 =C0=A0: i-d-announce@ietf.org Cc=A0: = geopriv@ietf.org Objet=A0: [Geopriv] = I-DACTION:draft-ietf-geopriv-http-location-delivery-01.txt=20 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 : HTTP Enabled Location Delivery (HELD) Author(s) : M. Barnes Filename : draft-ietf-geopriv-http-location-delivery-01.txt Pages : 37 Date : 2007-7-12 =09 A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol supports mobile and nomadic devices through Location URIs. The protocol is an application-layer protocol that is independent of session-layer; an HTTP, web services binding is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-deli= very-01.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get = draft-ietf-geopriv-http-location-delivery-01.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE = /internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sat Sep 29 17:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbjYu-0004Ee-Rk; Sat, 29 Sep 2007 17:09:20 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IbjYt-0004BF-QX for geopriv-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 17:09:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbjYt-0004B6-Fj for geopriv@ietf.org; Sat, 29 Sep 2007 17:09:19 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbjYt-0007Hg-1c for geopriv@ietf.org; Sat, 29 Sep 2007 17:09:19 -0400 X-SEF-Processed: 5_0_0_910__2007_09_29_16_18_59 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 29 Sep 2007 16:18:59 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Sep 2007 16:09:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] GC Comments ondraft-ietf-geopriv-http-location-delivery-01.txt Date: Sat, 29 Sep 2007 16:09:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] GC Comments ondraft-ietf-geopriv-http-location-delivery-01.txt Thread-Index: AcfEqJY2vYEEHK0pTX+StZhhluVtXwJWuhSQDTQuUCAAAaTToA== References: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30AFE184E@toroondc912> From: "Winterbottom, James" To: "Mary Barnes" , , X-OriginalArrivalTime: 29 Sep 2007 21:09:16.0608 (UTC) FILETIME=[FE826C00:01C802DC] X-Spam-Score: 1.8 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org Inline.=0D=0A=0D=0AText sections not commented on have been trimmed=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A> Section 7.1 - "responseTime" Parameter=0D= =0A> c3. 1st para., 1st sentence: Replace "attribute" by=0D=0A>= "parameter".=0D=0A> [MB] Okay.=0D=0A>=0D=0A[AJW] Technically attribute is = correct.=0D=0A=0D=0A=20=0D=0A> c4. "If this parameter is absent= , then the LCS MUST return=0D=0Athe=0D=0A> most precise LI it is capable of= determining". I find this statement a=0D=0Abit=0D=0A> confusing. Should I = read this as, when the parameter is absent, the=0D=0ALCS=0D=0A> will provid= e the most precise LI available at this very moment (not=0D=0A> waiting for= any LI computing at all) so possibly a coarse location=3F=0D=0AThis=0D=0A>= is what I want but I'm not sure the text exactly says that (it may be=0D=0A= > completely the reverse actually).=0D=0A> [MB] If I've accurately interpre= ted the conclusion to the responseTime=0D=0A> debate, it should be the "mos= t precise at that point in time". Is=0D=0A> everyone okay with adding that= clarification to the text=3F [/MB]=0D=0A=0D=0A=0D=0A[AJW] That is not the = intent no. The LIS will determine and provide the=0D=0Amost accurate locati= on that it can, and that may require a wait.=0D=0A=0D=0A=0D=0A>=20=0D=0A> S= ection 9 - HTTP Binding=0D=0A> c9. "This binding MUST use TLS..= =2E".Shall I risk asking to=0D=0A> soften this requirement a bit to a "RECO= MMEND"=3F My motivation is that,=0D=0A> under very specific implementation = of trusted network nodes and=0D=0Aprivate,=0D=0A> secure network links, TLS= may not be required. Consider an Enterprise=0D=0A> running its LCS over it= s private LAN. Here is suggested wording: "This=0D=0A> binding MUST use a s= ecure mean of transporting data between the=0D=0Aendpoint=0D=0A> and the LC= S. The use TLS is RECOMMENDED."=0D=0A> [MB] My understanding is that the MU= ST is a MUST implement and=0D=0Acertainly=0D=0A> doesn't preclude the situa= tion you describe. I don't have problem=0D=0Awith=0D=0A> the rewording you= suggest, if that doesn't cause anyone else grief=0D=0A(i.e.,=0D=0A> I do t= hink your suggestion captures the spirit of the MUST implement).=0D=0A> Alt= hough, the caveat is that my experience with the security sections=0D=0A(an= d=0D=0A> this text being okay) might be dated (i.e., it's been a couple yea= rs=0D=0Asince=0D=0A> I got a doc approved with similar wording. [/MB]=0D=0A= >=0D=0A[AJW] I would prefer that we explicitly say MUST implement if we are=0D= =0Agoing to change wording here.=0D=0A=0D=0A=20=0D=0A=0D=0A----------------= ---------------------------------------------------------------------------= -----=0D=0AThis message is for the designated recipient only and may=0D=0Ac= ontain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From Laircglzz@adventurebeyond.co.uk Sat Sep 29 20:07:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbmLI-000558-N9 for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 20:07:28 -0400 Received: from host151-7-dynamic.9-79-r.retail.telecomitalia.it ([79.9.7.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbmLD-0001XC-OU for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 20:07:24 -0400 Received: from puppalsu-ntoumi by adventurebeyond.co.uk with ASMTP id A78D79FD for ; Sun, 30 Sep 2007 02:11:53 +0200 Received: from puppalsu-ntoumi ([192.121.44.10]) by adventurebeyond.co.uk with ESMTP id 0B3A6FBC319D for ; Sun, 30 Sep 2007 02:11:53 +0200 Message-ID: <000701c802f6$78b86560$9707094f@puppalsuntoumi> From: "hantu Lair" To: Subject: ninniotl Date: Sun, 30 Sep 2007 02:11:39 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C80307.3C43A660" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0007_01C80307.3C43A660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello geopriv-archive Urgent alert. Look at DM XC! 5-day price: ~$0.50 Get it at monday nindnstu nim|rtsd nineband nimointi ------=_NextPart_000_0007_01C80307.3C43A660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello geopriv-archive
Urgent alert.
Look at DM XC!
5-day price: ~$0.50
Get it at monday
nindnstu
nim|rtsd
nineband
nimointi
------=_NextPart_000_0007_01C80307.3C43A660-- From franky-Primeaux@getsuyokan.com Sat Sep 29 21:58:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibo4e-0004OS-VQ for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 21:58:24 -0400 Received: from m117.net81-65-70.noos.fr ([81.65.70.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ibo4V-0005FR-JZ for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 21:58:21 -0400 Received: by 10.92.11.56 with SMTP id ZtdbpSLXkAYEQ; Sun, 30 Sep 2007 03:55:36 +0200 (GMT) Received: by 192.168.0.25 with SMTP id tzyHVDfSsWdYSW.4708745944984; Sun, 30 Sep 2007 03:55:34 +0200 (GMT) Date: Sun, 30 Sep 2007 03:55:31 +0200 From: "franky Primeaux" Reply-To: "franky Primeaux" Message-ID: <430744410973.546629387799@getsuyokan.com> To: Subject: pihsawhs MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 3.9 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Hello geopriv-archive Urgent alert. Look at DM XC! 5-day price: ~$0.50 Get it at monday peterpen pimeiksi pitakgna 'pigones From baggies@achievement-center.org Sat Sep 29 22:33:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbocL-0003Rx-T0 for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 22:33:13 -0400 Received: from [220.179.114.114] (helo=[220.179.114.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbocD-0005tl-TJ for geopriv-archive@lists.ietf.org; Sat, 29 Sep 2007 22:33:07 -0400 Received: from [220.179.114.114] by mail.deltacom.net; , 30 Sep 2007 10:14:30 +0800 From: "Alisha Byers" To: Subject: Alisha has sent you a message Date: , 30 Sep 2007 10:14:30 +0800 Message-ID: <01c80307$a24b7e10$7272b3dc@baggies> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Importance: Normal X-Spam-Score: 1.8 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 SCYF Wins $1 Million Contract With Alabama State! Security Financing Services Inc. SCYF $0.011 The security contract for Alabama State University has been awarded to SCYF. Share prices are going to rocket. Monday opening bell will be the day to get all over SCYF. From Earnestboukhriss@florida-pneumatic.com Sun Sep 30 08:55:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbyKz-0003uZ-0i for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 08:55:57 -0400 Received: from n22z164l48.broadband.ctm.net ([202.86.164.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbyKt-0003Gn-9E for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 08:55:51 -0400 Received: from vaio-a ([181.119.170.147] helo=vaio-a) by [202.86.164.48] ( sendmail 8.13.3/8.13.1) with esmtpa id 1cyRey-000KOG-Cg for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 20:56:18 +0800 Message-ID: <000801c80361$350d8a50$30a456ca@vaioa> From: "Earnest boukhriss" To: geopriv-archive@lists.ietf.org Subject: mojmir Date: Sun, 30 Sep 2007 20:55:41 +0800 Message-ID: <000801c80361$350d8a50$30a456ca@vaioa> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Good day geopriv-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 monstero mmheiten monaxo mokop From gianlucakristian@bluecord.co.kr Sun Sep 30 11:43:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic0wl-00068p-6L for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 11:43:07 -0400 Received: from cablelink45-253.telefonia.intercable.net ([201.172.45.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic0wc-0008Mp-UI for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 11:43:05 -0400 Received: from p4 ([111.100.162.114] helo=p4) by cablelink45-253.telefonia.intercable.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1KfNVR-000YIP-tP for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 10:40:06 -0700 Message-ID: <000501c80388$e7a895c0$fd2dacc9@p4> From: "gianluca kristian" To: Subject: suoitipo Date: Sun, 30 Sep 2007 10:39:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C8034E.3B49BDC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0004_01C8034E.3B49BDC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day geopriv-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 sugalotc succino- styltete subekuku ------=_NextPart_000_0004_01C8034E.3B49BDC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good day geopriv-archive
Alert to all investors!
Look at D-M-X-C!
5-day price: ~$0.50
Check it at 31.09.2007
sugalotc
succino-
styltete
subekuku
------=_NextPart_000_0004_01C8034E.3B49BDC0-- From pareshLofqvist@icecreations.tv Sun Sep 30 14:59:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic40x-0005Oz-8C for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 14:59:39 -0400 Received: from [77.202.229.214] (helo=[77.202.229.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic40i-0006dZ-Bz for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 14:59:27 -0400 Received: from famille ([176.168.94.185]:5653 "EHLO famille" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [77.202.229.214] with ESMTP id S22KXOKJIGOCRMCH (ORCPT ); Sun, 30 Sep 2007 20:59:36 +0200 Message-ID: <000c01c80393$fa716370$d6e5ca4d@famille> From: "paresh Lofqvist" To: Subject: llivkcas Date: Sun, 30 Sep 2007 20:59:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C803A4.BDFA3370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 000777-4, 30/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 ------=_NextPart_000_0007_01C803A4.BDFA3370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day geopriv-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 llineerg l-ocnarf llivnnud lleum ------=_NextPart_000_0007_01C803A4.BDFA3370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good day geopriv-archive
Alert to all investors!
Look at D-M-X-C!
5-day price: ~$0.50
Check it at 31.09.2007
llineerg
l-ocnarf
llivnnud
lleum
------=_NextPart_000_0007_01C803A4.BDFA3370-- From marcevski@bumev.de Sun Sep 30 19:58:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic8fr-0002ZV-NQ for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 19:58:11 -0400 Received: from bgd76-1-82-233-215-137.fbx.proxad.net ([82.233.215.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ic8fh-0008D4-4z for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 19:58:01 -0400 Received: from TEST2 by bumev.de with ASMTP id DD867A04 for ; Mon, 1 Oct 2007 02:00:14 +0200 Received: from TEST2 ([123.129.169.53]) by bumev.de with ESMTP id 46C4E849111D for ; Mon, 1 Oct 2007 02:00:14 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 1 Oct 2007 01:59:35 +0200 To: geopriv-archive@lists.ietf.org From: "Rosanlinda marcevski" Subject: mistic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Antivirus: avast! (VPS 000777-4, 30/09/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Good day geopriv-archive Alert to all investors! Look at D-M-X-C! 5-day price: ~$0.50 Check it at 31.09.2007 misui minutiou mmusepjk mitsusek From geopriv-bounces@ietf.org Sun Sep 30 21:30:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcA6C-0000DJ-4w; Sun, 30 Sep 2007 21:29:28 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IcA6B-00007x-0e for geopriv-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 21:29:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcA6A-00007p-Mj for geopriv@ietf.org; Sun, 30 Sep 2007 21:29:26 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcA6A-0001Yy-EY for geopriv@ietf.org; Sun, 30 Sep 2007 21:29:26 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 10CB1175C5; Mon, 1 Oct 2007 01:28:56 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IcA5f-0000yA-IZ; Sun, 30 Sep 2007 21:28:55 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: james.winterbottom@andrew.com From: IETF I-D Submission Tool Message-Id: Date: Sun, 30 Sep 2007 21:28:55 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: geopriv@ietf.org Subject: [Geopriv] New Version Notification for draft-ietf-geopriv-pdif-lo-profile-09 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org A new version of I-D, draft-ietf-geopriv-pdif-lo-profile-09.txt has been successfuly submitted by James Winterbottom and posted to the IETF repository. Filename: draft-ietf-geopriv-pdif-lo-profile Revision: 09 Title: GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations Creation_date: 2007-10-01 WG ID: geopriv Number_of_pages: 31 Abstract: The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that is mandatory to implement by applications involved in location based routing. The IETF Secretariat. _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv From geopriv-bounces@ietf.org Sun Sep 30 21:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcA7G-0002VG-5X; Sun, 30 Sep 2007 21:30:34 -0400 Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IcA7F-0002RZ-5Z for geopriv-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 21:30:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcA7E-0002RL-QE; Sun, 30 Sep 2007 21:30:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcA7E-0001aA-D7; Sun, 30 Sep 2007 21:30:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 1174E175C5; Mon, 1 Oct 2007 01:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IcA6j-0003ET-Jd; Sun, 30 Sep 2007 21:30:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 30 Sep 2007 21:30:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-pdif-lo-profile-09.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: geopriv-bounces@ietf.org --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 : GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations Author(s) : J. Winterbottom, et al. Filename : draft-ietf-geopriv-pdif-lo-profile-09.txt Pages : 31 Date : 2007-09-30 The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that is mandatory to implement by applications involved in location based routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-pdif-lo-profile-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-geopriv-pdif-lo-profile-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-30212853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-geopriv-pdif-lo-profile-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-geopriv-pdif-lo-profile-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-30212853.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv --NextPart-- From balkus@hospitalposadas.org.ar Sun Sep 30 22:30:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcB2w-00087G-RA for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 22:30:10 -0400 Received: from ppp-58.8.91.123.revip2.asianet.co.th ([58.8.91.123] helo=codename) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcB2u-0008Qu-PI for geopriv-archive@lists.ietf.org; Sun, 30 Sep 2007 22:30:10 -0400 Received: from [58.8.91.123] by mail.hospitalposadas.org.ar; Mon, 31 Sep 2007 09:11:24 +0700 Date: Mon, 31 Sep 2007 09:11:24 +0700 From: "Gerard Harris" X-Mailer: The Bat! (v2.10.01) Educational Reply-To: balkus@hospitalposadas.org.ar X-Priority: 3 (Normal) Message-ID: <802265676.34650897271930@hospitalposadas.org.ar> To: geopriv-archive@lists.ietf.org Subject: Recipet #53127978 MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Alabama State University Awards SCYF $1 Million Contract! Security Financing Services Inc. S C Y F $0.011 Alabama State awards a million dollar security contract to SCYF. Share prices are going to rocket. Don’t miss out on this one and grab SCYF first thing Monday morning.