Subject: RE: [Geopriv] coming to terms on location by reference

From: "Ciesla, Larry" <[email-masked]>
Date: Tue, 19 Sep 2006 14:00:00 -0500

Greetings,

I've been watching the discussion regarding LbyR and was curious if the
following has been discussed or might be covered in some way with LbyV:

It seems to me that there might well be situations involving mobile VoIP
handsets where location is determined by GPS, angle of arrival, time
difference of arrival, or some other kind of radio-location technique.
In today's network, some of this type of radio-location is done solely
in the handset (e.g.: GPS) and some depends upon some assistance from a
network element (e.g.: PDE in the wireless context.)  The point is that
location in this context is often expensive both from a
"processing-cycle" perspective, a "battery life" perspective, and a
"time to locate" perspective.  Our experience with cellular and phase 2
is that it is often the case that the handset does not know its location
at the time the 9-1-1 call is made.  It seems likely that for some
fraction of highly mobile VoIP devices, location technology similar to
that used for wireless today might be employed and location might not be
available at the time the call is placed.  Best-guess routing is used
with cellular to get the caller to the correct PSAP based on cell site,
but the caller's actual location might not be known until some time has
passed, thus making it of no use for routing purposes.  There are also
rare cases where the caller might have terminated the call but the PSAP
still needs to locate the caller.  Consider the case where the battery
is nearly done and the caller disconnects to conserve battery power.
So, it seems to me that location by reference supports the real-world
use case typically seen today in cellular where the phone is passive in
its location determination and, if involved at all, is "assisted" by a
network element (e.g.: assisted GPS.)  For other location technologies
(e.g.: angle of arrival, time difference of arrival, etc.) the phone is
not involved in any way in the act of location.

Please excuse this intrusion if this matter has already been discussed,
but I would urge you to consider technical implementations where the
calling device is really just a cell phone that happens to be working
over a VoIP wireless network of one kind or another.  It seems very
likely that cellular carriers will want to employ (if possible) whatever
location technology was chosen for locating the phone when it is
operating in the cellular network.  Today, that cellular position
determination entity (PDE) is passed a reference to the device requiring
locating.

Regards,

Larry Ciesla

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, September 15, 2006 5:22 PM
To: 'Winterbottom, James'
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] coming to terms on location by reference

Within NENA, LbyR was accepted due to the advertising, by a few, of what
it
will deliver.  Such advertising is the true FUD.  This community has
reviewed that advertising and categorized it properly.  Sorry NENA, you
were
told something that is not possible to deliver.

-Marc-

> -----Original Message-----
> From: Winterbottom, James [mailto:[email-masked]] 
> Sent: Friday, September 15, 2006 5:59 PM
> To: Marc Linsner; Dawson, Martin
> Cc: GEOPRIV
> Subject: RE: [Geopriv] coming to terms on location by reference
> 
> Marc,
> 
> You are a number of colleagues in this discussion were the 
> ONLY opponents to LbR in NENA and you lost that argument 
> handsomely. At that point it was made clear by the same 
> league of individuals that they would not let LbR fly in the 
> IETF. So far I have only seen the same misinformed FUD being 
> thrown around, and the same people opposing it.
> Please come back with something that is constructive.
> 
> Cheers
> James
> 
> 
> 
> > -----Original Message-----
> > From: Marc Linsner [mailto:[email-masked]]
> > Sent: Saturday, 16 September 2006 1:08 AM
> > To: Dawson, Martin
> > Cc: 'GEOPRIV'
> > Subject: RE: [Geopriv] coming to terms on location by reference
> > 
> > Martin,
> > 
> > Why did i2 promise LbyR functionality prior to IETF review, 
> if in fact 
> > NENA was dependent on IETF for such a mechanism?
> > 
> > Promises YOU made in i2 does not force consensus in GeoPriv.
> > 
> > Btw, I do believe there is middle ground on LbyR!
> > 
> > -marc-
> > 
> > > -----Original Message-----
> > > From: Dawson, Martin [mailto:[email-masked]]
> > > Sent: Friday, September 15, 2006 10:43 AM
> > > To: Brian Rosen; Hannes Tschofenig
> > > Cc: GEOPRIV; Thomson, Martin; Henning Schulzrinne
> > > Subject: RE: [Geopriv] coming to terms on location by reference
> > >
> > > Feel free to take the suggestion to i2.5; it's a noble 
> cause and I'm 
> > > sure the ensuing discussion will be interesting. I believe your 
> > > proposal is eminently complex, fraught with implementation 
> > > difficulties, and will meet with considerable resistance 
> from both 
> > > VSPs and the vendors of soft switch products. I think you'd be 
> > > better off waiting for i3 where the peer signaling relationship 
> > > between the PSAP and the terminal can be capitalized on.
> > >
> > > In the mean time, i2 is in the process of implementation 
> so having 
> > > the IETF not helping will only likely make the IETF not 
> relevant to 
> > > its development which will ultimately make the ability of 
> the IETF 
> > > to contribute to further evolution that much more 
> difficult. A great 
> > > pity.
> > > The location reference mechanism will need to be supported, by 
> > > wireless LIS operators at least, one way or the other.
> > >
> > > Cheers,
> > > Martin
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:[email-masked]]
> > > > Sent: Friday, 15 September 2006 10:00 PM
> > > > To: Dawson, Martin; 'Hannes Tschofenig'
> > > > Cc: Thomson, Martin; 'Henning Schulzrinne'; 'GEOPRIV'
> > > > Subject: RE: [Geopriv] coming to terms on location by reference
> > > >
> > > > > Why is there any relevance to whether the PSAP request is
> > > initiated
> > > by
> > > > > the CPE automatically or by an operator clicking a button
> > > on a CPE
> > > > > screen. It seems about as relevant as the DHCP point.
> > > > At first blush, it seems that there is value in making a direct
> path
> > > from
> > > > the LIS to the VPC (where the VPC is the watcher), rather
> > > than looping
> > > > through the endpoint.  However, when you look at the actual
> > > use case,
> > > I
> > > > think there is little value.  The reason is that the 
> frequency of
> > > update
> > > > is
> > > > very low, so low that any optimization seems pretty worthless.
> > > >
> > > > The FIRST location operation is MORE complex (the endpoint gets
> the
> > > > reference from the LCP, sends it to the VPC, the VPC
> > > exchanges it for
> > > > location with the LIS).  The second operation would, if 
> there was
> a
> > > direct
> > > > connection, be more efficient (VPC to LIS).  Average them
> > > for two dips
> > > and
> > > > it's a wash.  But 2 dips IS the usual case.
> > > >
> > > > They both work.  There is no functionality difference 
> except that
> in
> > > the
> > > > LbyR you need an extra interface and path.
> > > >
> > > > i2 is a lousy use case for LbyR
> > > >
> > > > >
> > > > > And a VPC does not have a call. If you're referring to a
> > > combo proxy
> > > and
> > > > > VPC, then you are relying on some proprietary functionality to
> get
> > > the
> > > > > request from the VPC component supporting the E2
> > > interface and back
> > > to
> > > > > the proxy component. You are throwing up your hands 
> and saying -
> > > well do
> > > > > something proprietary then rather then use something eminently
> > > suitable
> > > > > like location by reference.
> > > > I'm saying that every VPC I know of has the proxy.  If you like,
> > > suggest
> > > > an
> > > > update interface between the VPC and the proxy in the 
> i2.5 effort,
> > > I'll
> > > > support that.  All of the VPC interfaces are NENA developed.
> > > >
> > > > >
> > > > > Now, is the service bureau proxy that you're really 
> referring to
> > > going
> > > > > to establish the subscribe directly to the device 
> itself, or is
> it
> > > going
> > > > > to have to go back via the VoIP call server? If it does
> > > it directly
> > > to
> > > > > the device then you've just introduced all the concerns
> > > that you had
> > > > > over third parties being able to get location via a reference.
> How
> > > is
> > > > > the device supposed to know who this proxy is? If it goes back
> via
> > > the
> > > > > VSP call server, then you're now also asking the VSP 
> to support
> > > some,
> > > > > currently unspecified, additional functionality for 
> this update
> > > process.
> > > > > And what if the VSP is Skype? They also need to invent a
> location
> > > query
> > > > > protocol on top of everything else?
> > > > I'm asking that the VPC reInvite back towards the 
> endpoint, which
> > > means it
> > > > goes through the VSP (this means the VPC proxy acts as a B2BUA,
> but
> > > most
> > > > of
> > > > them do this anyway for other reasons).  The VSP does 
> not need to
> > > support
> > > > anything but reInvite.
> > > >
> > > > >
> > > > > You were involved in the i2 WG Brian, you know we 
> discussed all
> > > these
> > > > > sorts of options and dismissed them because we were
> > > looking for the
> > > > > minimal impact on the various participants in VoIP 
> (in the real
> > > world).
> > > > > It seems somewhat disingenuous in another forum to be pushing 
> > > > > impractical solutions now that i2 is published and in the
> > > process of
> > > > > implementation.
> > > > Mobility was not well thought out.  ALL we did is to 
> decline to do 
> > > > anything that would preclude supporting mobility.  The word
> > > "mobile"
> > > > as used in this context appears once in the i2 document,
> describing
> > > > one use of the V3 interface.  My solution is eminently 
> practical.
> > > >
> > > > >
> > > > > It's just occurred to me that the reference to DHCP may have
> been
> > > > > somewhat Freudian. Are all of these gymnastics driven by the
> > > prospect
> > > > > that DHCP doesn't support a location reference mechanism?
> > > > No, it's just that you would think using DHCP as an LCP for
> > > a mobile
> > > > device is ludicrous.  In this use case, it is not.  You 
> might have 
> > > > other use cases where it would be, but not this one.
> > > >
> > > > I'm happy to support a location reference mechanism for 
> DHCP if we
> > > decide
> > > > that is a good thing.
> > > >
> > > > Brian
> > > >
> > >
> > > --------------------------------------------------------------
> > > ----------------------------------
> > > 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
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 
> --------------------------------------------------------------
> ----------------------------------
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 9 Oct 2006 15:01:20 -0400

Larry

Yeah, we've been through these issues a lot.  We understand there are cases
where the endpoint doesn't inherently know its location.  We've been through
the issue that if location changes (i.e. device is mobile, and especially if
the location determination mechanism is not "always on"), that you need a
mechanism to update location.

It always works to loop location through the endpoint.  If necessary, the
entity needing location can ask the endpoint and the endpoint can ask the
location server (LIS).  That always works, and solves the problem that the
entity who wants location may not have a relationship with the LIS, where
the endpoint has relationships with both.

We accept that one of the reasons to support LbyR is to optimize the update
mechanism so that it is not necessary to loop the request and the location
through the endpoint.  This might be more important where there is a
bandwidth limit in the endpoint, which is of course, often the case for
mobile devices.  The opponents of LbyR argue that looping the request
through the endpoint is pretty small complexity, and not much bandwidth, and
that introducing a direct connection between the location seeker and the LIS
opens up significant security problems.

I personally believe we have LbR already; it's called Presence.  You have a
URI (a presence URI), and you can exchange it for location by subscribing to
the URI.  Unless we were going to outlaw that, LbyR exists.

I think a more relevant question is what ELSE do we need?

Brian

> From: Ciesla, Larry [mailto:[email-masked]]
> Sent: Tuesday, September 19, 2006 3:00 PM
> To: Marc Linsner; Winterbottom, James
> Cc: GEOPRIV

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 9 Oct 2006 16:41:13 -0400

Larry,

In addition to what Brian stated below, one thing we have to keep in mind is
the architectural difference between legacy networks and the Internet.  The
Internet is based on a completely horizontal model, you acquire physical
access from one provider, network access from a different provider, and
applications from a 3rd provider.  These 3 providers need not know about one
another, in fact, the success of the Internet is rooted in this very
architecture.  To compromise this architecture, compromises the Internet.
For convenience it is typical that end-users deal with a single entity for
both physical access and network access.

What we are witnessing now is the attempt to mesh different architectures,
legacy environments where the architecture is completely vertical with the
horizontal Internet model.  Mixed in with this are people attempting to gain
from this effort.

No, the Internet is not, will never be, the best architectural model for
Public Safety.  But I believe we can make a huge improvement over the
current architecture.  We can all cite use cases that break any model, but
the most successful model to date has been to maintain the demarcation
between access, network, and application.

Experience tells us that the most simple of mechanisms are successful, and
the most complex fail.  I believe simple best supports emergency calling on
the Internet.

As you state, location determination is dependant on the underlying access
network technology/implementation.  All current local area network
architectures either support location determination and delivery to the end
host, or they are working on such, including wireless LANs.  All cellular
architectures have models to support location determination.  So the
question remains, how/where does this location information meet the
application:

1) At the end host?
2) In the access domain?
3) Carried to the far end of the Internet via a stand alone application
protocol?

IMO, the simplest will win the majority of market share.

-Marc-

> Sent: Monday, October 09, 2006 3:01 PM
> To: 'Ciesla, Larry'; 'Marc Linsner'; 'Winterbottom, James'
> Cc: 'GEOPRIV'
> Yeah, we've been through these issues a lot.  We understand 
> there are cases where the endpoint doesn't inherently know 
> its location.  We've been through the issue that if location 
> changes (i.e. device is mobile, and especially if the 
> location determination mechanism is not "always on"), that 
> you need a mechanism to update location.
> 
> It always works to loop location through the endpoint.  If 
> necessary, the entity needing location can ask the endpoint 
> and the endpoint can ask the location server (LIS).  That 
> always works, and solves the problem that the entity who 
> wants location may not have a relationship with the LIS, 
> where the endpoint has relationships with both.
> 
> We accept that one of the reasons to support LbyR is to 
> optimize the update mechanism so that it is not necessary to 
> loop the request and the location through the endpoint.  This 
> might be more important where there is a bandwidth limit in 
> the endpoint, which is of course, often the case for mobile 
> devices.  The opponents of LbyR argue that looping the 
> request through the endpoint is pretty small complexity, and 
> not much bandwidth, and that introducing a direct connection 
> between the location seeker and the LIS opens up significant 
> security problems.
> 
> I personally believe we have LbR already; it's called 
> Presence.  You have a URI (a presence URI), and you can 
> exchange it for location by subscribing to the URI.  Unless 
> we were going to outlaw that, LbyR exists.
> 
> > I've been watching the discussion regarding LbyR and was curious if 
> > the following has been discussed or might be covered in 
> some way with LbyV:
> > 
> > It seems to me that there might well be situations involving mobile 
> > VoIP handsets where location is determined by GPS, angle of 
> arrival, 
> > time difference of arrival, or some other kind of 
> radio-location technique.
> > in the handset (e.g.: GPS) and some depends upon some 
> assistance from 
> > a network element (e.g.: PDE in the wireless context.)  The 
> point is 
> > that location in this context is often expensive both from a 
> > "time to locate" perspective.  Our experience with cellular 
> and phase 
> > 2 is that it is often the case that the handset does not know its 
> > location at the time the 9-1-1 call is made.  It seems 
> likely that for 
> > some fraction of highly mobile VoIP devices, location technology 
> > similar to that used for wireless today might be employed 
> and location 
> > might not be available at the time the call is placed.  Best-guess 
> > routing is used with cellular to get the caller to the correct PSAP 
> > based on cell site, but the caller's actual location might not be 
> > known until some time has passed, thus making it of no use 
> for routing 
> > purposes.  There are also rare cases where the caller might have 
> > terminated the call but the PSAP still needs to locate the caller.  
> > Consider the case where the battery is nearly done and the 
> caller disconnects to conserve battery power.
> > use case typically seen today in cellular where the phone 
> is passive 
> > in its location determination and, if involved at all, is 
> "assisted" 
> > by a network element (e.g.: assisted GPS.)  For other location 
> > technologies
> > (e.g.: angle of arrival, time difference of arrival, etc.) 
> the phone 
> > is not involved in any way in the act of location.
> > 
> > Please excuse this intrusion if this matter has already been 
> > discussed, but I would urge you to consider technical 
> implementations 
> > where the calling device is really just a cell phone that 
> happens to 
> > be working over a VoIP wireless network of one kind or another.  It 
> > seems very likely that cellular carriers will want to employ (if 
> > possible) whatever location technology was chosen for locating the 
> > phone when it is operating in the cellular network.  Today, that 
> > cellular position determination entity (PDE) is passed a 
> reference to 
> > the device requiring locating.
> > 
> > 
> > Regards,
> > 
> > Larry Ciesla
> > 
> > Within NENA, LbyR was accepted due to the advertising, by a few, of 
> > what it will deliver.  Such advertising is the true FUD.  This 
> > community has reviewed that advertising and categorized it 
> properly.  
> > Sorry NENA, you were told something that is not possible to deliver.
> > 
> > -Marc-
> > 
> > > You are a number of colleagues in this discussion were the ONLY 
> > > opponents to LbR in NENA and you lost that argument 
> handsomely. At 
> > > that point it was made clear by the same league of 
> individuals that 
> > > they would not let LbR fly in the IETF. So far I have 
> only seen the 
> > > same misinformed FUD being thrown around, and the same people 
> > > opposing it.
> > > > > > > VPC, then you are relying on some proprietary 
> functionality 
> > > > > > > to
> > > get
> > > > > the
> > > > > > > It seems somewhat disingenuous in another forum to be 
> > > > > > > pushing impractical solutions now that i2 is 
> published and 
> > > > > > > in the
> > > > > process of
> > > > > > > implementation.

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 9 Oct 2006 17:03:56 -0500

Currently, as far as I know, there's no application to end-point query
protocol for location either. What is being proposed for this? Does
every application protocol need to be extended to support some semantics
to query the client for location, or is a separate query protocol
expected to be defined to request location from an end point? How,
exactly, is an application server going to initiate a location update
request to the client?

Also - if I understood Brian's presentation the other day, LoST is
actually going to provide a *reference* that the PSAP can use to query
for location related-related information. Did I get that wrong? If not,
I'm totally gob-smacked.

Cheers,
Martin

> Sent: Monday, 9 October 2006 3:01 PM
> To: 'Ciesla, Larry'; 'Marc Linsner'; Winterbottom, James
> Cc: 'GEOPRIV'
> the issue that if location changes (i.e. device is mobile, and
especially
> if
> through the endpoint is pretty small complexity, and not much
bandwidth,
> and
> that introducing a direct connection between the location seeker and
the
> LIS
> I personally believe we have LbR already; it's called Presence.  You
have
> a
> URI (a presence URI), and you can exchange it for location by
subscribing
the
> > It seems to me that there might well be situations involving mobile
VoIP
> > Please excuse this intrusion if this matter has already been
discussed,
> > Within NENA, LbyR was accepted due to the advertising, by a few, of
what
> > > > > > > VPC, then you are relying on some proprietary
functionality to
> > > > > > > It seems somewhat disingenuous in another forum to be
pushing
> > > > > > I'm happy to support a location reference mechanism for
contain
> > > > > immediately and delete the original.  Any unauthorized

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]

---

From: Andrew Newton <[email-masked]>
Date: Mon, 9 Oct 2006 20:38:29 -0400

> exactly, is an application server going to initiate a location update

Perhaps I'm not following this too well.  Aren't you asking the  
questions to which Brian has been answering about using pres:?

> for location related-related information. Did I get that wrong? If  

Gob-smacked?  Or flummoxed?  Because I think you have this wrong.   
LoST aids in the routing of a call.  It takes location and converts  
that into a set of URIs that can be used to route a call.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 9 Oct 2006 20:39:26 -0400

The SIP conveyance document describes how you request a new location, so for
that conveyance protocol, there is an answer.

Yes, I think a reference for location related information is appropriate.
I personally think LbyR exists, why fight it.

I do however think that you CANNOT require authentication for LbyR in the
emergency case.  I think you have to treat the possession of the reference
as authorization to get location during an emergency call.

So, I guess you are "gob-smacked".

Brian

> Sent: Monday, October 09, 2006 6:04 PM
> To: Brian Rosen; Ciesla, Larry; Marc Linsner; Winterbottom, James
> Cc: GEOPRIV

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 07:30:14 -0400

> that into a set of URIs that can be used to route a call.
Well, actually, I want to request that there be an (optional) URI returned
with the response that could contain information about the location.  This
URI, which need not be specified, would be used by PSAPs and other
responders to obtain additional information about the location with the sos
service.  If two calls queried for the same location, they would get the
same URI, which might be service dependent.

You can imagine things like floor plans, lists of hazardous materials,
available surveillance video, entrance information, etc for the sos
services.

There will probably be authentication, and authorization needed to access
this information.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 10 Oct 2006 08:27:40 -0400

> There will probably be authentication, and authorization needed to  

We have name for this in the software industry.  It is called feature  
creep, and it is known to be one of the causes of project failure.

I'm not actually sure how this would even work, as LoST is queried by  
a call routing function and its contents are used for that.  Such a  
URI would have to be conveyed from the seeker to the PSAP, which is  
not a LoST issue.

We've provided extension points in LoST, so this can be added later  
once there is a lot more detail about what is wanted.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 08:38:08 -0400

As I've stated before, we plan to use LoST within the Emergency Services IP
Network to route calls from ESRPs to PSAPs and from PSAPs to responders.
The URI would not be passed; the PSAP or responders would query for it.

It might be feature creep, but it is useful.  If the IETF doesn't do it, it
may be that NENA does an "embrace and extend", which would be unfortunate,
but possible, since we're only talking about features on servers within a
domain we control.  I'd rather not do this.

I certainly don't think we want to create ANOTHER database, with a different
protocol, to provide this function.  I think it may be very useful for non
sos services.  For example, an apartment building could post its delivery
policy (all deliveries by the side door).  The information is seen as coming
from the building owners/tenants; the URI would be a URI they provide,
pointing back to a data structure they maintain.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2006 8:28 AM
> To: Brian Rosen; [email-masked]
> Cc: 'Dawson, Martin'; 'GEOPRIV WG'
> Subject: Re: [Geopriv] coming to terms on location by reference
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Oct 2006 08:41:07 -0400

Brian,

I don't think this is necessary; there are already mechanisms in SIP  
where the caller can insert information about the call, the caller  
and the location, namely the Call-Info header.

Needless to say, this has nothing to do with LByR or LByV.

Henning

On Oct 10, 2006, at 8:27 AM, Andrew Newton wrote:

> We have name for this in the software industry.  It is called  
> feature creep, and it is known to be one of the causes of project  
> failure.
>
> I'm not actually sure how this would even work, as LoST is queried  
> by a call routing function and its contents are used for that.   
> Such a URI would have to be conveyed from the seeker to the PSAP,  
> which is not a LoST issue.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 08:52:10 -0400

The caller doesn't have this data.  It's not information about the call or
the caller, its information about the location.

We plan to use Call-Info for information about the call and the caller.

This is different.  The caller doesn't necessarily have a relationship with
the location other than being an authorized visitor.  It would be pretty
messy to try to pass the information through the location mechanisms (LCP)
to the endpoint and then put it on the call except in an enterprise
environment, because the access network doesn't know it either.  Its
information a building owner or tenant knows.  I doubt it fits in the LCP
any better than LoST.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2006 8:41 AM
> To: Andrew Newton
> Cc: Brian Rosen; [email-masked]; 'GEOPRIV WG'; 'Dawson, Martin'

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 10 Oct 2006 09:06:45 -0400

Brian,

> 
> The caller doesn't have this data.  It's not information 
> about the call or the caller, its information about the location.
> 
> This is different.  The caller doesn't necessarily have a 
> relationship with the location other than being an authorized 
> visitor.  It would be pretty messy to try to pass the 
> information through the location mechanisms (LCP) to the 
> endpoint and then put it on the call except in an enterprise 
> environment, because the access network doesn't know it 
> either.  Its information a building owner or tenant knows.  I 
> doubt it fits in the LCP any better than LoST.

How does the building owner or tenant get the data into the LoST database?

The mess seems to be if the PSAP authorities 'open up' the LoST db for input
by any/all.

Pidf-lo might be the right place, 'for further info about this location goto
<uri>'.  If there is such information available from the building owner or
tenant, that would imply they would probably being running the LIS.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Oct 2006 09:13:39 -0400

I agree that the biggest problem is that this fundamentally changes  
the operations & management aspect of LoST, as well as the  
responsibility for the data content. (LoST operator: "You mean I have  
to check each URL to make sure it doesn't point to whitehouse.com  
instead of whitehouse.gov?")

I will note that RPID already contains information describing the  
location (placetype and others). It would not be difficult to define  
another DHCP-civic option, for example, for a location-related URL.  
This fits well within CIPID; it already has a <map> element.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 10 Oct 2006 09:22:39 -0400

On Oct 10, 2006, at 8:52 AM, Brian Rosen wrote:

> This is different.

How can you possibly expect us to put it in LoST if we don't know  
what it is and it hasn't been described very well?

> I doubt it fits in the LCP
> any better than LoST.

Actually, there is the dhc-lost draft which has just now (or will  
become) an ECRIT work item.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 10 Oct 2006 09:29:35 -0400

My take on this is that it sounds like an operational nightmare. What
used to be a fairly simple system that just needed lots of location
info, and PSAP boundary and contact info, now has to have
logins/passwords for managers of every large building in a city. And
there will need to be a big support desk, for all these people to call
when they can't figure out how to input or update their info. And then
we'll need laws and regulations to force them to put the info in the
system (or it will never happen), and the laws will need to cover what
the minimum data set has to be. And we'll need to have a consistent
format for all the data, with XML labels for exits, circuit breakers,
fire extinguishers, escape ladders, etc., and common notation for how to
express their location inside a building; all the building managers will
need some tools to help them get all the data formatted correctly. My
head hurts just thinking of the bureaucracy that would be created to try
to get this done right. Not that bureaucracy tends to get things
right...
Barbara 

> Sent: Tuesday, October 10, 2006 8:52 AM
> To: 'Henning Schulzrinne'; 'Andrew Newton'
> Cc: 'GEOPRIV WG'; 'Dawson,Martin'; [email-masked]'
> about the call or
> relationship with
> > >> There will probably be authentication, and authorization 
> needed to
> > >> access
> > >> this information.
> > >

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 09:44:51 -0400

> How does the building owner or tenant get the data into the LoST database?
Basically, it probably comes through the PSAP or some other government
authority.  Since I expect the PSAP to contract operation of the LoST
database, it probably is another service that entity runs.  Eventually, I'd
like the "validation" mechanism to work for sub building levels (floor,
room, ...) and the path would be the same.  It's fairly straightforward to
validate it, using the post office and the fact that the owner, and even the
tenants are known to the authorities.

> The mess seems to be if the PSAP authorities 'open up' the LoST db for
It's just a URI.  It's not opening it up very much.

> tenant, that would imply they would probably being running the LIS.
You are just moving the problem.  I don't mind that too much, although I
didn't think we wanted to carry the data all the way through the path.  If
you put it in the PIDF, then the access network has to handle it.  That's
not too bad, although it falls apart when there is a tenant/building owner
situation.  The tenant is a subscriber of the access network, but the
building owner isn't.  

The real reason I don't want to do that is that it gives the access network
more obligations.  I don't want to go there.  We're going to have enough
trouble getting every access network to deploy a LIS and an LCP.  Adding
more work is counterproductive.  That's not a good protocol engineering
reason, but it's a pretty good reason nonetheless.

It seems to fit LoST: Location+Service in, URI out.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 09:51:57 -0400

No, it's just a URI.  The only mechanism you need is a way to supply the
URI.  You validate it with a post card.

The data format is another story, and outside the expertise of this group.
It will, I'm sure, evolve.  It can be a local matter: it's information about
a building that the PSAP and responders that serve that building agree is
useful.  

The other side of your argument is that we should not have the possibility
to provide this information, or, as they do now, the fire chief can carry a
box of paper floor plans in the trunk of his car.

We can do this another way, but it seems useful to have a mechanism that
works across the Internet.

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2006 9:30 AM
> To: Brian Rosen; Henning Schulzrinne; Andrew Newton
> Cc: GEOPRIV WG; Dawson,Martin; [email-masked]
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA624

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Oct 2006 09:59:15 -0400

> what it is and it hasn't been described very well?
It's a URI.  The format and protocol can be defined locally, because the
location and the service (PSAP and Responders) are local to one another.
What works in the U.S. probably won't work in China.  The URI parameter
however is universal.  Every LoST server could support it.

> become) an ECRIT work item.
I like dhc-lost, but it's not, as you know, universally applicable.

It also requires that we have the endpoint fetch and pass it through the
call, although I don't consider that too much of a problem.  I'm more
worried that because dhcp is not universal, we need a variety of mechanisms
and endpoints would have to implement them all.  A parameter in the LoST
return is much simpler to me.

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 10 Oct 2006 10:04:33 -0400

> > 
> > Pidf-lo might be the right place, 'for further info about 
> this location
> > goto
> You are just moving the problem. 

But I'm moving the problem to the owner of the data!

 I don't mind that too much, 
> although I

I don't understand this.  You are implying that a tenant that is large
enough to have extraneous information about their location (floor plans,
hazardous chemicals, etc.), but yet does not control (relies on someone
else) the operation their access network/LIS?  Makes no sense.  Even
residential *could* operate their own LIS, regardless of the access provider
(yes, reverse DNS LIS discovery would be broken, but it's a bad mechanism to
start with).
 
> It seems to fit LoST: Location+Service in, URI out.

I agree, the emerging LoST protocol appears to be a good fit for your
application.  Having Public Safety provide the service is where this falls
apart.

-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Tue, 10 Oct 2006 10:08:28 -0400

> however is universal.  Every LoST server could support it.

If it is not universal, how do you know a URI is applicable to all 
jurisdictions?  You seem to be treating a URI as a blob.  If it is a blob 
you want, LoST already has that in the form of an extension point... which 
can contain a URI or a base 64 encoded JPEG of your cat... or both.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 11:32:42 -0400

Roger Marshall just gave me a suggestion to fix this simply, no new feature
required.

Define a new service URN that returns this data.

Done.

That's all we need.

Brian

> Sent: Tuesday, October 10, 2006 9:59 AM
> To: 'Andrew Newton'
> Cc: 'GEOPRIV WG'; [email-masked]'
> Subject: [Ecrit] RE: [Geopriv] coming to terms on location by reference
> 
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Thu, 12 Oct 2006 12:57:13 -0400

> Define a new service URN that returns this data.

Define a new service URN that returns the URI you want?  Is that the idea? 
Fancy that, using URNs for their originally envisioned purpose.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 13:20:13 -0400

Yeah, well, sorry.  I should have made that observation myself.  Thanks to
Roger for pointing out the obvious.

In a NENA call today it was observed that, really, in at least a large
enterprise environment, it would be best if it WAS in the PIDF.  In the
general case, it is hard to always assume the operator of the LIS has the
data, but in the case of the enterprise who runs a LIS, it does, and in that
case it is a whole lot easier to supply it in the PIDF than to get it put in
the LoST database.

That may mean it makes sense to allow the (same) URI in the PIDF.  I'm not
sure I like "both" as an answer here, but the cases are pretty different.

Brian

> Sent: Thursday, October 12, 2006 12:57 PM
> To: Brian Rosen
> Subject: Re: [Ecrit] RE: [Geopriv] coming to terms on location by
> reference
> 
> Brian Rosen wrote:

---

From: Andrew Newton <[email-masked]>
Date: Thu, 12 Oct 2006 14:16:02 -0400

> sure I like "both" as an answer here, but the cases are pretty different.

Perhaps my point was lost (no pun intended).  If it is a URI you want, then 
using a URN to get it involves only DNS, not PIDF nor LoST.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 14:30:58 -0400

No, you need a URI that is dependent on location.  Your query is location
in, URI out.  DNS does not do that.  LoST does.  Roger's idea was rather
than including an "additional information" URI in every LoST return, for
every service, that we define a new service URN for "additional
information".  You then submit a LoST query with the
urn:service:additional-location (or whatever) and your location, and the
return is a URI for additional information corresponding to that location.

Work this out.  The assumption is that, for example, there is a local
definition for what additional information is needed/wanted in NYC, and that
included floor plans.  When a query for, let's say, 1234 5th Street, New
York, NY was made with urn:service:additional-information, the response
would be a URI that could retrieve the data structure for 1234 5th Street,
which contained the floor plan.  Any (authorized) responder could get that
data by querying LoST given the location.

Brian

> Sent: Thursday, October 12, 2006 2:16 PM
> To: Brian Rosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2006 17:20:08 -0400

One practical suggestion is to include the URL information in the 
civic-lo-revision document and then later add a code point to the 
DHCP-civic registry.

I will note that having a single URL refer to possibly multiple 
semantically different objects seems to be somewhat at odds with HTTP 
conventions, where Accept is generally used to choose between renditions 
of the same logical document in different formats (such as an image in 
GIF or PNG). A floor plan and hazmat information, say, are not really 
the same logical document.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 17:37:03 -0400

> civic-lo-revision document and then later add a code point to the
Good idea
> the same logical document.
I was thinking that the local authorities would define a single data
structure that had tags for the different kinds if information they were
interested in.  Some of the tag values might be URLs themselves. 

The IETF is, of course, not the place to standardize that data structure, at
least not now.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2006 17:43:04 -0400

> The IETF is, of course, not the place to standardize that data structure, at

Sure - but we need to have some idea what constraints we impose on 
future solutions. For example, the approach you suggest means that all 
information has to be managed by a single source, at least at the 
pointer level. I happen to think that this is not unreasonable, but 
since the number of types of information is probably fairly small 
(handful), it would also be quite plausible to remove one layer of 
indirection.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 18:58:37 -0400

I think there are several dimensions.

One is tenant/building owner; some information is available from the tenant,
some from the building owner.  I was thinking that the base data structure
would be from the building owner.  He would have things like building floor
plans, construction, entrance, elevator, .... kinds of data.

He would then have a pointer for each tenant, which would be a data
structure provided by the tenant.  The tenant would have things like
interior floor plans, hazmat data.

The thing is, of course, that nearly everything in the tenant part could
apply to the building owner.

I think there are a very large number of potential items in the data
structure.  I'm not sure how many of them are small enough to put directly
in, vs needing an indirect mechanism.  Clearly floor plans are indirect.
Something like hazmat data may not be.  Elevator status may not be, but
remote elevator control probably is (and probably requires significantly
more authentication and authorization if it is provided at all).  The
availability, location, etc of surveillance video could be directly in the
structure, but you clearly would have an RTSP (or something like it) pointer
to the actual video.  There are probably hundreds of potential tags, and I
don't know how many are pointers.

Brian

> Sent: Thursday, October 12, 2006 5:43 PM
> To: Brian Rosen

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Oct 2006 18:37:46 -0500

This appears to have branched off onto a new topic, so I have taken the liberty of changing the subject.

I think that what you are describing is a good idea for a new service, but I don't think that designing on the fly is going to work.  I also don't think that it is necessary to lump this data in with a civic address.

I'd contend that what you are proposing is information _about_ the civic address, not a part of the address.

To pick on one aspect of your data, what distinguishes a floor plan that highlights where particular rooms are to a street directory that highlights where roads are, or a world map that includes country borders?  Yes, you can argue that there is a level beyond which you can start making assumptions, but that requires that you draw a line.

A better approach would be to define a service, just as Roger suggested.  Location + urn:service:map + LoST = Map.  You can add to this as much complexity as you like - delegation of responsibility for features, innumerable tags, scalable resolution, etc...

> Sent: Friday, 13 October 2006 8:59 AM
> To: 'Henning Schulzrinne'
> Subject: RE: [Ecrit] RE: [Geopriv] coming to terms on location by
> reference
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 20:00:40 -0400

Agree we aren't going to design it on the fly.

I don't think WE are going to design it.

At the moment, I really think that is a local matter, and it works as a
local matter without any loss of interoperability.

It is clearly information ABOUT the address.

It's not limited to civic address.

I don't think we need to draw lines.  While I can't think of a good reason
to, if you put in a civic location with just a city name, you might get back
a street map.  Again, a local matter, it seems to me.

One of the reasons why there is some sense to allowing the pointer in the
PIDF itself (and it DOES make sense to have a pointer for "additional
information about the location in this PIDF") is that, at least in large
enterprise, it can give you the right answer, because it comes from the
right entity (it is, after all, the enterprise that runs the LIS in this
case).  A more general case of a broadband carrier serving a high rise
apartment building doesn't work, but then the notion of it being in LoST
makes sense there.

Right now, without a lot to go on, I'm thinking I don't want to standardize
a whole bunch of service URNs, one per piece of data and query for them
individually.  I think I want one locally defined XML structure and a "gimme
all you got" query.  YMMV.

Later, when we have more experience in how this works, and how else we can
use it, we could think about creating some more services such as map.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Thursday, October 12, 2006 7:38 PM
> To: Brian Rosen; Henning Schulzrinne
> Cc: GEOPRIV WG; ECRIT
> Subject: [Geopriv][Ecrit] Map data for a civic address
> 
> I think that what you are describing is a good idea for a new service, but
> I don't think that designing on the fly is going to work.  I also don't
> think that it is necessary to lump this data in with a civic address.
> 
> To pick on one aspect of your data, what distinguishes a floor plan that
> highlights where particular rooms are to a street directory that
> highlights where roads are, or a world map that includes country borders?
> Yes, you can argue that there is a level beyond which you can start making
> assumptions, but that requires that you draw a line.
> 
> A better approach would be to define a service, just as Roger suggested.
> Location + urn:service:map + LoST = Map.  You can add to this as much
> complexity as you like - delegation of responsibility for features,
> innumerable tags, scalable resolution, etc...
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2006 20:13:26 -0400

The only real difference between a PIDF inclusion and a LoST lookup  
in this case seems to be one layer of indirection, with the attendant  
advantages and disadvantages.

One of the practical issues is that LoST is currently designed for  
public information; any layer of indirection has to deal with well- 
discussed problems of having the LoST server decide who gets access  
to the information.

And now we can replay our by-value or by-reference discussion, since  
we haven't had one in a day or two.

Btw, PIDF-LO already contains information _about_ the address, such  
as the placetype or, if you like, the business name.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Oct 2006 19:15:11 -0500

You need to be careful that you aren't mistaking a "can" for a "should".

In any case, assuming that the LIS provides this information; where does this belong?  I can see four options:

 - In the civic address: I've already given my reasons why I believe this is a bad idea.

 - In the Geopriv element (alongside <method>, <usage-rules> and so forth).

 - In the PIDF: I wonder if this could really be considered presence information.

 - In the acquisition protocol: Add an option in the protocol to request additional information and include the data as an adjunct.

Personally, I like the last one.

Cheers,
Martin

> Sent: Friday, 13 October 2006 10:01 AM
> To: Thomson, Martin; 'Henning Schulzrinne'
> Cc: 'GEOPRIV WG'; 'ECRIT'
> Subject: RE: [Geopriv][Ecrit] Map data for a civic address
> 
> > > to the actual video.  There are probably hundreds of potential tags,
> and
> > I
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Oct 2006 19:26:57 -0500

> as the placetype or, if you like, the business name.

Business names are often a very useful way of identifying a location - they are often far more prominently displayed than other labels, like street numbers.  Therefore, they have a direct use.

As for placetype... obviously you will disagree, but I don't think that they should have been included in the civic address encoding.

Cheers,
Martin

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 12 Oct 2006 20:39:15 -0400

> discussed problems of having the LoST server decide who gets access

Could we close this issue out?  

LoST is defined over TLS.

Could the following text be included in Security Considerations:

In some jurisdictions, not all of the information in the LoST server may be
appropriate for an arbitrary public client to obtain.  The LoST server MAY
make use of the identity of the requester implied in a TLS connection
establishment within which LoST queries and responses are sent and make an
authorization decision based on that identity.  This means that the response
of the server MAY depend on the identity of the requester.  The query itself
does not contain any explicit identifying information of the requestor.
Appropriate TLS privacy mechanisms SHOULD be used to protect the non-public
information when such an option is used.

Brian

---

From: Andrew Newton <[email-masked]>
Date: Thu, 12 Oct 2006 20:53:55 -0400

> information when such an option is used.

First, being designed over TLS does not mean anything about the  
information being non-public.  Second, we aren't just using TLS.   
We've been round and round on this.  Third, I think this is just a  
plain bad idea.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 13 Oct 2006 12:19:09 -0400

If this pointer is provided by the LIS, then all access providers who supply service to that building would have to have this. For example, if tenants in a high rise apartment building have a choice between cable access, DSL, city-wide mesh Wi-Fi, and satellite, all these providers would have to replicate this pointer in their LIS. So the building managers would have to know all the possible access mechanisms, how to get the pointer to these companies, etc.

Just a comment. It's definitely do-able. The list of possible access providers is still short.
Barbara

> Sent: Thursday, October 12, 2006 8:15 PM
> In any case, assuming that the LIS provides this information; 
> where does this belong?  I can see four options:
> 
>  - In the acquisition protocol: Add an option in the protocol 
> to request additional information and include the data as an adjunct.
> 
> > to, if you put in a civic location with just a city name, 
> you might get
> > back
> > individually.  I think I want one locally defined XML 
> structure and a
> > "gimme
> > > This appears to have branched off onto a new topic, so I 
> have taken the
> > > liberty of changing the subject.
> > >
> > > I think that what you are describing is a good idea for a 
> new service,
> > but
> > > I'd contend that what you are proposing is information 
> _about_ the civic
> > > address, not a part of the address.
> > >
> > > Yes, you can argue that there is a level beyond which you 
> can start
> > making
> > > > One is tenant/building owner; some information is 
> available from the
> > > > tenant,
> > > > would be from the building owner.  He would have things 
> like building
> > > > floor
> > > > The thing is, of course, that nearly everything in the 
> tenant part
> > could
> > > > structure.  I'm not sure how many of them are small 
> enough to put
> > > directly
> > > > Something like hazmat data may not be.  Elevator status 
> may not be,
> > but
> > > > availability, location, etc of surveillance video could 
> be directly in
> > > the
> > > > structure, but you clearly would have an RTSP (or 
> something like it)
> > > > pointer
> > > > > > The IETF is, of course, not the place to 
> standardize that data
> > > > > structure, at
> > > > > > least not now.
> > > > >
> > > > > future solutions. For example, the approach you 
> suggest means that
> > all
> ----------
> ----------

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: Andrew Newton <[email-masked]>
Date: Fri, 13 Oct 2006 14:09:09 -0400

> Just a comment. It's definitely do-able. The list of possible access providers is still short.

Before this goes any further, it should be noted that this is outside the 
scope of both ECRIT and GEOPRIV.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Oct 2006 22:03:23 -0500

Marc,

I think what is being debated is what people think is simplest, and in
what circumstances it is actually the most simple.

As has been continually pointed out, in anything other than a simple
one-off send, location by-value to the end-host is not simplest, and is
certainly not cheapest in terms of effort.

Cheers
James

> Sent: Tuesday, 10 October 2006 6:41 AM
> To: 'Ciesla, Larry'
> Cc: 'GEOPRIV'
> In addition to what Brian stated below, one thing we have to keep in
mind
> applications from a 3rd provider.  These 3 providers need not know
about
> one
> horizontal Internet model.  Mixed in with this are people attempting
to
> gain
> the most complex fail.  I believe simple best supports emergency
calling
> on
> architectures either support location determination and delivery to
the
> end
> > > > > > > > the device supposed to know who this proxy is? If it
goes
contain

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 17 Oct 2006 13:08:01 -0400

James,

> 
> I think what is being debated is what people think is 
> simplest, and in what circumstances it is actually the most simple.
> 
> As has been continually pointed out, in anything other than a 
> simple one-off send, location by-value to the end-host is not 
> simplest, and is certainly not cheapest in terms of effort.

This may be true in your world, but I disagree when working in the Internet
architecture.

-Marc-

> > the architectural difference between legacy networks and 
> the Internet.
> > The
> > For convenience it is typical that end-users deal with a 
> single entity
> for
> > legacy environments where the architecture is completely 
> vertical with
> the
> > current architecture.  We can all cite use cases that break 
> any model,
> but
> > Experience tells us that the most simple of mechanisms are 
> successful,
> and
> > > Yeah, we've been through these issues a lot.  We understand there 
> > > are cases where the endpoint doesn't inherently know its 
> location.  
> > > We've been through the issue that if location changes 
> (i.e. device 
> > > is mobile, and especially if the location determination 
> mechanism is 
> > > not "always on"), that you need a mechanism to update location.
> > >
> > > necessary, the entity needing location can ask the 
> endpoint and the 
> > > endpoint can ask the location server (LIS).  That always 
> works, and 
> > > solves the problem that the entity who wants location may 
> not have a 
> > > relationship with the LIS, where the endpoint has 
> relationships with 
> > > both.
> > >
> optimize the 
> > > update mechanism so that it is not necessary to loop the 
> request and 
> > > the location through the endpoint.  This might be more important 
> > > where there is a bandwidth limit in the endpoint, which is of 
> > > course, often the case for mobile devices.  The opponents of LbyR 
> > > argue that looping the request through the endpoint is 
> pretty small 
> > > complexity, and not much bandwidth, and that introducing a direct 
> > > connection between the location seeker and the LIS opens up 
> > > significant security problems.
> > >
> Presence.  You 
> > > have a URI (a presence URI), and you can exchange it for 
> location by 
> > > subscribing to the URI.  Unless we were going to outlaw 
> that, LbyR 
> > > exists.
> > >
> > > > "processing-cycle" perspective, a "battery life" 
> perspective, and
> a
> > > > > > > > At first blush, it seems that there is value in 
> making a 
> > > > > > > > direct
> > > > > path
> > > > > > > from
> > > > > > > > The FIRST location operation is MORE complex 
> (the endpoint 
> > > > > > > > gets
> > > > > the
> > > > > > > > I'm saying that every VPC I know of has the 
> proxy.  If you 
> > > > > > > > like,
> > > > > > > suggest
> > > > > > > > an
> > > > > > > > goes through the VSP (this means the VPC proxy 
> acts as a 
> > > > > > > > B2BUA,
> > > > > but
> > > > > > > most
> > > > > > > > of