Subject: Re: [Ecrit] Service Boundary and listServicesByLocation / New Version Notification for draft-wolf-ecrit-lost-servicelistboundary-00

From: "Karl Heinz Wolf" <[email-masked]>
Date: Wed, 28 May 2008 13:18:57 +0200

I discussed this topic with Hannes at the last Emergency Workshop and
he suggested to write a draft. So here it is:

A new version of I-D, draft-wolf-ecrit-lost-servicelistboundary-00.txt
has been successfuly submitted by Karl Wolf and posted to the IETF
repository.

Filename:	 draft-wolf-ecrit-lost-servicelistboundary
Revision:	 00
Title:		 Location-to-Service Translation Protocol (LoST) Extension:
ServiceListBoundary
Creation_date:	 2008-05-28
WG ID:		 Independent Submission
Number_of_pages: 8

Abstract:
LoST [I-D.ietf-ecrit-lost] is able to map service identifiers and
location information to service contact URIs.  If a LoST client wants
to discover available services for a particular location, it will
perform a <listServicesByLocation> query to the LoST server.
However, the response from the LoST server does not give information
about the geographical region, for which the returned service list is
valid.  Therefore this document proposes a ServiceListBoundary, in
addition to the ServiceBoundary (which indicates the region a
specific service URL is valid).

The IETF Secretariat.

http://www.ietf.org/internet-drafts/draft-wolf-ecrit-lost-servicelistboundary-00.txt

Feedback and comments are appreciated.

cheers
karl heinz

On Mon, Jan 14, 2008 at 3:26 PM, Karl Heinz Wolf <[email-masked]> wrote:
> I have a question about how a mobile client notices a change of
> available emergency services when moving. Maybe I've just got
> something wrong.
>
> LoST returns a service boundary for a service when a client does a
> findService. So the client knows the area, this particular mapping is
> valid.
> When a client requests listServicesByLocation, no boundary information
> is provided telling where this list of services applicable. So, when
> is a client expected to do a listServicesByLocation query again?
> For example, the client moves to an area where a mountain rescue
> service is available, but the listServicesByLocation was done at a
> location where no mountain rescue is available.
> Did I read over a rule on when to do a listServicesByLocation?
>
> cheers
> karl heinz
>
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Ted Hardie <[email-masked]>
Date: Wed, 28 May 2008 07:42:19 -0700

Hi,
	I just took a quick look through the draft, and I have a
couple of questions.  The core of the draft's purpose seems to
be this;

  Clients can discover available services for a
   particular location by the <listServicesByLocation> query.  The LoST
   server returns a list of services that are available at this
   particular location.  But the server does not inform the client, for
   which geographical region the returned service list is valid.  This
   may lead to the situation where a client initially discovered all
   available services by the <listServicesByLocation> query, and then
   moves to a different location while refreshing the service mappings,
   but does not notice the availability of another service.

	So if I originally do listServicesByLocation in
a flat part of the country, I may not know of
Mountain Rescue services; I either have to periodically
query using the listServicesByLocation (to see if something
new is available) or do without Mountain Rescue even if it
is available after I've left the flat lands.  Does that capture
your aim?
	First, I think we should all be clear that in
emergency services we're dealing with a registered list,
so that listServicesByLocation will only ever tell you which
items from a known set of items is available.  The list
is small, and I expect it to be cached.  Does that make sense
to you?   If so, we're using this mechanism not to expand
the list, but to indicate when you need to check to see if
the "available" state for items on it has changed.
	Assuming I have your aim right, I see this as a
potentially useful optimization.  Rather than have periodic
client queries drive the discovery process, you shift the work
to those creating the mapping databases to generate
these boundaries.   I'm not actually sure how much this
optimization is needed, as I see the listServicesByLocation
as fairly easy and likely to be piggy-backed on other
queries (when refreshing cached data that has expired,
for example), but I also don't see any harm in it. My only real concern
is that it may be fairly difficult (especially outside of emergency services)
to generate these boundaries, as it may require knowledge
at a level higher than that of the authoritative server for
a particular region.  That means to me that this response
must be interpreted as "list valid at least for this area" rather
than "response is authoritative boundary;there will be change outside
this".
	Some additional questions:  why not include
the profiles the client understands in the query, so that the
server does not bother returning boundaries in a profile
the client does not understand?  what errors and warnings
do you thing you need?  is the expires value in the ServiceBoundary
mandatory?
			regards,
				Ted Hardie

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 29 May 2008 09:47:53 +0200

Hi Ted,

thank you for your response. See my comments inline.

> is available after I've left the flat lands.  Does that capture

yes.

> to you?

I'm not sure what the advantage for the client is, when he knows all
the 10 SOS services registered in RFC5031, but at its current location
just 1 SOS service is available. Since you can learn the available
services with listServicesBylocation, I would expect this query to be
the first. Anyway, if the client knows all registered SOS services,
and findService says this service is not available at THIS location -
when should the client try a findService again? This is the point I'm
concerned about.

> If so, we're using this mechanism not to expand

yes, my concern is that a client does not notice a new service when
moving ("new" does not mean it is not defined in RFC5031, but it was
not available at the old location).

> for example),

A ServiceList may change independent of the service boundary of a
particular service or the expiry of cached data of other services. So
when should a client perform a listServicesByLocation query? every
second? any time moving 1 mm? I think it is the same issue as for the
Serviceboundary.

> but I also don't see any harm in it. My only real concern

I agree. I could be difficult to get the pizza servicelistboundary.

> the client does not understand?

Of course, this makes sense.
This is possible in LoST for the ServiceBoundary? I'm afraid I
overlooked this. I only read that the server must use one profile the
client utilized in the request and may use other, additional profiles
too.

>  what errors and warnings

I would suggest the ServiceListBoundary to be defined similar to the
ServiceBoundary, so the same elements would be mandatory and probably
there are no new errors and warnings necessary.
I wrote this first version of the draft rather to point my concern out
and to get feedback if such a mechanism is useful at all.

cheers
karl heinz