Subject: [Ecrit] Comments on lost-04

From: "Reese, Theresa E" <[email-masked]>
Date: Fri, 16 Feb 2007 09:16:01 -0500

Having reviewed draft-ietf-ecrit-lost-04, I have the following comments:

1. Section 5.3 of lost-04 states, "On occasion, a server may be forced
to return an expired mapping if
   it cannot reach the authoritative server or the server fails to
   return a usable answer.  Clients and servers MAY cache the mapping so
   that they have at least some information available.  Caching servers
   that have such stale information SHOULD re-attempt the query each
   time a client requests a mapping."  

Since, based on prior feedback received in response to my comments on
lost-03, there will be no warning included in a response that contains
expired data,  please add a statement that says that the client is
expected to check 'expires' attribute associated with mapping data
returned in a LoST response. There is already a statement in this
paragraph that describes client behavior (i.e., that the client may
cache the mapping data).  I would like to see this expanded to clarify
this additional client behavior.

2. The first sentence of Section 5.6 states, " A response MAY indicate
the region for which the service URL returned would be the same as in
the actual query, the so-called _service region_."  Later on in the
paragraph, there is a statement that states, "The response MUST contain
at least one service boundary using the same profile as the request."  

Since it is optional to include a <serviceBoundary> in a response, it is
suggested that the text in the latter sentence of the paragraph be
modified as follows, "If included in a response, the <serviceBoundary>
element MUST contain at least one service boundary that uses the same
profile as the request." 

Also in a response to my comments on lost-03, it was stated, "A
serviceBoundary needs to be requested by the client (using a
serviceBoundary="value" attribute) or is included by the server if local
policy indicates it."  I do not see any text in lost-04 that describes
the latter condition under which a <serviceBoundary> element will be
included in a response.

3. Section 7.3 of lost-04 states the following:  "The <findService>
request includes attributes that govern whether the request is handled
iteratively or recursively, whether location validation is performed and
which elements must be contained in the response."  

Please change the text to read "....which elements MAY be contained in
the response."  Based on a previous e-mail exchange, the LoST server may
or may not return the explicitly requested elements identified above, as
well as others that are implicitly requested (i.e., URI, displayName,
serviceNumber) depending on whether it supports them or not. As
indicated in previous e-mails, my preference would be to include a
warning if requested data cannot be provided in the response.  However,
if lost-04 addresses this situation by just omitting the unavailable
information from the response (without treating it as an abnormal
condition), then the text in Section 7.3 should not use the word "must".

4.  In my comments on lost-03, I requested that additional text be added
to Section 7.3.3 to clarify the iterative case.  The response that
Hannes provided to my comments on lost-03 provided a number of helpful
clarifications, but I do not see any additional clarifications included
in lost-04.

5. Section 7.4.2 of lost-04 states, "A server can indicate in its
response which civic address elements it has recognized as valid, which
ones it has ignored and which ones it has checked and found to be
invalid.   The server MUST include this information if the
'validateLocation' attribute in the request was true."

The continued use of the word MUST in the last sentence is inconsistent
with the e-mails received in response to my comments on lost-03.  If a
LoST server receives an iterative request for validation information,
but does not support validation, either it will return an error message
or it will just omit the information from the response.  In my opinion,
only the first option applies if the text in Section 7.4.2 continues to
use the word "MUST", and Hannes described an error message that would be
appropriate for this case.  Henning was of the opinion that the response
message should instead just omit the validation information (without any
type of error/warning provided).  As indicated previously, my preference
is for an appropriate error/warning to be returned.  If this approach is
not to be supported by LoST, then the text in Section 7.4.2 should only
use the word "MAY".  It should be further noted that, if Henning's
approach is used, changes will need to be made to Section 12 of the
document which states that a warning should be provided if the server is
only capable of returning part of the requested information, and an
error of "not found" if the server cannot find an answer to the query.
Again, my preference is to use the errors/warnings defined in Section 12
for such scenarios.

6. Section 12.2 of lost-04 states the following: "This version of the
specification does not define any warning elements."    

This statement is inconsistent with the text in Section 12 which states,
" It returns a <warnings> element as part of another response element if
it was able to respond in part, but the response may not be quite what
the client had desired" and "Unless otherwise noted, all elements below
can be either an error or a warning, depending on whether a default
response, such as a mapping, is included."  

To reiterate, consistent with Hannes' response to my previous comments
on lost-03, I support the use of warnings when only partial information
is available.  

Thank you for your consideration of my comments.

Terry Reese 

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