Re: [Ecrit] servicelistboundary - discussion in the meeting today

[Ted Hardie <[e-mail]>]

At 5:01 AM -0700 7/29/09, Karl Heinz Wolf wrote:
>There was some discussion during the meeting today on my draft
>http://tools.ietf.org/html/draft-wolf-ecrit-lost-servicelistboundary-01
>
>My main concern is how to ensure that a client never misses a change
>in available services and consequently learns all location dependent
>dialstrings for the current location in order to be able to detect an
>emergency call based on the dialstring.

I think this is where the draft is a bit unclear.  Let's start from
what RFC 5222 says:

  A LoST client can ask a LoST server for the list of services it knows
   about for a particular area.  The <listServicesByLocation> query
   contains one or more <location> elements, each from a different
   location profile (Section 12), and may contain the <service> element.
   As for <findService>, the server selects the first location element
   that has a profile the server understands and it can operate either
   recursively or iteratively; <via> elements track the progress of the
   request.  The query indicates the services that the server can
   enumerate from within the forest structure of which it is a part.
   Because LoST does not presume a single, overarching organization of
   all potential service types, there may be services available within a
   geographic area that could be described by other LoST servers
   connected to other forest structures.  As an example, the emergency
   services forest for a region may be distinct from the forests that
   locate commercial services within the same region.

   If the query contains the <service> element, the LoST server returns
   only immediate child services of the queried service that are
   available for the provided location.  If the <service> element is
   absent, the LoST service returns all top-level services available for
   the provided location that it knows about.

The current mechanism only works within a single forest structure.
This draft is not clear, at least to me, in being scoped to a single
forest structure, and the discussion in the room wandered around
that topic (partly by referring to the services for which the responding
servers are authoritative). 


>Currently the listServiceByLocation response does not give any
>information on the area the service list is valid for. So a client
>might miss a change in the available services, so it won't have the
>dialstring configured and is not able to detect an emergency call.

But there are many more available services than emergency services.
These will also change.  Are we clear that this only captures changes
to those within a service hierarchy?


>The problem arises in countries not having a single emergency
>dialstring, like 911, but having different dialstrings for different
>services and dialstrings as well as services depend on location. When
>travelling around, the availability of services may change, as well as
>the dialstrings. So there needs to be some kind of rule on when to
>update the service list. Since the service boundary tells when to do a
>findService again, I thought it would be consistent to introduce
>another boundary to tell the client when to update the service list
>(as proposed in the draft).

In the past, we discussed this in terms of time, rather than movement;
this was because the list could also change because of additions (again,
not so much for emergency servies, but potentially for other services)


>Since I was just listening remotely to the discussion, I'd like to ask
>if I understood Ted's idea correctly: instead of a boundary indicating
>the area, the service list is valid for, the LoST Server should also
>return services that are NOT available at the current location.
>This would mean: when a client does a findService for
>urn:service:sos.ambulance for its current location, it would also get
>back a mapping for urn:service:sos.physician for a different location?

No; it sounds like something got lost here.  I was first proposing that
this should be limited in applicability, essentially to a single forest or
service type.  Then I was suggesting that a server able to traverse that
forest respond with a list of relevant services but without location
boundary information for those not available in the area relevant
to the query.  That is, you do a query using findServicebyLocation for
urn:service:geg and get back urn:service:geg.orthozog with a boundary,
and urn:service:geg.mumblefratz. with no boundary.  That avoids
dumping the database (and the current server having to collect the
information about where geg.mumblefratz is available); it simply
lets the client know that there are other services out there which
are explicitly not available at the target site of the first query.

If the client wants to use geg.mumblefratz, it needs to re-query.
It can requery at some specified time scale, or it can requery on
only when it wants to use geg.mumblefratz.

I was somewhat surprised, honestly, to see Henning arguing
for this, since he has argued against this idea in the past.  This
makes me suspect I am missing some subtle difference,
and I would not be surprised to find that this is so.  I would
like, however, if we did not concentrate on the emergency
services use case to the exclusion of other use cases; that
tends to skew the design in ways that will limit LoST's usefulness
in other realms.
			regards,
				Ted Hardie

>So when moving to this other area, the client already knows which
>services and dialstrings are available there.
>I'm afraid this approach would just solve the problem in case the LoST
>Server would dump more or less it's complete database to the client.
>If the LoST Server would just send a couple of mappings, and others
>not, the client could still be lost.
>Besides, traffic and complexity for the client would increase. The
>servicelistboundary wouldn't increase complexity too much for a client
>already evaluating the service boundary, since all the necessary
>functionality should be already in place. On the server side, the
>complexity should also be manageable (the servicelistboundary could be
>pre-calculated for the area the server has data for).
>
>Please let me know if I missed something in the discussion.
>
>karl heinz
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit