Subject: [Ecrit] Comments/Questions on draft-ietf-ecrit-lost-02

From: "Reese, Theresa E" <[email-masked]>
Date: Mon, 20 Nov 2006 14:19:28 -0500

I have spent some time going through the latest draft of the LoST
document, and had the following questions for clarification:

1.	Is the 'recursive' attribute mandatory in all <findService>
queries?
Is the 'recursive' attribute mandatory only in <findService> civic
queries?
Is the 'recursive' attribute optional in <findService> queries?

Currently, the 'recursive' attribute is not shown in Figure 2
(<findService> geodetic query), but is included in Figure 4
(<findService> civic query).

2.	If a 'recursive' attribute is included in a <findService> query,
must a <via> always be present in the associated response?

Figure 4 includes a 'recursive' attribute in the query, but Figure 5,
which shows the associated response does not include a <via> element.
Also, the text in Section 6.4.1 specifies that responses to iterative
queries contain one <via> element, while responses to recursive queries
will have a <via> element for each server that was used in the
resolution.

3.	If the query originator sets the 'recursive' attribute in a
<findService> query message to "true," and the LoST server cannot answer
the query and has nowhere to forward the query to (i.e., the LoST server
does not have any arrangements with any other LoST servers to provide
assistance under this type of failure scenario), should the LoST server
treat the query as an iterative query (i.e., return an
<iterativeSearchExhausted> message)?

4.	The <findServiceResponse> message in Figure 6 includes some
elements that were not identified in the 'include' attribute of the
<findService> query (e.g., displayName, serviceBoundary). Is this a
typo?  Also, this example includes a 'recursive' attribute in the query,
but there is not via in the response.  Should the <via> element be
present in the response?

5.	There seem to be some inconsistencies in Figure 12 between the
information being requested in the <findService> query and the
information provided in the <findServiceResponse> message.  The query
requests the uri and serviceNumber.  The response provides
<displayName>, <service>, and <serviceBoundary>, and does not provide
<serviceNumber>.  I assume the author intended the query to include a
request for serviceBoundary, but this raises a question.  If the query
originator did not request serviceBoundary information, and provided
location using two different profiles (as is illustrated in Figure 12),
and the server did not understand the non-baseline profile, would the
server still communicate the locationProfileError, even if it was not
returning location information (in the form of a serviceBoundary)
itself?

6.	There seems to be text missing from the last sentence of the
first paragraph in Section 10.  The text begins to talk about errors
that are labeled as fatal, but then the text just stops.  The sentence
fragment either needs to be completed or deleted.

Also, the text in Section 10.2 says that the errors described in this
section "may be generated by referent LoST serve[r]s queried on behalf
of seekers by a resolving LoST server."  This seems to imply that these
would be error indications that would be received by the resolving LoST
server.  I assume that these would be passed back to the query
originator by the resolving LoST server.  Also, I assume that if the
LoST server is both the resolving and the responding LoST server, that
it would generate these error messages and pass them back to the query
originator (possibly with the exception of the serverError element which
seems to only apply to an error indication that a resolving LoST server
would receive from a responding LoST server).  Is this correct?

Thanks, in advance, for any clarification that can be provided.

Terry Reese
Telcordia Technologies

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

---

From: Andrew Newton <[email-masked]>
Date: Mon, 20 Nov 2006 20:32:00 -0500

Theresa,

Thanks for the questions.  Comments/answers are in-line:

> (<findService> civic query).

It is optional in both cases, with a default value of true.

> will have a <via> element for each server that was used in the

This is an inconsistency in the example.  We did a very poor job of  
putting <via> in anywhere.  That has been rectified in the new set of  
examples.  I believe you have specified the behavior correctly,  
though.  However, I'll let Henning have the last word here.

> <iterativeSearchExhausted> message)?

Well, the <iterativeSearchExhasted> was actually a redirect.   
Confusing, huh?  We've pulled it, and the new XML just has a  
redirect.  You can see the next schema and examples on-line here:
http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/RelaxNG/

To answer your question, I believe <notFound> would be the correct  
response to the scenario you have described.

> but there is not via in the response.  Should the <via> element be

Again, the examples were not consistent with the text.  We'll fix  
that problem next time around.

> returning location information (in the form of a serviceBoundary)

Good question.  The answer would be yes, the server should provide a  
warning (<locationProfileUnrecognized> in the new schema).

> fragment either needs to be completed or deleted.

Thanks.  As we mentioned in the meeting, we've overhauled the error/ 
warning scheme.  You can see that reflected in the schema which is on- 
line.  I suspect most of the text for that section will be rewritten  
entirely.

> would receive from a responding LoST server).  Is this correct?

I believe you have it correct.

-andy