Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft)

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 5 Feb 2001 10:44:54 -0500

There was an effort started several IETFs ago to define a PROTOCOL
to exchange geographic location.  That was shot down.  There is still
a low level effort to define a format for exchanging such information.

Before starting another effort, you might want to look at the prior
work (spatial).  You also MUST forthrightly face up to the privacy
concerns that have stymied other efforts.  The security implications of
knowing where you are can be VERY daunting, and in general discussions
on the issues have yielded more problems than answers.'

Brian

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Saturday, February 03, 2001 4:49 PM
> To: Mark Watson
> Cc: [email-masked]'
> Subject: Location information (was Re: [SIP] SIP Privacy Draft)
> 
> 
> > Mark Watson wrote:
> [...]
> > 5) Location Information
> > 
> > A further type of Party information is the physical 
> location of the Party. This is useful for calls to emergency 
> service centers and for geographic routing services. There is 
> apparantly a URL format for geographic location, so this 
> could be used for this purpose.
> 
> Where is the URL format specified?
> 
> I agree that URL is a good place to accomodate geographical 
> location and it
> would be useful to have a standardized notation. 
> draft-daviel-http-geo-header-02.txt
> specifies header fields for conveying location in HTTP. 
> However as the position 
> identifies services and may be used with more protocols than 
> just HTTP I would 
> prefer conveying it in URLs.
> 
> Henning's 911 draft also addresses many of related issues. 
> 
> Is there interest in going ahead with such URLs?
> 
> Jiri
> 
> 
> 
> ------------
> P.S. It seems to me there are some geo-service points on 
> which some folks 
> like to disagree. Let me give a couple of more details from 
> my perspective 
> so that we can save a couple of RTTs if there is interest in 
> discussing this.
> - URL format for conveying geo-info is a URL format and 
> nothing else. There 
>   are three orthogonal jobs: 1) determining geo-info, 2) 
> finding a server 
>   providing location-base services and 3) conveying the 
> geo-info to it. 
>   Geo-info in URLs would make only the third job. 
> - The geo-info may be gained from anywhere: access providers, 
> from GPS provider, 
>   typed-in by sextant-equipped user, from IPv6 address, etc. 
> It does not have to 
>   indicate your current position; for example, when planning 
> a trip a travelling 
>   agent may want to get connected to a hotel nearby his 
> client's destination.
> - Both end-devices and proxies (if they know it) may insert 
> geo-info. The latter
>   case may be subject to privacy issues -- users may not be 
> always happy to 
>   disseminate geo-info.  
> - No limitations are put on how to find location-based 
> services. They may be
>   located at an outbound proxy discovered automatically using 
> DHCP but they
>   may be at Jeff's pizza server advertised in newspaper as well.
> - No assumptions are made about what the services are; it is 
> service providers'
>   discretion to implement "conntact a Pizza Inc. rep in 
> caller's proximity", 
>   "notify my parents whenever I move", "emergency", etc.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 5 Feb 2001 18:08:21 -0000

There is however a requirement in existing protocols for passing this
information around within network entities. Therefore you will see support
in ISUP, MAP, INAP and CAMEL for such an identifier. I believe that there is
requirement to be able to carry this identifier within SIP, although not in
"clear" to the user entities. Work done in ITU-T and in ETSI, both in the
services area and in the ISUP area, defined this identifier as another form
of calling line identity.

The usage in these protocols is all based on the same set of underlying
variants, of which the best definition in protocol independent terms is
probably in the following 3GPP reference 

TS 23.032.

3rd Generation Partnership Project; 
Technical Specification Group Core Network; 
Universal Geographical Area Description (GAD)

and which may be found at the following URL

ftp://ftp.3gpp.org/Specs/2000-12/R1999/23_series/23032-310.zip 

Due to the need to interwork between SIP and other protocols, it would
appear to be essential to maintain the same number and type of parameters
within the SIP encoding, although some difference will obviously have to
exist at the transfer level to allow a text encoding in SIP, while the other
protocols use a binary encoding.

This is not a matter of telling the IETF what to do, it is merely that every
other signalling protocol in the world appears to use a subset of these
formats.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Rosen, Brian[SMTP:[email-masked]]
> Sent: 	05 February 2001 15:44
> To: 	'Jiri Kuthan'; Mark Watson
> Subject: 	RE: Location information (was Re: [SIP] SIP Privacy Draft)
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 5 Feb 2001 13:28:04 -0500

The cited proposal uses WGS84, which is the accepted standard for
world coordinates.  I know that there is some variability in the precise
ellipsoid definitions that have some national variation.  I'm not enough
of an expert to know which version this represents, but it appears to offer
no variation, so they probably picked one and went on; a position I favor.
It also seems to have all of the variables one might want (including motion 
vectors).  So, I would agree that we want to have something very closely 
aligned with this format in terms of parameters.

I didn't see anything having to do with intentional degrading of
accuracy, so that is one missing capability.

Brian

> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Monday, February 05, 2001 1:08 PM
> To: 'Jiri Kuthan'; Mark Watson; 'Rosen, Brian'

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 6 Feb 2001 11:53:21 -0000

See below.
Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> Sent: 	05 February 2001 18:28
> To: 	'Drage, Keith (Keith)'; 'Jiri Kuthan'; Mark Watson
This is certainly based on WGS84, as the intention when it was defined was
not to invent something new. I am not sure how well it now corresponds
because I have only ever worked from this document (as have ETSI, 3GPP and
ITU-T), and not from WGS84.

> accuracy, so that is one missing capability.
The document developed over time. For reasons of compatibility new
descriptions were added rather than modify old descriptions. The later
additions were principally "uncertainty" and "confidence" so you will find
some descriptions that include them and some that do not. I believe these
are the terms you are looking for.

By the way we do not need to cater for all descriptions in this document.
Rather it should be a shopping list where the selection of descriptions:

a)	fulfils the requirements of the SIP community
b)	can be mapped to those used by ISUP, MAP, INAP and CAMEL (and any
other protocols that people can identify as important but which I do not
know about).