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

[Ted Hardie <hardie at qualcomm.com>]

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


At 4:18 AM -0700 5/28/08, Karl Heinz Wolf wrote:
>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 <khwolf1 at gmail.com> 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
>Ecrit at ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit