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

[Dan Banks <[e-mail]>]

Inline as well.

> -----Original Message-----
> From: Randall Gellens <[e-mail]>
> Sent: Wednesday, October 6, 2021 1:38 PM
> To: Dan Banks <[e-mail]>
> Cc: ECRIT <[e-mail]>
> Subject: Re: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct
> 13
> 
> Please see inline.
> 
> On 5 Oct 2021, at 14:30, Dan Banks wrote:
> 
> > 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.
> 
> [RG] My understanding is that the current definition and expected use
> includes returning one or more similar locations for both valid (but potentially
> incomplete) or invalid queried locations.  If so, this proposed change is too
> limiting.
> 

[DB] I believe this is incorrect, and that the intent is for similar locations to be returned only in response to an invalid location in the query, while a complete location will only be returned in response to a valid (but potentially incomplete) location in the query.  Ensuring that this intent is clear was part of the reason I suggested the edit.

> 
> 
> > 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.
> 
> [RG] Or, we could reword slightly to avoid trying to impose normative
> requirements on future documents:
> 
> [RG] 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 whose definition provides instructions
> concerning its use with this extension.  As of this document, no such
> additional location profiles have been defined, so this document describes
> the returned location extension primarily in terms of how it is used with the
> Basic Civic profile.

[DB] That seems fine to me.

> 
> > 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.
> 
> [RG] Or, using the same language as above:
> 
> [RG] or in another profile whose definition provides instructions concerning
> its use with this extension.
>

[DB] I would be ok with making this AND - derives from the Basic Civic profile and provides instructions, etc.  I think it is important to identify this concept - the extension applies to validation, and validation is only defined for civic profiles.


> >    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.
> 
> [RG] Perhaps:
> 
> [RG] The other use case for this extension is when the queried location is an
> Invalid Location.

[DB] I prefer it the way I originally suggested, but this would be ok.

> 
> 
> > 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,
> 
> [RG] Did you want to suggest changing "labeled" to "listed" to match
> your other suggested edit?

[DB] yes, I believe "listed" is more correct.

> 
> >    the validation portion of
> >    the <findServiceResponse> can be extended to include
> >    one or more locations that might be the location desired.
> 
> [RG] I'd suggest changing this to:
> 
> [RG] this extension allows the server to include in the
> <findServiceResponse> one or more locations that might be the intended
> location.

[DB] I believe it is important to keep the specificity regarding the validation portion.  This could alternately be expressed as "the <locationValidation> element.  We're not using the extension point directly in the <findServiceResponse>, and I wish to prevent readers from misunderstanding that.

> 
> 
> > 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.
> 
> [RG] I'd suggest changing "having" to "with" and changing "=" to "set
> to".
> 

[DB] That's fine with me.

> >
> > 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