From geopriv-bounces@ietf.org Fri Sep 01 14:45:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GJE0s-0001LH-Cx; Fri, 01 Sep 2006 14:45:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GJE0q-0001L0-EF; Fri, 01 Sep 2006 14:45:08 -0400
Received: from cdx28.winwebhosting.com ([70.85.255.82])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GJE0p-0002Os-3K; Fri, 01 Sep 2006 14:45:08 -0400
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp)
by cdx28.winwebhosting.com with esmtpa (Exim 4.52)
id 1GJE0f-0001nb-8X; Fri, 01 Sep 2006 13:44:57 -0500
From: "Brian Rosen"
To: "'GEOPRIV'" ,
"'Ecrit@Ietf.Org'"
Date: Fri, 1 Sep 2006 14:44:59 -0400
Message-ID: <073201c6cdf6$bce4adb0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0733_01C6CDD5.35D30DB0"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Thread-Index: AcbNN2ni6DSEKWv4QG6zY2iLRkoRxwAvteOA
X-PopBeforeSMTPSenders: br@brianrosen.net,brosen
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - cdx28.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: 2857c5c041d6c02d7181d602c22822c8
Cc:
Subject: [Geopriv] FW: I-D ACTION:draft-ietf-sip-location-conveyance-04.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
This is a multi-part message in MIME format.
------=_NextPart_000_0733_01C6CDD5.35D30DB0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Note that we have released a new version of location conveyance.
This edition has some significant changes and rewrites. Your comments would
be appreciated.
-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Thursday, August 31, 2006 3:50 PM
To: i-d-announce@ietf.org
Cc: sip@ietf.org
Subject: I-D ACTION:draft-ietf-sip-location-conveyance-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Session Initiation Protocol Working Group
of the IETF.
Title : Session Initiation Protocol Location Conveyance
Author(s) : J. Polk, B. Rosen
Filename : draft-ietf-sip-location-conveyance-04.txt
Pages : 27
Date : 2006-8-31
This document defines an extension to the Session Initiation
Protocol (SIP) to convey geographic location information from one
SIP entity to another SIP entity. The extension covers end to end
conveyance as well as location-based routing, where proxy servers
make routing decisions based on the location of the UAC.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-04.tx
t
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-sip-location-conveyance-04.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-sip-location-conveyance-04.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_000_0733_01C6CDD5.35D30DB0
Content-Type: Message/External-body;
name="ATT01296.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="ATT01296.dat"
Content-Type: text/plain
Content-ID: <2006-8-31105138.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-sip-location-conveyance-04.txt
------=_NextPart_000_0733_01C6CDD5.35D30DB0
Content-Type: Message/External-body;
name="draft-ietf-sip-location-conveyance-04.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="draft-ietf-sip-location-conveyance-04.txt"
Content-Type: text/plain
Content-ID: <2006-8-31105138.I-D@ietf.org>
------=_NextPart_000_0733_01C6CDD5.35D30DB0
Content-Type: text/plain;
name="ATT01299.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="ATT01299.txt"
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
------=_NextPart_000_0733_01C6CDD5.35D30DB0
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_000_0733_01C6CDD5.35D30DB0--
From geopriv-bounces@ietf.org Fri Sep 01 14:57:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GJED6-0003PG-3A; Fri, 01 Sep 2006 14:57:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1GJED4-0003P4-GR
for geopriv@ietf.org; Fri, 01 Sep 2006 14:57:46 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJED3-00036e-9W
for geopriv@ietf.org; Fri, 01 Sep 2006 14:57:46 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
by rtp-iport-1.cisco.com with ESMTP; 01 Sep 2006 11:57:45 -0700
X-IronPort-AV: i="4.08,201,1154934000";
d="scan'208"; a="39532672:sNHT31449400"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
k81IviVU014321; Fri, 1 Sep 2006 14:57:44 -0400
Received: from [68.50.22.220] (rtp-vpn2-307.cisco.com [10.82.241.51])
by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k81IvidM016560;
Fri, 1 Sep 2006 14:57:44 -0400 (EDT)
In-Reply-To: <44F739DE.9050005@gmx.net>
References: <44F4A254.6080404@gmx.net>
<93b35a0ab7a80228e1c8a66b4d666b43@cisco.com>
<44F70D37.9050308@hxr.us> <44F739DE.9050005@gmx.net>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id:
Content-Transfer-Encoding: 7bit
From: John Schnizlein
Subject: Re: [Geopriv] draft-tschofenig-geopriv-l7-lcp-ps-02.txt
Date: Fri, 1 Sep 2006 14:57:51 -0400
To: Hannes Tschofenig
X-Mailer: Apple Mail (2.624)
DKIM-Signature: a=rsa-sha1; q=dns; l=1405; t=1157137064; x=1158001064;
c=relaxed/simple; s=rtpdkim1001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=jschnizl@cisco.com;
z=From:John=20Schnizlein=20
|Subject:Re=3A=20[Geopriv]=20draft-tschofenig-geopriv-l7-lcp-ps-02.txt
|To:Hannes=20Tschofenig=20;
X=v=3Dcisco.com=3B=20h=3DUEZVe5yFOARdP53sVLFFmHZjXio=3D;
b=q+XqLLvAdJ1/KZ0T5w1PTyQRMRd9hQ4znQGc+4UEf/gO9S725tW4TKrTlCCqxnpLJYpqUTYj
DesDXHT3/drmNWiCeDcEeeUPNbBIv94RaMa3T9LbWbtsasCjI5bkcW/e;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=jschnizl@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: GEOPRIV , Andrew Newton
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 Aug 31, 2006, at 3:34 PM, Hannes Tschofenig wrote:
> Andrew Newton schrieb:
>> John Schnizlein wrote:
>>> The goal of the document stated in the abstract is correct: "a
>>> problem statement and lists requirements for a GEOPRIV Layer 7
>>> Location Configuration Protocol". From the Dallas minutes: "Jon
>>> Peterson proposed that a document specifying the requirements for a
>>> layer 7 location configuration or sighting protocol be developed in
>>> order to facilitate a proper discussion." However, this document
>>> does not identify requirements (if any) for a Layer-seven location
>>> retrieval protocol. Instead it appears to assume a hypothetical
>>> protocol is required and discusses characteristics of such a
>>> protocol. It does not answer the questions: What problem would a
>>> layer-7 protocol solve? Why are other methods inadequate to solve
>>> that problem?
>> I can't answer all the questions you just asked, but I will answer
>> one of them. The layer 7 protocol to dereference a location
>> reference and the layer 7 protocol to hand out a location reference
>> do not have to be the same.
>
> John: Do you got the impression that this is the case?
> To avoid confusion I actually stated it in the document. See text
> below Figure 4.
No, Hannes, neither of my two questions here has anything to do with
dereferencing.
John
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Fri Sep 01 15:08:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GJEMy-0002Lg-Nk; Fri, 01 Sep 2006 15:08:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GJEMx-0002LQ-MT; Fri, 01 Sep 2006 15:07:59 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GJEMu-0003cm-2C; Fri, 01 Sep 2006 15:07:59 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
by sj-iport-6.cisco.com with ESMTP; 01 Sep 2006 12:07:55 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
k81J7tYR013647; Fri, 1 Sep 2006 12:07:55 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
[171.70.151.144])
by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k81J7t1E009745;
Fri, 1 Sep 2006 12:07:55 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 1 Sep 2006 12:07:55 -0700
Received: from jmpolk-wxp.cisco.com ([10.21.89.71]) by
xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 1 Sep 2006 12:07:54 -0700
Message-Id: <4.3.2.7.2.20060901135912.0368bbf0@email.cisco.com>
X-Sender: jmpolk@email.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 01 Sep 2006 14:07:53 -0500
To: "'GEOPRIV'" , "'Ecrit@Ietf.Org'"
From: "James M. Polk"
In-Reply-To: <073201c6cdf6$bce4adb0$640fa8c0@cis.neustar.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 01 Sep 2006 19:07:54.0885 (UTC)
FILETIME=[EDEBEB50:01C6CDF9]
DKIM-Signature: a=rsa-sha1; q=dns; l=4909; t=1157137675; x=1158001675;
c=relaxed/simple; s=sjdkim3002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=jmpolk@cisco.com;
z=From:=22James=20M.=20Polk=22=20
|Subject:draft-ietf-sip-location-conveyance-04.txt=20;
X=v=3Dcisco.com=3B=20h=3DNipG362oGES9fSFsrOiAHLInSUs=3D;
b=HobKlfx1vUJ8RKvYo5OnXfvN6VwFaGOnppkjVMwUgLv2cf//i910PPZcoihoHl6LqkVpT2S9
mH0og+aHdjDMk4UKkpDAz5erXlWz8bjEAotffpTMduHf8Se9C+Gqo9zO;
Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc:
Subject: [Geopriv] draft-ietf-sip-location-conveyance-04.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
Here is a highlevel list of the changes that have been made from the SIP WG
version -03 to this version -04:
- removed the inappropriate 2119 language from the Requirements section
(which is now an appendix in the back, but will stay in the final version
as a point of history of the doc)
- removed the old Section 2., which was a "Location in a header vs. in
a body" artifact from the original versions of the document. That subject
is no longer current.
- Added a new Geopriv (or Privacy) Considerations section, and
interwove critical to know Geopriv points into the Intro
- Changed the ABNF to reflect discussion on how restrictive the
location-by-reference schemes should be, with an added "Editor's Note"
discussing the issues being faced on this point.
- Changed the "Location" header and option-tag to "Geolocation" header
and option-tag, due to it being pointed out that there is a conflicting
HTTP header called "Location".
- Added a new element to PIDF-LO 'routing-query-allowed', which will
"update" RFC 4119
- Stipulated the Reason Header can be used in the 424 Response Message.
This is allowed in 3326, but not normally how Reason is used.
- added SUBSCRIBE and NOTIFY as Methods for location conveyance when
used to dereference a sip:, sips: or pres: location-by-reference URI
- Added OPTIONS Method for a UAC to request the location of a UAS with
a Require header geolocation option-tag.
At 02:44 PM 9/1/2006 -0400, Brian Rosen wrote:
>Note that we have released a new version of location conveyance.
>
>This edition has some significant changes and rewrites. Your comments would
>be appreciated.
>
>-----Original Message-----
>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>Sent: Thursday, August 31, 2006 3:50 PM
>To: i-d-announce@ietf.org
>Cc: sip@ietf.org
>Subject: I-D ACTION:draft-ietf-sip-location-conveyance-04.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Session Initiation Protocol Working Group
>of the IETF.
>
> Title : Session Initiation Protocol Location Conveyance
> Author(s) : J. Polk, B. Rosen
> Filename : draft-ietf-sip-location-conveyance-04.txt
> Pages : 27
> Date : 2006-8-31
>
>This document defines an extension to the Session Initiation
> Protocol (SIP) to convey geographic location information from one
> SIP entity to another SIP entity. The extension covers end to end
> conveyance as well as location-based routing, where proxy servers
> make routing decisions based on the location of the UAC.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-04.tx
>t
>
>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-sip-location-conveyance-04.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-sip-location-conveyance-04.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.
>Content-Type: text/plain
>Content-ID: <2006-8-31105138.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-sip-location-conveyance-04.txt
>Content-Type: text/plain
>Content-ID: <2006-8-31105138.I-D@ietf.org>
>
>
>_______________________________________________
>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 Sun Sep 03 03:44:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GJmeJ-0000eT-Ij; Sun, 03 Sep 2006 03:44:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1GJmeH-0000bx-N1
for geopriv@ietf.org; Sun, 03 Sep 2006 03:44:09 -0400
Received: from cs.columbia.edu ([128.59.16.20])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJmZm-0001J8-BN
for geopriv@ietf.org; Sun, 03 Sep 2006 03:39:32 -0400
Received: from bear.cs.columbia.edu
(IDENT:uMIFkdqA1tXPqRfTOKjf8hKdf3VQxnry@bear.cs.columbia.edu
[128.59.16.121])
by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k837dQGb022651
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT)
for ; Sun, 3 Sep 2006 03:39:27 -0400 (EDT)
Received: from [128.59.23.96] (vs2140pc.cs.columbia.edu [128.59.23.96])
(authenticated bits=0)
by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k837dQbI004997
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
for ; Sun, 3 Sep 2006 03:39:26 -0400
Message-ID: <44FA86A6.3030805@cs.columbia.edu>
Date: Sun, 03 Sep 2006 03:39:18 -0400
From: Vishal Kumar Singh
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: geopriv@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu
X-Spam-Score: 0.5 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [Geopriv] Draft for dynamic feature extensions to 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
Hello All,
We have submitted a new Internet-draft:
Dynamic Feature Extensions to the Presence Information Data Format
Location Object (PIDF-LO).
The draft is currently available at:
http://www1.cs.columbia.edu/~vs2140/presence/dynamicFeatures/draft-singh-geopriv-pidf-lo-dynamic-00.txt
Please find the abstract below:
The Geopriv Location Object introduced by the Presence Information
Data Format Location Object (PIDF-LO), RFC 4119, defines a basic XML
format for carrying geographical information of a presentity. This
document extends the element specified in RFC 4119 to carry
temporal feature elements useful for tracking moving objects.
It defines four elements, namely speed, bearing, acceleration, and
elevation. The document also specifies mechanism to carry multiple
moving object's status elements and proposes mechanism to indicate the
type of the PIDF-LO content.
Please send your comments.
Regards,
Vishal
--
Not everything that can be counted counts, and not everything that
counts can be counted.
-By Albert Einstein
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Thu Sep 07 13:44:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLNv4-0005ks-Sb; Thu, 07 Sep 2006 13:44:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1GLNv3-0005ki-SJ
for geopriv@ietf.org; Thu, 07 Sep 2006 13:44:05 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GLNv2-0002TN-KB
for geopriv@ietf.org; Thu, 07 Sep 2006 13:44:05 -0400
Received: (qmail invoked by alias); 07 Sep 2006 17:44:02 -0000
Received: from p54985A1A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.90.26]
by mail.gmx.net (mp038) with SMTP; 07 Sep 2006 19:44:02 +0200
X-Authenticated: #29516787
Message-ID: <45005A61.4000609@gmx.net>
Date: Thu, 07 Sep 2006 19:44:01 +0200
From: Hannes Tschofenig
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: ECRIT , GEOPRIV
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc:
Subject: [Geopriv] RFC 3825 & draft-ietf-geopriv-dhcp-civil-09.txt
Implementation?
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,
who has implemented RFC 3825 and/or draft-ietf-geopriv-dhcp-civil-09.txt?
Is there open source code available?
Ciao
Hannes
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Fri Sep 08 14:11:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLkoK-0008Fj-Ou; Fri, 08 Sep 2006 14:10:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLkoI-0008DJ-EY; Fri, 08 Sep 2006 14:10:38 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GLkoB-0004Lp-TV; Fri, 08 Sep 2006 14:10:38 -0400
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
by sj-iport-5.cisco.com with ESMTP; 08 Sep 2006 11:10:31 -0700
X-IronPort-AV: i="4.09,134,1157353200";
d="scan'208"; a="319274409:sNHT34407892"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
k88IAVk0022754; Fri, 8 Sep 2006 11:10:31 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
[171.70.151.144])
by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k88IAN6c006339;
Fri, 8 Sep 2006 11:10:30 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 8 Sep 2006 11:10:25 -0700
Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 8 Sep 2006 11:10:23 -0700
From: "Marc Linsner"
To: "'Clive D.W. Feather'" ,
"'Winterbottom, James'"
Date: Fri, 8 Sep 2006 14:10:19 -0400
Message-ID: <007e01c6d372$0c828290$2b0d0d0a@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.2962
In-Reply-To: <20060908073335.GA9691@finch-staff-1.thus.net>
thread-index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEA
X-OriginalArrivalTime: 08 Sep 2006 18:10:24.0738 (UTC)
FILETIME=[0E5D8420:01C6D372]
DKIM-Signature: a=rsa-sha1; q=dns; l=3552; t=1157739031; x=1158603031;
c=relaxed/relaxed; s=sjdkim8002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=mlinsner@cisco.com;
z=From:=22Marc=20Linsner=22=20
|Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti
ation,need=20for=20time=20and=20accuracy?;
X=v=3Dcisco.com=3B=20h=3DDeBnvD7aPVFo3uIn1zbxAYE9EaQ=3D;
b=qs//86FFtvVgfGfHKgjwB6vkhlc54llddUcaEdLgvwhnASD4IjNnPFOagRuULCtoCxbDP1OO
FMI7zPKFCxJ+BQE79NfPdZhPSOH+FU8XrGqwgfKZPMBnWYK55ZCzZdqx;
Authentication-Results: sj-dkim-8.cisco.com; header.From=mlinsner@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: geopriv@ietf.org, ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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
Could someone please identify any/all application(s) where geo coordinates
are used to describe the location of a fixed (e.g. non-mobile) entity where
uncertainty/polygons are expressed? I've reviewed many aviation/marine
charts/data (very pervasive use of geo coordinates) that express geo
locations for fixed objects and I've yet to find any expressed with
uncertainty. (I'm 70% confident you'll find a runway at x,y,z)
RFC3825:
- is NOT intended to advise a mobile client of it's location (as suggested
in the text, it could possibly convey the location of the access point)
- is NOT a mechanism for expressing polygons
- is capable of conveying a 3 dimensional geo point from one entity to
another via dhcp
- is capable of expressing the resolution of the shown value
- is capable of allowing the creator of the object to express resolution
values other than what is actually known
- is an efficient mechanism for passing geo point location values via dhcp
...............snip....................
>
> 3825 does not explain in normative text:
> - that the encoding is twos complement (sign and magnitude would
> probably
> be more sensible in this context);
As seen in the quote below, it certainly specifies twos complement. In the
1960s problems with this representation were identified and resolved with
twos complement representation.
http://en.wikipedia.org/wiki/Signed_number_representations
"Within the LCI described here, Latitude and Longitude are represented in
fixed-point 2s-complement binary degrees, for the economy of a smaller
option size compared to a string encoding of digits in [7]. The integer
parts of these fields are 9 bits long to accommodate +/- 180 degrees. The
fractional part is 25 bits long, better than the precision of 7 decimal
digits. The length of each field is 40 bits, 34 of which is the sum of the
integer (9) and fractional (25) bits, plus 6 bits of resolution."
> - how to construct a rectangle that crosses the Prime Meridian or the
> equator;
RFC 3825 is not about representing arbitrary rectangles, but about
representing a geographic location, with explicit indication of the
resolution of the point.
> - what is the meaning of a value that is, or includes cases, outside
> the
> +/-90 or +/-180 range (the SHOULD be in range rule doesn't cut it,
> here).
One could extrapolate many meanings from values expressed that are outside
the SHOULD of the RFC. One of those meanings may be that the value
expressed is an error. Or a value outside the specified range could be an
alias (wrapping the globe) for a value within the specified ranges. The
"SHOULD" allows those who understand the complications to violate this
specification, but warns of unintended consequences.
>
> It's also a bad encoding because it requires boundaries to be aligned
> to units of the same size as the boundary. For example, if I want to
> define an area 2 degrees high, I have to use boundaries that are even
> numbers of degrees; there's no way to encode a square, 2 degrees on a
> side, centred on 52N 2W.
>
> In fact, the *only* encoding I can do for an area centred on that
> point is a rectangle 4 degrees east-west and 8 degrees north-south.
> For *any* point, there's only one rectangle with that point at its
> centre that can be encoded.
Since there is no arbitrary rectangle specified in RFC 3825, it does not
require anything about boundaries of any rectangle.
..................snip............................
-Marc-
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Fri Sep 08 17:47:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLoBu-0003p8-Lv; Fri, 08 Sep 2006 17:47:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLoBt-0003or-3X; Fri, 08 Sep 2006 17:47:13 -0400
Received: from marauder.andrew.com ([198.17.217.129])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GLoBr-0005wG-4O; Fri, 08 Sep 2006 17:47:13 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 16:47:10 -0500
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
E-mail Filter (4.7); Fri, 08 Sep 2006 16:47:10 -0500
Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 16:47:09 -0500
Message-ID:
From: "Winterbottom, James"
To: "Marc Linsner" , "Clive D.W. Feather"
Date: Fri, 8 Sep 2006 16:47:05 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 08 Sep 2006 21:47:09.0473 (UTC)
FILETIME=[55CA9910:01C6D390]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
In-Reply-To: <007e01c6d372$0c828290$2b0d0d0a@amer.cisco.com>
Content-class: urn:content-classes:message
Thread-Topic: [Ecrit] Location information in emergency sessioninitiation,
need for time and accuracy?
Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0
Cc: geopriv@ietf.org, ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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,
I would like you and James to get your arguments in synch and come back
with a cohesive, uncontradictory response to the concerns that are being
raised here.
You say " is NOT a mechanism for expressing polygons" and have said
before that you see it as a mechanisms for expressing single points
only.
James said " RFC3825 has resolution as part of its solution. This
creates a GML defined Linear Ring.."
These are in direct conflict.
The moment you use the resolution bits to describe a linear ring, you
are specifying a polygon, which by its very definition defines the area
of uncertainty for the host. The coding mechanism described in RFC-3825
for doing this introduces the problems that we have described.
So, either it is a point, in which case the resolution for the most part
should be ignored and a Biz to RFC-3825 is required to say this. Or, it
is an area which is described by the resolution bits, in which case you
need to find a way to eliminate the problems described or accept that it
should not be used in emergency applications.
I am only interested in location representation, and so far I see
conflict amongst the authors of that RFC with regards to what RFC-3825
represents and I see confusion over how the authors are interpreting the
terms uncertainty and confidence with regards to their usage in the
expression to areas.
Cheers
James
> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Saturday, 9 September 2006 4:10 AM
> To: 'Clive D.W. Feather'; Winterbottom, James
> Cc: ecrit@ietf.org; geopriv@ietf.org
> Subject: RE: [Ecrit] Location information in emergency
> sessioninitiation,need for time and accuracy?
>=20
> Could someone please identify any/all application(s) where geo
coordinates
> are used to describe the location of a fixed (e.g. non-mobile) entity
> where
> uncertainty/polygons are expressed? I've reviewed many
aviation/marine
> charts/data (very pervasive use of geo coordinates) that express geo
> locations for fixed objects and I've yet to find any expressed with
> uncertainty. (I'm 70% confident you'll find a runway at x,y,z)
>=20
> RFC3825:
>=20
> - is NOT intended to advise a mobile client of it's location (as
suggested
> in the text, it could possibly convey the location of the access
point)
> - is NOT a mechanism for expressing polygons
> - is capable of conveying a 3 dimensional geo point from one entity to
> another via dhcp
> - is capable of expressing the resolution of the shown value
> - is capable of allowing the creator of the object to express
resolution
> values other than what is actually known
> - is an efficient mechanism for passing geo point location values via
dhcp
>=20
>=20
> ...............snip....................
>=20
>=20
> >
> > 3825 does not explain in normative text:
> > - that the encoding is twos complement (sign and magnitude would
> > probably
> > be more sensible in this context);
>=20
> As seen in the quote below, it certainly specifies twos complement.
In
> the
> 1960s problems with this representation were identified and resolved
with
> twos complement representation.
> http://en.wikipedia.org/wiki/Signed_number_representations
>=20
> "Within the LCI described here, Latitude and Longitude are represented
in
> fixed-point 2s-complement binary degrees, for the economy of a smaller
> option size compared to a string encoding of digits in [7]. The
integer
> parts of these fields are 9 bits long to accommodate +/- 180 degrees.
The
> fractional part is 25 bits long, better than the precision of 7
decimal
> digits. The length of each field is 40 bits, 34 of which is the sum
of
> the
> integer (9) and fractional (25) bits, plus 6 bits of resolution."
>=20
>=20
> > - how to construct a rectangle that crosses the Prime Meridian or
the
> > equator;
>=20
> RFC 3825 is not about representing arbitrary rectangles, but about
> representing a geographic location, with explicit indication of the
> resolution of the point.
>=20
> > - what is the meaning of a value that is, or includes cases, outside
> > the
> > +/-90 or +/-180 range (the SHOULD be in range rule doesn't cut it,
> > here).
>=20
> One could extrapolate many meanings from values expressed that are
outside
> the SHOULD of the RFC. One of those meanings may be that the value
> expressed is an error. Or a value outside the specified range could
be an
> alias (wrapping the globe) for a value within the specified ranges.
The
> "SHOULD" allows those who understand the complications to violate this
> specification, but warns of unintended consequences.
>=20
>=20
> >
> > It's also a bad encoding because it requires boundaries to be
aligned
> > to units of the same size as the boundary. For example, if I want to
> > define an area 2 degrees high, I have to use boundaries that are
even
> > numbers of degrees; there's no way to encode a square, 2 degrees on
a
> > side, centred on 52N 2W.
> >
> > In fact, the *only* encoding I can do for an area centred on that
> > point is a rectangle 4 degrees east-west and 8 degrees north-south.
> > For *any* point, there's only one rectangle with that point at its
> > centre that can be encoded.
>=20
> Since there is no arbitrary rectangle specified in RFC 3825, it does
not
> require anything about boundaries of any rectangle.
>=20
> ..................snip............................
>=20
> -Marc-
---------------------------------------------------------------------------=
---------------------
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
From geopriv-bounces@ietf.org Fri Sep 08 18:02:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLoQh-000296-1U; Fri, 08 Sep 2006 18:02:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLoQf-00028p-BX; Fri, 08 Sep 2006 18:02:29 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GLoQe-0007AW-2L; Fri, 08 Sep 2006 18:02:29 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
by sj-iport-2.cisco.com with ESMTP; 08 Sep 2006 15:02:27 -0700
X-IronPort-AV: i="4.09,134,1157353200";
d="scan'208"; a="340516764:sNHT28779624"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
k88M2RSa025190; Fri, 8 Sep 2006 15:02:27 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
[171.70.151.144])
by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k88M2RYp005274;
Fri, 8 Sep 2006 15:02:27 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 8 Sep 2006 15:02:26 -0700
Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 8 Sep 2006 15:02:25 -0700
From: "Marc Linsner"
To: "'Winterbottom, James'"
Date: Fri, 8 Sep 2006 18:02:16 -0400
Message-ID: <000601c6d392$7633ccb0$2b0d0d0a@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.2962
Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsA==
In-Reply-To:
X-OriginalArrivalTime: 08 Sep 2006 22:02:26.0244 (UTC)
FILETIME=[783AC040:01C6D392]
DKIM-Signature: a=rsa-sha1; q=dns; l=532; t=1157752947; x=1158616947;
c=relaxed/simple; s=sjdkim2002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=mlinsner@cisco.com;
z=From:=22Marc=20Linsner=22=20
|Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti
ation,need=20for=20time=20and=20accuracy?;
X=v=3Dcisco.com=3B=20h=3DDeBnvD7aPVFo3uIn1zbxAYE9EaQ=3D;
b=sKMeUlYj16R6Gjiz0QxY3lIXH6II0KJ5oYYqddyUouRlutaF2egFgnE1k1te/DAeTWYJ037z
LAtuoB1cRgN0ZPL9WFwtnmDzZdzDSwrCw2t3+6Wnyp0BOg1Wg7DtF+KA;
Authentication-Results: sj-dkim-2.cisco.com; header.From=mlinsner@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: geopriv@ietf.org, ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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,
>
> So, either it is a point, in which case the resolution for
> the most part should be ignored and a Biz to RFC-3825 is
> required to say this. Or, it is an area which is described by
> the resolution bits, in which case you need to find a way to
> eliminate the problems described or accept that it should not
> be used in emergency applications.
Please explain why emergency applications are different from other
applications that describe fixed locations using the geo coordinate system.
-Marc-
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Fri Sep 08 18:11:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLoZ4-0002gD-3w; Fri, 08 Sep 2006 18:11:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLoZ3-0002fv-LO; Fri, 08 Sep 2006 18:11:09 -0400
Received: from marauder.andrew.com ([198.17.217.129])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GLoZ1-0008Jg-Dh; Fri, 08 Sep 2006 18:11:09 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:11:07 -0500
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
E-mail Filter (4.7); Fri, 08 Sep 2006 17:11:06 -0500
Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:11:06 -0500
Message-ID:
From: "Winterbottom, James"
To: "Marc Linsner"
Date: Fri, 8 Sep 2006 17:11:05 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 08 Sep 2006 22:11:06.0569 (UTC)
FILETIME=[AE5E0B90:01C6D393]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
In-Reply-To: <000601c6d392$7633ccb0$2b0d0d0a@amer.cisco.com>
Content-class: urn:content-classes:message
Thread-Topic: [Ecrit] Location information in emergency sessioninitiation,
need for time and accuracy?
Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: geopriv@ietf.org, ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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,
Perhaps the statement should have been, is not suitable for any
application that require a deterministic degree of accuracy, something
to that effect.
I am quite sure that in some circumstances that the encoding scheme is
fine, but I wouldn't want to be my life on it in an emergency, would
you?
James
> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Saturday, 9 September 2006 8:02 AM
> To: Winterbottom, James
> Cc: ecrit@ietf.org; geopriv@ietf.org
> Subject: RE: [Ecrit] Location information in emergency
> sessioninitiation,need for time and accuracy?
>=20
> James,
>=20
> >
> > So, either it is a point, in which case the resolution for
> > the most part should be ignored and a Biz to RFC-3825 is
> > required to say this. Or, it is an area which is described by
> > the resolution bits, in which case you need to find a way to
> > eliminate the problems described or accept that it should not
> > be used in emergency applications.
>=20
> Please explain why emergency applications are different from other
> applications that describe fixed locations using the geo coordinate
> system.
>=20
>=20
> -Marc-
---------------------------------------------------------------------------=
---------------------
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
From geopriv-bounces@ietf.org Fri Sep 08 18:30:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLorO-00011C-BJ; Fri, 08 Sep 2006 18:30:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLorN-00010s-9g; Fri, 08 Sep 2006 18:30:05 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GLorK-0002RX-Ti; Fri, 08 Sep 2006 18:30:05 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
by sj-iport-2.cisco.com with ESMTP; 08 Sep 2006 15:29:21 -0700
X-IronPort-AV: i="4.09,134,1157353200";
d="scan'208"; a="340520031:sNHT2409188040"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
k88MTK5u014615; Fri, 8 Sep 2006 15:29:20 -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 k88MTJYp019709;
Fri, 8 Sep 2006 15:29:19 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
Fri, 8 Sep 2006 15:29:19 -0700
Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 8 Sep 2006 15:29:19 -0700
From: "Marc Linsner"
To: "'Winterbottom, James'"
Date: Fri, 8 Sep 2006 18:29:12 -0400
Message-ID: <000b01c6d396$37c8a7d0$2b0d0d0a@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.2962
Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQAAAstRA=
In-Reply-To:
X-OriginalArrivalTime: 08 Sep 2006 22:29:19.0287 (UTC)
FILETIME=[39AD9470:01C6D396]
DKIM-Signature: a=rsa-sha1; q=dns; l=658; t=1157754560; x=1158618560;
c=relaxed/simple; s=sjdkim2002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=mlinsner@cisco.com;
z=From:=22Marc=20Linsner=22=20
|Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti
ation,need=20for=20time=20and=20accuracy?;
X=v=3Dcisco.com=3B=20h=3DDeBnvD7aPVFo3uIn1zbxAYE9EaQ=3D;
b=Suqsgj4ISgSNU6a9SeLWCPomXxrrGpZ3+oGtnV4trobdUwczdhWTfZlJ3FOLuiVNHuFpKeyx
2UkmUerdCBU2v0SVq6jECU3FfVKlX+w+22w0y+vZB9qn+wyE0fxoV3Gx;
Authentication-Results: sj-dkim-2.cisco.com; header.From=mlinsner@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: geopriv@ietf.org, ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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,
>
> Perhaps the statement should have been, is not suitable for
> any application that require a deterministic degree of
> accuracy, something to that effect.
> I am quite sure that in some circumstances that the encoding
> scheme is fine, but I wouldn't want to be my life on it in an
> emergency, would you?
I suggest emergency responders would have no problem finding locations
described by RFC3825, it's the same data expressions used by aviation and
marine everyday. So, unless you travel exclusively by rail, you've probably
already placed you life in the hands of such data representation, I know I
have.
-Marc-
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Fri Sep 08 18:52:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLpD8-0000hC-GL; Fri, 08 Sep 2006 18:52:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLpD6-0000dC-UQ; Fri, 08 Sep 2006 18:52:32 -0400
Received: from marauder.andrew.com ([198.17.217.129])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GLpD5-0000Ds-Mc; Fri, 08 Sep 2006 18:52:32 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:52:31 -0500
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
E-mail Filter (4.7); Fri, 08 Sep 2006 17:52:30 -0500
Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 17:52:30 -0500
Message-ID:
From: "Winterbottom, James"
To: "Marc Linsner"
Date: Fri, 8 Sep 2006 17:52:30 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 08 Sep 2006 22:52:30.0289 (UTC)
FILETIME=[76C7A410:01C6D399]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
In-Reply-To: <000b01c6d396$37c8a7d0$2b0d0d0a@amer.cisco.com>
Content-class: urn:content-classes:message
Thread-Topic: [Ecrit] Location information in emergency sessioninitiation,
need for time and accuracy?
Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQAAAstRAAALMNEA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: geopriv@ietf.org, ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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 interesting that you point this out and I am certainly no expert
in aviation and marine location systems. I will however point out that
from what I have seen that searches at sea and for downed aircraft often
span many thousands of square kilometres, I scarcely think that this
would be acceptable in a domestic wired or wireless phone emergency
situation.
I would also point out that if you have used the same encoding as is
used in those industries it behoves you to have put them in the
references section of the RFC, and to have indicated that the encoding
scheme came from the there in the text somewhere, I certainly couldn't
find any.
Now back to my initial series of questions:
Point or Polygon, single answer please.
How do you intend to address the concern regarding errors.
Cheers
James
> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Saturday, 9 September 2006 8:29 AM
> To: Winterbottom, James
> Cc: ecrit@ietf.org; geopriv@ietf.org
> Subject: RE: [Ecrit] Location information in emergency
> sessioninitiation,need for time and accuracy?
>=20
>=20
> >
> > Marc,
> >
> > Perhaps the statement should have been, is not suitable for
> > any application that require a deterministic degree of
> > accuracy, something to that effect.
> > I am quite sure that in some circumstances that the encoding
> > scheme is fine, but I wouldn't want to be my life on it in an
> > emergency, would you?
>=20
> I suggest emergency responders would have no problem finding locations
> described by RFC3825, it's the same data expressions used by aviation
and
> marine everyday. So, unless you travel exclusively by rail, you've
> probably
> already placed you life in the hands of such data representation, I
know I
> have.
>=20
> -Marc-
---------------------------------------------------------------------------=
---------------------
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
From geopriv-bounces@ietf.org Fri Sep 08 19:42:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLpz8-0000TA-Ly; Fri, 08 Sep 2006 19:42:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLpz7-0000Ql-RX; Fri, 08 Sep 2006 19:42:09 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GLpz6-0001Gg-An; Fri, 08 Sep 2006 19:42:09 -0400
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
by sj-iport-6.cisco.com with ESMTP; 08 Sep 2006 16:42:07 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
k88Ng73m020696; Fri, 8 Sep 2006 16:42:07 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
[171.70.151.144])
by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k88Ng76W002782;
Fri, 8 Sep 2006 16:42:07 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 8 Sep 2006 16:42:06 -0700
Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
with Microsoft SMTPSVC(6.0.3790.1830);
Fri, 8 Sep 2006 16:42:02 -0700
From: "Marc Linsner"
To: "'Winterbottom, James'"
Date: Fri, 8 Sep 2006 19:41:55 -0400
Message-ID: <001001c6d3a0$625b0c40$2b0d0d0a@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.2962
Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQAAAstRAAALMNEAABCiww
In-Reply-To:
X-OriginalArrivalTime: 08 Sep 2006 23:42:05.0968 (UTC)
FILETIME=[646C3900:01C6D3A0]
DKIM-Signature: a=rsa-sha1; q=dns; l=3905; t=1157758927; x=1158622927;
c=relaxed/simple; s=sjdkim5002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=mlinsner@cisco.com;
z=From:=22Marc=20Linsner=22=20
|Subject:RE=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti
ation,need=20for=20time=20and=20accuracy?;
X=v=3Dcisco.com=3B=20h=3DDeBnvD7aPVFo3uIn1zbxAYE9EaQ=3D;
b=xyItbd8aefrFOsrOqg1Izpwgkq3TdLXWmGuhs1pbSp8aWbiqWcHBJCBKcZbmRwUsn9FxvByj
K46UHOkfrR+H0HsXb9rf82A2a9/QKFIvUq4rxlIyYXrfOYiCnXQQ7OzB;
Authentication-Results: sj-dkim-5.cisco.com; header.From=mlinsner@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: geopriv@ietf.org, ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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,
We are obviously talking past each other. I used the aviation and marine
industries as examples of users of geo coordinates for their respective
navigation applications. I used that analogy because both those
applications commonly refer to fixed locations (e.g. airport runways, marine
buoys/markers), the same non-mobile type entities served by RFC3825 (the
commonality being 'non-mobile, not the application). I can't testify
whether these application implementations internally represent data in
binary, octal, decimal, etc. But I can attest that these applications DO
NOT express any kind of uncertainty association in addition to the location
representations. My experience with these applications have been with
variable length fields, hence a separate resolution parameter has not been
included.
Resolution, whether expressed in binary, octal, decimal, etc. cannot
represent an arbitrary area/shape. Hence, RFC3825 cannot express an
arbitrary area/shape as it only includes resolution.
Would you please expand your question concerning errors? What errors?
-Marc-
> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Friday, September 08, 2006 6:53 PM
> To: Marc Linsner
> Cc: ecrit@ietf.org; geopriv@ietf.org
> Subject: RE: [Ecrit] Location information in emergency
> sessioninitiation,need for time and accuracy?
>
> It is interesting that you point this out and I am certainly
> no expert in aviation and marine location systems. I will
> however point out that from what I have seen that searches at
> sea and for downed aircraft often span many thousands of
> square kilometres, I scarcely think that this would be
> acceptable in a domestic wired or wireless phone emergency situation.
>
> I would also point out that if you have used the same
> encoding as is used in those industries it behoves you to
> have put them in the references section of the RFC, and to
> have indicated that the encoding scheme came from the there
> in the text somewhere, I certainly couldn't find any.
>
> Now back to my initial series of questions:
>
> Point or Polygon, single answer please.
> How do you intend to address the concern regarding errors.
>
> Cheers
> James
>
>
> > -----Original Message-----
> > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > Sent: Saturday, 9 September 2006 8:29 AM
> > To: Winterbottom, James
> > Cc: ecrit@ietf.org; geopriv@ietf.org
> > Subject: RE: [Ecrit] Location information in emergency
> > sessioninitiation,need for time and accuracy?
> >
> >
> > >
> > > Marc,
> > >
> > > Perhaps the statement should have been, is not suitable for any
> > > application that require a deterministic degree of accuracy,
> > > something to that effect.
> > > I am quite sure that in some circumstances that the
> encoding scheme
> > > is fine, but I wouldn't want to be my life on it in an emergency,
> > > would you?
> >
> > I suggest emergency responders would have no problem
> finding locations
> > described by RFC3825, it's the same data expressions used
> by aviation
> and
> > marine everyday. So, unless you travel exclusively by rail, you've
> > probably already placed you life in the hands of such data
> > representation, I
> know I
> > have.
> >
> > -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 Fri Sep 08 21:10:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLrM0-0007JQ-5U; Fri, 08 Sep 2006 21:09:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GLrLz-0007Ik-0e; Fri, 08 Sep 2006 21:09:51 -0400
Received: from marauder.andrew.com ([198.17.217.129])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GLrLv-0004Ul-3j; Fri, 08 Sep 2006 21:09:50 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 20:09:44 -0500
Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl
E-mail Filter (4.7); Fri, 08 Sep 2006 20:09:44 -0500
Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Sep 2006 20:09:44 -0500
Message-ID:
From: "Winterbottom, James"
To: "Marc Linsner"
Date: Fri, 8 Sep 2006 20:09:41 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 09 Sep 2006 01:09:44.0050 (UTC)
FILETIME=[A27BDD20:01C6D3AC]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
In-Reply-To: <001001c6d3a0$625b0c40$2b0d0d0a@amer.cisco.com>
Content-class: urn:content-classes:message
Thread-Topic: [Ecrit] Location information in emergency sessioninitiation,
need for time and accuracy?
Thread-Index: AcbTGV3rLC52tGDTSZGKsnPW07RXYgAVTGEAAAfyCUAAAOacsAAAYhNQAAAstRAAALMNEAABCiwwAAQ5khA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: geopriv@ietf.org, ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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,
In all the examples used in RFC-3825 in the appendix, the way resolution
is used is to express a range in the latitude, longitude and altitude.
This expresses an area or volume, there is no other way to interpret
this. I am past believing that you can't see this.
I am not saying having a resolution parameter is not useful, just the
way that RFC-3825 stipulates it be interpreted.
As for errors please read PIDF-LO profile, it is very clear there.
Cheers
James
> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Saturday, 9 September 2006 9:42 AM
> To: Winterbottom, James
> Cc: ecrit@ietf.org; geopriv@ietf.org
> Subject: RE: [Ecrit] Location information in emergency
> sessioninitiation,need for time and accuracy?
>=20
> James,
>=20
> We are obviously talking past each other. I used the aviation and
marine
> industries as examples of users of geo coordinates for their
respective
> navigation applications. I used that analogy because both those
> applications commonly refer to fixed locations (e.g. airport runways,
> marine
> buoys/markers), the same non-mobile type entities served by RFC3825
(the
> commonality being 'non-mobile, not the application). I can't testify
> whether these application implementations internally represent data in
> binary, octal, decimal, etc. But I can attest that these applications
DO
> NOT express any kind of uncertainty association in addition to the
> location
> representations. My experience with these applications have been with
> variable length fields, hence a separate resolution parameter has not
been
> included.
>=20
> Resolution, whether expressed in binary, octal, decimal, etc. cannot
> represent an arbitrary area/shape. Hence, RFC3825 cannot express an
> arbitrary area/shape as it only includes resolution.
>=20
> Would you please expand your question concerning errors? What errors?
>=20
> -Marc-
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > Sent: Friday, September 08, 2006 6:53 PM
> > To: Marc Linsner
> > Cc: ecrit@ietf.org; geopriv@ietf.org
> > Subject: RE: [Ecrit] Location information in emergency
> > sessioninitiation,need for time and accuracy?
> >
> > It is interesting that you point this out and I am certainly
> > no expert in aviation and marine location systems. I will
> > however point out that from what I have seen that searches at
> > sea and for downed aircraft often span many thousands of
> > square kilometres, I scarcely think that this would be
> > acceptable in a domestic wired or wireless phone emergency
situation.
> >
> > I would also point out that if you have used the same
> > encoding as is used in those industries it behoves you to
> > have put them in the references section of the RFC, and to
> > have indicated that the encoding scheme came from the there
> > in the text somewhere, I certainly couldn't find any.
> >
> > Now back to my initial series of questions:
> >
> > Point or Polygon, single answer please.
> > How do you intend to address the concern regarding errors.
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > Sent: Saturday, 9 September 2006 8:29 AM
> > > To: Winterbottom, James
> > > Cc: ecrit@ietf.org; geopriv@ietf.org
> > > Subject: RE: [Ecrit] Location information in emergency
> > > sessioninitiation,need for time and accuracy?
> > >
> > >
> > > >
> > > > Marc,
> > > >
> > > > Perhaps the statement should have been, is not suitable for any
> > > > application that require a deterministic degree of accuracy,
> > > > something to that effect.
> > > > I am quite sure that in some circumstances that the
> > encoding scheme
> > > > is fine, but I wouldn't want to be my life on it in an
emergency,
> > > > would you?
> > >
> > > I suggest emergency responders would have no problem
> > finding locations
> > > described by RFC3825, it's the same data expressions used
> > by aviation
> > and
> > > marine everyday. So, unless you travel exclusively by rail,
you've
> > > probably already placed you life in the hands of such data
> > > representation, I
> > know I
> > > have.
> > >
> > > -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]
---------------------------------------------------------------------------=
---------------------
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
From geopriv-bounces@ietf.org Sat Sep 09 10:51:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GM4Ab-0003iy-7q; Sat, 09 Sep 2006 10:50:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GM4AZ-0003iq-Hu; Sat, 09 Sep 2006 10:50:55 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GM4AX-0006uu-8n; Sat, 09 Sep 2006 10:50:55 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
by rtp-iport-2.cisco.com with ESMTP; 09 Sep 2006 10:50:53 -0400
X-IronPort-AV: i="4.09,136,1157342400";
d="scan'208"; a="101540253:sNHT33095980"
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.20060308/8.12.11) with ESMTP id
k89Eoq5Z026127; Sat, 9 Sep 2006 10:50:52 -0400
Received: from [68.50.22.220] (che-vpn-cluster-2-182.cisco.com [10.86.242.182])
by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k89EoouI026295;
Sat, 9 Sep 2006 10:50:50 -0400 (EDT)
In-Reply-To:
References:
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id:
Content-Transfer-Encoding: 7bit
From: John Schnizlein
Date: Sat, 9 Sep 2006 10:50:46 -0400
To: "Winterbottom, James"
X-Mailer: Apple Mail (2.624)
DKIM-Signature: a=rsa-sha1; q=dns; l=2937; t=1157813452; x=1158677452;
c=relaxed/simple; s=rtpdkim1001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=jschnizl@cisco.com;
z=From:John=20Schnizlein=20
|Subject:Re=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti
ation,=20need=20for=20time=20and=20accuracy?
|To:=22Winterbottom,=20James=22=20;
X=v=3Dcisco.com=3B=20h=3DiqJrDvQ3r+LNFuEMj8tkFjFc+20=3D;
b=e14EsNy93CPC2ewqYuQDTO5QCUdJU2iF/FnC63oqjB0m1zDJH1VeCkY95l/Ivnj0W42ZDl6r
A3eO0hq2vNjp12cZhfSnTD5embGH3UeWKNBXtZpyi32LmN+RSuDzvpRb;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=jschnizl@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: geopriv@ietf.org, Marc Linsner , ecrit@ietf.org
Subject: [Geopriv] Re: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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 8, 2006, at 9:09 PM, Winterbottom, James wrote:
>
> In all the examples used in RFC-3825 in the appendix, the way
> resolution
> is used is to express a range in the latitude, longitude and altitude.
> This expresses an area or volume, there is no other way to interpret
> this. I am past believing that you can't see this.
These illustrations are in an appendix to indicate that they are not
normative. The point of the appendix is to show what size regions
different resolutions imply, including deliberately partially hiding
location by lowering resolution. This does not change the fact that
the resolution is SPECIFIED as "number of valid bits in the fixed-point
value". As we have explained before, this represents the normal
scientific/engineering concept of significant figures.
> I am not saying having a resolution parameter is not useful, just the
> way that RFC-3825 stipulates it be interpreted.
The way RFC 3825 specifies resolution is just what is necessary to
implement the principle of significant figures when using a
fixed-length binary number rather than a variable number (limited by
the measurement precision) of decimal digits.
> As for errors please read PIDF-LO profile, it is very clear there.
No, it is not. As explained in the dialog on the GeoPriv list some
time ago, the errors are in your interpretation of the illustration in
the appendix of RFC 3825. RFC 3825 does not specify arbitrary
geographic polygons, although you seem to insist it should. Your
invention of longest matching substrings of boundaries leads to the
errors you report. Please stop attributing your erroneous
interpretation to the different purpose of RFC 3825.
John
>> From: Marc Linsner
>>
>> We are obviously talking past each other. I used the aviation and
>> marine industries as examples of users of geo coordinates for their
>> respective navigation applications. I used that analogy because both
>> those applications commonly refer to fixed locations (e.g. airport
>> runways,
>> marine buoys/markers), the same non-mobile type entities served by
>> RFC3825
>> (the commonality being 'non-mobile, not the application). I can't
>> testify
>> whether these application implementations internally represent data in
>> binary, octal, decimal, etc. But I can attest that these applications
>> DO NOT express any kind of uncertainty association in addition to the
>>
>> location representations. My experience with these applications have
>> been with variable length fields, hence a separate resolution
>> parameter
>> has not been included.
>>
>> Resolution, whether expressed in binary, octal, decimal, etc. cannot
>> represent an arbitrary area/shape. Hence, RFC3825 cannot express an
>> arbitrary area/shape as it only includes resolution.
>>
>> Would you please expand your question concerning errors? What errors?
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Sat Sep 09 18:11:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMB2h-0000PX-Io; Sat, 09 Sep 2006 18:11:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMB2f-0000Nf-Q1; Sat, 09 Sep 2006 18:11:13 -0400
Received: from marauder.andrew.com ([198.17.217.129])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GMB2f-0007Al-Fn; Sat, 09 Sep 2006 18:11:13 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Sep 2006 17:11:10 -0500
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
E-mail Filter (4.7); Sat, 09 Sep 2006 17:11:09 -0500
Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Sep 2006 17:10:42 -0500
Message-ID:
From: "Winterbottom, James"
To: "John Schnizlein"
Date: Sat, 9 Sep 2006 17:11:07 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 09 Sep 2006 22:10:42.0301 (UTC)
FILETIME=[CA50CAD0:01C6D45C]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
In-Reply-To:
Content-class: urn:content-classes:message
Thread-Topic: [Ecrit] Location information in emergency sessioninitiation,
need for time and accuracy?
Thread-Index: AcbUH1oLlbGwRsnOSoymJDM7leqO2gAO2MGQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Cc: geopriv@ietf.org, Marc Linsner , ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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
John,
Please!
Normal scientific measurements will say +- half the smallest unit. This
will place a point in the middle somewhere, and you yourself at the very
start of this debate came back with a proposal saying that.=20
The fact of the matter is that you are starting in the normative section
of the draft that the resolutions parameters place you with in an area.
If this is what is meant, then I am sorry to say that this but the
PIDF-LO draft is correct and you are plain wrong!
James Polk has stated more than once now that the shape defined in
RFC-3825 is a linear ring polygon. If this is the case then the
calculation in PIDF-LO profile also stand.
Quite frankly what is it that RFC-3825 represents. This part of previous
question you have tactfully ignored.
So I am going to ask you. Point, or area?
If Point, then a clarification draft stipulating this is required.
If an area, then please provide a detailed explanation of how would
re-describe the examples in PIDF-LO profile with references to the
sections RFC-3825 that eliminate the inherent errors.
I am tired of you saying that this is wrong, when it clearly follows
your specification, and you do not provide through the same example
where it is wrong, or provide a reasonable alternative.
BR
James
> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]
> Sent: Sunday, 10 September 2006 12:51 AM
> To: Winterbottom, James
> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org
> Subject: Re: [Ecrit] Location information in emergency
sessioninitiation,
> need for time and accuracy?
>=20
>=20
> On Sep 8, 2006, at 9:09 PM, Winterbottom, James wrote:
> >
> > In all the examples used in RFC-3825 in the appendix, the way
> > resolution
> > is used is to express a range in the latitude, longitude and
altitude.
> > This expresses an area or volume, there is no other way to interpret
> > this. I am past believing that you can't see this.
>=20
> These illustrations are in an appendix to indicate that they are not
> normative. The point of the appendix is to show what size regions
> different resolutions imply, including deliberately partially hiding
> location by lowering resolution. This does not change the fact that
> the resolution is SPECIFIED as "number of valid bits in the
fixed-point
> value". As we have explained before, this represents the normal
> scientific/engineering concept of significant figures.
>=20
> > I am not saying having a resolution parameter is not useful, just
the
> > way that RFC-3825 stipulates it be interpreted.
>=20
> The way RFC 3825 specifies resolution is just what is necessary to
> implement the principle of significant figures when using a
> fixed-length binary number rather than a variable number (limited by
> the measurement precision) of decimal digits.
>=20
> > As for errors please read PIDF-LO profile, it is very clear there.
>=20
> No, it is not. As explained in the dialog on the GeoPriv list some
> time ago, the errors are in your interpretation of the illustration in
> the appendix of RFC 3825. RFC 3825 does not specify arbitrary
> geographic polygons, although you seem to insist it should. Your
> invention of longest matching substrings of boundaries leads to the
> errors you report. Please stop attributing your erroneous
> interpretation to the different purpose of RFC 3825.
>=20
> John
>=20
> >> From: Marc Linsner
> >>
> >> We are obviously talking past each other. I used the aviation and
> >> marine industries as examples of users of geo coordinates for their
> >> respective navigation applications. I used that analogy because
both
> >> those applications commonly refer to fixed locations (e.g. airport
> >> runways,
> >> marine buoys/markers), the same non-mobile type entities served by
> >> RFC3825
> >> (the commonality being 'non-mobile, not the application). I can't
> >> testify
> >> whether these application implementations internally represent data
in
> >> binary, octal, decimal, etc. But I can attest that these
applications
> >> DO NOT express any kind of uncertainty association in addition to
the
> >>
> >> location representations. My experience with these applications
have
> >> been with variable length fields, hence a separate resolution
> >> parameter
> >> has not been included.
> >>
> >> Resolution, whether expressed in binary, octal, decimal, etc.
cannot
> >> represent an arbitrary area/shape. Hence, RFC3825 cannot express
an
> >> arbitrary area/shape as it only includes resolution.
> >>
> >> Would you please expand your question concerning errors? What
errors?
---------------------------------------------------------------------------=
---------------------
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
From geopriv-bounces@ietf.org Sat Sep 09 20:50:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMDVe-0003GB-GU; Sat, 09 Sep 2006 20:49:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMDVd-0003Fw-9u; Sat, 09 Sep 2006 20:49:17 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GMDVb-0002M2-2t; Sat, 09 Sep 2006 20:49:17 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
by rtp-iport-1.cisco.com with ESMTP; 09 Sep 2006 17:49:15 -0700
X-IronPort-AV: i="4.09,137,1157353200";
d="scan'208"; a="40814512:sNHT30584372"
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.20060308/8.12.11) with ESMTP id
k8A0nE6H018446; Sat, 9 Sep 2006 20:49:14 -0400
Received: from [68.50.22.220] (che-vpn-cluster-2-182.cisco.com [10.86.242.182])
by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k8A0nCuI008736;
Sat, 9 Sep 2006 20:49:12 -0400 (EDT)
In-Reply-To:
References:
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3b16f2ec895557379e48b424be6f0a12@cisco.com>
Content-Transfer-Encoding: 7bit
From: John Schnizlein
Date: Sat, 9 Sep 2006 20:49:09 -0400
To: "Winterbottom, James"
X-Mailer: Apple Mail (2.624)
DKIM-Signature: a=rsa-sha1; q=dns; l=487; t=1157849354; x=1158713354;
c=relaxed/simple; s=rtpdkim1001;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=jschnizl@cisco.com;
z=From:John=20Schnizlein=20
|Subject:Re=3A=20[Ecrit]=20Location=20information=20in=20emergency=20sessioniniti
ation,=20need=20for=20time=20and=20accuracy?
|To:=22Winterbottom,=20James=22=20;
X=v=3Dcisco.com=3B=20h=3DiqJrDvQ3r+LNFuEMj8tkFjFc+20=3D;
b=btT+ENZgdSeHtzLTtH2qk1oj8n1N/K1mqAAfL2V0VQcosJQ6d2kiZNzNAb3HJksJK72z9ZVv
k9Hf2gR5BD0V5RvxchYyci02nnw8XVwAoe+GcQnp23Pd4alyQCyow5Qm;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=jschnizl@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: geopriv@ietf.org, Marc Linsner , ecrit@ietf.org
Subject: [Geopriv] Re: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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
What part of "geographic location of the client" is unclear to you?
It is beyond comprehension how this could be interpreted as a area
rather than a point, with the resolution of the measurement of that
point explicitly included in the location information.
Why is this old argument being rehashed in the ecrit WG when if finally
seemed to die (mercifully) in GeoPriv?
On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote:
> So I am going to ask you. Point, or area?
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Sat Sep 09 21:02:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMDiL-0000L9-0p; Sat, 09 Sep 2006 21:02:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMDiJ-0000L1-G9; Sat, 09 Sep 2006 21:02:23 -0400
Received: from marauder.andrew.com ([198.17.217.129])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GMDiI-0006Gr-8p; Sat, 09 Sep 2006 21:02:23 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Sep 2006 20:02:21 -0500
Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl
E-mail Filter (4.7); Sat, 09 Sep 2006 20:02:21 -0500
Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Sep 2006 20:02:20 -0500
Message-ID:
From: "Winterbottom, James"
To: "John Schnizlein"
Date: Sat, 9 Sep 2006 20:02:18 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 10 Sep 2006 01:02:20.0776 (UTC)
FILETIME=[C4AF5E80:01C6D474]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
In-Reply-To: <3b16f2ec895557379e48b424be6f0a12@cisco.com>
Content-class: urn:content-classes:message
Thread-Topic: [Ecrit] Location information in emergency sessioninitiation,
need for time and accuracy?
Thread-Index: AcbUcvDwkNuQ6VLiQG2mB92eZip6LgAAYJfg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: geopriv@ietf.org, Marc Linsner , ecrit@ietf.org
Subject: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
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 you are saying that the examples in the appendix of RFC-3825 are
wrong, and that RFC-3825 cannot and never will describe an area?
It didn't die in Geopriv, I was waiting for you to actual come back with
an explanation, what you did was write back an email that was totally
irrelevant to the discussion. So I am still waiting!
> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]
> Sent: Sunday, 10 September 2006 10:49 AM
> To: Winterbottom, James
> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org
> Subject: Re: [Ecrit] Location information in emergency
sessioninitiation,
> need for time and accuracy?
>=20
> What part of "geographic location of the client" is unclear to you?
>=20
> It is beyond comprehension how this could be interpreted as a area
> rather than a point, with the resolution of the measurement of that
> point explicitly included in the location information.
>=20
> Why is this old argument being rehashed in the ecrit WG when if
finally
> seemed to die (mercifully) in GeoPriv?
>=20
> On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote:
>=20
> > So I am going to ask you. Point, or area?
---------------------------------------------------------------------------=
---------------------
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
From geopriv-bounces@ietf.org Sat Sep 09 23:29:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMG0C-0002Fn-JF; Sat, 09 Sep 2006 23:29:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMG0B-0002Ff-Bn; Sat, 09 Sep 2006 23:28:59 -0400
Received: from zeke.ecotroph.net ([69.31.8.124])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GMG09-0007iL-2p; Sat, 09 Sep 2006 23:28:59 -0400
Received: from [10.0.1.50] ([::ffff:72.196.237.170])
(AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA)
by zeke.ecotroph.net with esmtp; Sat, 09 Sep 2006 23:28:33 -0400
id 0158802A.45038661.00004DC7
In-Reply-To:
References:
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: Andrew Newton
Date: Sat, 9 Sep 2006 23:28:38 -0400
To: Geopriv WG , "Ecrit@Ietf.Org"
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: Marc Linsner , John Schnizlein
Subject: [Geopriv] I'm 100% certain I Don't Understand
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 the risk of ending the cordial and praiseworthy correspondence of
this thread, I would like to interject that I am fairly confused.
Certainly (pun intended) I should have given much more attention to
my math and statistics studies when I was younger.
First, my initial confusion about this dealt with the terminology
being used, which is somewhat a point of contention here. For the
life of me, I could not understand why anybody would care to
communicate their "uncertainty" regarding location information nor
could I understand why a PSAP would want to know it. "The building I
am in is on fire, but I'm only 50% certain that it is my house. I
could be at work as well." That just doesn't make sense. So I can
only gather that the word is being used in the context of statistical
probability about a specific point within a shape. Is this correct?
And can somebody point to an actual definition of the word? Is it
the same as confidence as is used in probability?
At looking at RFC 3825, I think there may be an issue with
terminology but I believe the concept is appropriate. 3825 uses the
term "resolution". I would have thought resolution would refer to
the range of numbers allowed in the protocol fields. Instead, it is
being used to describe the resolution of the measurement. That is
fine. And the take away from it is that a point in 3 dimensions is
being expressed.
Now, if the receiver of this information is capable of understanding
a higher "resolution", then one could start asking questions about
the probability of where a point (at the receivers highest
resolution) resides inside the shape that can be taken from the
senders lower resolution point. I guess that might be useful if
first responders are sent to the location given by the higher
resolution point, find nothing, and are then advised to search a
perimeter of a specific size.
It turns out that the other document in this discussion does talk
about this. From Section 6 of draft-ietf-geopriv-pdif-lo-profile:
Generally these locations are expressed as a point
(either in two or three dimensions) and an area or volume of
uncertainty around the point. In theory, the area or volume
represents a coverage in which the user has a relatively high
probability of being found, and the point is a convenient means of
defining the centroid for the area or volume. In practice, most
systems use the point as an absolute value and ignore the
uncertainty.
Interchange "uncertainty" and "resolution" and these documents are
saying the same thing. Which term is correct? At present, I'm not
convinced either is.
All this leaves me with two very big questions. Since 3825 is
describing a point in 3 dimensions, why does pidf-lo-profile talk
about 3825 LCI as being a rectangle in Appendix A? And if 3825 is
describing a point, how can its equivalent in GML be a linear ring?
I would think it would be a GML point (or Position in GML speak).
-andy
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
From geopriv-bounces@ietf.org Sun Sep 10 10:12:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMQ2R-0003w4-Mi; Sun, 10 Sep 2006 10:11:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMQ2P-0003vw-W8; Sun, 10 Sep 2006 10:11:57 -0400
Received: from marauder.andrew.com ([198.17.217.129])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GMQ2O-0001CG-Im; Sun, 10 Sep 2006 10:11:57 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Sep 2006 09:11:56 -0500
Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl
E-mail Filter (4.7); Sun, 10 Sep 2006 09:11:55 -0500
Received: from AOPEX4.andrew.com ([10.3.20.127]) by aopexbh1.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Sep 2006 09:11:55 -0500
Message-ID:
From: "Dawson, Martin"
To: "Andrew Newton" , "Geopriv WG" ,
"Ecrit@Ietf.Org"
Date: Sun, 10 Sep 2006 09:11:51 -0500
Subject: RE: [Geopriv] I'm 100% certain I Don't Understand
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 10 Sep 2006 14:11:55.0130 (UTC)
FILETIME=[12001DA0:01C6D4E3]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
In-Reply-To:
Content-class: urn:content-classes:message
Thread-Topic: [Geopriv] I'm 100% certain I Don't Understand
Thread-Index: AcbUiZB5ych+XwS0QmKkp+CNY9OOhwAUiVfQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: Marc Linsner , John Schnizlein
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 help with the definitions.
Uncertainty: The parameter which defines the area in which the target is
expected to be. An area of uncertainty may be represented as a point
center and a radius. There's nothing special about the center - all
points within the circle defined by the radius are equally likely to be
correct for the target. For example, a location based on the serving
cell of a radio network is no more likely to be correct for the center
of the cell than it is for any other point of coverage of that cell.
Confidence: The probability that the target is actually in that area of
uncertainty. For example, the radius may be provided with 80%
confidence. This means that four out of five times the target will be
somewhere with that circle and one time out of five it will be outside
the circle. That one time out of five the target could be anywhere in
the universe. The circle does not convey anything about the uncertainty
associated with the 20% of cases when the target is outside the circle.
Statistically, given many (actually all) location measurement techniques
are subject to error, an uncertainty area is inevitably associated with
the result. In the above example, the only way to have a higher
confidence (e.g. push it up to 95% so that only one out of twenty
targets are incorrectly located) is to re-evaluate the measurement
technique to work out the larger radius of uncertainty associated with
that higher confidence.
Uncertainty and confidence are actually quite important to emergency
services because:
A) The uncertainty value allows for more reliable routing of calls
occurring close enough to the routing boundaries for the uncertainty to
be significant. There is nothing special about the centroid point - it
is as likely to be the location of the target as any other point within
the area of uncertainty. If significantly more of the area of
uncertainty lies on one side of a boundary, even if it doesn't include
the centroid, then the that is the more reliable route to select.
B) When dispatching first responders, the area of uncertainty tells
emergency services where they need to focus the search.
C) Since no area of uncertainty for a measured location has 100%
confidence, dispatch procedures must also cover the instance where the
target doesn't actually lie within the area of uncertainty. The
confidence provides the likelihood that this is the case and the form
that the contingency procedures take will be governed in part by the
degree of that likelihood.
The geo-coding prescribed in RFC 3825 does not have the ability to
specify arbitrary values of uncertainty or confidence. As such it cannot
provide the benefits described above.
For example: what would the 3825 encoding be if you wanted to specify a
location 100 meters either side of latitude North 52 degrees? Or, to
emphasize the extreme case, what if that was in the UK at 100 meters
either side of zero degrees longitude?
3825 specifically says that the bits not covered by the resolution can
be either one or zero or one. You actually have to try and use this
approach to codify arbitrary location uncertainties such as the above to
see what the problem is.
Cheers,
Martin
> -----Original Message-----
> From: Andrew Newton [mailto:andy@hxr.us]
> Sent: Sunday, 10 September 2006 1:29 PM
> To: Geopriv WG; Ecrit@Ietf.Org
> Cc: Marc Linsner; John Schnizlein
> Subject: [Geopriv] I'm 100% certain I Don't Understand
>=20
> At the risk of ending the cordial and praiseworthy correspondence of
> this thread, I would like to interject that I am fairly confused.
> Certainly (pun intended) I should have given much more attention to
> my math and statistics studies when I was younger.
>=20
> First, my initial confusion about this dealt with the terminology
> being used, which is somewhat a point of contention here. For the
> life of me, I could not understand why anybody would care to
> communicate their "uncertainty" regarding location information nor
> could I understand why a PSAP would want to know it. "The building I
> am in is on fire, but I'm only 50% certain that it is my house. I
> could be at work as well." That just doesn't make sense. So I can
> only gather that the word is being used in the context of statistical
> probability about a specific point within a shape. Is this correct?
> And can somebody point to an actual definition of the word? Is it
> the same as confidence as is used in probability?
>=20
> At looking at RFC 3825, I think there may be an issue with
> terminology but I believe the concept is appropriate. 3825 uses the
> term "resolution". I would have thought resolution would refer to
> the range of numbers allowed in the protocol fields. Instead, it is
> being used to describe the resolution of the measurement. That is
> fine. And the take away from it is that a point in 3 dimensions is
> being expressed.
>=20
> Now, if the receiver of this information is capable of understanding
> a higher "resolution", then one could start asking questions about
> the probability of where a point (at the receivers highest
> resolution) resides inside the shape that can be taken from the
> senders lower resolution point. I guess that might be useful if
> first responders are sent to the location given by the higher
> resolution point, find nothing, and are then advised to search a
> perimeter of a specific size.
>=20
> It turns out that the other document in this discussion does talk
> about this. From Section 6 of draft-ietf-geopriv-pdif-lo-profile:
>=20
> Generally these locations are expressed as a point
> (either in two or three dimensions) and an area or volume of
> uncertainty around the point. In theory, the area or volume
> represents a coverage in which the user has a relatively high
> probability of being found, and the point is a convenient means of
> defining the centroid for the area or volume. In practice, most
> systems use the point as an absolute value and ignore the
> uncertainty.
>=20
> Interchange "uncertainty" and "resolution" and these documents are
> saying the same thing. Which term is correct? At present, I'm not
> convinced either is.
>=20
> All this leaves me with two very big questions. Since 3825 is
> describing a point in 3 dimensions, why does pidf-lo-profile talk
> about 3825 LCI as being a rectangle in Appendix A? And if 3825 is
> describing a point, how can its equivalent in GML be a linear ring?
> I would think it would be a GML point (or Position in GML speak).
>=20
> -andy
>=20
>=20
>=20
> _______________________________________________
> 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. =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
From geopriv-bounces@ietf.org Mon Sep 11 04:36:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMhHI-0008VS-PR; Mon, 11 Sep 2006 04:36:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMhHI-0008V9-2D; Mon, 11 Sep 2006 04:36:28 -0400
Received: from mail.opengeospatial.org ([208.44.53.140])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GMhHF-0008RY-Lp; Mon, 11 Sep 2006 04:36:28 -0400
Received: from mail.opengeospatial.org (localhost [127.0.0.1])
by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
k8B8a1ls023201; Mon, 11 Sep 2006 04:36:01 -0400
Received: from 218.208.53.35 (SquirrelMail authenticated user creed)
by mail.opengeospatial.org with HTTP;
Mon, 11 Sep 2006 04:36:02 -0400 (EDT)
Message-ID: <3086.218.208.53.35.1157963762.squirrel@mail.opengeospatial.org>
In-Reply-To:
References: <3b16f2ec895557379e48b424be6f0a12@cisco.com>
Date: Mon, 11 Sep 2006 04:36:02 -0400 (EDT)
Subject: Re: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
From: creed@opengeospatial.org
To: "Winterbottom, James"
User-Agent: SquirrelMail/1.4.4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: ClamAV 0.88.4/1846/Sun Sep 10 23:45:12 2006 on
mail.opengeospatial.org
X-Virus-Status: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: geopriv@ietf.org, Marc Linsner , ecrit@ietf.org,
John Schnizlein
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 conversation peaked my interest. I have just looked at RFC-3825. Not
having been privy to all the original discussions and decisions, I am a
fresh set of "eyes" looking at this document. I think what we have here is
a failure to communicate due to ambiguous semantics in 3825. I may be
wrong in this perception, but . . .
My interpretation is that what is being defined is a uncertainty shape in
which the location of the device falls. As such, it is not truly a point.
A point in Euclidean geometry has no size, orientation, or any other
feature except position. This is the basis of the ISO/OGC definition for a
point geometry.
Take the following example. We draw a point by placing a dot with a
pencil. This dot may have a diameter of 0.2mm, but a point has no size. No
matter how far you zoomed in, it would still have no width.
What this discussion is really about is the fact that a point geometry,
whose location is defined by a lat/long coordinate, also has properties.
These properties include estimates of accuracy and precision. Very simply
stated: If the actual value is 4.321 and you say that it is 4.30, then you
are precise to the first decimal place but inaccurate by .021. There are
also properties of error and uncertainty. All these four properties are
very well defined in the literature. For example see:
http://scidiv.bcc.ctc.edu/Physics/Measure&sigfigs/B-Acc-Prec-Unc.html
So, what I would suggest is that perhaps 3825 be modified to very clearly
disambiguate the semantics of the terms being used. I suspect that what
"resolution" is really referring to is a description of the uncertainty of
the measurement. The point being measured falls somewhere in the area of
certainty. The shape of this area (yes, it is an area/polygon) actually
has a pretty strange shape if one transforms from lat/long to some other
coordinate reference system, such as State Plane.
Regards
Carl
> So you are saying that the examples in the appendix of RFC-3825 are
> wrong, and that RFC-3825 cannot and never will describe an area?
>
> It didn't die in Geopriv, I was waiting for you to actual come back with
> an explanation, what you did was write back an email that was totally
> irrelevant to the discussion. So I am still waiting!
>
>
>
>
>
>> -----Original Message-----
>> From: John Schnizlein [mailto:jschnizl@cisco.com]
>> Sent: Sunday, 10 September 2006 10:49 AM
>> To: Winterbottom, James
>> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org
>> Subject: Re: [Ecrit] Location information in emergency
> sessioninitiation,
>> need for time and accuracy?
>>
>> What part of "geographic location of the client" is unclear to you?
>>
>> It is beyond comprehension how this could be interpreted as a area
>> rather than a point, with the resolution of the measurement of that
>> point explicitly included in the location information.
>>
>> Why is this old argument being rehashed in the ecrit WG when if
> finally
>> seemed to die (mercifully) in GeoPriv?
>>
>> On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote:
>>
>> > So I am going to ask you. Point, or area?
>
> ------------------------------------------------------------------------------------------------
> 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 Mon Sep 11 05:03:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMhgm-0002Fy-NA; Mon, 11 Sep 2006 05:02:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMhgN-0001cI-4E; Mon, 11 Sep 2006 05:02:23 -0400
Received: from marauder.andrew.com ([198.17.217.129])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GMhgD-0004Tg-0G; Mon, 11 Sep 2006 05:02:23 -0400
Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 04:02:12 -0500
Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl
E-mail Filter (4.7); Mon, 11 Sep 2006 04:02:12 -0500
Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with
Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 04:02:11 -0500
Message-ID:
From: "Winterbottom, James"
To:
Date: Mon, 11 Sep 2006 04:02:09 -0500
Subject: RE: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 11 Sep 2006 09:02:11.0701 (UTC)
FILETIME=[F7D3A250:01C6D580]
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
In-Reply-To: <3086.218.208.53.35.1157963762.squirrel@mail.opengeospatial.org>
Content-class: urn:content-classes:message
Thread-Topic: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
Thread-Index: AcbVfV5qqSx3y7LMRJWVpJrhuAc7zAAArZGw
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: geopriv@ietf.org, Marc Linsner , ecrit@ietf.org,
John Schnizlein
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,
Thanks for the input.
I guess as far as I see it, this should go one of two ways.
Either, stipulate RFC-3825 as representing a point only, in which case a
specification is required to make this clear and unambiguous.
Or
A specification is required expressing how to interpret the encoding
scheme such that the problems around the equator, prime meridian and
other arbitrary locations are not encountered.
I don't mind which, but a problem exist and supporters of the RFC-3825
mechanism should seek to resolve it. Until such time as it is resolved
this specification should only be used with a great deal of caution.
Cheers
James
> -----Original Message-----
> From: creed@opengeospatial.org [mailto:creed@opengeospatial.org]
> Sent: Monday, 11 September 2006 6:36 PM
> To: Winterbottom, James
> Cc: John Schnizlein; geopriv@ietf.org; Marc Linsner; ecrit@ietf.org
> Subject: Re: [Geopriv] RE: [Ecrit] Location information in emergency
> sessioninitiation, need for time and accuracy?
>=20
> This conversation peaked my interest. I have just looked at RFC-3825.
Not
> having been privy to all the original discussions and decisions, I am
a
> fresh set of "eyes" looking at this document. I think what we have
here is
> a failure to communicate due to ambiguous semantics in 3825. I may be
> wrong in this perception, but . . .
>=20
> My interpretation is that what is being defined is a uncertainty shape
in
> which the location of the device falls. As such, it is not truly a
point.
> A point in Euclidean geometry has no size, orientation, or any other
> feature except position. This is the basis of the ISO/OGC definition
for a
> point geometry.
>=20
> Take the following example. We draw a point by placing a dot with a
> pencil. This dot may have a diameter of 0.2mm, but a point has no
size. No
> matter how far you zoomed in, it would still have no width.
>=20
> What this discussion is really about is the fact that a point
geometry,
> whose location is defined by a lat/long coordinate, also has
properties.
> These properties include estimates of accuracy and precision. Very
simply
> stated: If the actual value is 4.321 and you say that it is 4.30, then
you
> are precise to the first decimal place but inaccurate by .021. There
are
> also properties of error and uncertainty. All these four properties
are
> very well defined in the literature. For example see:
> http://scidiv.bcc.ctc.edu/Physics/Measure&sigfigs/B-Acc-Prec-Unc.html
>=20
> So, what I would suggest is that perhaps 3825 be modified to very
clearly
> disambiguate the semantics of the terms being used. I suspect that
what
> "resolution" is really referring to is a description of the
uncertainty of
> the measurement. The point being measured falls somewhere in the area
of
> certainty. The shape of this area (yes, it is an area/polygon)
actually
> has a pretty strange shape if one transforms from lat/long to some
other
> coordinate reference system, such as State Plane.
>=20
> Regards
>=20
> Carl
>=20
>=20
> > So you are saying that the examples in the appendix of RFC-3825 are
> > wrong, and that RFC-3825 cannot and never will describe an area?
> >
> > It didn't die in Geopriv, I was waiting for you to actual come back
with
> > an explanation, what you did was write back an email that was
totally
> > irrelevant to the discussion. So I am still waiting!
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: John Schnizlein [mailto:jschnizl@cisco.com]
> >> Sent: Sunday, 10 September 2006 10:49 AM
> >> To: Winterbottom, James
> >> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org
> >> Subject: Re: [Ecrit] Location information in emergency
> > sessioninitiation,
> >> need for time and accuracy?
> >>
> >> What part of "geographic location of the client" is unclear to you?
> >>
> >> It is beyond comprehension how this could be interpreted as a area
> >> rather than a point, with the resolution of the measurement of that
> >> point explicitly included in the location information.
> >>
> >> Why is this old argument being rehashed in the ecrit WG when if
> > finally
> >> seemed to die (mercifully) in GeoPriv?
> >>
> >> On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote:
> >>
> >> > So I am going to ask you. Point, or area?
> >
> >
------------------------------------------------------------------------
> ------------------------
> > 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
>=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
From geopriv-bounces@ietf.org Mon Sep 11 10:20:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMmdT-000361-CL; Mon, 11 Sep 2006 10:19:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1GMmdS-00035t-7Y; Mon, 11 Sep 2006 10:19:42 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
by ietf-mx.ietf.org with esmtp (Exim 4.43)
id 1GMmdQ-0002Lu-T0; Mon, 11 Sep 2006 10:19:42 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
by sj-iport-5.cisco.com with ESMTP; 11 Sep 2006 07:19:41 -0700
X-IronPort-AV: i="4.09,146,1157353200";
d="scan'208"; a="319852473:sNHT33897622"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
k8BEJeIX006614; Mon, 11 Sep 2006 07:19:40 -0700
Received: from [10.10.10.212] (sjc-vpn2-738.cisco.com [10.21.114.226])
by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8BEJbw7001599;
Mon, 11 Sep 2006 07:19:39 -0700 (PDT)
In-Reply-To: <3086.218.208.53.35.1157963762.squirrel@mail.opengeospatial.org>
References: <3b16f2ec895557379e48b424be6f0a12@cisco.com>
<3086.218.208.53.35.1157963762.squirrel@mail.opengeospatial.org>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id:
Content-Transfer-Encoding: 7bit
From: John Schnizlein
Subject: Re: [Geopriv] RE: [Ecrit] Location information in emergency
sessioninitiation, need for time and accuracy?
Date: Mon, 11 Sep 2006 10:19:40 -0400
To: creed@opengeospatial.org
X-Mailer: Apple Mail (2.624)
DKIM-Signature: a=rsa-sha1; q=dns; l=3101; t=1157984380; x=1158848380;
c=relaxed/simple; s=sjdkim7002;
h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
d=cisco.com; i=jschnizl@cisco.com;
z=From:John=20Schnizlein=20
|Subject:Re=3A=20[Geopriv]=20RE=3A=20[Ecrit]=20Location=20information=20in=20emer
gency=20=20sessioninitiation,=20need=20for=20time=20and=20accuracy?;
X=v=3Dcisco.com=3B=20h=3DPXYtkYxFinjFm/dJ0pLaUwpqHKA=3D;
b=Ja3V4E0cZzdmv5NmIBKf3qQjDF76WXpzA5mDkbwn415aTPPtXVkwtdBCf5nNYA6O+ltMfxPw
evM7IoD3LXghD3g23zGot3Iq76xOOnpEnkGgiygtKFUK7u3Z5qb/JdON;
Authentication-Results: sj-dkim-7.cisco.com; header.From=jschnizl@cisco.com;
dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: geopriv@ietf.org, Marc Linsner , ecrit@ietf.org
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy
List-Unsubscribe: ,
List-Post: