Subject: Re: [Ecrit] Changes in LoST -02

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 17 Dec 2006 13:33:08 -0500

I'm in the process of folding in comments into the -03 edition of the  
LoST spec, which should appear before Christmas. Adding to Andy  
comments and splitting the response to keep the size manageable:

On Nov 5, 2006, at 6:39 PM, Shida Schubert wrote:

>
> Hi;
>
> General comments on the 02 version of the draft.
> BTW Overall I really like where the draft is going.
> 1. Now that the protocol is allowed to carry more than 1 location  
> information
>     in the findservice query, it may be a good idea to indicate  
> which location was
>     used to find out the URIs.
>     > Otherwise I don't see how a server(proxy etc.) would be able  
> to cache a response and
>         later correlate it to a new request.

The text now indicates that the server picks the first-listed profile  
it understands.
The service boundary indicates which one it used (via 'profile').

>
> 2. Last paragraph in section 1 talks about how LoST is able to  
> provide list of services that
>     are provided in the location requested. Does this always hold  
> true? I can see that the server
>     is able to provide a list of services that the server in  
> question can provide but I don't see
>     how server will be aware of all the services that is provided  
> in the area.. (What if service
>     X is provided at a state level but service Y is provided at a  
> city level??)

I amplified the description to say that this can only be about the  
services known to a particular server. If a resolver doesn't know  
about 'food:pizza', it can't provide a useful answer, even if another  
resolver somewhere is an expert on food delivery services.

>
> 3. With many location possibly included in the findService is there  
> any way to
>      prioritize and indicate the location user wants  LoST server  
> to use? (I might have read the
>      draft wrong but section 6.3.1 reads as if you can have more  
> than one location with the
>      same location-profile..)

I clarified that each profile MUST only appear once and that the  
server picks the first one it knows.

>
> 4. There is no text explaining the ordering of <via> and its  
> semantics. If there is no rule,
>     there is no way for an endpoint to figure out which LoST server  
> provided the final
>     resolution.
>

Added text to the effect that its in response order, i.e., an entity  
processing a response appends its <via>.

> 5. What happens when the LoST query is exhausted while it's being  
> iterated?

You mean 'recursed'? Iteration is done by the querier, so it can give  
up if there's a loop, such as server A telling the querier to go back  
to B, where it just came from.

>
> 6. Can client put an asterisk to indicate it wants all the possible  
> information LoST server
>     can provide in "include" attribute.

We'll probably drop the 'include' mechanism, so this will become moot.

>
> 7. Figure 6 shows a response with the ServiceBoundry but it is not  
> requested in the
>     request. Is serviceBoundry a MUST in a response?

No, but the mechanism of requesting a serviceBoundary (none, value,  
reference) is still under discussion.

>
> 8. Section 6.4.7. <serviceNumber> is the only thing that is  
> declared optional in the
>     draft? Is everything else mandatory??

No, everything is optional in a mapping. I've clarified that aspect.

>
> 9. Section 6.4.4. Let's say the LoST server being queried is  
> responsible for the city,
>     and it only provides X and Y. But the server responsible for  
> state may provide
>     service X, Y and Z. Would it only return the alternative it is  
> aware of or should
>     it query the server responsible for the state and respond  
> according to what it
>     finds out..

Let's unwrap this a bit. The resolver knows about several different  
trees (indirectly, via forest guides). The assumption was (see  
architecture document) that each tree supports a whole service (e.g.,  
all of urn:service:sos). Things get messier if trees support some  
subset only. Is this something we want to support?

(It's still possible to do that, but the resolver would have to  
contact multiple trees.)

We probably need to have a more in-depth discussion on what we want  
to use listServices for. This is probably not as well defined as the  
other operations.

>
> 10. I don't understand why <getServiceBoundary> needs to be  
> defined. Can't
>      we just use the findService and have include

I'm not sure I understand your question. The idea is that the  
response, for space reasons, includes the reference, which the client  
then retrieves.

>
> 11. <getServiceBoundary> does not have the serviceURN in question.  
> I am assuming
>      that with LoST server possibly providing different services,  
> each services can also
>      have different boundary. If so the request and response should  
> have the relevant
>      service.

Andy answered that one.

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit