Subject: [Ecrit] Comments on draft-forte-lost-extensions-00

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Apr 2010 14:12:30 +0800

Reading this draft, I'm not convinced of what this provides - aside from more syntax.  LoST already provides for most of this functionality.

Where there is ambiguity arising from uncertainty, LoST allows a server to provide multiple choices:

   A server MAY return multiple <mapping> elements if the
   shape extends across multiple service areas.  

This covers "within distance X" if you use uncertainty (as stated, use a circle and you need no extension).

"served by" is the most confusing.  Isn't the purpose of LoST to provide a list of the entities that service the selected location?

Service location seems a reasonable addition to service metadata.  However, this can already be provided by reference.  A pres: URI would be adequate.

Limiting the number of services is of marginal benefit at best, and is arguably better left to server policy to control.

--Martin

---

From: Andrea G Forte <[email-masked]>
Date: Tue, 06 Apr 2010 16:25:09 -0400

In RFC5222, Section 1 a service region is defined as follows.

"To minimize round trips and to provide robustness against network 
failures, LoST supports caching of individual mappings and indicates the 
region for which the same answer would be returned ("service region")."

and in Section 5.5:
"A response MAY indicate the region for which the service URL returned 
would be the same as in the actual query, the so-called service region."

Given that for non-emergency services for each query we could get a 
large number of service URLs, a service region as per definition above 
would be the region within which a user would get the same set of 
service URLs. If even only one of the URLs changes, the set of URLs 
changes that is, the service region changes.
Therefore, for non-emergency services we can distinguish two types of 
service regions. One is the region served by the single POI (e.g., pizza 
delivery), the other one is according to the definition in RFC 5222 the 
region within which the client would always get the same set of service 
URLs. The second type of service region would include multiple service 
regions of the first type. Because of this, the service region as 
defined in RFC 5222 would change very frequently, making the use of 
service regions as described in RFC 5222 not that useful.

This difference between emergency and non-emergency services is due to 
the fact that PSAPs have service regions that do not overlap 
significantly with one another and one service region is served by a 
single PSAP. As explained above, this is not the case for non-emergency 
services.

Please read other answers inline.

-Andrea

On 4/6/10 2:12 AM, Thomson, Martin wrote:
>     A server MAY return multiple<mapping>  elements if the
It does not. For example, how would LoST handle today a request for all 
available ATM machines within 300m from my current location? ATM 
machines do not have a service region.
Similarly, if I want to search for a French restaurant to go and have 
dinner to within 200m from my current location, I do not care about its 
service region (assuming it has one). I am not interested in the 
restaurant delivering food to me, I am interested in going to that 
restaurant. This means that I could be out of its service region and 
still be willing to go and eat there.

Again, service regions have different meanings for non-emergency services.
> "served by" is the most confusing.  Isn't the purpose of LoST to provide a list of the entities that service the selected location?
The "served by" query is a "normal" LoST query but somehow we have to 
distinguish it from the other types of queries described in the draft 
and that is why we define a new boolean element. In other words, "served 
by" queries are the queries LoST handles today.
> Service location seems a reasonable addition to service metadata.  However, this can already be provided by reference.  A pres: URI would be adequate.
We are doing it by value, yes you can do it also by reference, but as in 
all the LoST documents we still would like to have a choice.
> Limiting the number of services is of marginal benefit at best, and is arguably better left to server policy to control.
What server? Provided and managed by whom? How would a server know about 
the capabilities/performance of your devices (e.g., available 
bandwidth), and the intentions of the user? It would be better to leave 
this choice to the user rather than forcing it on the user.

I do not consider this issue marginal. In places like New York City 
where the number of results can be quite large, a way for the user to 
limit the number of results to a custom value can be very useful. This 
is true from a device (and its capabilities) perspective as well as from 
a user perspective. Also, similarly to large SIP messages in the IMS 
(SigComp - RFC 3320 anyone?), receiving large LoST messages on low 
bit-rate links is not good.

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