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

From: "Caron, Guy" <[email-masked]>
Date: Tue, 5 Oct 2021 20:44:01 +0000

I've reviewed -11 and only have editorial changes to propose. Embedded in track-change in the MSWord version attached. I did not recheck the XML schema.

Other than that, I'm fine with advancing this document.

Thanks,

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Randall Gellens
Envoyé : 29 septembre 2021 15:52
À : ECRIT <[email-masked]>
Objet : [EXT][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
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Dan Banks <[email-masked]>
Date: Tue, 5 Oct 2021 21:30:58 +0000

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 <[email-masked]> On Behalf Of Randall Gellens
> Sent: Wednesday, September 29, 2021 3:52 PM
> To: ECRIT <[email-masked]>
> 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
> 
> 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

---

From: "Randall Gellens" <[email-masked]>
Date: Wed, 06 Oct 2021 07:43:03 -0700

I have comments on a few of Guy's proposed edits; the ones not mentioned 
below I have no opinion on.

(1) Regarding Guy's proposal to delete geodetic location from the 
definition of "Location" as well as the definition of "Geodetic 
Location," I think it would be more confusing to do that.  Note that the 
definition of "Geodetic Location" says "Note: geodetic location  is 
defined here for context, but is not used elsewhere within this 
document."  We could add additional clarifying text if anyone feels it's 
needed, e.g., adding to the "Location" definition text such as "However, 
geodetic location is out of scope of this document."

(2) Regarding Guy's proposed insertion of "proffered" into the 
definition of "Similar Location," I suggest instead adding "queried" as 
I think it's more clear (especially for some English speakers).

(3) In Section 3, in the paragraph starting "In a LoST 
<findServiceResponse>", Guy suggests adding "the" in front of "<HNO>, 
<RD>, <STS>, <POD>, <A3> and <A1> Civic Address Elements".  I disagree; 
the sentence reads better without it.

(4) Also in Section 3, in the paragraph starting "The information 
provided in the request may be enough", Guy suggests changing "alert the 
user to" to "alert the user of".  I disagree, "to" reads better.

(5) Section 4, second paragraph, Guy suggests changing "cannot assume 
that any of them are the correct location" to "cannot assume that any of 
them is the correct location".  I suggest either retaining "are"
or changing to "is" and also adding "one" in front of "any": "cannot 
assume that any one of them is the correct location."

--Randall

On 5 Oct 2021, at 13:44, Caron, Guy wrote:

> I've reviewed -11 and only have editorial changes to propose. Embedded 
> in track-change in the MSWord version attached. I did not recheck the 
> XML schema.
>
> This starts WGLC for draft-ietf-ecrit-similar-location-11, a LoST 
> extension to return complete or similar location info.
>
> External Email: Please use caution when opening links and attachments 
> / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: "Randall Gellens" <[email-masked]>
Date: Wed, 06 Oct 2021 10:37:44 -0700

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

[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.
>
>    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
>    either in the Basic Civic profile defined in [RFC5222]

>    or in another profile

[RG] Or, using the same language as above:

[RG] or in another profile whose definition provides instructions
concerning its use with this extension.

>    To query the LoST server.

[RG] Perhaps:

[RG] The other use case for this extension is when the queried location 
is an Invalid Location.

>    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

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

> 'validateLocaton' = true.

[RG] I'd suggest changing "having" to "with" and changing "=" to "set 
to".

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

---

From: "Caron, Guy" <[email-masked]>
Date: Fri, 8 Oct 2021 12:57:59 +0000

Inline.

I will point out that all my proposed editorial changes are just that, editorial and are not meant to be blocking WGLC progress.

I leave it to the authors to accept or reject any and all of those suggested changes.

Guy

-----Message d'origine-----
De : Randall Gellens <[email-masked]>
Envoyé : 6 octobre 2021 10:43
À : Caron, Guy <[email-masked]>
Cc : ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct 13

I have comments on a few of Guy's proposed edits; the ones not mentioned below I have no opinion on.

(1) Regarding Guy's proposal to delete geodetic location from the definition of "Location" as well as the definition of "Geodetic Location," I think it would be more confusing to do that.  Note that the definition of "Geodetic Location" says "Note: geodetic location  is defined here for context, but is not used elsewhere within this document."  We could add additional clarifying text if anyone feels it's needed, e.g., adding to the "Location" definition text such as "However, geodetic location is out of scope of this document."

[GC] I suggest - Location: In the context of this document, the term Location is restricted to a civic location.

And get rid of the Geodetic Location definition.

(2) Regarding Guy's proposed insertion of "proffered" into the definition of "Similar Location," I suggest instead adding "queried" as I think it's more clear (especially for some English speakers).

[GC] Languages are not 100% codified, which lives room for preferences and style. I don’t think “queried” is more clear than “proffered”. I would argue that “queried” is less accurate in the sense that the findService Request is not querying something, it is offering/presenting/requesting a location to be processed for validation. I recognize that “query”/”queried” are used in the document, along with “provided” and “input”, and “proffered” would be a new word. Despite the fact that I think “proffered” is appropriate, I will not die on that hill.

I do take exception to the commentary in parenthesis though, which I find on the tangent of being offensive and discriminatory. I’m not sure if these comments were submitted as an individual or as an IETF WG Chairperson but think about the message this is sending to this community or international participants: If you mother tongue is not English, you do not have the moral authority to suggest editorial changes.

(3) In Section 3, in the paragraph starting "In a LoST <findServiceResponse>", Guy suggests adding "the" in front of "<HNO>, <RD>, <STS>, <POD>, <A3> and <A1> Civic Address Elements".  I disagree; the sentence reads better without it.

[GC] Matter of style. I don’t care.

(4) Also in Section 3, in the paragraph starting "The information provided in the request may be enough", Guy suggests changing "alert the user to" to "alert the user of".  I disagree, "to" reads better.

[GC] “Alert to” calls for an immediate action while “alert of” is more passive and is meant to raise awareness. I took the latter to be appropriate in the context but I’m fine either way.

(5) Section 4, second paragraph, Guy suggests changing "cannot assume that any of them are the correct location" to "cannot assume that any of them is the correct location".  I suggest either retaining "are"

or changing to "is" and also adding "one" in front of "any": "cannot assume that any one of them is the correct location."

[GC] I’m fine with this suggestion.

--Randall

> De : Ecrit <[email-masked]<mailto:[email-masked]>> De la part de Randall Gellens

> Envoyé : 29 septembre 2021 15:52 À : ECRIT <[email-masked]<mailto:[email-masked]>> Objet :

> [EXT][Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct

> 13

> [email-masked]<mailto:[email-masked]>

> ----------------------------------------------------------------------

> -------- External Email: Please use caution when opening links and

> attachments / Courriel externe: Soyez prudent avec les liens et

> documents joints

---

From: "Randall Gellens" <[email-masked]>
Date: Fri, 08 Oct 2021 07:59:13 -0700

Please see inline.

--Randall

On 8 Oct 2021, at 5:57, Caron, Guy wrote:

> Inline.
>
>
>
> I will point out that all my proposed editorial changes are just that, 
> editorial and are not meant to be blocking WGLC progress.
>
>
>
> Location," I think it would be more confusing to do that.  Note that 
> the definition of "Geodetic Location" says "Note: geodetic location  
> is defined here for context, but is not used elsewhere within this 
> document."  We could add additional clarifying text if anyone feels 
> it's needed, e.g., adding to the "Location" definition text such as 
> "However, geodetic location is out of scope of this document."
>
> [GC] I suggest - Location: In the context of this document, the term 
> Location is restricted to a civic location.
>
>
>

[rg] I believe it is helpful for clarification to retain the definition 
of geodetic.  For the clarifying text that explains that geodetic isn't 
used in the document, I think "out of scope" or "not discussed" or "not 
used" is more clear than "restricted".

> definition of "Similar Location," I suggest instead adding "queried" 
> as I think it's more clear (especially for some English speakers).
>
> [GC] Languages are not 100% codified, which lives room for preferences 
> and style. I don’t think “queried” is more clear than 
> “proffered”. I would argue that “queried” is less accurate in 
> the sense that the findService Request is not querying something, it 
> is offering/presenting/requesting a location to be processed for 
> validation.

[rg] Validation is only done as part of a findService request, which is 
a query.  Hence, it is most clear to describe it as a "queried" 
location.  If you don't like "queried", then "sent in a <findService> 
request" is the most direct and clear language.

> I recognize that “query”/”queried” are used in the document, 
> along with “provided” and “input”, and “proffered” would 
> be a new word. Despite the fact that I think “proffered” is 
> appropriate, I will not die on that hill.
>
>
>
> I do take exception to the commentary in parenthesis though, which I 
> find on the tangent of being offensive and discriminatory. I’m not 
> sure if these comments were submitted as an individual or as an IETF 
> WG Chairperson but think about the message this is sending to this 
> community or international participants: If you mother tongue is not 
> English, you do not have the moral authority to suggest editorial 
> changes.

[rg] Thanks for letting me know you found my comment offensive, Guy.  
That was not my intent and I hadn't realized it could be seen as 
offensive. I'm sorry.  I was not suggesting that anyone lacked moral 
authority for editorial suggestions; to the contrary, editorial comments 
can be especially valuable from those for whom their first language is 
not English as spoken in North America (especially the northeastern U.S. 
and much of Canada).  The point I was trying to make is that using words 
that are less common can make comprehension more difficult for some 
English speakers, including some for whom it is not their first language 
as well as some whose native form is different.  In conversations with 
IETF participants over many years, I've learned that words and phrases 
that may seem artful from the perspective of a native speaker of English 
in the U.S. can be difficult for others to follow.  I try to use more 
common words and more direct language in Internet Drafts, as they have a 
worldwide audience.

> <RD>, <STS>, <POD>, <A3> and <A1> Civic Address Elements".  I 
> disagree; the sentence reads better without it.
>
> provided in the request may be enough", Guy suggests changing "alert 
> the user to" to "alert the user of".  I disagree, "to" reads better.
>
> [GC] “Alert to” calls for an immediate action while “alert of” 
> is more passive and is meant to raise awareness. I took the latter to 
> be appropriate in the context but I’m fine either way.
>
>
>
> that any of them are the correct location" to "cannot assume that any 
> of them is the correct location".  I suggest either retaining "are"
>
>> Envoyé : 29 septembre 2021 15:52 À : ECRIT 
>> <[email-masked]<mailto:[email-masked]>> Objet :
>

---

From: Dan Banks <[email-masked]>
Date: Fri, 8 Oct 2021 20:44:17 +0000

Inline as well.

> From: Randall Gellens <[email-masked]>
> Sent: Wednesday, October 6, 2021 1:38 PM
> To: Dan Banks <[email-masked]>
> Cc: ECRIT <[email-masked]>
> Subject: Re: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct
> 13
> 
> Please see inline.
> 
> 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.

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

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

> your other suggested edit?

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

> <findServiceResponse> one or more locations that might be the intended

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

[DB] That's fine with me.

> >> Please send both comments and messages that you support
> advancement
> >> of

---

From: "Randall Gellens" <[email-masked]>
Date: Fri, 08 Oct 2021 16:47:08 -0700

Also in line.

--Randall

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

>>>       the <civicAddress> type defined in [RFC5139], including 
>>> elements
>>> used
>>>       this document, we use the term Invalid Location only to refer 
>>> to
>>> a
>>>       one or more Civic Address Elements in the <invalid> list.  
>>> Note
>>> that
>>>       LoST server may return a <notFound> or <locationInvalid> 
>>> error.
>>> In
>> potentially
> [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.

>>>    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
>>>    Location Information using a location profile that differs from 
>>> the
>>> profile
>>>    include Returned Location Information using a location profile 
>>> that
>>> was
> [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.
>
>
>>>    The other use case for this extension is when Invalid Location 
>>> has
>>> been used
> [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.
>
>>
>>

---

From: "Randall Gellens" <[email-masked]>
Date: Fri, 08 Oct 2021 17:07:22 -0700

My apologies, I sent the prior message prematurely.

Also in line.

--Randall

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

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

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

---

From: Roger Marshall <[email-masked]>
Date: Wed, 13 Oct 2021 23:19:17 +0000

I support the advancement of this draft.

-roger marshall.

-----Original Message-----
From: Ecrit <[email-masked]> On Behalf Of Randall Gellens
Sent: Wednesday, September 29, 2021 12:52 PM
To: ECRIT <[email-masked]>
Subject: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct 13

WARNING: External Email: Exercise Caution

Thank you,

--Randall

_______________________________________________
Ecrit mailing list
[email-masked]
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecrit&amp;data=04%7C01%7Croger.marshall%40comtechtel.com%7Cee07597698b543bfdf2108d983829078%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637685419842974972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=m7fDshyDx%2FrHYyWsRj0v0ysMGHNlZVNf7ngegaO3x%2Bw%3D&amp;reserved=0
NOTICE TO RECIPIENT: This email, including attachments, may contain information which is confidential, proprietary, attorney-client privileged and / or controlled under U.S. export laws and regulations and may be restricted from disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agreement between the parties unless expressly stated herein and provided by an authorized representative of Comtech Telecommunications Corp. or its subsidiaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify us immediately by return email and permanently delete all copies of the original email and any attached documentation from any computer or other media.

---

From: Jeff Martin <[email-masked]>
Date: Thu, 14 Oct 2021 00:10:12 +0000

I support advancement of the latest draft.

/Jeff/

-----Original Message-----
From: Roger Marshall <[email-masked]>
Sent: Wednesday, October 13, 2021 5:19 PM
To: Randall Gellens <[email-masked]>; ECRIT <[email-masked]>
Cc: Jeff Martin <[email-masked]>
Subject: RE: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct 13

-roger marshall.

-----Original Message-----
From: Ecrit <[email-masked]> On Behalf Of Randall Gellens
Sent: Wednesday, September 29, 2021 12:52 PM
To: ECRIT <[email-masked]>
Subject: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct 13

Thank you,

--Randall