Subject: [Ecrit] comments on draft-ietf-ecrit-similar-location-01

From: Dan Banks <[email-masked]>
Date: Tue, 16 Feb 2016 23:39:17 +0000

I have reviewed draft-ietf-ecrit-similar-location-01 and believe the functionality described will be useful.  The existing validation portion of a LoST response carries limited information that is not always helpful in resolving issues with invalid locations.  I do have a few comments that follow below.

The introduction states, in part:
   The use of this protocol extension will reduce
   user and system input errors, and will result in a higher level of
   civic address matching, reducing the number of mismatch errors, where
   a civic address that appears to be valid gets wrongly associated with
   the physical location of the caller.

I think it would be better to say that this protocol extension will facilitate the correction of errors, and allow location servers to be more easily provisioned with complete address information.  This may be splitting hairs, but to reduce input errors from the beginning, I think it would be necessary to implement guided data entry - something like the auto-complete text boxes on popular search/mapping websites - and I do not see this draft being especially helpful for something like that.  I also do not believe that this draft will be very helpful in preventing valid - but incorrect - civic addresses from being associated with a caller.

In section 2:

1)      The definitions for Civic Location and Street Address reference the concepts of a grid and basemap.  While some addressing schemes may in fact be based on a grid, my experience is that this tends to not be the case.  Except in cases where the <ADDCODE> element happens to reference a grid (or <SEAT>), there are not any civic address elements that specifically grid-oriented.  While the house numbers assigned along a road may sometimes also align with a grid, that is usually of secondary importance.  Without further definition, I think it is also troublesome to use the term "basemap".  I suggest replacing ". . . to designates a place within a defined grid or basemap" with ". . . to designate a specific place within a region of geography, or a region of geography by itself."  I am also concerned that we may be redefining civic location needlessly, and should simply leave the definition as a reference to RFC 5139, as is done in LoST itself.

2)      The definitions for Invalid and Valid do not seem to be helpful to me.  These are referencing the valid and invalid categories defined in RFC5222, but seem to be vague restatements of the definitions.  I do, however, think that we should clarify and tweak the normative definitions of these elements, including the <unchecked> element.  I'm not familiar enough with the process to know if this draft is the appropriate place to do that, but it seems relevant.

3)      While this definition of Invalid Location is appropriate to the very narrow case that is described, it does not even encompass all cases of invalid location within LoST.  I see this potentially leading to confusion.  We may wish to explicitly call out the distinction between the case where elements are marked as invalid and the cases where a locationInvalid or notFound error are returned.

4)      The definition of Valid Location needs to also account for the possibility of some elements being unchecked.

5)      In the definition of Similar Location, the pronoun "which" after the comma could be unclear.  I understand which location is being referred to, but an unfamiliar reader may be confused.

6)      The definition of Returned Location Information here seems redundant, but if kept, could be simplified to say something more like "A set of civic locations returned in a LoST response."  I specifically wish to avoid saying "standard . . . elements" because that seems to exclude the return of extended elements.  The language in section 4 should also be made consistent.  Section 4 also contains the only reference to the civic location profile.  I think it is a good idea to explicitly state somewhere that this entire extension only applies to responses generated for queries containing location in the civic profile, and reference the definition in RFC 5222.  However, we may also want to consider allowing RLI in other profiles that are derived from the baseline civic profile in addition to the civic profile itself.

Section 3 is titled overview, but then goes into significant detail.  So much so that the remaining sections contain little more than examples and schema.  Consider reorganizing.

In some cases, it might be dangerous to assume that an underspecified location really is the "complete" location that an LoST server identifies as the best match.  I think the language that states that the server MAY return complete location information is in alignment with this concern, but perhaps caution could should be advised.

In the last paragraph of page 5, the text seems to define a "valid location response".  While I understand the intent, there really is no such thing, and I would prefer to avoid this language in favor of being more precise.  I suggest "In a LoST <findServiceResponse> indicating a valid location - i.e. containing a <locationValidation> element with no elements listed as invalid - the <locationValidation> element MAY be extended to include additional location information . . . "

In the discussion about returning a complete location, I think it should also say something to the effective of " the complete location SHOULD NOT contain any elements that would be marked as invalid, or cause an error, if a recipient of that location performs a subsequent findService request using the complete location."  I'm only hesitant about making this a MUST NOT because the conditions for returning CLI state SHOULD only happen when there are only valid elements.  Also, the existing condition should be changed to allow unchecked elements, consistent with my earlier comments.

The examples given show missing A1 and country elements, and I think this is a bad example.  While it might be theoretically ok if there is only one Seattle in the world, there are practical issues that would need to be addressed to make this possible (e.g., listing a coverage region for Seattle in the forest guide).  Also, the example on page 8 does show A1 as an input, but does not include it in the <valid> list in the response.

The examples in section 3 also are shown as a traditionally written address, which may aid in understanding the general concepts, but also leaves ambiguities (such as A3 v. PCN).  I think this might be ok because the XML examples later show all of the elements, but it may be better reorganize and either move the XML examples closer to the text describing the scenarios, or find a way to eliminate the ambiguities entirely.

Another note about the examples: the addresses as shown are not consistent with CLDXF (civic address usage profile for the U.S.)

I would like to see one or more parameters added to the <findService> request to ask for similar or complete location info.  In certain scenarios, the client may not want to receive this info.  As a specific example, as a location server, when I am doing bulk validation of many records, I have no interest in similar locations.  I only need that data once I have a human in front of a screen who can evaluate it and take action, and I would submit a request to get a fresh response at that time.

The schema in section 7 has a few issues:

1)      completeLocation and similarLocation are defined by name in the schema, but consist of 1 or more elements simply named <location>.  This is not consistent with the examples and appears to be a cut/paste mistake from RFC 5222.  These definitions also include the 'id' attribute, which is not otherwise described here (and probably not useful).

2)      The locationInformation definition includes a profile attribute.  Considering my comment #6 about section 2, this would be appropriate if we allow RLI in multiple profiles, but otherwise is not described in the current draft.

3)      The locationInformation definition includes an apparent error also present in RFC 5222.

notLost = element * - (ns1:* | ns1:*) { anyElement }
should be
                notRLI = element * - (ns1:* | local:*) { anyElement }
with a prior definition of
namespace local = ""
                and description of "Any element not in the LoST-RLI namespace" or similar.
                I believe the schema in RFC 5222 was intended to exclude the local namespace as well, and the non-normative schema in XML syntax is consistent with that (at odds with the normative schema in compact form).  If we can do a normative update of RFC 5222 with this document, I would like to see this fixed (and if we can, the other previously reported errata pertaining to the schema as well).

The title of section 9.2 should specify the LoST-RLI namespace (not simply LoST), and the <title> element appears to contain a copy/paste error: <title>LoST Planned Change Namespace</title>.

Dan Banks