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

["Brian Rosen" <[e-mail]>]

Perhaps the service URN has some sub urns, like
urn:service:servicelistboundary.sos


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Karl Heinz Wolf
> Sent: Wednesday, July 29, 2009 9:21 AM
> To: Ted Hardie
> Cc: ECRIT
> Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting
> today
> 
> Ted,
> 
> thank you for your clarification.
> 
> You might be correct, I probably focused too much on emergency
> services. But there it hurts the most: if you're unaware of the
> service, you don't have the dialstring and you definitely cannot
> detect the emergency call to this service.
> 
> On Wed, Jul 29, 2009 at 2:27 PM, Ted Hardie<[e-mail]> wrote:
> > 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).
> >
> right, the draft does not explicitly say this at the moment.
> Thank you for pointing this out, it helps me understanding the
> discussion better.
> >
> >>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?
> >
> 
> but you don't need to know the dialstring for pizza in advance: if you
> press the pizza button on your device, it can simply do the service
> discovery.
> 
> >
> >>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)
> >
> 
> I wasn't talking about changes in time - sorry if didn't express that
> clearly. Besides, the changes in time would be addressed by the
> expires attribute.
> 
> >
> >>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.
> >
> 
> hm, as I understand it, the client has still the same problem: when
> does the service become available? The only information the client
> gets is that this service is available "somewhere". I'm not sure this
> is helpful?
> Moreover, considering the emergency service case, you have to know the
> dialstring right before the call. I know I'm concentrating on
> emergency services...
> 
> > 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.
> 
> I'm afraid we need some kind of rule on when to update the service
> list when travelling. And this is crucial for figuring out the
> dialstings as long as there is not a single emergency dialstring all
> over the world.
> I'm not sure if the servicelistboundary makes much sense for other
> services, since as you pointed out, they may just get discovered on
> demand without any problems.
> However, also the service boundary is optional in LoST, also the
> servicelistboundary could just be optional and only be returned in
> case the server knows it or it's about emergency services.
> 
> karl heinz
> 
> >                        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
> >
> >
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit