Subject: [Ecrit] LoST serviceBoundaryReference as a URI?

From: Richard Barnes <[email-masked]>
Date: Thu, 18 Oct 2007 17:18:01 -0400

It seems odd to me that LoST uses its own, unique 
serviceBoundaryReference format for references to service boundaries, 
rather than encoding the same information in a URI.  Is there a 
compelling reason for this?

It seems like having URIs that point to serviceBoundaries could be 
useful, as a usage of LbyR.  The reference could return a PIDF-LO for 
the PSAP presentity with  location information from the 
<serviceBoundary>.  The PSAP <uri> elements could go in <contact> field. 
  (You could even define a "service-boundary" value for <method>, and 
put the <path> in the <provided-by> block.  It would be nice if there 
were a sensible place for a service URN, but I don't see an obvious 
one.)   There would be an expectation that these URLs would be 
accessible by anyone, just like SBrefs.

One reason to do this would be to resolve the location hiding problem: A 
location provider that doesn't want to provide endpoint location to all 
requesters could provide instead a set of URIs: one to refer to the 
endpoint's location (with limited access), and others to refer to 
relevant PSAP SBs.  Endpoints could then query LoST with locations 
within the provided SBs, and include these URIs as LbyR in an emergeny 
call.

--Richard

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Oct 2007 17:30:39 -0400

This was discussed earlier. The reason is that we want to be able to  
use the caching mechanisms in LoST, so we want to refer to an object,  
not a location.

Plus, we currently do not have a LoST URL as such.

Henning

On Oct 18, 2007, at 5:18 PM, Richard Barnes wrote:

> serviceBoundaryReference format for references to service  
> boundaries, rather than encoding the same information in a URI.  Is  
> there a compelling reason for this?
>
> useful, as a usage of LbyR.  The reference could return a PIDF-LO  
> for the PSAP presentity with  location information from the  
> <serviceBoundary>.  The PSAP <uri> elements could go in <contact>  
> field.  (You could even define a "service-boundary" value for  
> <method>, and put the <path> in the <provided-by> block.  It would  
> be nice if there were a sensible place for a service URN, but I  
> don't see an obvious one.)   There would be an expectation that  
> these URLs would be accessible by anyone, just like SBrefs.
>
> One reason to do this would be to resolve the location hiding  
> problem: A location provider that doesn't want to provide endpoint  
> location to all requesters could provide instead a set of URIs: one  
> to refer to the endpoint's location (with limited access), and  
> others to refer to relevant PSAP SBs.  Endpoints could then query  
> LoST with locations within the provided SBs, and include these URIs  
> as LbyR in an emergeny call.
>
> --Richard
>
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Oct 2007 08:55:13 -0400

> The reason is that we want to be able to use 
> the caching mechanisms in LoST, so we want to refer to an object, not a 
> location.

I'm not sure I understand this.  If I'm reading the LoST draft right, to 
dereference a serviceBoundaryReference you send a getServiceBoundary 
query directly to the server in the "source" attribute of the reference 
and get back a location (serviceBoundary) and a path.  So I don't see 
how caching plays into this?

> Plus, we currently do not have a LoST URL as such.

Seems like you could do this with any LbyR URL, e.g., an HTTP or SIP 
URL.  The mapping would be something like the following: The sbref

<serviceBoundaryReference source="authoritative.eg" key="4A841E8B"/>

becomes the URI (borrowing from the SAML URI binding):

https://authoritative.eg/lost-sb?key=4A841E8B
sips:[email-masked]

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 Oct 2007 10:28:03 -0700

At 8:55 AM -0400 10/19/07, Richard Barnes wrote:
>>The reason is that we want to be able to use the caching mechanisms in LoST, so we want to refer to an object, not a location.
>
>I'm not sure I understand this.  If I'm reading the LoST draft right, to dereference a serviceBoundaryReference you send a getServiceBoundary query directly to the server in the "source" attribute of the reference and get back a location (serviceBoundary) and a path.  So I don't see how caching plays into this?

>Seems like you could do this with any LbyR URL, e.g., an HTTP or SIP URL.  The mapping would be something like the following: The sbref
>

Seems to me this buys you absolutely nothing and potentially forces the client to
understand/invoke protocol processing for some other protocol.  We know
the client "speaks" lost.  What's the advantage to forcing them to speak
anything else?

				Ted

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Oct 2007 14:03:09 -0400

> the client "speaks" lost.  What's the advantage to forcing them to speak

That's true if the only entity that wants the service boundary is the 
LoST client.  I was thinking more about cases where one entity wants to 
point another entity to a service boundary, such as a client telling a 
proxy "this is the service boundary of the PSAP I'm calling" .  In this 
case, there's no guarantee that the receiving entity, the one that does 
the dereference, speaks LoST.

So I think there are two advantages:  The first (and less clearly 
advantageous) is that dereferences doesn't depend on support for LoST, 
just L-by-R dereference -- which may be more or less common.  The 
second, greater advantage is that there's already protocol fields that 
can carry a URI, and none that carry a serviceBoundaryReference.

I should also be clear that I didn't mean to get rid of 
serviceBoundaryReferences, just to add an additional, optional mechanism 
for referring to service boundaries.  So nobody would be forced to speak 
anything other than LoST.

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 Oct 2007 11:29:27 -0700

At 2:03 PM -0400 10/19/07, Richard Barnes wrote:
>
>That's true if the only entity that wants the service boundary is the LoST client.  I was thinking more about cases where one entity wants to point another entity to a service boundary, such as a client telling a proxy "this is the service boundary of the PSAP I'm calling" .  In this case, there's no guarantee that the receiving entity, the one that does the dereference, speaks LoST.

The set of mechanisms around serviceBoundaries are there to minimize the number
of queries that need to go to LoST servers by letting the queriers know when they
are still within a serviceBoundary.  If I understand what you are proposing, you
want the serviceBoundaryReference to be passed away from the client to
a location-aware proxy that does not speak LoST but will cache this data for
some other purpose.    That is a different optimization.

>So I think there are two advantages:  The first (and less clearly advantageous) is that dereferences doesn't depend on support for LoST, just L-by-R dereference -- which may be more or less common.  The second, greater advantage is that there's already protocol fields that can carry a URI, and none that carry a serviceBoundaryReference.

I've argued that creating a LoST uri has advantages for the second reason, but I agree
with those in the working group who asked that it be decoupled from progress on the
main spec.  I still have some drafts of the docs around, if you are interested in working
on them. 

>I should also be clear that I didn't mean to get rid of serviceBoundaryReferences, just to add an additional, optional mechanism for referring to service boundaries.  So nobody would be forced to speak anything other than LoST.

If you would like to propose an extension for the purpose, I would be happy to
review it and I may well support it.  I'm immensely relieved to hear that you are
not proposing this as a protocol change to a doc that's already in an AD queue for
publication requested.  That tends to get things pushed down the queue, and I
think we're way past the time when we should have shipped LoST.

					Ted

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2007 10:07:44 -0400

> some other purpose.    That is a different optimization.

Sure, no disagreement there.  Let me clarify the use case I have in 
mind: In current proposals, LoST is used to verify that the destination 
(e.g., R-URI or Route:) of an emergency call is in fact a PSAP URI.  In 
order to do this verification, the verifier needs a location and a 
service URN.  Emergency calls by definition carry a service URN, but may 
not have location (e.g., in the location hiding use case).  Service 
boundaries are useful because the service boundary could be used as an 
ersatz location when there is no other location available.  That is, a 
verifier could use a location within the boundary with the provided URN 
to verify that a URI is a PSAP URI.

Having a URI reference to a service boundary is convenient because
1) It can be provisioned as a location reference in HELD, and
2) It can be carried in a SIP Geolocation header field

Having the LoST server provide such references is a convenient discovery 
mechanism, and having the LoST server (or its delegate) be the target of 
these references avoids the need for lots of entities to maintain 
references to the same service boundary.

> main spec.  I still have some drafts of the docs around, if you are interested in working

In order to support the above use case, such a URI would need to have 
more semantics than the one last specified in LoST (-03).  In addition 
to referring to the LoST server itself (the function of the LoST URI in 
-03), there would need to be a way to refer to individual service 
boundaries.  (You could conceivably refer to other things, like 
mappings, in this way, but I'm not sure to what extent that's feasible.)

I'm not sure that a LoST URI is necessary for this case either, because 
the transaction doesn't require any of the semantics of LoST beyond the 
simple retrieval semantics of the getServiceBoundary query.  And that 
request is essentially equivalent to an HTTP GET.

If you think a LoST URI is still the way to go, though, I'd be glad to 
take a look at the remaining docs and try to make some progress.

Best,
--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 22 Oct 2007 10:20:17 -0400

This doesn't make any sense to me.  The reference has to resolve to the real
location when the PSAP gets it.  That means the domain of the location
reference has to be that of the LIS.  The LIS could get the service
boundary, and return that as the value for a dereference done by some entity
other than a PSAP, but that means the LIS wants the value from LoST, not a
URI.

Brian

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Monday, October 22, 2007 10:08 AM
> To: Ted Hardie; ECRIT
> Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI?
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2007 10:49:50 -0400

Brian,

Keep in mind that there can be multiple location references in an 
INVITE.  They all have to refer to the same location (that of the 
endpoint), but some of them could do that by saying "it's within this 
service boundary" while others could say "it's at this point".

> The reference has to resolve to the real
> location when the PSAP gets it. 

Really, you only need ONE of the references to resolve to the real 
location.  Suppose you have the following headers:

Geolocation: <http://lis.bbn.com/rbarnes>
Geolocation: <http://lost.va.us/3AB7F67C>;used-for-routing

The PSAP could use the first one to get precise location, while other 
entities could use the second one to get a service boundary to verify 
that the destination is a PSAP.

> The LIS could get the service
> other than a PSAP

Using a URI that points to a service boundary does the same thing 
without the LIS having to (1) apply transformations to the location 
(i.e., it just has to deny or allow), or (2) maintain a local cache of 
the serviceBoundary (just needs the reference).

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 22 Oct 2007 11:33:16 -0400

I think the burden of handling location hiding should be on the access
network.  I think the burden of location verification should be on the
verifier.  I think the endpoint, the PSAP or a non-involved proxy, should
have zero burden for these shenanigans.

That means I want the LIS to return a simple reference, which everyone
treats as the actual location.  I want the verifier, if it wants to, to
dereference it, and deal with what it gets back.  I want the PSAP to get one
reference, and use it.

Among other things, the PSAP doesn't know which reference to use.  You would
think it would start with the one used for routing.

I don't care how much work the LIS has to do to hide location, and I don't
care how much work the verifier has to do to verify.  I care a lot how much
work everyone else has to do to make it possible for these things to happen.

Brian

> Sent: Monday, October 22, 2007 10:50 AM
> To: Brian Rosen; ECRIT

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2007 12:55:15 -0400

> have zero burden for these shenanigans.

Creating an additional way to refer to service boundaries adds work for 
anybody.  It just provides another mechanism for referring to what the 
LoST server already provides.

-- The LIS still has to do the work to figure out which service boundary 
references to give to the endpoint

-- The verifier still has to acquire the location and do the LoST query 
to verify

-- The PSAP still gets location to the same accuracy in the same amount 
of time (it can do multiple dereferences in parallel)

-- Non-involved proxies can just ignore the location headers

The only entity that gets any more work here is the LoST server, who may 
have to answer more queries for service boundaries.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 22 Oct 2007 13:16:47 -0400

No, you want the LoST server to have to handle content indirection for
service boundaries, and only because some access networks want to hide
location.  I think that's putting the burden on the LoST server
inappropriately.

You are also putting burdens on endpoints, non-involved proxies and PSAPs to
handle multiple locations.

The other way, the LIS does all the work.  That's, in my opinion, as it
should be.

Brian

> Sent: Monday, October 22, 2007 12:55 PM
> To: Brian Rosen; ECRIT