Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-12.txt

From: [email-masked]
Date: Mon, 11 Oct 2021 16:29:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies WG of the IETF.

        Title           : A LoST extension to return complete and similar location info
        Authors         : Brian Rosen
                          Roger Marshall
                          Jeff Martin
	Filename        : draft-ietf-ecrit-similar-location-12.txt
	Pages           : 17
	Date            : 2021-10-11

Abstract:
   This document introduces a new way to provide returned location
   information in LoST responses that is either of a completed or
   similar form to the original input civic location, based on whether
   valid or invalid civic address elements are returned within the
   <findServiceResponse> message.  This document defines a new extension
   to the <findServiceResponse> message within the LoST protocol
   [RFC5222] that enables the LoST protocol to return in a response a
   completed civic address element set for a valid location response,
   and one or more suggested sets of similar location information for an
   invalid location.  These two types of civic addresses are referred to
   as either "complete location" or "similar location", and are included
   as a compilation of CAtype xml elements within the existing LoST
   <findServiceResponse> message structure.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-similar-location-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-12

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dwight Purtle <[email-masked]>
Date: Mon, 11 Oct 2021 20:20:39 -0500

The minor edits I requested have been made in this version.  I'm good with
proceeding to approval.

Dwight Purtle

On Mon, Oct 11, 2021 at 6:30 PM <[email-masked]> wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Dan Banks <[email-masked]>
Date: Tue, 12 Oct 2021 16:21:29 +0000

I am satisfied with the changes made in this version.  There are a handful of new editorial issues:

Invalid Location and Valid Location definitions have a difference in wording that I think is unintentional:
Invalid Location:  A Civic Location that, when included
versus
Valid Location:  A Civic Location, when included
I prefer the inclusion of 'that'.
Both of these definitions are also missing a period at the end.

In section 3,
there is no such thing as "15th Ave North
should be
there is no such thing as "15th Avenue North"
(expand Ave and add missing double quote)

In the first paragraph of section 4, there appears to be an escaping issue:
<civicAddressgt;

I still believe the document could be improved with a bit of reorganization of sections 3 and 4, but I support advancing the document without additional changes if that is the consensus.

Dan Banks

> -----Original Message-----
> From: Ecrit <[email-masked]> On Behalf Of [email-masked]
> Sent: Monday, October 11, 2021 7:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-12.txt
> 
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-ecrit-similar-
> location%2F&amp;data=04%7C01%7Cdbanks%40ddti.net%7C2677c3624c9b43
> ef4bf408d98d0f141a%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C6
> 37695918186302761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=
> P3BH1wZSXLDkc8UrC7mVYLaNlTMWLj63lN4M9sivfa0%3D&amp;reserved=0
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ecrit-similar-location-
> 12&amp;data=04%7C01%7Cdbanks%40ddti.net%7C2677c3624c9b43ef4bf408
> d98d0f141a%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C637695918
> 186302761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mPns%2
> BzOYeJw5Wv6ZksmQKvkQVy%2BooWwkpOX0jJOK9Rw%3D&amp;reserved=
> 0
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ecrit-similar-location-
> 12&amp;data=04%7C01%7Cdbanks%40ddti.net%7C2677c3624c9b43ef4bf408
> d98d0f141a%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C637695918
> 186302761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BQ1%2F
> b3vGjlo4Oh80lx6xiKegu1FpzlWjsTb%2BCydveVI%3D&amp;reserved=0
> 
> 
> https://nam12.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf
> .org%2Finternet-
> drafts%2F&amp;data=04%7C01%7Cdbanks%40ddti.net%7C2677c3624c9b43e
> f4bf408d98d0f141a%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C63
> 7695918186302761%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=
> 20pHDNNfNOyd1JvEeCtlhJz%2FT6VJzj3wN%2FKSSD8G63k%3D&amp;reserve
> d=0
> 
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Fmailman%2Flistinfo%2Fecrit&amp;data=04%7C01%7Cdbanks%
> 40ddti.net%7C2677c3624c9b43ef4bf408d98d0f141a%7C4c0f48ba5f2944b1b29
> c1aff8251101b%7C0%7C0%7C637695918186312756%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=fyo4rmGKcNdQUGrlrcucZBRYR8JBmvaQKB99
> XOeE7jI%3D&amp;reserved=0

---

From: "Michael Smith" <[email-masked]>
Date: Tue, 12 Oct 2021 16:52:12 -0400

I thought the use of "Ave" was the reason there was no such thing as "15th
Ave North". Did I miss the point of the example?

I would prefer that the examples follow the convention of separating the
street address from the city with a comma, like "6000 15th Avenue North,
Seattle, WA". It doesn't affect implementation of course, but "6000 15th
Avenue, North Seattle, WA " is different from "6000 15th Avenue North,
Seattle, WA". It's a very small nit, and up to the editor as far as I'm
concerned. 

I also noticed the "gt;" issue but didn't see any others when I searched for
it.

I support advancing the document. It seems pretty clear to me.

Michael Smith
Chief Technologist, Equature/DSS Corp.
Ph: 606.877.2788 | Mobile: 606.231.0243

-----Original Message-----
From: Ecrit <[email-masked]> On Behalf Of Dan Banks
Sent: Tuesday, October 12, 2021 12:21 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-12.txt

I am satisfied with the changes made in this version.  There are a handful
of new editorial issues:

Invalid Location and Valid Location definitions have a difference in wording
that I think is unintentional:
Invalid Location:  A Civic Location that, when included versus Valid
Location:  A Civic Location, when included I prefer the inclusion of 'that'.
Both of these definitions are also missing a period at the end.

In section 3,
there is no such thing as "15th Ave North should be there is no such thing
as "15th Avenue North"
(expand Ave and add missing double quote)

I still believe the document could be improved with a bit of reorganization
of sections 3 and 4, but I support advancing the document without additional
changes if that is the consensus.

Dan Banks

---

From: Roger Marshall <[email-masked]>
Date: Tue, 12 Oct 2021 20:56:41 +0000

Yes, Michael is correct.  In this case, the intent of including "Ave" in the example was to point out that there would NOT be a match when compared to what was inside the database, namely, "Avenue".

-roger.

-----Original Message-----
From: Ecrit <[email-masked]> On Behalf Of Michael Smith
Sent: Tuesday, October 12, 2021 1:52 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-12.txt

WARNING: External Email: Exercise Caution

I thought the use of "Ave" was the reason there was no such thing as "15th Ave North". Did I miss the point of the example?

I would prefer that the examples follow the convention of separating the street address from the city with a comma, like "6000 15th Avenue North, Seattle, WA". It doesn't affect implementation of course, but "6000 15th Avenue, North Seattle, WA " is different from "6000 15th Avenue North, Seattle, WA". It's a very small nit, and up to the editor as far as I'm concerned.

I also noticed the "gt;" issue but didn't see any others when I searched for it.

Michael Smith

-----Original Message-----
From: Ecrit <[email-masked]> On Behalf Of Dan Banks
Sent: Tuesday, October 12, 2021 12:21 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-12.txt

In section 3,
there is no such thing as "15th Ave North should be there is no such thing as "15th Avenue North"
(expand Ave and add missing double quote)

Dan Banks

> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnam1
> 2.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdata
> &amp;data=04%7C01%7Croger.marshall%40comtechtel.com%7C294c1dfd65634249
> 948208d98dc23305%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C63769668
> 7503445942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=zUNYk8yhYRr1Step%2Bda
> D42rID%2FnLEbELOu5Lvx0bHoQ%3D&amp;reserved=0
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnam1
> 2.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdata
> &amp;data=04%7C01%7Croger.marshall%40comtechtel.com%7C294c1dfd65634249
> 948208d98dc23305%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C63769668
> 7503445942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=zUNYk8yhYRr1Step%2Bda
> D42rID%2FnLEbELOu5Lvx0bHoQ%3D&amp;reserved=0
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnam1
> 2.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww&a
> mp;data=04%7C01%7Croger.marshall%40comtechtel.com%7C294c1dfd6563424994
> 8208d98dc23305%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C6376966875
> 03445942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=tEjpTJ46VxC2ik2t%2Bxhe%
> 2F1AaqYlp%2F3%2Btfy0qmIAOMn4%3D&amp;reserved=0
> https://gcc02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ie
> %2F&amp;data=04%7C01%7Croger.marshall%40comtechtel.com%7C294c1dfd65634
> 249948208d98dc23305%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C63769
> 6687503445942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LWJ%2BBX%2FVZICAEb
> 0%2FlQpY1WI%2BZhvgv4NQbZhJJkmCfus%3D&amp;reserved=0
> tf
> .org%2Finternet-
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnam1
> 2.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww&a
> mp;data=04%7C01%7Croger.marshall%40comtechtel.com%7C294c1dfd6563424994
> 8208d98dc23305%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C6376966875
> 03445942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=tEjpTJ46VxC2ik2t%2Bxhe%
> 2F1AaqYlp%2F3%2Btfy0qmIAOMn4%3D&amp;reserved=0

_______________________________________________
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%7C294c1dfd65634249948208d98dc23305%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637696687503445942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=P0KaOWeuxe2M4m2m4gS4qdkj7KXqkyjGtsfE1poVlw4%3D&amp;reserved=0

_______________________________________________
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%7C294c1dfd65634249948208d98dc23305%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637696687503445942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=P0KaOWeuxe2M4m2m4gS4qdkj7KXqkyjGtsfE1poVlw4%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: Dan Banks <[email-masked]>
Date: Tue, 12 Oct 2021 21:22:07 +0000

We changed the input and the similar addresses in this example to all have Avenue spelled out, and focused on the 'North' being the problem.  Leaving 'Ave' abbreviated would also be a perfectly reasonable example for an invalid location, but I do not believe that was the intent with this example.

The 'Ave' that I am pointing out is in the discussion and does not match the given input address, which I believe was an oversight during the last edit.

Dan

> From: Ecrit <[email-masked]> On Behalf Of Roger Marshall
> Sent: Tuesday, October 12, 2021 4:57 PM
> To: Michael Smith <[email-masked]>; [email-masked]
> Yes, Michael is correct.  In this case, the intent of including "Ave" in the
> example was to point out that there would NOT be a match when compared
> to what was inside the database, namely, "Avenue".
> 
> -roger.
> 
> I still believe the document could be improved with a bit of reorganization of
> sections 3 and 4, but I support advancing the document without additional
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc0
> >
> 2.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fn
> am1
> >
> &amp;data=04%7C01%7Cdbanks%40ddti.net%7C920e7e0062ad4cbfc3aa08d9
> 8dc2d4
> >
> 77%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C1%7C63769669020573536
> 1%7CU
> >
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1ha
> >
> WwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=PHPHapI8hVqzMmKwVn9FZI4z
> %2FPCnH4y%2
> > BN8A%2BGMZRoLM%3D&amp;reserved=0
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc0
> >
> 2.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fn
> am1
> >
> &amp;data=04%7C01%7Cdbanks%40ddti.net%7C920e7e0062ad4cbfc3aa08d9
> 8dc2d4
> >
> 77%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C1%7C63769669020574535
> 7%7CU
> >
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1ha
> >
> WwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BDEOmnmenOvzXr7%2FeK0
> NJ%2FXXkHu0W
> > U2wNZXn6VIFC%2Bg%3D&amp;reserved=0
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc0
> >
> 2.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fn
> am1
> >
> &amp;data=04%7C01%7Cdbanks%40ddti.net%7C920e7e0062ad4cbfc3aa08d9
> 8dc2d4
> >
> 77%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C1%7C63769669020574535
> 7%7CU
> >
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1ha
> >
> WwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BDEOmnmenOvzXr7%2FeK0
> NJ%2FXXkHu0W
> > U2wNZXn6VIFC%2Bg%3D&amp;reserved=0
> >
> https://nam12.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ie
> >
> %2F&amp;data=04%7C01%7Cdbanks%40ddti.net%7C920e7e0062ad4cbfc3aa
> 08d98dc
> >
> 2d477%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C1%7C63769669020574
> 5357%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BtofUCrOiI0nsH8yoJU4pmPv
> HNKvXWRi
> > 8%2BiMWHP4XSs%3D&amp;reserved=0
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc0
> >
> 2.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fn
> am1
> >
> &amp;data=04%7C01%7Cdbanks%40ddti.net%7C920e7e0062ad4cbfc3aa08d9
> 8dc2d4
> >
> 77%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C1%7C63769669020574535
> 7%7CU
> >
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1ha
> >
> WwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BDEOmnmenOvzXr7%2FeK0
> NJ%2FXXkHu0W
> > U2wNZXn6VIFC%2Bg%3D&amp;reserved=0
> >
> 40ddti.net%7C920e7e0062ad4cbfc3aa08d98dc2d477%7C4c0f48ba5f2944b1b2
> 9c1aff8251101b%7C0%7C1%7C637696690205745357%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000&amp;sdata=vE5%2FxIWenE%2BCzUPCqRWc0qnWldjccB
> nQcJBfIQr9FXU%3D&amp;reserved=0
> 
> 40ddti.net%7C920e7e0062ad4cbfc3aa08d98dc2d477%7C4c0f48ba5f2944b1b2
> 9c1aff8251101b%7C0%7C1%7C637696690205745357%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000&amp;sdata=vE5%2FxIWenE%2BCzUPCqRWc0qnWldjccB
> nQcJBfIQr9FXU%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.
> 
> 40ddti.net%7C920e7e0062ad4cbfc3aa08d98dc2d477%7C4c0f48ba5f2944b1b2
> 9c1aff8251101b%7C0%7C1%7C637696690205745357%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000&amp;sdata=vE5%2FxIWenE%2BCzUPCqRWc0qnWldjccB
> nQcJBfIQr9FXU%3D&amp;reserved=0

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 26 Oct 2021 13:58:04 -0700

I apologize for the delay.  I've finished a thorough read-through of the 
latest draft and have the following change notes:

(1) In the definition of 'Invalid Location', the fourth line starts with 
"that It is".  The word "it" should not be capitalized.

(2) Section 3, first paragraph, consider changing "As of this document" 
to "As of this document's publication".

(3) Same paragraph, consider changing "describes the returned location 
extension primarily in terms of how it is used with the" to "describes 
the extension using the".

(4) Section 3, third paragraph starting "In a LoST findServiceResponse", 
I suggest enclosing "findServiceResponse" in angle brackets.

(5) Same paragraph, I think it would be more clear to change "a 
<locationValidation>" to "the <locationValidation>" because otherwise it 
sounds like an additional <locationValidation> might be included.

(6) Same paragraph, I find the text describing the example confusing.  
Maybe I'm misreading it, but it seems to starts out describing an 
example where <POD> is needed, but then it says that other entities 
might want <A2> and <PC>.  If I'm reading it correctly, it seems to be 
describing two examples, one where the address is only borderline valid 
but still sufficient to be uniquely identified, and another where an 
address is more clearly valid but missing two elements that should be 
there for completeness.  I suggest breaking this into two examples and 
also rewording the material as follows:

Change:

    As an
    example, the query might contain <HNO> (house number), <RD> (road
    name) <A3> (city), <A1> (state/province) and a few more CAtype
    elements, but might not contain <POD> (Post-Directional) or <PC>
    (Postal Code) CAtype elements.  In this example, there is no street
    with just the streetname, all streets have a post-directional.  The
    civic location in the request might contain <HNO>, <RD>, <STS>, <A3>
    and <A1> Civic Address Elements that are sufficient enough for the
    LoST server to uniquely locate the address specified in the request
    and thus be considered Valid, meaning there was only one street with
    the house street name and house number in the city that it could be.
    Yet, other entities involved in a subsequent emergency call might
    find it helpful to have additional Civic Address Elements such as
    <A2> (county) and <PC> (Postal Code) included as part of a complete
    civic location.

To:

    As an example, a query contains <HNO> (house number), <RD> (road
   name) <A3> (city), <A1> (state/province) but not <POD>
   (Post-Directional).  In this example, there is no street with just
   the street name, all streets have a post-directional.  However, the
   LoST server is able to uniquely locate the intended address and
   thus consider the queried location Valid, as there is only one
   street with the street name and house number in the city
   that it could be.  As the queried location is missing the
   post-directional element, a more strict entity might consider it
   Invalid (e.g., during a subsequent query) or worse, the lack of
   a Post-Directional element might cause confusion and delay
   an emergency response.  The server can use this extension to
   supply the missing post-directional element <POD> in a
   <completeLocation> element within the <locationValidation>
   element.

    In another example, the civic location in a request might lack
    <A2> (county) and <PC> (Postal Code) Civic Address Elements.  In
    this example, too, the LoST server is able uniquely locate the
    intended address and consider the location <Valid>, but other
    entities involved in a subsequent emergency call might find it
    helpful to have the additional Civic Address Elements.  The LoST
    server can use this extension to supply the missing <A2> and <PC>
    Civic Address Elements.

(7) Section 3, fifth paragraph, there is an example addresses shown in 
colloquial form (not in Civic Address elements).  I suggest adding a 
comma before the city.

Change:

    Input address: 6000 15th Avenue Seattle, WA US	
  		
    Complete Location: 6000 15th Avenue Northwest Seattle, WA 98105 US

To:

   Input address: 6000 15th Avenue, Seattle, WA US

   Complete Location: 6000 15th Avenue Northwest, Seattle, WA 98105 US

(8) In Section 3, eight paragraph, second line, starting with "request 
contains Invalid Location", should this be "an Invalid Location"?

(9) Following paragraph, third line, I suggest changing "was sufficient" 
to "is sufficient".

(10) Following line, I suggest changing "In that case" to "in this case" 
and change "would be listed" to "is listed".

(11) Same text, should "just as in the above example" be changed to 
"just as in the above example the missing <A3> element is included in a 
<completeLocation> element"?

(12) Following paragraph, consider rewording the run-on sentence that 
starts the paragraph.

Change:

    As another example of the use of <similarLocation>, consider the
    results based on a similar data set as used above, where the <HNO>,
    <RD>, <STS>, <A1>, and <A3> Civic Address Elements are not 
sufficient
    to locate a unique address, which leads to an invalid location 
result
    because the LoST server contains additional civic address elements
    which would have resulted in a uniquely identifiable location if
    these additional elements had been included in the location sent in
    the query.

To:

    As another example of the use of <similarLocation>, consider the
    results based on a similar data set as used above, but where the
    <HNO>, <RD>, <STS>, <A1>, and <A3> Civic Address Elements are not
    sufficient to locate a unique address, resulting an invalid
    location response.  Because the LoST server contains additional
    civic address elements which, had they been included in the
    query,  would have resulted in a uniquely identifiable location,
    the server can include one or more <similarLocation> elements
    containing the supplied Civic Address Elements plus the omitted
    ones.

(13) Same paragraph, near the end, I suggest deleting "message" from 
"the <findServiceResponse> message".

(14) Following paragraph, I suggest enclosing "findService" in angle 
brackets in "findService request:".

(15) In the following paragraph (the 13th, I think) I suggest adding a 
comma after the street Post-Directional in the colloquial form example 
addresses.

Change:

   Input address: 6000 15th Avenue North Seattle, WA US

To:

   Input address: 6000 15th Avenue North, Seattle, WA US

(15) Same section, 15th and 16th paragraphs, I suggest adding a comma 
after the street Post-Directional in the colloquial form example 
addresses (as above).

Change:

    Similar address #1: 6000 15th Avenue Northwest Seattle, WA 98107 US

    Similar address #2: 6000 15th Avenue Northeast Seattle, WA 98105 US

To:

    Similar address #1: 6000 15th Avenue Northwest, Seattle, WA 98107 US

    Similar address #2: 6000 15th Avenue Northeast, Seattle, WA 98105 US

(16) In the first paragraph of Section 4, there's a typo where 
"<civicAddressgt;" appears (an improperly opened entity name).  This is 
corrected in the suggested replacement text of item (17).

(17) In Section 4, the text states that <completeLocation> and 
<similarLocation> elements "contain location information in the same 
profile of the location used to answer the query."  Isn't 'profile' an 
attribute of both elements, and shouldn't the text say that the 
'profile' attribute must be set to the same value as the profile of the 
queried location, or, to be more similar to how RFC 5222 treats 
<serviceBoundary>, if one or more <completeLocation> or 
<similarLocation> elements are included in the response, at least one 
must be use the same profile as the request (which would allow a server 
to include, e.g., two <completeLocation> elements, one in the profile of 
the request and one in a different profile (if/when additional civic 
profiles are defined)?

Change:

    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 derived from the Basic Civic profile whose definition
    provides instructions concerning its use with this extension.  When
    used with the Basic Civic profile, these elements contain a
    <civicAddressgt; element as defined in [RFC5139].

To either:

    The <completeLocation> and <similarLocation> elements are of type
    "locationInformation" as defined by the LoST schema in [RFC5222].
    These elements MAY contain location information either in the
    Basic Civic profile defined in RFC5222 or in another profile
    derived from the Basic Civic profile whose definition provides
    instructions concerning its use with this extension, but this
    MUST be the same profile as the location in the query.  When used
    with the Basic Civic profile, these elements contain a
    <civicAddress> element as defined in [RFC5139].

Or:

    The <completeLocation> and <similarLocation> elements are of type
    "locationInformation" as defined by the LoST schema in [RFC5222].
    These elements MAY contain location information either in the
    Basic Civic profile defined in [RFC5222] or in another profile
    derived from the Basic Civic profile whose definition provides
    instructions concerning its use with this extension.  A response
    MAY include more than one <completeLocation> or <similarLocation>
    elements containing the same address expressed using different
    profiles, but at least one MUST use the same profile as the
    request.  When used with the Basic Civic profile, these elements
    contain a <civicAddress> element as defined in [RFC5139].

(18) If we go with the second option of (17), to explicitly allow 
multiple <similarLocation> or <completeLocation> elements that express 
the same location in different profiles, for clarity we should change 
the second paragraph of Section 4:

Change:

    more than one <similarLocation> element

To:

    more than one <similarLocation> element expressing different 
locations

(19) If we go with the second option of (17), to explicitly allow 
multiple <similarLocation> or <completeLocation> elements that express 
the same location in different profiles, for clarity we should change 
the third paragraph of Section 4:

Change:

    MAY include a <completeLocation>
    element

To:

    MAY include a <completeLocation> element (or multiple elements
    containing the same location using different profiles)

(20) In the last paragraph of Section 4, I suggest rewording the text to 
avoid any confusion over possible future profiles (since the document 
says earlier that profiles other than 'civic' in RFC 5222 may be defined 
that specify how they are used with this extension).

Change:

    in a profile derived from the 'civic' profile

To:

    in a profile other than the 'civic' profile

(21) I suggest changing the name of Section 5.1 for clarity, either keep 
"response" and change "for" to "in", or delete "response":

Change:

    Complete Location returned for Valid Location response

To either:

    Complete Location returned in Valid Location response

Or:

    Complete Location returned for Valid Location

(Personally, I think the latter reads slightly better.)

(22) In the first paragraph of Section 5.1, I suggest rewording for 
easier reading:

Change:

    Based on the example input request above, Returned Location
    Information is provided in a <findServiceResponse> message since the
    original input address is considered valid but is missing some
    additional data that the LoST server has.

To:

    This example is based on the example request above; the LoST
    server considered the location in the query to be valid but
    missing some Civic Address elements, so in the Returned Location
    Information in the <findServiceResponse>, the server includes a
    <completeLocation> element supplying the omitted Civic Address
    elements <A2>, <PC>, and <PCN>.

(23) (21) I suggest changing the name of Section 5.2 for clarity, as 
with 5.1, by either keeping "response" and changing "for" to "in", or 
deleting "response":

Change:

    Similar Location returned for Invalid Location response

To either:

    Similar Location returned in Invalid Location response

Or:

    Similar Location returned for Invalid Location

(Personally, I think the latter reads slightly better.)

(24) In the first paragraph of Section 5.2, I suggest slight rewording:

Change:

    two returned Similar Locations in a

to:

    two Similar Locations returned in a

--Randall

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 26 Oct 2021 14:58:41 -0700

I support spelling out "Avenue" in the text.

--Randall

On 12 Oct 2021, at 14:22, Dan Banks wrote:

> We changed the input and the similar addresses in this example to all 
> have Avenue spelled out, and focused on the 'North' being the problem. 
>  Leaving 'Ave' abbreviated would also be a perfectly reasonable 
> example for an invalid location, but I do not believe that was the 
> intent with this example.
>
> The 'Ave' that I am pointing out is in the discussion and does not 
> match the given input address, which I believe was an oversight during 
> the last edit.
>
> Dan
>
>> I am satisfied with the changes made in this version.  There are a 
>> handful of
>> new editorial issues:
>>
>> there is no such thing as "15th Ave North should be there is no such 
>> thing as
>> "15th Avenue North"
>>>         Title           : A LoST extension to return complete and 
>>> similar
>> location info
>>>         Authors         : Brian Rosen
>>>                           Roger Marshall
>>>                           Jeff Martin

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 26 Oct 2021 15:01:55 -0700

I support Dan's suggested edits.  Regarding the suggestion to reorganize 
the text, Dan, do you have specific suggestions (e.g., move paragraphs 
x-y of Section 3 to follow Paragraph z of Section 4)?

--Randall

On 12 Oct 2021, at 9:21, Dan Banks wrote:

> handful of new editorial issues:
>
> I still believe the document could be improved with a bit of 
> reorganization of sections 3 and 4, but I support advancing the 
> document without additional changes if that is the consensus.
>
> Dan Banks
>
>> This draft is a work item of the Emergency Context Resolution with 
>> Internet
>> Technologies WG of the IETF.
>>
>> similar location info

---

From: Dan Banks <[email-masked]>
Date: Thu, 28 Oct 2021 16:43:31 +0000

I do not have specific recommendations for reorganizing.  I do think it would be better if the overview was more of an overview (i.e., shorter than a full description which would presumably follow).

I also just noticed that the last paragraph of section 3 states "The next section shows examples", but those examples do not appear until section 5.  We should probably fix that to say "Section 5 shows examples".

Dan

> From: Randall Gellens <[email-masked]>
> Sent: Tuesday, October 26, 2021 6:02 PM
> To: Dan Banks <[email-masked]>
> Cc: [email-masked]; [email-masked]
> I support Dan's suggested edits.  Regarding the suggestion to reorganize the
> text, Dan, do you have specific suggestions (e.g., move paragraphs x-y of
> Section 3 to follow Paragraph z of Section 4)?
> 
> --Randall
> 
> > thing as "15th Avenue North"
> >> Internet Technologies WG of the IETF.
> >>
> https://nam12.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.i
> >>
> etf%2F&amp;data=04%7C01%7Cdbanks%40ddti.net%7Ccb29e7a0170841f40b
> 2a08d
> >>
> 998cc3dd0%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C6377088252
> 9081
> >>
> 5667%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJB
> >>
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FQ47hK8r708zBmq6
> T%2FmVx
> >> 5rlrIzT0GOqXwn%2Ff%2FBUt%2Bg%3D&amp;reserved=0
> >> .org%2Finternet-
> >>
> w.
> ietf.org%2Fmailman%2Flistinfo%2Fecrit&amp;data=04%7C01%7Cdbanks%40
> ddti
> >
> .net%7Ccb29e7a0170841f40b2a08d998cc3dd0%7C4c0f48ba5f2944b1b29c1aff8
> 251
> >
> 101b%7C0%7C0%7C637708825290815667%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4w
> >
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am
> p;sdat
> >
> a=xKFVAi123p%2F8xR2n1C8HopkEAj2QXGGJn29SdkEDX0A%3D&amp;reserv
> ed=0