Re: [Ecrit] draft-ietf-ecrit-similar-location-11.txt (was: Ecrit Digest, Vol 187, Issue 52)

[Dan Banks <[e-mail]>]

First, an additional fix that I neglected to include in my earlier emails:  in the example in section 5.2, the 'similarLocationsLimited' attribute is shown on the final <similarLocation> element.  This is incorrect, as the attribute is defined by the schema directly on the <LocationValidation> element.

Additional discussion inline.

Dan

> -----Original Message-----
> From: Randall Gellens <[e-mail]>
> Sent: Wednesday, October 6, 2021 1:51 PM
> To: Dan Banks <[e-mail]>
> Cc: Victor Burton <[e-mail]>; [e-mail]
> Subject: Re: [Ecrit] draft-ietf-ecrit-similar-location-11.txt (was: Ecrit Digest,
> Vol 187, Issue 52)
> 
> Please see inline:
> 
> --Randall
> 
> On 5 Oct 2021, at 10:41, Dan Banks wrote:
> 
> > Regarding the examples in section 3, I'm a bit uncomfortable with
> > addresses not being expressed in a way that is consistent with the
> > CLDXF profile (fully spelled out), although I agree that they can
> > still communicate the concepts while using abbreviations.  I would
> > prefer that we modify these to use fully spelled STS and POD values
> > since CLDXF is supposed to be the official profile for the locations
> > being used.  And IIRC, CLDXF also requires the use of <country>.
> 
> [RG] This seems reasonable.
> 
> 
> > However, the point you make about missing country is important for
> > another, more basic reason.  While <country> is minOccurs="0" in the
> > civicAddress schema of RFC 5139, for all practical purposes a LoST
> > server (with less than global coverage, at least) cannot be expected
> > to know if it (or another server) is authoritative for a queried
> > location if that location does not include country.  Because of this,
> > our implementation considers civic locations without country to be
> > invalid - not in the <locationValidation> <invalid> list sense, but in
> > the <locationInvalid> error sense.
> >
> > So, I think the first example where the complete location adds
> > country, A1, and PC is a poor example.  In order for this to occur,
> > the LoST server would need to know that the remaining elements are
> > globally unique in combination - or more practically, that there is
> > only one A3 = "Seattle" in the world.
> 
> [RG] It seems to me that, in practice, an LVF will have a limited scope (a
> particular area), and hence will assume an omitted country (or even
> state) is the one in which it is authoritative or in which it is part of the LoST
> tree.  But I do agree that one use of this extension is to complete an address
> to make it pedantically correct rather than just sufficient to find the intended
> address, and in that sense, showing an omitted country corrected to include
> it is good.

[DB] I agree that an LVF will have a limited scope, however I strongly disagree that it would be appropriate for a LoST server to make an assumption as you describe.  One of the main principles that I have vocalized over the years with respect to how LoST servers should operate and interoperate is that a query should get the same answer no matter which LoST server the client first presents the query to.  There are some edge cases where this may not be 100% possible, but making an assumption about a critical omitted element undermines the principle.  And it is precisely because of the limited scope that an element such as country becomes critical.

I disagree, however, that showing an omitted country corrected to include is a good example.  In order to correct it, the server has to either know or assume it.  Knowledge is unlikely, and assumption is bad, leading to my conclusion that the example is problematic.

If we wanted to show an example of making something pedantically correct, I would suggest the A2 element being returned in the complete location.  A2 is mandatory in CLDXF (IIRC we argued in NENA about this at length), but LoST servers with state-wide GIS data are deployed and it is easy to understand that such a LoST server would know if a location within its county+A1 but missing A2 is uniquely identified or not.


> 
> > Additionally, I believe the later example of input and similar
> > addresses should also include country.
> 
> [RG] I agree that it would be good to also include country.
> 

[remainder trimmed]