Re: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct 13

[Dan Banks <[e-mail]>]

I have reviewed draft -11 and in addition to my earlier response to Victor's comments, I have the following suggestions and feedback:

In section 2, Terminology
Change:
   Civic Address Element:  The term Civic Address Element is used within
      this document to apply to an individual CAtype data descriptor,
      for example, as is described in [RFC4776], [RFC5774], and
      [RFC6848].
To:
   Civic Address Element:  The term Civic Address Element is used within
      this document to indicate any individual XML element used within
      the <civicAddress> type defined in [RFC5139], including elements used
      at the extension point therein such as those defined in [RFC6848] and
      elsewhere.  This term also includes the reference to such elements
      by qualified name as defined within the <locationValidation> element
      in [RFC5222].


The definitions of Invalid Location and Valid Location being constrained to those locations that have actually been queried against a LoST server is problematic for the usage elsewhere in the document.  While we could argue that a location is neither Valid nor Invalid until we actually test it, then we would have to separately define "expected" valid and invalid locations.  I think it would be better to modify the definitions as follows:

Change:
Valid Location:  A Civic Location that was included in a LoST query
      with 'validateLocation' set and subsequently returned with all
      Civic Address Elements in the <valid> or <unchecked> lists.
To:
Valid Location:  A Civic Location that, when included in a LoST query
      with 'validateLocation' set, will obtain a response having all
      Civic Address Elements in the <valid> or <unchecked> lists.

Change
   Invalid Location:  A Civic Location that was included in a LoST
      request with 'validateLocation' set and subsequently returned with
      one or more Civic Address Elements marked as invalid.  Note that
      location information may be submitted in the <findService> request
      that causes the LoST server to return Civic Address Elements in
      the <invalid> list.  It is also possible that the location
      information submitted is so inaccurate that this extension can not
      be used, and the LoST server may return a <notFound> error.  In
      this document, we use the term Invalid Location only to refer to a
      case where the LoST server returns one or more elements in the
      <invalid> list.
To:
   Invalid Location:  A Civic Location that, when included in a LoST
      query with 'validateLocation' set, will obtain a response having
      one or more Civic Address Elements in the <invalid> list.  Note that
      It is also possible that the location information submitted is so 
      inaccurate that location validation cannot be performed, and the
      LoST server may return a <notFound> or <locationInvalid> error.  In
      this document, the term Invalid Location only refers to a
      case where the LoST server returns one or more elements in the
      <invalid> list; the error conditions are not considered.

I suggest rewording the definition for Similar Location to make it more clear.
Change:
      A suggested civic location that is similar to the
      civic location which was input, but which had one or more invalid
      civic address elements returned by the LoST server or was missing
      Civic Adddress Elements the server has for the location.
To:
      A suggested civic location that is similar to an
      Invalid Location which was used in a LoST query, but which has one
      or more elements added, modified, or removed such that the
      suggested location is a Valid Location.


It's probably good for the draft to allow the use of not-yet-defined location profiles that "derive" from the civic profile, but it is also a bit problematic.  Even in RFC 5222, the concept of location validation is really only discussed with respect to the baseline civic profile.  I think we need a few changes related to that.

In section three, first paragraph:
Change:
   This
   extension is applicable when the location information in the
   <findService> request is in a civic profile as described in RFC5222
   or in another profile derived from that civic profile.
To:
   This
   extension is applicable when the location information in the
   <findService> request is in the Basic Civic profile as described in RFC5222
   or in another profile derived from the Basic Civic profile.  Because such
   derived profiles have not yet been defined, this document describes
   the returned location extension primarily in terms of how it is to be
   used with the Basic Civic profile.  Future definitions of profiles deriving
   from the Basic Civic profile SHOULD provide instructions concerning the
   use of their respective profiles with this extension.  In addition, the
   following restriction is imposed:  A server MUST NOT include Returned
   Location Information using a location profile that differs from the profile
   of the location used to answer the query and, by extension, MUST NOT
   include Returned Location Information using a location profile that was
   not used by the client in the request. 


In section four, first paragraph,
Change:
   The
   <completeLocation> and <similarLocation> elements contain a list of
   Civic Address Elements identical to the elements used in the location
   element with the 'civic' profile in [RFC5222] or another profile
   derived from the civic profile.
To:
   The
   <completeLocation> and <similarLocation> elements are of type 
   "locationInformation" as defined by the LoST schema in [RFC5222], and 
   contain location information in the same profile of the location used to 
   answer the query.  These elements MAY contain location information
   either in the Basic Civic profile defined in [RFC5222] or in another profile
   that derives from the Basic Civic profile when such a profile has been defined.
   When used with the Basic Civic profile, these elements contain  a
   <civicAddress> element as defined in [RFC5139]. 


In the middle of section three, 
Change:
   in the case where a LoST server response includes one or more Civic
   Address Elements marked as invalid, constituting an Invalid Location
   response.
To:
   in the case where a LoST server response includes one or more Civic
   Address Elements marked as invalid, indicating an Invalid Location
   used in the query.

Change:
   The other use case for this extension is when Invalid Location is
   received from the LoST server.
To:
   The other use case for this extension is when Invalid Location has been used
   To query the LoST server.

And also change:
   When a LoST server returns a response
   to a <findService> request that contains a set of Civic Address
   Elements with one or more labeled as invalid, the location
   information in the <findServiceResponse> can be extended to include
   one or more locations that might be the location desired.
To:
   When a LoST server returns a response
   to a <findService> request that contains a set of Civic Address
   Elements with one or more labeled as invalid, the validation portion of 
   the <findServiceResponse> can be extended to include
   one or more locations that might be the location desired.

In the final paragraph of section three,
Change:
   This extension allows the LoST server to include the above similar
   addresses in the response to 'validateLocaton' request.
To:
   This extension allows the LoST server to include the above similar
   addresses in the response to a <findService> request having 'validateLocaton' = true.

In the schema, the <group> element still needs to be corrected to include an xs: prefix.


Overall, section three, the "overview", has the same concepts expressed more than once.  This seems unnecessary.  Also, the overview is about twice as long as section four.  I would like to see some effort to make these two sections better organized.

I believe the extension defined here is useful (and implemented a version of it quite some time ago), but I think the draft deserves another pass or two before it advances.

Dan Banks


> -----Original Message-----
> From: Ecrit <[e-mail]> On Behalf Of Randall Gellens
> Sent: Wednesday, September 29, 2021 3:52 PM
> To: ECRIT <[e-mail]>
> Subject: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct 13
> 
> This starts WGLC for draft-ietf-ecrit-similar-location-11, a LoST extension to
> return complete or similar location info.
> 
> Please send both comments and messages that you support advancement of
> the draft to this mailing list before October 13.
> 
> Thank you,
> 
> --Randall
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Fmailman%2Flistinfo%2Fecrit&amp;data=04%7C01%7Cdbanks%
> 40ddti.net%7Caa8d2edeb98a4a7b667108d98382903a%7C4c0f48ba5f2944b1b2
> 9c1aff8251101b%7C0%7C0%7C637685419081084242%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C1000&amp;sdata=%2BmezKd%2FhSQT3mUcMvQcEg3IWNUus
> 1yuz%2FU%2B0dim%2BTfI%3D&amp;reserved=0