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

[Randall Gellens <[e-mail]>]

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.



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

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

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


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

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


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

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