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

From: Karl Heinz Wolf <[email-masked]>
Date: Wed, 5 Aug 2009 14:01:23 +0200

My idea was actually to have the service boundary as a role model
since it is pretty much the same problem.
So I'm not sure if the definition of a separate service or subservice
is necessary.
The service boundary is optional in RFC 5222, why not have an optional
boundary information for the service list? If the server knows the
boundary for urn:service:sos, it can hand it out. If it does not know
it for urn:service:pizza, it returns no servicelistboundary. Is there
a problem with this approach?

karl heinz

On Wed, Jul 29, 2009 at 3:54 PM, Brian Rosen<[email-masked]> wrote:
> Well, I was thinking of either explicitly defining a subservice, much as we
> have defined sos and sos.police OR perhaps defining the urn so that any
> token(s) after servicelistboundary be treated as a filter for which services
> were composed into the servicelistboundary, with the default being all of
> the services the LoST server handles.
>
> Brian
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Brian Rosen
>> Sent: Wednesday, July 29, 2009 9:33 AM
>> To: 'Karl Heinz Wolf'; 'Ted Hardie'
>> Cc: 'ECRIT'
>> Subject: Re: [Ecrit] servicelistboundary - discussion in the meeting
>> today
>>
>> Perhaps the service URN has some sub urns, like
>> urn:service:servicelistboundary.sos
>>
>>
>> > -----Original Message-----
>> > From: [email-masked] [mailto:[email-masked]] 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<[email-masked]>
>> 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
>> > >>[email-masked]
>> > >>https://www.ietf.org/mailman/listinfo/ecrit
>> > >
>> > >
>> > _______________________________________________
>> > Ecrit mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/ecrit
>>
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>