Subject: Re: [Ecrit] draft-ietf-ecrit-similar-location-11.txt (was: Ecrit Digest, Vol 187, Issue 52)

From: Victor Burton <[email-masked]>
Date: Fri, 1 Oct 2021 17:48:03 +0000

Introduction: Delete "timely".
Use of this enhancement increases the likelihood that the correct and/or complete
   form of a civic location becomes timely known in those cases where it
   is incomplete or incorrect.

Terminology: Replace "can be" with is
Location:  The term Location can be used to refer to either a civic location or a geodetic location.

Section 3: Include "US" in the similarLocation address returned from LoST. It's a required CAType for addresses submitted to the ECRF, correct?
   Similar address #1: 6000 15th Ave NW Seattle, WA 98107 US

   Similar address #2: 6000 15th Ave NE Seattle, WA 98105 US After reading the example in section 5.2 which aligns with section 3, the Input address: 6000 15th Ave N Seattle, WA. should also include US. I assume the LVF will validate an address without <country> but then the description in section 3 would need to state that, correct?

-----Original Message-----
From: Ecrit <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, September 30, 2021 12:02 PM
To: [email-masked]
Subject: Ecrit Digest, Vol 187, Issue 52

WARNING: External Email: Exercise Caution

Send Ecrit mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fecrit&amp;data=04%7C01%7Cvictor.burton%40comtechtel.com%7C145e686b03b748082ae508d984451396%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637686254489287946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=f9gMbo0rlGv4X5ECA%2BiubeLb0N8ZkaiAIrD6Gf%2Fkojw%3D&amp;reserved=0
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ecrit digest..."

Today's Topics:

   1. I-D Action: draft-ietf-ecrit-similar-location-11.txt
      ([email-masked])
   2. WGLC draft-ietf-ecrit-similar-location-11 -- end date Oct 13
      (Randall Gellens)

----------------------------------------------------------------------

Message: 1
Date: Wed, 29 Sep 2021 12:07:46 -0700
From: [email-masked]
To: <[email-masked]>
Cc: [email-masked]
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-11.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

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-11.txt
        Pages           : 18
        Date            : 2021-09-29

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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ecrit-similar-location%2F&amp;data=04%7C01%7Cvictor.burton%40comtechtel.com%7C145e686b03b748082ae508d984451396%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637686254489287946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vjjfZ6BXP5fAotW8pS3Naw392lylShpCdXCJQkYhmxM%3D&amp;reserved=0

There is also an htmlized version available at:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ecrit-similar-location-11&amp;data=04%7C01%7Cvictor.burton%40comtechtel.com%7C145e686b03b748082ae508d984451396%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637686254489287946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2BDFEVqf6%2FO5v2qplCi7x7q8uXSXumYFczDWjbYuRtyc%3D&amp;reserved=0

A diff from the previous version is available at:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ecrit-similar-location-11&amp;data=04%7C01%7Cvictor.burton%40comtechtel.com%7C145e686b03b748082ae508d984451396%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637686254489287946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=iKVPNTmcJ6BPH6VBtsMGr9od%2FKeXYEQROpPoUw2ff0g%3D&amp;reserved=0

Internet-Drafts are also available by anonymous FTP at:
https://gcc02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&amp;data=04%7C01%7Cvictor.burton%40comtechtel.com%7C145e686b03b748082ae508d984451396%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637686254489287946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=IFc2XL21yZd3eXktHc6dFntS6OgQZ5J9Y%2BlEdtBWbSk%3D&amp;reserved=0

------------------------------

Message: 2
Date: Wed, 29 Sep 2021 12:51:36 -0700
From: "Randall Gellens" <[email-masked]>
To: ECRIT <[email-masked]>
Subject: [Ecrit] WGLC draft-ietf-ecrit-similar-location-11 -- end date
        Oct 13
Message-ID: <[email-masked]>
Content-Type: text/plain; format=flowed; markup=markdown

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

------------------------------

Subject: Digest Footer

_______________________________________________
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%7Cvictor.burton%40comtechtel.com%7C145e686b03b748082ae508d984451396%7Ca9a26e696ae040c1bd801ca6cc677828%7C0%7C0%7C637686254489287946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=f9gMbo0rlGv4X5ECA%2BiubeLb0N8ZkaiAIrD6Gf%2Fkojw%3D&amp;reserved=0

------------------------------

End of Ecrit Digest, Vol 187, Issue 52
**************************************
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: Victor Burton <[email-masked]>
Date: Fri, 1 Oct 2021 17:22:18 +0000

-----Original Message-----
From: Ecrit <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, September 30, 2021 12:02 PM
To: [email-masked]
Subject: Ecrit Digest, Vol 187, Issue 52

Today's Topics:

Message: 1

Abstract:

Message: 2

Thank you,

--Randall

Subject: Digest Footer

---

From: Dan Banks <[email-masked]>
Date: Tue, 5 Oct 2021 17:41:12 +0000

Regarding the examples in section 3, I'm a bit uncomfortable with addresses not being expressed in a way that is consistent with the CLDXF profile (fully spelled out), although I agree that they can still communicate the concepts while using abbreviations.  I would prefer that we modify these to use fully spelled STS and POD values since CLDXF is supposed to be the official profile for the locations being used.  And IIRC, CLDXF also requires the use of <country>.

However, the point you make about missing country is important for another, more basic reason.  While <country> is minOccurs="0" in the civicAddress schema of RFC 5139, for all practical purposes a LoST server (with less than global coverage, at least) cannot be expected to know if it (or another server) is authoritative for a queried location if that location does not include country.  Because of this, our implementation considers civic locations without country to be invalid - not in the <locationValidation> <invalid> list sense, but in the <locationInvalid> error sense.

So, I think the first example where the complete location adds country, A1, and PC is a poor example.  In order for this to occur, the LoST server would need to know that the remaining elements are globally unique in combination - or more practically, that there is only one A3 = "Seattle" in the world.

I think it would be a better example to illustrate the addition of something like an STS value where the RD is already unique within the county+A1+A3 that is shown, which would be a reasonable determination for a LoST server to be able to make.

Additionally, I believe the later example of input and similar addresses should also include country.

Dan

> From: Ecrit <[email-masked]> On Behalf Of Victor Burton
> Sent: Friday, October 1, 2021 1:22 PM
> To: [email-masked]
> Subject: Re: [Ecrit] draft-ietf-ecrit-similar-location-11.txt (was: Ecrit Digest,
> Vol 187, Issue 52)
> 
> Section 3: Include "US" in the similarLocation address returned from LoST. It's
> a required CAType for addresses submitted to the ECRF, correct?
>    Similar address #2: 6000 15th Ave NE Seattle, WA 98105 US After reading
> the example in section 5.2 which aligns with section 3, the Input address:
> 6000 15th Ave N Seattle, WA. should also include US. I assume the LVF will
> validate an address without <country> but then the description in section 3
> would need to state that, correct?
> 
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Fmailman%2Flistinfo%2Fecrit&amp;data=04%7C01%7Cdbanks%
> 40ddti.net%7Cf17bc75b13234b0036a108d9851af0e2%7C4c0f48ba5f2944b1b29
> c1aff8251101b%7C0%7C0%7C637687173040020776%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=0F20KJpZD1t0XP3OMpP6GVcFyW8dHxozi0xo
> xWDELlI%3D&amp;reserved=0
> 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%7Cf17bc75b13234
> b0036a108d9851af0e2%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C
> 637687173040020776%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata
> =G1%2BBRTNV8IFiHIbVG8rjXnOFO0fKKozuHSuvDzLAr6M%3D&amp;reserve
> d=0
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ecrit-similar-location-
> 11&amp;data=04%7C01%7Cdbanks%40ddti.net%7Cf17bc75b13234b0036a108
> d9851af0e2%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C637687173
> 040030772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Lr0HdMj
> HXSxysWCELfIGUBQFRzUvVGBxGxCFKJGNDlU%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-
> 11&amp;data=04%7C01%7Cdbanks%40ddti.net%7Cf17bc75b13234b0036a108
> d9851af0e2%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C637687173
> 040030772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6Rv0F%
> 2Bx0oVvrhZCfnuTSRNhvseRKkaR4%2BNmMhuRHQYM%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%7Cf17bc75b13234b0
> 036a108d9851af0e2%7C4c0f48ba5f2944b1b29c1aff8251101b%7C0%7C0%7C63
> 7687173040030772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=
> TXVZQCG7lGkCnzt0bnmBOb6HWf0ZJDAF1YZ%2BeGI3aXM%3D&amp;reserv
> ed=0
> 
> 
> 
> 
> 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%7Cf17bc75b13234b0036a108d9851af0e2%7C4c0f48ba5f2944b1b29
> c1aff8251101b%7C0%7C0%7C637687173040030772%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=vc7NVYnhCFBaQPEtTxvWDYVd8rB2UNH0T76L
> qrsJ8Ao%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.
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Fmailman%2Flistinfo%2Fecrit&amp;data=04%7C01%7Cdbanks%
> 40ddti.net%7Cf17bc75b13234b0036a108d9851af0e2%7C4c0f48ba5f2944b1b29
> c1aff8251101b%7C0%7C0%7C637687173040030772%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=vc7NVYnhCFBaQPEtTxvWDYVd8rB2UNH0T76L
> qrsJ8Ao%3D&amp;reserved=0

---

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

Inline.

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Victor Burton
Envoyé : 1 octobre 2021 13:22
À : [email-masked]
Objet : [EXT]Re: [Ecrit] draft-ietf-ecrit-similar-location-11.txt (was: Ecrit Digest, Vol 187, Issue 52)

[GC] I think the use of "timely" is warranted since without the enhancement, the client would not even be aware of a location being incomplete. 

Section 3: Include "US" in the similarLocation address returned from LoST. It's a required CAType for addresses submitted to the ECRF, correct?
   Similar address #1: 6000 15th Ave NW Seattle, WA 98107 US
[GC] an ECRF is one specific embodiment of a LoST server and there are other use cases that may have different policies.

   Similar address #2: 6000 15th Ave NE Seattle, WA 98105 US After reading the example in section 5.2 which aligns with section 3, the Input address: 6000 15th Ave N Seattle, WA. should also include US. I assume the LVF will validate an address without <country> but then the description in section 3 would need to state that, correct?
[GC] The input address does not contain <country> so technically speaking, there is no requirement to include it in the response.

---

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

Please see inline.

--Randall

On 5 Oct 2021, at 14:01, Caron, Guy wrote:

> [GC] I think the use of "timely" is warranted since without the 
> enhancement, the client would not even be aware of a location being 
> incomplete.

[RG] I agree with Guy; we should retain "timely".

> location or a geodetic location.

[RG] Normally I'd be in favor of replacing "can be" with "is" (since 
it's almost always better wording) but in this particular case the 
document doesn't use "Location" to refer to geodetic location, so I 
think here "can be" is better.  Or, we could say "is in general used" to 
refer to the larger scope outside this document.

---

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

Please see inline:

--Randall

On 5 Oct 2021, at 10:41, Dan Banks wrote:

> Regarding the examples in section 3, I'm a bit uncomfortable with 
> addresses not being expressed in a way that is consistent with the 
> CLDXF profile (fully spelled out), although I agree that they can 
> still communicate the concepts while using abbreviations.  I would 
> prefer that we modify these to use fully spelled STS and POD values 
> since CLDXF is supposed to be the official profile for the locations 
> being used.  And IIRC, CLDXF also requires the use of <country>.

[RG] This seems reasonable.

> However, the point you make about missing country is important for 
> another, more basic reason.  While <country> is minOccurs="0" in the 
> civicAddress schema of RFC 5139, for all practical purposes a LoST 
> server (with less than global coverage, at least) cannot be expected 
> to know if it (or another server) is authoritative for a queried 
> location if that location does not include country.  Because of this, 
> our implementation considers civic locations without country to be 
> invalid - not in the <locationValidation> <invalid> list sense, but in 
> the <locationInvalid> error sense.
>
> So, I think the first example where the complete location adds 
> country, A1, and PC is a poor example.  In order for this to occur, 
> the LoST server would need to know that the remaining elements are 
> globally unique in combination - or more practically, that there is 
> only one A3 = "Seattle" in the world.

[RG] It seems to me that, in practice, an LVF will have a limited scope 
(a particular area), and hence will assume an omitted country (or even 
state) is the one in which it is authoritative or in which it is part of 
the LoST tree.  But I do agree that one use of this extension is to 
complete an address to make it pedantically correct rather than just 
sufficient to find the intended address, and in that sense, showing an 
omitted country corrected to include it is good.

> addresses should also include country.

[RG] I agree that it would be good to also include country.

>> Use of this enhancement increases the likelihood that the correct 
>> and/or
>> complete
>> Location:  The term Location can be used to refer to either a civic 
>> location or a
>> geodetic location.
>>
>> When replying, please edit your Subject line so it is more specific 
>> than "Re:
>> Contents of Ecrit digest..."
>>
>>
>> Today's Topics:
>>
>> This draft is a work item of the Emergency Context Resolution with 
>> Internet
>> Technologies WG of the IETF.
>>
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Dan Banks <[email-masked]>
Date: Fri, 8 Oct 2021 21:24:23 +0000

First, an additional fix that I neglected to include in my earlier emails:  in the example in section 5.2, the 'similarLocationsLimited' attribute is shown on the final <similarLocation> element.  This is incorrect, as the attribute is defined by the schema directly on the <LocationValidation> element.

Additional discussion inline.

Dan

> From: Randall Gellens <[email-masked]>
> Sent: Wednesday, October 6, 2021 1:51 PM
> To: Dan Banks <[email-masked]>
> Cc: Victor Burton <[email-masked]>; [email-masked]
> [RG] It seems to me that, in practice, an LVF will have a limited scope (a
> particular area), and hence will assume an omitted country (or even
> state) is the one in which it is authoritative or in which it is part of the LoST
> tree.  But I do agree that one use of this extension is to complete an address
> to make it pedantically correct rather than just sufficient to find the intended
> address, and in that sense, showing an omitted country corrected to include
> it is good.

[DB] I agree that an LVF will have a limited scope, however I strongly disagree that it would be appropriate for a LoST server to make an assumption as you describe.  One of the main principles that I have vocalized over the years with respect to how LoST servers should operate and interoperate is that a query should get the same answer no matter which LoST server the client first presents the query to.  There are some edge cases where this may not be 100% possible, but making an assumption about a critical omitted element undermines the principle.  And it is precisely because of the limited scope that an element such as country becomes critical.

I disagree, however, that showing an omitted country corrected to include is a good example.  In order to correct it, the server has to either know or assume it.  Knowledge is unlikely, and assumption is bad, leading to my conclusion that the example is problematic.

If we wanted to show an example of making something pedantically correct, I would suggest the A2 element being returned in the complete location.  A2 is mandatory in CLDXF (IIRC we argued in NENA about this at length), but LoST servers with state-wide GIS data are deployed and it is easy to understand that such a LoST server would know if a location within its county+A1 but missing A2 is uniquely identified or not.

> [RG] I agree that it would be good to also include country.

[remainder trimmed]