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

From: [email-masked]
Date: Tue, 21 Jan 2003 18:24:35 -0700 (MST)

Exactly. I am providing the following from similar work we did in the OGC and also in conjunction with the Location Interoperabity Forum (LIF, now OMA)

Another example. We have a draft interface specification called "Gateway Service". This is a network-accessible service that fetches the position of a known mobile terminal from the network. This interface is modeled after the Mobile Location Protocol (MLP), Standard Location Immediate Service, specified in LIF 3.0 (see Open Mobile Alliance). Upon receiving a request from a client application, the Gateway Service returns the geographic coordinates of the mobile station (Position ADT).

The use case

7	A Location Request Use Case
A subscriber wants to use a Location-Based Service. The Gateway Service is employed to obtain the position of the subscriber’s mobile terminal from the network. A Location Service Client sends the request to determine a position to the Gateway. The Gateway calculates the position of the subscriber’s mobile terminal and forwards to the Location Service Client, which may store it for as long as needed. The request will be sent to the gateway as follows:

<GatewayParameters priority="HIGH" locationType="CURRENT_OR_LAST" requestedsrsName="WGS84">
		<MSIDS>
			<MSInformation  msIDType="IPV4" msIDValue="461018765728"></MSInformation>
		</MSIDS>
		<RequestedQoP responseReq="No_Delay" responseTimer="20">
			<HorizontalAcc>
				<Distance value="1000"></Distance>
			</HorizontalAcc>
		</RequestedQoP>
	</GatewayParameters>

The gateway response will be provided as follows:
		<Response version="1.0" requestID="32">
		<Position levelOfConf="85">
			<Point>
				<Coord>23432,5432</Coord>
			</Point>
		</Position>
		</Response>

Notice the reference to WGS84. We went through a similar set of discussions with the LIF membership (TelCOs, infrastructure folks, network providers) and jointly came to the conclusion that datum was a mandatory.

I can provide more information if required.

Carl

-------Original Message-------
From: Henning Schulzrinne <[email-masked]>
Sent: 01/21/03 03:42 PM
To: Marc Linsner <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt

> 
> 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?

Marc Linsner wrote:
> 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-
>

---

From: Martin Layley <[email-masked]>
Date: Wed, 22 Jan 2003 10:18:25 +0000

There is a big problem if the entity you are communicating with is in a different part of the world.  It is not always possible to work out which country an originator is in from the location data alone, especially if something is misconfigured for the locality (e.g. 3 different countries in a day!).  There are some serious internationalisation issues here.  If you use the telephone call centre as a parallel (after all, one of the discussions earlier was about IP phones), there is a trend to re-locate call centres to India.  That Indian call centre will be handling queries from all over the world.  If it needs to know an entity's location, what datum should it assume?

Translating location data from one datum to another will always accumulate errors.  If the datum for an item of location data is known and can be stored/communicated, then the location data will need to be translated a maximum of once.  If the datum has to be guessed, or cannot be stored, then systems will have to translate into the local datum space and errors will accumulate.

		Martin Layley
		Samsung SERI

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
Sent: 21 January 2003 23:42
To: Henning Schulzrinne
Cc: James M. Polk; Carl Reed; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt

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-

> > 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

The mail message has been scanned by MAILsweeper
for content analysis.