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

[Andrew Newton <andy at hxr.us>]

Theresa,

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

On Nov 20, 2006, at 2:19 PM, Reese, Theresa E wrote:

> 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).

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

> 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.

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.

> 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)?

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.

> 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?

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

> 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?

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

> 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.

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.

> 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?

I believe you have it correct.

-andy



_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit