Subject: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt

From: [email-masked]
Date: Fri, 17 Jan 2003 07:23:45 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title		: DHC Location Object within GEOPRIV
	Author(s)	: J. Polk, J. Schnizlein, M. Linsner
	Filename	: draft-ietf-geopriv-dhcp-lo-option-00.txt
	Pages		: 12
	Date		: 2003-1-16
	
This document specifies a Dynamic Host Configuration Protocol Option for 
the geographic location of the client. The location object includes 
latitude, longitude, and altitude, with resolution indicators for each.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lo-option-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-geopriv-dhcp-lo-option-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-geopriv-dhcp-lo-option-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

---

From: Carl Reed <[email-masked]>
Date: Mon, 20 Jan 2003 19:12:39 -0700

I have done an initial review of the document. To insure proper
interoperability with the geospatial and location services domains, I would
encourage the inclusion of a parameter that provides metadata on the
datum(s) in which the latitude and longitude are being provided. Without
this information, the location provided may not be able to be properly
georegistered with other digital spatial repositories being used (such as
those in the E-911) world. This could result in responders to an emergency
not being able to determine where the individual (or individuals) are
actually located. And, unfortunately one cannot always assume a default
datum, such as WGS 84. However, the impact on the size of the location
object of providing this information is minimal. For international use and
standards consistency, you could use a binary representation of the EPSG
code.

Regards

Carl Reed
OGC

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 20 Jan 2003 20:36:14 -0600

At 07:12 PM 1/20/2003 -0700, Carl Reed wrote:
>actually located.

Excellent point.

The authors believe this is a function of the Geopriv Protocol (or Using 
Protocol of the Geopriv Location Object) - and either one of those is best 
for supplying this Field in the message.

>And, unfortunately one cannot always assume a default
>datum, such as WGS 84.

agreed

>However, the impact on the size of the location
>object of providing this information is minimal.

I can envision it only taking a few bits if each value within a field of 
this option are registered with IANA. But I don't yet think it's necessary 
to add to this ID (Geopriv should include it in the Reply Header to a 
authorized Location Request).

>For international use and

cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Jan 2003 17:18:57 -0500

I don't understand. Why wouldn't the DHCP server have to indicate what 
datum is being used? After all, the device receiving the information has 
no way of knowing.

James M. Polk wrote:
> Protocol of the Geopriv Location Object) - and either one of those is 
> best for supplying this Field in the message.
> 
> this option are registered with IANA. But I don't yet think it's 
> necessary to add to this ID (Geopriv should include it in the Reply 
> Header to a authorized Location Request).
>

---

From: Marc Linsner <[email-masked]>
Date: Tue, 21 Jan 2003 17:39:07 -0500

The thought was that since the geo-loc received was from a local source, it
would be derived from the datum in use locally.  Since datum is a political
issue, who cares what it is as long as it's the correct one for the locale
I'm in.  Obviously, if you derive your location via some other means, your
own gps, datum is an issue.  For the propose of the draft, it was assumed
that the maker of the 'wire map' would use the local datum.

-Marc Linsner-

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2003 5:19 PM
> To: James M. Polk
> Cc: Carl Reed; [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Jan 2003 17:42:08 -0500

I'm still missing something here. If I visit Cisco with my device, I 
have no clue what datum you are using. If I then use this information on 
my mapping software or to create a trip log or do anything else, I need 
to know. How else would a random stranger walking into an 802.11 network 
at Starbucks know?

---

From: Marc Linsner <[email-masked]>
Date: Tue, 21 Jan 2003 18:42:00 -0500

OK, what purpose would it serve for the Cisco San Jose campus network to
pass you a geo-loc using datum other than WGS84, since that is the datum
used in the US?  BTW, map datums are country wide, so it's not like every
county in the US is using a different reference.

It's like knowing what time zone you are in.....for purposes of making the
wg sessions on time, you didn't care what the time zone was in Yokohama, as
long as the clock in your hotel was in sync with the clock in the meeting
rooms.  But if you left your watch on EST, then you would need to know the
time zone to derive the offset.

Granted, there are reasons to know the map datum used to derive a geo-loc,
but the purpose of the draft was to define an object to be passed by a dhcp
option to a 'hard-wired' client.  Certainly your mapping software could show
you that you are standing in the middle of the street instead of inside
Starbucks if your software was set on a different map datum than the one
used to pass your geo-loc via dhcp.

I don't object to adding a couple of bytes to include the map datum used,
I'm just stating the thought process when writing the draft.

-Marc Linsner-

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Jan 2003 20:25:43 -0500

> county in the US is using a different reference.

I don't want to have to configure my laptop or 3G phone for each country 
I'm in. I was in three different ones today, not counting the ones I 
crossed at 39,000'. In general, I find any new system that requires the 
user to make any manual adjustments deficient, particularly on such 
obscure items like a datum. Nobody is going to get that right. We need 
to design for autoconfiguration and user mobility (and for uses that may 
not be obvious right now).

> rooms.  

I gather you are advocating we go back to the ca-1850 style of US time 
keeping, where each city had its own "time zone"?

Your assumption assumes local use only. This is not true for geo 
information which is often used in very different locales.

> But if you left your watch on EST, then you would need to know the

Given that your format provides for millimeter-level accuracy for the 
location, it makes sense to include the information that allows for this 
in practice.

> I'm just stating the thought process when writing the draft.

I just fail to see the disadvantage of adding the datum byte. If you 
wanted to save bytes, there would have been better ways to do that (such 
as variable-length coordinates). I'm not suggesting you do the latter, 
but I find these byte-pinching exercises a bit strange, given that one 
serious mistake or debugging exercise is going to cost more than these 
bytes ever will.

---

From: Marc Linsner <[email-masked]>
Date: Wed, 22 Jan 2003 09:38:39 -0500

It is obviously the sentiment that a field is needed to express map datum
used to derive the geo-loc data within the LO.  In a short search, it
appears there are ~260 different map datum.  There is a trend globally to
move towards WGS84, and several political entities have already made the
move.  One of the largest GPS manufacturers decided 5 years ago that only
~100 were necessary to load into their products.  So with this market data
in mind showing the diminishing use of all of the defined datum, I propose
that we add a 1 byte field to the LO and define code=1 to be WGS84 with the
remaining codes to be assigned by IANA via future requests.

Would this satisfy everyone's needs?

-Marc Linsner-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Jan 2003 09:49:09 -0500

Since this information is likely to be needed for other geo formats, at 
least the binary ones, it would be nice to create a general IANA 
registry, not one specific to the DHCP option. Does LIF define a text 
string for each of datums?

---

From: Carl Reed <[email-masked]>
Date: Wed, 22 Jan 2003 16:29:38 -0700

No, but EPSG does. The EPSG database has now become the normative reference
for coordinate reference systems (including datums) for many organizations
such as the petroleum industry, numerous GIS vendors, the OGC and LIF/OMA.
The OGC has recently developed an on-line registry for the common reference
systems and datums expressed in the EPSG database. Perhaps we could look to
the EPSG.

Just a thought -

Carl

----- Original Message -----
From: Henning Schulzrinne <[email-masked]>
To: Marc Linsner <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 22, 2003 7:49 AM
Subject: Re: LO Option Proposal (was: Re:
I-DACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt)

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Jan 2003 09:58:15 -0500

Since there's no point in having IANA duplicate the work of the EPSG, it 
makes sense to just use that database. We need a small numeric 
identifier that can be derived from that database, e.g., by subtracting 
some fixed offset from a larger identifier.