[Ecrit] draft-ietf-ecrit-similar-location-03 feedback

[Dan Banks <[e-mail]>]

I have been working on an implementation of the similar location mechanism described by draft-ietf-ecrit-similar-location-03, and have some feedback:

1)
For completeLocation, the actual element name in the schema is "completedlocation", with a 'd' and lowercase 'l'.  It appears this should be "completeLocation".  There is also a use of "completedLocation" on page 5 that should be changed.  Also, there will only be a single completeLocation returned.

   ##
   ##       completeLocation
   ##
   div {
     completeLocation =
       element completedlocation {
         locationInformation
       }+
   }

Should be:

   ##
   ##       completeLocation
   ##
   div {
     completeLocation =
       element completeLocation {
         locationInformation
       }
   }

2)
An element "returnedLocationResponse" is defined by the schema, but not discussed in the text or illustrated in the examples:


   div {

     returnedLocationResponse =

       element returnedLocationResponse {

         completeLocation, similarLocation, extensionPoint

       }

   }

Perhaps we need a better way state that completeLocation or similarLocation elements can be placed at the existing extension point within the LoST locationValidation element.

3)
It is desirable to have away for a client to specifically request RLI, instead of it being included any time that validation is performed.  Responses with multiple similar locations can quickly become large compared to responses without RLI, and may also incur additional processing cost at the server.  This could be wasteful if automated validation is being performed or if the RLI is otherwise not understood or discarded.  I suggest an attribute be added to the findService request (perhaps rli:returnLocation) with defined values of { "none" | "similar"  | "complete" | "any" } to indicate which return location types the client is interested in.  Further, I suggest that the server be restricted to including only RLI types in the response that are requested, and that omitting the attribute from the request is equivalent to rli:returnLocation="none".

4)
The text and schema state that the similarLocation and completeLocation elements include the "profile" attribute, but this is not shown in the examples.  RFC5222 makes the profile attribute optional in location chunks.  On the server side, this means that any location chunks without a profile attribute need to be further analyzed to see if they can be recognized, which is an unnecessary complication.  On the client side, the response pertains to one particular location in the request (indicated by <locationUsed>), so the profile could be assumed from that, but I would much rather have it be explicit.

I suggest we make the profile attribute mandatory where it is used within this extension.  I also suggest we add text to the effect of "If completeLocation or similarLocation is included in the findService response, the profile MUST be the same as that of the location in the request that is used to generate the findService response."

Also, section 4 states:

   completeLocation and similarLocation use the locationInformation

   element from [RFC5222<https://tools.ietf.org/html/rfc5222>] including the profile attribute which is

   useful if the request contains location information in a profile

   derived from the civic profile.

However, locationInformation is only a pattern defined in the schema in RFC5222, borrowed and reused here, not an actual element.  Suggest changing the wording from "element" to "pattern".

5)
I would like to suggest that each element that users the locationInformation pattern should only represent one location.  That is, instead of a single similarLocation element containing multiple civicAddress elements (as illustrated in the example), multiple similarLocation elements should be used with each containing a single civicAddress.

I am continuing to review this draft and may have additional comments.

Dan Banks