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

From: Dan Banks <[email-masked]>
Date: Fri, 6 Apr 2018 20:42:50 +0000

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:[email-masked]] On Behalf Of Az Mankin
Sent: Sunday, March 25, 2018 5:50 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Apr 2018 16:50:42 -0700

On 3/25/18 2:49 AM, Az Mankin wrote:
> This starts WGLC for draft-ietf-ecrit-similar-location-05,**A LoST
> extension to return complete and similar location info
> 

Sorry about the slow response. Here is some feedback on the schema (each
comment is prefaced by "^^^").

###

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="urn:ietf:params:xml:ns:lost-rli1"
           targetNamespace="urn:ietf:params:xml:ns:lost-rli1"
           elementFormDefault="qualified">
     <!-- Import base Lost -->
     <xs:import namespace="urn:ietf:params:xml:ns:lost1"/>

^^^ We import this for the <location/> element, right? That should be
prefaced appropriate below...

<!-- extend the extensionPoint of commonRequestPattern of findService to
include:  -->

^^^ Although we can say where an extension is intended to go, AFAIK
there's no way in XML schema to restrict the use of an extension to a
particular place in a structure defined by another schema.

      <xs:atttribute name="asOf" type="xs:dateTime" minOccurs="0"/>

^^^ As Dan mentioned, this might have been copied from another schema.

      <xs:attribute name="returnAdditionalLocation" minOccurs="0">
       <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="none"/>
            <xs:enumeration value="similar"/>
            <xs:enumeration value="complete"/>
            <xs:enumeration value="any"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>

<!-- extend the extensionPoint of commonResponsePattern of
findServiceReponse to include -->
 <xs:group ref="similarLocation"/>
        <xs:group ref="completeLocation"/>
<!-- where -->
<xs:group name="similarLocation">
    <xs:sequence xmlns:base="urn:ietf:params:xml:ns:lost1">

^^^ add the imported namespace here

      <xs:element ref="base:location" maxOccurs="unbounded"/>

^^^ add the namespace preface

      <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:group>

<xs:group name="completeLocation">
    <xs:sequence xmlns:base="urn:ietf:params:xml:ns:lost1">
      <xs:element ref="base:location" maxOccurs="1"/>

^^^ as above

      <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:group>
</xs:schema>

###

Because the definitions of the similarLocation and completeLocation
groups are the same, we could define this in a less verbose way, but
what we have is OK.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 25 Apr 2018 08:28:12 -0700

One more note...

> ^^^ add the imported namespace here

^^^ Actually that could go in the xs:schema element at the very top.

Peter