Re: [Ecrit] WGLC for draft-ietf-ecrit-similar-location - end date April 8

[Dan Banks <[e-mail]>]

I have spent some time reviewing the similar location draft, comparing to my previous suggestions as well as our preliminary implementations (both server and client side, in use in a large, live deployment for some time), and have some feedback:

In Section 4, text was added to give the client control of the response, which aligns closely with the suggestion I made previously.  There are a couple of differences, however:

  *   The text describes a <returnAdditionalLocation> element, rather than an attribute.  I would prefer an attribute, but can live with an element.  The schema in section 6, however, specifies an attribute.  The text and the schema need to be consistent.
  *   Originally I suggested that omission of the attribute be equivalent to asking for “none”, but the draft stipulates that omission be equivalent to asking for “any”.  I still believe that it is safer if the server not incur the cost of generating return location data unless the client specifically asks for it, and would prefer that omission be equivalent to “none” as previously suggested.
  *   This section also describes a <similarLocationsLimited> element to contain a number indicating how many locations were not included in the response.  This is compatible with my earlier suggestion of a boolean attribute simply indicating that some undetermined number of additional location exists.  However, the new element does not appear in the schema in section 6.  Again I would prefer an attribute for this purpose, but I can live with an element.

Also in section 4, it states that “The number of similar locations sent is entirely up to the server, but MUST be less than 10.”  Based upon user feedback from our live environment, a limit of 10 severely degrades the usability of this extension for certain scenarios where there are large numbers of very similar addresses (differing only by a sub-address element, for example).  Our limit was originally slightly higher, but has since been revised to be larger by more than an order of magnitude.  I suggest that a specific number limit be removed from this draft entirely, and the decision truly be “entirely up to the server”.  I also suggest revising the text that states “but SHOULD NOT return more than a few possible similar locations” to be consistent.

Previously I pointed out that the text states similarLocation and completeLocation include the ‘profile’ attribute, and that I believe it is important to make it mandatory to use the same profile in the response as the request, and that using the profile attribute also be mandatory.  This does not appear to have been included in the revisions, but I still believe it is important.

Section 4 states ”completeLocation and similarLocation use the locationInformation element from [RFC5222]”.  This was previously shown as part of the RelaxNG schema.  However, the schema in version -05 no longer references 5222 and instead attempts to redefine these elements.  In terms of schema, this seems to be a trivial difference.  However, unless I am misunderstanding the use of xs:group, the schema in -05 now does not actually define these elements at all.  This will need to be fixed.

The first sentence of section 4 states “The LoST server implementing this extension MAY include completeLocation or similarLocation in the findService response.”  This is not exactly the most accurate description.  This would be better: “The LoST server implementing this extension MAY include <completeLocation> or <similarLocation> within the <locationValidation> portion of the <findServiceResponse>.  (The use of angle-brackets around the element names is not entirely consistent throughout the document, and I’m not sure what we should do about that, but I have included them here.)  There is also similar text in section 3 that may need to be revised.  Specifically, it should always be clear that we are extending the validation portion of the response.

In the examples in sections 5.1 and 5.2:

  *   The returnAdditionalLocation attribute or element (see comments above) should be shown in the findService request.
  *   The locations in the requests do not follow the CLDXF profile, but the responses were revised so that they do.  This seems like an oversight and leads to an example where an element is listed as Valid but then the value of that element is different in the returned <completeLocation>.  I think this would be undesirable (if intended).  Section 3 also illustrates these addresses in abbreviated form, and while this is not really incorrect, I think it would be better to spell them out.

Section 6 (schema):
I am not fond of making this draft dependent upon the planned changes draft, and would prefer that it stand alone, especially in light of my concerns with “replacement” of the 5222 schema.
That aside, the schema in this sections has some issues as previously noted.  Additionally, the ‘asOf’ attribute appears to have been inadvertently copied from the planned changes draft, and should be removed.

An included comment states “<!-- extend the extensionPoint of commonRequestPattern of findService to include:  -->”.  The wording on this seems awkward.  I think we understand that we are not extending the commonRequestPattern itself, but it could be misinterpreted.  I suggest something like “<!—extend findService by placing the following at the extensionPoint in the included commonRequestPattern: -->”.

I would also replace “<!-- extend the extensionPoint of commonResponsePattern of findServiceReponse to include -->” with “<!—extend locationValidation by placing the following at the extensionPoint: -->”.  Also, please note that we are extending the locationValidation element, not the findServiceResponse itself.  The language in sections 3/4 is not currently clear on this (see comments above), and I’m not sure that a comment in the schema alone is sufficient either.  We should make sure it is obvious in the text precisely where these extended elements go.

Overall, I find this extension to be very useful and support its advancement when the remaining issues are resolved.

Dan Banks

From: Ecrit [mailto:[e-mail]] On Behalf Of Az Mankin
Sent: Sunday, March 25, 2018 5:50 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [Ecrit] WGLC for draft-ietf-ecrit-similar-location - end date April 8

This starts WGLC for draft-ietf-ecrit-similar-location-05, A LoST extension to return complete and similar location info
Please send both comments and messages that you support advancement to this mailing list before April 8.
Roger and Allison