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

Randall Gellens <rg+ietf@randy.pensive.org> Sat, 09 October 2021 00:07 UTC

Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C52F3A0E13 for <ecrit@ietfa.amsl.com>; Fri, 8 Oct 2021 17:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn18KCg4gpVa for <ecrit@ietfa.amsl.com>; Fri, 8 Oct 2021 17:07:23 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 915AC3A0E15 for <ecrit@ietf.org>; Fri, 8 Oct 2021 17:07:23 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 8 Oct 2021 17:07:23 -0700
From: Randall Gellens <rg+ietf@randy.pensive.org>
To: Dan Banks <dbanks@ddti.net>
Cc: ECRIT <ecrit@ietf.org>
Date: Fri, 08 Oct 2021 17:07:22 -0700
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <3DD731A1-3AA8-4AA9-A477-077441BCC701@randy.pensive.org>
In-Reply-To: <MWHPR1701MB1822AB919FAB146E5DD59EC9A7B29@MWHPR1701MB1822.namprd17.prod.outlook.com>
References: <6AA591C6-B84B-4A7E-936A-10C95C5FA936@randy.pensive.org> <DM5PR1701MB1818510A235B96FEAC3A64EAA7AF9@DM5PR1701MB1818.namprd17.prod.outlook.com> <8B928AC8-4087-482D-86FB-553689596348@randy.pensive.org> <MWHPR1701MB1822AB919FAB146E5DD59EC9A7B29@MWHPR1701MB1822.namprd17.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/GouTkY7HZMJ_2HYmcazdhTDXi8w>
Subject: Re: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct 13
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Emergency Context Resolution with Internet Technologies <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Oct 2021 00:07:29 -0000

My apologies, I sent the prior message prematurely.

Also in line.

--Randall

On 8 Oct 2021, at 13:44, Dan Banks wrote:

> Inline as well.
>
>> -----Original Message-----
>> From: Randall Gellens <rg+ietf@randy.pensive.org>
>> Sent: Wednesday, October 6, 2021 1:38 PM
>> To: Dan Banks <dbanks@ddti.net>
>> Cc: ECRIT <ecrit@ietf.org>
>> 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.

[rg] Yes, you're correct, my apologies.

[rg] Possibly, it might be helpful to add a sentence to the definitions 
of "Complete Location" and "Similar Location" along the lines of 
"Complete Location may be returned when the input location is valid but 
incomplete" and likewise "Similar Location may be returned when the 
input location is invalid", to be more clear.


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

[rg] Presumably, no new geodetic location profile will be defined that 
includes instructions for use with this extension, for this reason.  
There might, in theory, be a new civic profile that isn't derived from 
the basic one.


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

[rg] I'm trying to make it clear that it's the location in this 
<findService> request that's being referenced.  Perhaps it's esoteric 
and not worth the bother.  What about "The other use case for this 
extension is when the <findService> request contains 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?
>
> [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.

[rg] Makes sense.  I was trying to avoid the fuzzy wording of the phrase 
"can be extended" and also use "intended" rather than "desired".  
Perhaps "this extension allows the server to include in the 
<locationValidation> element 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".
>>
>
> [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 <ecrit-bounces@ietf.org> On Behalf Of Randall Gellens
>>>> Sent: Wednesday, September 29, 2021 3:52 PM
>>>> To: ECRIT <ecrit@ietf.org>
>>>> 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
>>>> Ecrit@ietf.org
>>>>
>> 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