[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Service Boundary and listServicesByLocation / New Version Notification for draft-wolf-ecrit-lost-servicelistboundary-00
Hi Ted,
thank you for your response. See my comments inline.
On Wed, May 28, 2008 at 4:42 PM, Ted Hardie <hardie at qualcomm.com> wrote:
> 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?
yes.
> 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?
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
> the list, but to indicate when you need to check to see if
> the "available" state for items on it has changed.
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).
> 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),
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
> 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".
I agree. I could be difficult to get the pizza servicelistboundary.
> 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?
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
> do you thing you need? is the expires value in the ServiceBoundary
> mandatory?
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
>
> 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