Subject: [sipcore] Use of term "Location Server" in location-conveyance draft

From: "Elwell, John" <[email-masked]>
Date: Fri, 03 Jul 2009 07:37:18 +0100

The separate thread arising from my review of the draft has left me very
confused about what exactly the term "Location Server" means in this
draft.

The draft itself says:
" A [RFC3693] defined "Using 
   Protocol" describes how a "Location Server" transmits a "Location 
   Object" to a "Location Recipient" while maintaining the contained 
   privacy intentions of the Target intact. This document describes the
   extension to SIP for how it complies with the Using Protocol 
   requirements, where the location server is a UA or Proxy Server and 
   the Location Recipient is another UA or Proxy Server."
My review comments that touched on this subject assumed the above
definition.
According to this, the server that the Location Recipient goes to to
dereference the LbyR URI is NOT a Location Server. But some of the
thread messages have suggested it IS a Location Server. We cannot use
the term Location Server to mean two different things. Can somebody
please clarify?

John

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 12 Jul 2009 23:39:48 -0500

john

Sorry I missed this note earlier... see below

>the term Location Server to mean two different things. Can somebody

In Geopriv, a Location Server (LS) is an entity that transmits 
location towards a Location Recipient (LR).  This transmission might 
take that message through another LS before getting to the LR.

In SIP terms, a UA or SIP server (of whatever flavor) that inserts 
location into a message (as a message body or as a dereferencable 
location URI) is an LS.

A B2BUA that completes a call leg that contains location, and 
regenerates a new SIP request towards another B2BUA or UAS with that 
location in the new SIP request is also an LS.

A proxy that inserts a dereferencable location URI is an LS.

A proxy that does not insert a dereferencable location URI is NOT an 
LS (this time). It is basically performing a repeater function that 
is not defined in Geopriv.

A UAS that understands location (i.e., something close to the 
Location Conveyance extension) is an LR.  A UAS that receives 
location - but does not understand Location Conveyance - is not an LR 
(because it doesn't do anything with the location except throw it away).

A SIP server that retargets a SIP request after viewing the contained 
location in that SIP request is also an LR, and because it did 
something with the location - I think it can be called an LS too (but 
some might disagree).

A good example of this last case is a location source based routing 
proxy that retargets a R-URI based on the contained location within a 
SIP request, like say - an INVITE to 911.

In this case, that proxy is an LR and an LS.  The UAC is a Location 
Generator (LG) and an LS; and the PSAP call center (i.e., the UAS for 
the call) is an LS.

Confused?

:-p

Geopriv elements change roles based on what they do, or can do.

The only debatable label here is LG, as the label seems to have 
changed since RFC 3693 (Geopriv Requirements) which I co-authored - 
and the new doc describing the new functions isn't an RFC yet, and is 
shifting positions with a couple of its definitions lately (i.e., 
within the last year).

James

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 13 Jul 2009 07:20:38 +0100

James,

I have to say this is mighty confusing. Basically location-conveyance is
an extension to SIP, and therefore its primary purpose is to specify the
SIP protocol and the behaviour of the various SIP entities involved. To
have an important term that sometimes can mean a SIP entity (the SIP
entity that inserts the Geolocation header field) and sometimes
something quite unrelated to SIP location conveyance (the entity to
which the dereferencing request is sent) strikes me as something we
should avoid. In my opinion we should do one of the following:

1. Limit LS to having only one of these meanings, and if necessary
introduce a new term for the other case. If this is not possible because
it would conflict with other published documents, then do it locally
within sip-location-conveyance using appropriate language ("For the
purposes of this document, location server means....")

2. Avoid the term LS altogether in this document and define new terms
for the various different purposes.

John

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: 13 July 2009 05:40
> To: Elwell, John; [email-masked]; [email-masked]
> Subject: Re: Use of term "Location Server" in 
> location-conveyance draft
> 
> john
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 Jul 2009 01:56:11 -0500

John

in-line

At 01:20 AM 7/13/2009, Elwell, John wrote:
>should avoid.

welcome to my world... ugh

>In my opinion we should do one of the following:
>
>introduce a new term for the other case.

I thought we had a server entity term defined that was just for 
dereferences, called a Location Information Server (LIS), but 
apparently that term was taken (hijacked?) just for Location 
Configuration Protocols (LCPs) like DHCP and especially HELD. See 
Martin's recent message clarifying this to me.  It was news too.  I 
say especially HELD because it appears that crew actually did the 
"taking" deed.

It appears to me that Location Servers that are essentially peers 
that communicate location values or references in the signaling path 
of the original SIP request is a good delineation.

Then, having another term defining what entity the location URIs 
point at (i.e., the dereferencing function) should NOT be called the 
same thing, this is what I was calling a LIS (Location Information 
Server), which had a unique function, storing all the PIDF-LOs for 
the location targets (prior to any dereferencing).

>  If this is not possible because

interesting... that would mean I (or a small group) would be defining 
a small parallel set of terms that do not go anywhere else except in 
the case of Conveyance...

Can I recommend you send this suggestion (with the WHY!) to Keith 
Drage? He's the doc shepherd for this ID.  That will probably go the 
farthest. CCing the chairs would always be a good idea.

I hope to have the final version ready for WGLC before the milestone 
date of Sept 09.

This will take a little thought once it's solved for, but it's pretty 
much a global replace function once we come up with a set of terms to use.

-01 of conveyance will be out tomorrow, and Spencer Dawkins did a 
pretty good job at making it easier to read.  He didn't address the 
term confusion though.

This term issue aside, I was hoping this -01 version was the version 
that went to WGLC.

>for the various different purposes.

yeah -- that would be what I'd have to do -- if the chairs and the 
shepherd agree to this.  We all can talk live about this in Stockholm 
hopefully.

BTW - if it's not clear yet within this message -- I'm not opposed to 
doing this (because of the confusion associated with this topic).

James

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 13 Jul 2009 08:15:33 +0100

James,

It occurs to me we already have the term location inserter used in
various places in the document, so why don't we stick to this, rather
than location server, for the UA or proxy that inserts? Then we could
use the term location server for the server you go to to dereference
LbyR.

I agree with others, by the way, that LIS is not an appropriate term for
the latter.

John 

> Sent: 13 July 2009 07:56
> To: Elwell, John; [email-masked]
> Cc: marc Linsner (mlinsner)
> Subject: RE: Use of term "Location Server" in

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 Jul 2009 12:36:44 -0500

>use the term location server for the server you go to to dereference

I thought about that - but the Geopriv Arch -00 ID just came out and 
the 6 authors there decided the LS is the location inserter in their 
terminology and the LIS is the dereferencer *but* only if a target 
wants to dereference their own location. If another entity wants to 
dereference your location, it is not a LIS, it's just an LS.

I believe this is even more confusing.

BTW - the LIS is who provides a target its DHCP or LLDP-MED or HELD 
location information too. Meaning, the LIS has to be able to do L2 
downloads of LI *and* L7 subscriptions.

>I agree with others, by the way, that LIS is not an appropriate term for

see above, it now *IS* the proper term for the latter, but only if it 
is the target that's doing it.

Talk about shifting roles...

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 Jul 2009 13:52:14 -0500

John

How about using the terms

- Location Inserter (just how it is defined in the doc now)
and
- Dereference Server (DS) (instead of Location Server) for the server 
that UAs subscribe to (using the location URI), to attain a Target's 
geolocation in a PIDF-LO format.

there can't be an acronym for the inserter, because LI means Location 
Information, and that ought to stay unconfused by this doc.

But DS could be the acronym for Dereference Server - and *not* have a 
limit on who can dereference from it (a target itself or a 3rd party).

These would become SIP terms, just as Target in Geopriv is a 
Presentity in Presence terms.

Let me know what you (and others) think about this.

This can't make it into the -01 version (which I'm about to submit) 
since there is no WG consensus on the matter, but that can be 
achieved fairly quickly though if we try.

James

At 12:36 PM 7/13/2009, James M. Polk wrote:
>see above, it now *IS* the proper term for the latter, but only if 
>it is the target that's doing it.
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 13 Jul 2009 21:19:34 +0100

> Sent: 13 July 2009 18:37
[JRE] That has always been my understanding.

> is the target that's doing it.
[JRE] But in the context of sip-location-conveyance, the UAS or a proxy
that receives the location will NEVER be the target, so it will NEVER be
a LIS when dereferencing occurs.

John

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 13 Jul 2009 21:20:08 +0100

That would work.

John 

> Sent: 13 July 2009 19:52

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 Jul 2009 15:59:55 -0500

>a LIS when dereferencing occurs.

that's not true. Conveyance states that a target can take its 
location URI and subscribe to it to receive its PIDF-LO. This has 
been in there for a while.

Now, which entity does the target subscribe to, the LIS or an LS?

James

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 Jul 2009 16:00:23 -0500

>That would work.

cool

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 14 Jul 2009 07:40:39 +0100

> Sent: 13 July 2009 22:00
[JRE] Perhaps NEVER is wrong, but HIGHLY UNLIKELY. Why would Bob's UAC
(or a proxy) insert Alice's LbyR into a request sent to Alice, such that
Alice's UAS receives Alice's LbyR and attempts to dereference?

John

> > > > > > > >The separate thread arising from my review of 
> the draft has
> > > > > > > left me very
> > > > > > > >    privacy intentions of the Target intact. 
> This document
> > > > > > > describes the
> > > > > > > >    requirements, where the location server is a 
> UA or Proxy
> > > > > > > Server and

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 15:09:45 -0500

>Alice's UAS receives Alice's LbyR and attempts to dereference?

I don't believe Bob would sent Alice her location URI to be 
dereferenced by Alice, but I don't believe we ought to prevent it.

I do see Alice receiving several of her friends' (i.e., buddy's) 
locations, say at a shopping mall, and then telling Carol where all 
their friends are in one message.

I have 2 daughters, 21 and 11, and the 21 yr old asked a couple of 
years ago when this can be possible so she can use it.  The 11 yr old 
is just starting to understand how this can be used.  Operators may 
not configure this ability, but the protocol shouldn't prevent it 
from all operators being able to offer the capability.