From nobody Fri Jan 7 14:50:53 2022 Return-Path: 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 635113A0D35 for ; Fri, 7 Jan 2022 14:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iRVGTH81-CWt for ; Fri, 7 Jan 2022 14:50:51 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABF33A0D38 for ; Fri, 7 Jan 2022 14:50:50 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id a18so26503029edj.7 for ; Fri, 07 Jan 2022 14:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=J+nkCeeVwZwvSWKWKtY6RCwD+Hxp2SXj4NVio9yY3AQ=; b=bh42DAurDTHGuwc/4XdQ4kAEcJ0g8wE+zwMTPWkn6F8hJ7jwhwluvO92EMHra2R/98 EHzdk+KIKiY6iLHD/bvZlRTvkQiiUYSDK1PmasPcLBylmN5dgvbgGo5c0qgLIEM3Jk5v wjY5t5AhmLjHktpG9EeQlvWst4JCS+UUn4QefDB5MmkmzR0lOU6Hj47WVdo0dlIPL85o 13f54y/NQw+Qd0I+b9Sxa2BLx0iUcePZtr2K/6u3nggE09/I7TjZ60hpWWEsihUwNyBw LO+s0teCurz0Bxez2pjEWBD6IjeMOfMD8xF+J5rXkYBPFURB1G5yTEdQEqKdvP45461o 2BHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=J+nkCeeVwZwvSWKWKtY6RCwD+Hxp2SXj4NVio9yY3AQ=; b=rx2stEC0TYgk+fME3sblEoioRPHRpkajdq6RRyfAlxJprVQZNARjg17mManXcmgKBm BAm05sKV1Dr0G7rFOs05byeWXMVQ90PyUSx+HOLCIyTADzphFA/Aq43dONZ54iceKYP6 TwJaLWYX9Af4dGUwdivU7RkkKYFIkMt+pwx7f/nxGuVkaTZLj3svBLl59m0qu8cWJGI6 /9v2tyO1bd3yjhVLi1gQ8gitoYfxmZdXKDbGYDlg50DXA7U2eUa9/56K6A9F/INDWFil Zp1w68wnVA++/5SihKejVkmthCQa3wvKxKKjC7hoihjUk2VVdboDJKf/8d55JeKN1uSy 0QSg== X-Gm-Message-State: AOAM532qD+sYUQ7Tt8YiWDtSe2k+dPGmXVw5+MV2Iw575EopL+vsozyg N1F2NVAyGz6OPyY+DD22xSv00WoMh4Hg8DseglJXMYMz X-Google-Smtp-Source: ABdhPJzfM4QhdD5MTEXu0XOS0BRLJQBVF2hw1lrwjFJmnhMnDKWRBn5svVg0qicsc/8xUFL3ABXsBLubyygJJDJd9Nc= X-Received: by 2002:a17:906:5796:: with SMTP id k22mr5905592ejq.500.1641595847755; Fri, 07 Jan 2022 14:50:47 -0800 (PST) MIME-Version: 1.0 From: Dwight Purtle Date: Fri, 7 Jan 2022 16:50:36 -0600 Message-ID: To: br@brianrosen.net Cc: ECRIT Content-Type: multipart/alternative; boundary="0000000000005eca5d05d505d192" Archived-At: Subject: [Ecrit] Requested revisions to draft-ecrit-similar-location-14.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2022 22:50:52 -0000 --0000000000005eca5d05d505d192 Content-Type: text/plain; charset="UTF-8" I have been asked to be the document shepherd for the similar-location document. After reviewing the document, I believe a revision is needed before the document is advanced for approval. Here is a list of the items I believe need to be corrected. All are editorial and do not affect the content of the document. 1. Correct the spelling of "protocol" in the third word of the introduction. 2. The abstract contains a reference to [RFC 5222]. I have learned that abstracts cannot contain references. Please change to text, such as (RFC 5222). 3. Section 8.1 refers to a schema in Section 7. I believe it should say Section 6. 4. The XML in Section 5.1 needs two edits. In the Response portion, the > symbols at the end of the first and third lines need to be removed. The first four lines should be contained in a single set of angle brackets beginning with . 5. The XML in Section 5.2, Response portion, needs the same edits as 5.1. 6. In Section 6 the XML schema needs two corrections. Line 34 should be . A line should be added after line 40 that reads . Thanks to Randall Gellens for helping me figure out the XML issues. I am by no means an XML-savvy person. Thanks! Dwight Purtle (document shepherd) --0000000000005eca5d05d505d192 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have been asked to be the document shepherd for the simi= lar-location document.=C2=A0 After reviewing the document, I believe a revi= sion is needed before the document is advanced for approval.=C2=A0 Here is = a list of the items I believe need to be corrected.=C2=A0 All are editorial= and do not affect the content of=C2=A0the document.

1.= =C2=A0 Correct the spelling of "protocol" in the third word of th= e introduction.

2.=C2=A0 The abstract contains a r= eference to [RFC 5222].=C2=A0 I have learned that abstracts cannot contain = references.=C2=A0 Please change to text, such as (RFC 5222).

=
3.=C2=A0 Section 8.1 refers to a schema in Section 7.=C2=A0 I be= lieve it should say Section 6.

4.=C2=A0 The XML in= Section 5.1 needs two edits.=C2=A0 In the Response portion, the > symbo= ls at the end of the first and third lines need to be removed.=C2=A0 The fi= rst four lines should be contained in a single set of angle brackets beginn= ing with <findServiceResponse and ending with :civicAddr">.

5.=C2=A0 The XML in Section 5.2, Response portion, nee= ds the same edits as 5.1.

6.=C2=A0 In Section 6 th= e XML schema needs two corrections.=C2=A0 Line 34 </group> should be = </xs:group>.=C2=A0 A line should be added after line 40 that reads &l= t;/xs:minInclusive>.

Thanks to Randall Gellens = for helping me figure out the XML issues.=C2=A0 I am by no means an XML-sav= vy person.

Thanks!

Dwight= Purtle (document shepherd)
--0000000000005eca5d05d505d192-- From nobody Mon Jan 10 08:21:32 2022 Return-Path: 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 3375A3A1465 for ; Mon, 10 Jan 2022 08:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.com 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 JG96l0rioZYk for ; Mon, 10 Jan 2022 08:21:28 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685963A1463 for ; Mon, 10 Jan 2022 08:21:28 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id o7so18205186ioo.9 for ; Mon, 10 Jan 2022 08:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jChQLw3SUhf10W4lDPym5f+X1iYA8L5fss2/FVvBL2M=; b=28T8UzxpCDHeNO4RSeLXPaLPeeo7DhAoIdm+wE1PlPkQPQ89KCBuVaxc4L0gsIrqSy zzcXfkexWnTO5q9Se/BONt0PKW7oNQEGvhs1xab2+ul2ffG12p8q+prfv/gW8jOhio0W Te+m+meY457bffYzQpNYrK3JUdgUbDRVNI6uu+58tFHKmkaJQwtdhGzgh1Mf3XmKCR++ BU5DrCjPmuZjx3+wIJwoQPEnlEBw/PDLwdRiOPbZUvV1suj7Xma4cKRZUPw06o1Nutqq SdFN8hbsQBiyEIW1Smd2aSzZjkI3XjHF7afuz3MYiIis0PfmvpElCz7JTOO/w0uV3IOY JV0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jChQLw3SUhf10W4lDPym5f+X1iYA8L5fss2/FVvBL2M=; b=8E6FVEdK7TOcCkIAN34mLpeSnKVmbS58YaJE/SNjH8xvEXwcD1jNln8ixULYSoqSA5 pe12vRyo35noAIJ7VGbG9dljGbhTSa+8R6FZbnwQJFTgVsjcJqk9Ntnmacd7Q3xjQ9Xs n0F98rv0I8JCp/Pwg0f528dZoFqDWzcKpWZ9XRUXnvdcpjaQmRQYfX4y+dVtQsU3t1iM QLwow9zrTVg+oOqUhmJV08IlFzIeRGobL/Trft0AIAtgXSSdWcbwJP0hJlGGK2zXEKVS I27m2orfGcclYMfBAuqpotd5WWiDhJWDF3FLUg5LN4doIS2ZtIvoJW2/i3fKS0sAC34q vEtA== X-Gm-Message-State: AOAM531djkFxr0/yrwSUdHjeofRHmOiZvS+UZSQ8JdbOE0xxJE3Jtpp1 zKkpkLlEPMeA7IxkjVAgBH/+K6W38uF9DObv X-Google-Smtp-Source: ABdhPJwlHp7aRQMd+vzUNFu9KnrNNVz3F9lHrmobZOm0mwZM/HoIFLq+nhhB4cgXXK0w5iOBGr7YQw== X-Received: by 2002:a5d:93d5:: with SMTP id j21mr112385ioo.71.1641831686568; Mon, 10 Jan 2022 08:21:26 -0800 (PST) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id v21sm916205ioh.10.2022.01.10.08.21.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jan 2022 08:21:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Brian Rosen In-Reply-To: Date: Mon, 10 Jan 2022 11:21:24 -0500 Cc: ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dwight Purtle X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Ecrit] Requested revisions to draft-ecrit-similar-location-14.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 16:21:30 -0000 I will release a -15 with these changes shortly. I fixed the second = issue in item 6 by making it be , which I think is a more common way to handle it than = > On Jan 7, 2022, at 5:50 PM, Dwight Purtle = wrote: >=20 > I have been asked to be the document shepherd for the similar-location = document. After reviewing the document, I believe a revision is needed = before the document is advanced for approval. Here is a list of the = items I believe need to be corrected. All are editorial and do not = affect the content of the document. >=20 > 1. Correct the spelling of "protocol" in the third word of the = introduction. >=20 > 2. The abstract contains a reference to [RFC 5222]. I have learned = that abstracts cannot contain references. Please change to text, such = as (RFC 5222). >=20 > 3. Section 8.1 refers to a schema in Section 7. I believe it should = say Section 6. >=20 > 4. The XML in Section 5.1 needs two edits. In the Response portion, = the > symbols at the end of the first and third lines need to be = removed. The first four lines should be contained in a single set of = angle brackets beginning with . >=20 > 5. The XML in Section 5.2, Response portion, needs the same edits as = 5.1. >=20 > 6. In Section 6 the XML schema needs two corrections. Line 34 = should be . A line should be added after line 40 = that reads . >=20 > Thanks to Randall Gellens for helping me figure out the XML issues. I = am by no means an XML-savvy person. >=20 > Thanks! >=20 > Dwight Purtle (document shepherd) From nobody Tue Jan 11 10:59:51 2022 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 769603A080E; Tue, 11 Jan 2022 10:59:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <164192758944.19973.13804878868707641937@ietfa.amsl.com> Date: Tue, 11 Jan 2022 10:59:49 -0800 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-15.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 18:59:49 -0000 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-15.txt Pages : 18 Date : 2022-01-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 message. This document defines a new extension to the 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 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-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-15 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Jan 11 18:23:18 2022 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D72143A1057; Tue, 11 Jan 2022 18:23:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Allison Mankin via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Cc: dwightpurtle@gmail.com, ecrit-chairs@ietf.org, ecrit@ietf.org, iesg-secretary@ietf.org Message-ID: <164195419686.18416.6526442205312520549@ietfa.amsl.com> Date: Tue, 11 Jan 2022 18:23:16 -0800 Archived-At: Subject: [Ecrit] Publication has been requested for draft-ietf-ecrit-similar-location-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 02:23:17 -0000 Allison Mankin has requested publication of draft-ietf-ecrit-similar-location-15 as Proposed Standard on behalf of the ECRIT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/ From nobody Tue Jan 11 18:44:20 2022 Return-Path: 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 2317D3A076C for ; Tue, 11 Jan 2022 18:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 Elq585FCoe-S for ; Tue, 11 Jan 2022 18:44:17 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1463A0768 for ; Tue, 11 Jan 2022 18:44:17 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 11 Jan 2022 18:44:16 -0800 From: "Randall Gellens" To: "Brian Rosen" , ecrit@ietf.org Date: Tue, 11 Jan 2022 18:44:16 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <44B193AC-537C-45C7-BB87-775DE4E18EEE@randy.pensive.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Ecrit] Typo in Similar-Location-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 02:44:19 -0000 One typo jumped out at me. In Section 8 (IANA Considerations), there's an unprocessed xref: XML Schema: The XML schema to be registered is contained in . The reason is that the xref is inside an " 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 5A66C3A1847 for ; Wed, 12 Jan 2022 10:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OUn19StREzUd for ; Wed, 12 Jan 2022 10:37:58 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B4D3A1844 for ; Wed, 12 Jan 2022 10:37:58 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id m15so6575546uap.6 for ; Wed, 12 Jan 2022 10:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gY4Z7+pwG/cIOeRv71XmSqYvKxiWryRRxzdkTYkbeto=; b=lldPDJNXSvP3nRdXflJ1c057eDUf+GD/Mv9XFT3P+G2u71S7KlLhBgJiaJAolp990f PczI7HcT3t5BKouKqieCTsGBBy3+WVjhoA9HQfJXnH2rkPIlF2F8BgQPqqvhHcGgr5lD R6Bc6okhR6U4kDrMPYHkaNxx8UIFn27DeHKRxIGKzaQiYkynlQrd9fvkrPKqOxOcW08b zLmcl6H/haPOpos3iPaero7cJMAiZl2n1gxjrdPVuZI/kxy+jUgsIWo9AS+GHHrRNWlq +SIS9l1Uh8mQogjsczT//uj0Hh+V77L6d3mvJoIonEfdvkrZeaIScSTTyeU9aJsX8Cz4 phXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gY4Z7+pwG/cIOeRv71XmSqYvKxiWryRRxzdkTYkbeto=; b=7k5DNTHocEbxNrjWCw9nL+wOoOyjwq+BLifZS/wFxD5GRMoXAxcVxA6ldBdp2ET8W0 roNEwqFaMGnOGngHEv5nymjxQLY9eM9qlAkzNK3riFdZRp4wzrUpPK9MtVXxdeKSv5Yc 0M71bC68nEwaWm+cQpkIpf9657WPtbJ1wzQQKDGrh4B/f36nH1TAYJaQYtLN9jKElHWY Bp69wtaRneKOR4jl+faXwVN7KAsPpiudWjoq+7g0po0gtDG5NNPGEbGhzC6uHvwNky2h Y7IfMcrNmSBN4fVJwwxg37dggXC/7AHqsuAgNVwNjuT4rqFtbUMQQKndSRfSdTau4/rS CbPw== X-Gm-Message-State: AOAM531SbTOcMqXIqrzbUGpUi1dHOks3U80z//wx3ozf4ENAx+r4mnWT QNzGXIfYZ0WfH3f42wSD5dnrDLrCn3lzPxJLxcL91lzH X-Google-Smtp-Source: ABdhPJxNdbQjkKLuwlJhvClefYNuUnMUlJN6ZR7Fbn12s7pgT7J8ce92qePCfOrO7cFaRJP3/J+OrB7Y3RlO67jMwuU= X-Received: by 2002:a05:6102:31b3:: with SMTP id d19mr643295vsh.79.1642012675308; Wed, 12 Jan 2022 10:37:55 -0800 (PST) MIME-Version: 1.0 References: <44B193AC-537C-45C7-BB87-775DE4E18EEE@randy.pensive.org> In-Reply-To: <44B193AC-537C-45C7-BB87-775DE4E18EEE@randy.pensive.org> From: "Murray S. Kucherawy" Date: Wed, 12 Jan 2022 10:37:44 -0800 Message-ID: To: Randall Gellens Cc: Brian Rosen , ecrit@ietf.org Content-Type: multipart/alternative; boundary="0000000000003a80fc05d566deb5" Archived-At: Subject: Re: [Ecrit] Typo in Similar-Location-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 18:38:02 -0000 --0000000000003a80fc05d566deb5 Content-Type: text/plain; charset="UTF-8" It's in AD Evaluation now, but you can submit fixes like this as needed. It's highly unlikely I'll get to it before Friday. -MSK On Tue, Jan 11, 2022 at 6:44 PM Randall Gellens wrote: > One typo jumped out at me. In Section 8 (IANA Considerations), there's > an unprocessed xref: > > XML Schema: The XML schema to be registered is contained > in . > > The reason is that the xref is inside an " prevents processing XML. We can proceed to IETF Last Call without > fixing it, but if so I'd expect we'd get a lot of comments pointing it > out. > > --Randall > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --0000000000003a80fc05d566deb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's in AD Evaluation now, but you can submit fix= es like this as needed.=C2=A0 It's highly unlikely I'll get to it b= efore Friday.

-MSK

On Tue, Jan 11, 2022= at 6:44 PM Randall Gellens <rg+ietf@randy.pensive.org> wrote:
One typo jumped out at me. In Section 8 (IANA = Considerations), there's
an unprocessed xref:

=C2=A0 =C2=A0 XML Schema: The XML schema to be registered is contained
=C2=A0 =C2=A0 =C2=A0 =C2=A0in <xref target=3D"XMLSchema"/>.=

The reason is that the xref is inside an "<artwork><![CDATA[&= quot; that
prevents processing XML.=C2=A0 We can proceed to IETF Last Call without fixing it, but if so I'd expect we'd get a lot of comments pointing= it
out.

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--0000000000003a80fc05d566deb5-- From nobody Wed Jan 12 11:03:10 2022 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A20753A1916; Wed, 12 Jan 2022 11:03:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <164201418760.7911.2318105561172546511@ietfa.amsl.com> Date: Wed, 12 Jan 2022 11:03:07 -0800 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 19:03:08 -0000 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-16.txt Pages : 18 Date : 2022-01-12 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 message. This document defines a new extension to the 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 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-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-16 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Jan 12 11:04:01 2022 Return-Path: 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 370863A1916 for ; Wed, 12 Jan 2022 11:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.com 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 XZSEM_xcRRuL for ; Wed, 12 Jan 2022 11:03:55 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95E23A1942 for ; Wed, 12 Jan 2022 11:03:44 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id j1so5112720iob.1 for ; Wed, 12 Jan 2022 11:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mxsJ7rpNy0GxYLEiuMg109U3m5AiuU0DOjvAOa3o9AA=; b=Sx+5LskFrPxNz/gMy/ekVJLQy3xUt6PO19KxykLSfNLw/mElkLuqA0fW/1BqCn0MoJ oihVHHcZhSEsbIKhFwy/9U/Xuhf1dF46AO+QTGFnkIZvFOUOOl3jK0M8kLR7Zgenu+0K i8gr1iV6wwUWdy7Luxc11jWs0KLMMWvTVkp4qRZvn14+qObmXeErtheC3FlUtpzyQtDa 5Q7tCbCcx3mpK3WzbWkwcLvAZO6nGdzsMtOfPhU79xbwMU7SFShe7rCqZNR01FjdPY8B 21G31TS8m+/bM6SBzHdlwTmGtNNwfEZ6WqZcx+dhLfZvjvC7w/J+BI1SpIaSudtmBfsO v9RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mxsJ7rpNy0GxYLEiuMg109U3m5AiuU0DOjvAOa3o9AA=; b=g4Lkl14/eFiaJAecVEOwd4uUWdffc+qsib90IAX8/FbHqvW2kX2iwg2CtsmtR71iTA miJrO2mIMt6bfCkEOCy3rhWFq9W2Lg3GPCxxOGXcy7eJLqB0S3zJ/qJWS61pftByXcB/ wjxkv4tTd64450nVHWdwjJkBahn/a2UeVR+wntBWCgnlpJcd0fQNN3Gx/ZjZM2aIz2ob LkbgDi0Jmh7O/ktypiSKJJEDvpr49SAcbfYMIOQJk57Rb7QvUGnpFRaaQoK1XDb9/4DD B15g2fhf7JtzCojdQzKuwkwsqBNY/zlPOp5QH2oIllYwv3uOHSJnr54PcUVntdLnCN0v J/xg== X-Gm-Message-State: AOAM532uF6SKOsue9egXm2QyEGUVO8Qp3mFmEAJACuFl+N+rzGs4grvv 7K6L7YmoypEFVykyilK6D1YoTAb65hKmLBeK X-Google-Smtp-Source: ABdhPJwTW7aTXJWV8c4lLBpsjzlGmxpKy0sTwUB1ShSb2vcAIMx1sYQm2kNAT4D3Y5sGug7U2zxvsw== X-Received: by 2002:a05:6602:2742:: with SMTP id b2mr553336ioe.29.1642014223647; Wed, 12 Jan 2022 11:03:43 -0800 (PST) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id j2sm333055ilr.71.2022.01.12.11.03.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Jan 2022 11:03:43 -0800 (PST) From: Brian Rosen Message-Id: <3F22D53D-63C9-4DC2-B807-B00D6249CD83@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_3D7D2C07-F68E-482A-AB90-8BBF3F818FC8" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Wed, 12 Jan 2022 14:03:41 -0500 In-Reply-To: Cc: Randall Gellens , ecrit@ietf.org To: "Murray S. Kucherawy" References: <44B193AC-537C-45C7-BB87-775DE4E18EEE@randy.pensive.org> X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Ecrit] Typo in Similar-Location-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 19:03:59 -0000 --Apple-Mail=_3D7D2C07-F68E-482A-AB90-8BBF3F818FC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I submitted a -16 with this fixed. > On Jan 12, 2022, at 1:37 PM, Murray S. Kucherawy = wrote: >=20 > It's in AD Evaluation now, but you can submit fixes like this as = needed. It's highly unlikely I'll get to it before Friday. >=20 > -MSK >=20 > On Tue, Jan 11, 2022 at 6:44 PM Randall Gellens = > wrote: > One typo jumped out at me. In Section 8 (IANA Considerations), there's=20= > an unprocessed xref: >=20 > XML Schema: The XML schema to be registered is contained > in . >=20 > The reason is that the xref is inside an " prevents processing XML. We can proceed to IETF Last Call without=20 > fixing it, but if so I'd expect we'd get a lot of comments pointing it=20= > out. >=20 > --Randall >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --Apple-Mail=_3D7D2C07-F68E-482A-AB90-8BBF3F818FC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = submitted a -16 with this fixed.

On Jan = 12, 2022, at 1:37 PM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

It's in AD Evaluation now, but = you can submit fixes like this as needed.  It's highly unlikely = I'll get to it before Friday.

-MSK

On Tue, Jan 11, 2022 at 6:44 PM Randall Gellens = <rg+ietf@randy.pensive.org> wrote:
One typo jumped out at me. In Section = 8 (IANA Considerations), there's
an unprocessed xref:

    XML Schema: The XML schema to be registered is = contained
       in <xref target=3D"XMLSchema"/>.

The reason is that the xref is inside an "<artwork><![CDATA[" = that
prevents processing XML.  We can proceed to IETF Last Call without =
fixing it, but if so I'd expect we'd get a lot of comments pointing it =
out.

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_3D7D2C07-F68E-482A-AB90-8BBF3F818FC8-- From nobody Wed Jan 12 16:46:59 2022 Return-Path: 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 94BFC3A07D6 for ; Wed, 12 Jan 2022 16:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 h9SiqTzWsAQn for ; Wed, 12 Jan 2022 16:46:54 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6B43A07D2 for ; Wed, 12 Jan 2022 16:46:54 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id q14so5139738qtx.10 for ; Wed, 12 Jan 2022 16:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=E9eymYR7Ubb6+qx9hwDm4MK/Xr0TuvfY7tHrmWhuSF4=; b=EWFE+jzO/X6MmokArs8to1R73g8for9rB9OUmS9uM01gW+ljOdF0uus5l626rE6lz7 XjGbt4oJ3VKbFRWi/fSLBh8VLaHHCrUBrC7D1dMsCvPDn93ejQHD6A1ltfWAY8atm+DJ wkBT/YZvypkMgoDtnNRCyetYgMheyxB3903GuROIND+ieG+Gy/OdkeSbZtSX3qFu5aMO fPyec/poWa/DxP98ENFm220dX/oycHg6++bhIeODAGTonVkasXVCjQZTc+eayG0A69Wx LJ2vObKFJoW+fd/8+b2kQUPBCN21JmEut/dN04jB9Uv7gjTzjRCtU+Z3eafe4TbE/Tow tuVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=E9eymYR7Ubb6+qx9hwDm4MK/Xr0TuvfY7tHrmWhuSF4=; b=k41Vds6je4/F1HpkO/TlAINOL+TnzmaaPXZ+ZzMETT4OD4vSPl5E2mJuhSILxoinXf gVp36N/5fh0+h4m/ulZkPmQQaL77y32M1WL3W5EKd4S9PoRVlXLXrR1OZth5ySV7pGqS tQ5hdhieo32OkKK58kN7CqqB6qbBwkuh/yfkD/ZcccOAa1dc0rxKZU8BaJJ+RuxLuXti Rq449ky27cCeS7yxTGMNq8xyhu3cvD2NXEOpYrvLUB7ssLNjUQbrw/y9Dc/gWJcbJHsr 5nrZgDTfuQAF5nNHvk+9wGw+1BnlnWy3SB8lp1l/NCaFc5j2W4SogCPxrErBDyXkz4F8 ssWw== X-Gm-Message-State: AOAM530uyx9pDDJYf52miTmOrAPiMrCIAGN89mp0zSQOCi3Rh9Afnw6g Wuey6xAV6kq4stFiguOk6z7Cy8dBpXPu9uV017kg5z19 X-Google-Smtp-Source: ABdhPJw8Lqdq+VY1uu7RdZWMd8BOk1yDzJQj3U+jK1ShiM/Ls2AxnXnbuWdmNoSls4xSntFywT4d1AlTFwI7qbHgi4E= X-Received: by 2002:a05:622a:164a:: with SMTP id y10mr1809056qtj.441.1642034812050; Wed, 12 Jan 2022 16:46:52 -0800 (PST) MIME-Version: 1.0 References: <164201418760.7911.2318105561172546511@ietfa.amsl.com> In-Reply-To: <164201418760.7911.2318105561172546511@ietfa.amsl.com> From: Az Mankin Date: Wed, 12 Jan 2022 19:46:41 -0500 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="000000000000ae603d05d56c057e" Archived-At: Subject: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-similar-location-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 00:46:59 -0000 --000000000000ae603d05d56c057e Content-Type: text/plain; charset="UTF-8" Just fixed a typo of a bracket in -15 ---------- Forwarded message --------- From: Date: Wed, Jan 12, 2022 at 14:03 Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-16.txt To: CC: 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-16.txt Pages : 18 Date : 2022-01-12 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 message. This document defines a new extension to the 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 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-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-16 Internet-Drafts are also available by rsync at rsync.ietf.org: :internet-drafts _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --000000000000ae603d05d56c057e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just fixed a typo of a bracket in -15



---------- Forwarded message -----= ----
From: <internet-drafts@ietf.org>
Date: Wed, Jan 12, 2022 at= 14:03
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-16= .txt
To: <i-d-announce@ietf= .org>
CC: <ecrit@ietf.org>



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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A LoST extension to return complete and similar location info
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Rosen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Roger Marshall
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jeff Martin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ecrit-similar-location-16.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-01-12

Abstract:
=C2=A0 =C2=A0This document introduces a new way to provide returned locatio= n
=C2=A0 =C2=A0information in LoST responses that is either of a completed or=
=C2=A0 =C2=A0similar form to the original input civic location, based on wh= ether
=C2=A0 =C2=A0valid or invalid civic address elements are returned within th= e
=C2=A0 =C2=A0<findServiceResponse> message.=C2=A0 This document defin= es a new extension
=C2=A0 =C2=A0to the <findServiceResponse> message within the LoST pro= tocol
=C2=A0 =C2=A0(RFC5222) that enables the LoST protocol to return in a respon= se a
=C2=A0 =C2=A0completed civic address element set for a valid location respo= nse,
=C2=A0 =C2=A0and one or more suggested sets of similar location information= for an
=C2=A0 =C2=A0invalid location.=C2=A0 These two types of civic addresses are= referred to
=C2=A0 =C2=A0as either "complete location" or "similar locat= ion", and are included
=C2=A0 =C2=A0as a compilation of CAtype xml elements within the existing Lo= ST
=C2=A0 =C2=A0<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.o= rg/doc/html/draft-ietf-ecrit-similar-location-16

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


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--000000000000ae603d05d56c057e-- From nobody Mon Jan 24 14:51:19 2022 Return-Path: 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 8D2433A153C for ; Mon, 24 Jan 2022 14:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6xVQ0GY1t_yA for ; Mon, 24 Jan 2022 14:51:16 -0800 (PST) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96A53A1539 for ; Mon, 24 Jan 2022 14:51:16 -0800 (PST) Received: by mail-vk1-xa29.google.com with SMTP id w206so11206241vkd.10 for ; Mon, 24 Jan 2022 14:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=hL48Zb3wWTtLJTveDeueiy9RGsKKEzuWEulWFe+V8iI=; b=AC03NP0jYI6vH4o0CeTuidgEd/uO2yhV6Hdbb5mAqJQECgVI5Gcskcz7AnQ1JRTtu/ eKWFBliw4e3BqrQhKd3ghoFLmAjk3xuP/CXvLTHyJxUpuaPSyCbOgUyHRFjT9ADGvZso g86rXt8k06grTW4TLSy/0b211EMRMFjNukaHWNxJiYESIZFBVI3akFPxfT5iWQzV7Mh/ E4CrgJQyVaNgOLOX/Ogrgv0anIJOq2+HINuLWOelpK5Xa22KFW3BmB6E6J30bixKR9i2 L2z43o0o3BNRh20/97ZtRqQyG/o1jRIhSWzCApnKU+YAmQJ9j80Jcr9zV7qV/n6jh2EI PaPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hL48Zb3wWTtLJTveDeueiy9RGsKKEzuWEulWFe+V8iI=; b=NvS2FdtXh7M6KQXsqbdDyF4BaWlnRlaaDKMGdg7ckeHKC/IaVNYbjZZZwbMnq4C3BF sKsAXnYW0K/r1q2Zz8UpX6+fHAlqdET75cYM/yL6uQFy6CIPZhAQAGz0apRTz44UrxXq vqVMuiFsUR96KEvsQ13fUXVd6DjgsRmEA15fMR+nRWOsuX+LPiNREBjJALet6BRuivC2 ChorwW+vB0MK/Vrwwn5LKMx1a2JuX2mZSrS++XgU8tKx3TvQCM5bcYW4/83Wv1jcSaKA Vdq4zfFV53R+Nx3VLAoqO5URMuV1eHBA5yxQ7Ywsb7AZW5ZwalaCi6zC2pvC+IFGXhJs 1iLg== X-Gm-Message-State: AOAM533kkaZIqHipBnHFwfKWJ/I7fN41QGDmO2TH3esgObtOrvUQE7Yo Smrwd3xCZLl3fdsQiUPr1nEru6BGkOYDAxJYMb9b5n/U X-Google-Smtp-Source: ABdhPJxm1ZNkrGo5taKuojJpIO63UtSGKgqiXD8L0/ZxaFgNvGtfJexDNtsVwFAQMfuSu0SNKcWXmCTPF61ischeh6U= X-Received: by 2002:a1f:2988:: with SMTP id p130mr5478050vkp.34.1643064674073; Mon, 24 Jan 2022 14:51:14 -0800 (PST) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Mon, 24 Jan 2022 14:51:03 -0800 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="0000000000003dc17a05d65bcefe" Archived-At: Subject: [Ecrit] AD review of draft-ietf-ecrit-similar-location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 22:51:19 -0000 --0000000000003dc17a05d65bcefe Content-Type: text/plain; charset="UTF-8" Hi all, thanks for getting this moving. Here's my brief AD review. Abstract (and throughout the document) * "xml" should be all-caps Section 2 * RFC 2119 has been updated and so the citation you need to include has changed. See (and include a reference to) RFC 8174 for the new citation. * Does "WGS84" need a reference? Seems like it should. (Or maybe just remove it?) Section 3 * The "This extension has two different use cases ..." text at the end of the first paragraph feels like it buries the lede a bit. Maybe move it up closer to the top, or make it its own paragraph? Section 4 * If "similarLocationsLimited" is non-zero, is there a way I can query the server to ask it for the ones it didn't give me? Or is the limited set I'm given essentially random each time? * Also, given its definition, maybe "similarLocationsOmitted" might be a more exact name. Section 7 * Nice work here, this covered all of the questions I was saving up. Section 8 * I think a normative reference to RFC 3688 is warranted for registering the schema, and RFC 3553 for the namespace. * Both of these subsections should include an introductory sentence, e.g.: "IANA is requested to register the following in the "schema" sub-registry of the IETF XML Registry:" -MSK --0000000000003dc17a05d65bcefe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all, thanks for getting this moving.=C2=A0 Here= 9;s my brief AD review.

Abstract (and throughout t= he document)

* "xml" should be all-c= aps

Section 2

* RFC 2119 = has been updated and so the citation you need to include has changed.=C2=A0= See (and include a reference to) RFC 8174 for the new citation.
=
* Does "WGS84" need a reference?=C2=A0 Seems like = it should.=C2=A0 (Or maybe just remove it?)

Se= ction 3

* The "This extension has two differe= nt use cases ..." text at the end of the first paragraph feels like it= buries the lede a bit.=C2=A0 Maybe move it up closer to the top, or make i= t its own paragraph?

Section 4

* If "similarLocationsLimited" is non-zero, is there a way I c= an query the server to ask it for the ones it didn't give me?=C2=A0 Or = is the limited set I'm given essentially random each time?
* Also, given its definition, maybe "similarLocationsOmit= ted" might be a more exact name.

Section 7

* Nice work here, this covered all of the questions = I was saving up.

Section 8

* I think a normative reference to RFC 3688 is warranted for registering = the schema, and RFC 3553 for the namespace.

* Both= of these subsections should include an introductory sentence, e.g.:=C2=A0 = "IANA is requested to register the following in the "schema"= sub-registry of the IETF XML Registry:"

-MSK=

--0000000000003dc17a05d65bcefe-- From nobody Tue Jan 25 14:03:34 2022 Return-Path: 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 9A0A63A0D3D for ; Tue, 25 Jan 2022 14:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.com 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 lw0PN9UabZuX for ; Tue, 25 Jan 2022 14:03:30 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6A03A0CC7 for ; Tue, 25 Jan 2022 14:03:30 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id r144so3437727iod.9 for ; Tue, 25 Jan 2022 14:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=24D2tpG8ipEBzYqdZedGyEp1E/WbN59cNyTl7ZQ8xyU=; b=I+wpfdZNhEGnjs/K+0Ty+rNBwE2RScZskX7N7HEP4pXs9EbkCPextefqvlVCOMoAak Hp+ljnZ0u1Ysz+WYmR9xm1o4uP1CKG35tZeb6z5uxbPbqZqCZBYRFK8bUitgX2nQynfS coGSH/D366E3Ga7gpUuFFn6E275RtHBvso0sQIHbip62wjh9XBOIsb3Qyu07bGTRI5Pw vLKQ5lBs8saH5fCofVFMUdQx6khqSYAT0XlbEFAZH4qn+9IJOv7/RXqK8DBLjIvs7x7n c94/Wh9iTGY+s6sJb7IgK22mp3/Si5LXkZyW5Fh/Yy8tqQCovaFIqEFi+v4gXMVoDfpu GerA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=24D2tpG8ipEBzYqdZedGyEp1E/WbN59cNyTl7ZQ8xyU=; b=aja6C8q9XR0LPiK2EVUuiI3zrNmPn5lAYD1VM3c0ppRLgwpoh8EPo1kIGAZI/osBm8 KTiMnZyqDq3E55A2zRH2oP02il5NkflHvYy15zg8NYhcj2qSYldQQEgfbL9uRf4jqiV1 j4DKll/W69Y1XW9ltc8oEttNXR6dpNjHQ7ktoR06fWeOCr12q5Y6pPjD2vSezFtKiT/g 6uMG7wxacYJsHLuOX7ee7PCU9UKqHpEQZOb1PuViSemxgKXfEJhLGsNKTrEgwmaEU02c JUDgykpar9pKFnNEN1UhpSSJXLygt0f39eYuY+X3zmJbwBDk9OyLgz60BPKojWU+ifTs q/ug== X-Gm-Message-State: AOAM530jIwJmYfjfT/ACBAOPRNIHsxn8Et58Y+zl7rrV7oyWFOCCPW6r ncJUdo/8pKqgfa2Yx89hTEaRCPqamLWuy+ys X-Google-Smtp-Source: ABdhPJwJzzvOGUDEzRG2sEHsR20GnItFFEfJCu/7eUMC7gXXZ2BIH4V3ygSD4muGznbwMLWm9yJeqQ== X-Received: by 2002:a02:cbc4:: with SMTP id u4mr5851474jaq.117.1643148208457; Tue, 25 Jan 2022 14:03:28 -0800 (PST) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id g21sm187153iow.4.2022.01.25.14.03.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jan 2022 14:03:27 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0ADAB3CE-329B-4C65-8E42-D37D0301FB45" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Tue, 25 Jan 2022 17:03:26 -0500 In-Reply-To: Cc: ecrit@ietf.org To: "Murray S. Kucherawy" References: X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Ecrit] AD review of draft-ietf-ecrit-similar-location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 22:03:33 -0000 --Apple-Mail=_0ADAB3CE-329B-4C65-8E42-D37D0301FB45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m preparing a -17 > On Jan 24, 2022, at 5:51 PM, Murray S. Kucherawy = wrote: >=20 > Hi all, thanks for getting this moving. Here's my brief AD review. >=20 > Abstract (and throughout the document) >=20 > * "xml" should be all-caps Done >=20 > Section 2 >=20 > * RFC 2119 has been updated and so the citation you need to include = has changed. See (and include a reference to) RFC 8174 for the new = citation. Done >=20 > * Does "WGS84" need a reference? Seems like it should. (Or maybe = just remove it?) Removed >=20 > Section 3 >=20 > * The "This extension has two different use cases ..." text at the end = of the first paragraph feels like it buries the lede a bit. Maybe move = it up closer to the top, or make it its own paragraph? Moved >=20 > Section 4 >=20 > * If "similarLocationsLimited" is non-zero, is there a way I can query = the server to ask it for the ones it didn't give me? Or is the limited = set I'm given essentially random each time? Text says: If there are too many possible locations, the server MAY = return none, or it MAY return a subset considered most likely. How many = to return is left to the implementation of the LoST server. The server = is unable to know what the intended location information was supposed to = be; it is guessing. Therefore the correct location may or may not be = one of the <similarLocation> elements the server provides, and the = client cannot assume that any one of them is the correct location. I will add =E2=80=9Cbut no mechanism to request more Similar Locations = from the server=E2=80=9D to remove any doubt if there is a way to get = them. It could have been a boolean, but we decided to tell the client how wild = the guess was :) >=20 > * Also, given its definition, maybe "similarLocationsOmitted" might be = a more exact name. Changed >=20 > Section 7 >=20 > * Nice work here, this covered all of the questions I was saving up. Thanks >=20 > Section 8 >=20 > * I think a normative reference to RFC 3688 is warranted for = registering the schema, and RFC 3553 for the namespace. Done >=20 > * Both of these subsections should include an introductory sentence, = e.g.: "IANA is requested to register the following in the "schema" = sub-registry of the IETF XML Registry:" >=20 > -MSK >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_0ADAB3CE-329B-4C65-8E42-D37D0301FB45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m preparing a -17

On Jan 24, 2022, at 5:51 PM, = Murray S. Kucherawy <superuser@gmail.com> wrote:

Hi all, thanks for getting this moving.  = Here's my brief AD review.

Abstract (and throughout the document)

* "xml" should be = all-caps
Done

Section 2

* RFC 2119 has been = updated and so the citation you need to include has changed.  See = (and include a reference to) RFC 8174 for the new = citation.
Done

* Does "WGS84" need a = reference?  Seems like it should.  (Or maybe just remove = it?)
Removed

Section 3

* The "This extension has two different use cases ..." text = at the end of the first paragraph feels like it buries the lede a = bit.  Maybe move it up closer to the top, or make it its own = paragraph?
Moved

Section 4

* = If "similarLocationsLimited" is non-zero, is there a way I can query the = server to ask it for the ones it didn't give me?  Or is the limited = set I'm given essentially random each = time?
Text says: If there are too many possible locations, the server = MAY return none, or it MAY return a subset considered most = likely.  = How many to return is = left to the implementation of the LoST server.  The server is unable to know what the intended location = information was supposed to be; it is guessing.  Therefore the correct = location may or may not be one of the &lt;similarLocation&gt; = elements the server provides, and the client cannot assume that any one = of them is the correct location.

I will add =E2=80=9Cbut no mechanism to request = more Similar Locations from the server=E2=80=9D to remove any doubt if = there is a way to get them.

It could = have been a boolean, but we decided to tell the client how wild the = guess was :)

* Also, given its definition, maybe = "similarLocationsOmitted" might be a more exact = name.
Changed


Section 7

* Nice work here, this covered all of the questions I was = saving up.
Thanks

Section 8

* I think a normative = reference to RFC 3688 is warranted for registering the schema, and RFC = 3553 for the namespace.
Done

* Both of these subsections should include an introductory = sentence, e.g.:  "IANA is requested to register the following in = the "schema" sub-registry of the IETF XML Registry:"

-MSK

_______________________________________________
Ecrit = mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_0ADAB3CE-329B-4C65-8E42-D37D0301FB45-- From nobody Tue Jan 25 14:04:44 2022 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0860E3A0D75; Tue, 25 Jan 2022 14:04:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <164314828290.342.7174833663658369306@ietfa.amsl.com> Date: Tue, 25 Jan 2022 14:04:42 -0800 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-17.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 22:04:43 -0000 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-17.txt Pages : 19 Date : 2022-01-25 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 message. This document defines a new extension to the 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 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-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-17 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Jan 25 14:08:20 2022 Return-Path: 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 E16C33A0DD1 for ; Tue, 25 Jan 2022 14:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.887 X-Spam-Level: X-Spam-Status: No, score=-6.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.com 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 lwyN3HYOR2E6 for ; Tue, 25 Jan 2022 14:08:16 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB6C3A0DCB for ; Tue, 25 Jan 2022 14:08:15 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id z199so10949054iof.10 for ; Tue, 25 Jan 2022 14:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iPliQZ+JJPfrLqsS5KgVe2J8JgUlfMlljQ7GJ5j2pB8=; b=NbxOjjvGJFBqDbKFeGGkgvJfRC/gnKd1tBPIqEFesh9wLjeM0/Ajtx2DQcHkheY4Fs bfi48AbDh51rQvZMjUfNPabr8i3oPi5TNAWFsCaCIUrzppxYSoL22SVirEWFsJ4Uj/Rc 09tX4uK0a0N+2WxoqFEILxDY3Q75l6K3myqSPMC4mt0K5N1ML+CsLiaBCr/Q/ixu0B0u YEgcAztem1X2bLljoYQSVppihbyTEDT5fh6G6cZhOiuEYLmyJDX8wlotm6jBZkSdLOZQ bcn04zBozLtZFDf0oiDPJkQpWygIqajFZ9a4aeq1ju+hCMS4qGvwPL3nblx+cp9xsgV+ KsCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iPliQZ+JJPfrLqsS5KgVe2J8JgUlfMlljQ7GJ5j2pB8=; b=qyczcKLg9GFtpaVm0uKBQ8tKc/gHslrHSvDl5MnKipuNuilbKArrhhSHcWXhfe2oSM srvVKHiQvv6Z63lTn5UimbEq5plgHDsnlvewwFhNEMcegXP8PByvcR/J6esEVPQxBzuI /OqDrZmPnhpgSA8u7ak1+ijxucgiv5OKDTsOwDfQfmT6B4epP2IBEupwwdqV4JxJQbVp 2hop12FyB9NeJ1M3A115ng3zj+cF+MLMsGhqVr2GKQFwktVH3yrIZthT2/ODNmWLRb/V /3gahN1b7eBDNO70upGUF0Dja+5UJR62fY8mZttY7Kl6k5cLb/aJiyaqAztKJaQMY285 7LOA== X-Gm-Message-State: AOAM532C8Gvs7fGX1OS6na+KSwXDI6jCqsKOrW1ym04zjobq+2dZf4di EnwRr5iaVZ7T3sTWzq6DC6lKCqAWyvH49OnBAKfaqeWATOqgow== X-Google-Smtp-Source: ABdhPJwBOrmlilBzazD0Wp1FBS5EkmvTc0LvjtISpLAC2XV61bfSBXRutiusaEjgucbC/4Ln0/lMoXIrQaTEUL8mHUQ= X-Received: by 2002:a05:6638:1b1:: with SMTP id b17mr8697226jaq.18.1643148494188; Tue, 25 Jan 2022 14:08:14 -0800 (PST) MIME-Version: 1.0 References: <164314828290.342.7174833663658369306@ietfa.amsl.com> In-Reply-To: <164314828290.342.7174833663658369306@ietfa.amsl.com> From: Brian Rosen Date: Tue, 25 Jan 2022 17:08:03 -0500 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f528a05d66f52ea" Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-17.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2022 22:08:18 -0000 --0000000000004f528a05d66f52ea Content-Type: text/plain; charset="UTF-8" This version addresses AD comments. Brian On Tue, Jan 25, 2022 at 5:04 PM wrote: > > 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-17.txt > Pages : 19 > Date : 2022-01-25 > > 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 > message. This document defines a new extension > to the 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 > 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-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-17 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --0000000000004f528a05d66f52ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This version addresses AD comments.=C2=A0

Brian

On Tue, Jan 25, 2022 at 5:0= 4 PM <internet-drafts@ietf.o= rg> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A LoST extension to return complete and similar location info
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Rosen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Roger Marshall
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jeff Martin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ecrit-similar-location-17.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-01-25

Abstract:
=C2=A0 =C2=A0This document introduces a new way to provide returned locatio= n
=C2=A0 =C2=A0information in LoST responses that is either of a completed or=
=C2=A0 =C2=A0similar form to the original input civic location, based on wh= ether
=C2=A0 =C2=A0valid or invalid civic address elements are returned within th= e
=C2=A0 =C2=A0<findServiceResponse> message.=C2=A0 This document defin= es a new extension
=C2=A0 =C2=A0to the <findServiceResponse> message within the LoST pro= tocol
=C2=A0 =C2=A0(RFC5222) that enables the LoST protocol to return in a respon= se a
=C2=A0 =C2=A0completed civic address element set for a valid location respo= nse,
=C2=A0 =C2=A0and one or more suggested sets of similar location information= for an
=C2=A0 =C2=A0invalid location.=C2=A0 These two types of civic addresses are= referred to
=C2=A0 =C2=A0as either "complete location" or "similar locat= ion", and are included
=C2=A0 =C2=A0as a compilation of CAtype XML elements within the existing Lo= ST
=C2=A0 =C2=A0<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.o= rg/doc/html/draft-ietf-ecrit-similar-location-17

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


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--0000000000004f528a05d66f52ea-- From nobody Wed Jan 26 06:55:37 2022 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E86D3A133E; Wed, 26 Jan 2022 06:55:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-ecrit-similar-location@ietf.org, dwightpurtle@gmail.com, ecrit-chairs@ietf.org, ecrit@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <164320893056.22411.15797607316561970461@ietfa.amsl.com> Date: Wed, 26 Jan 2022 06:55:30 -0800 Archived-At: Subject: [Ecrit] Last Call: (A LoST extension to return complete and similar location info) to Proposed Standard X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 14:55:31 -0000 The IESG has received a request from the Emergency Context Resolution with Internet Technologies WG (ecrit) to consider the following document: - 'A LoST extension to return complete and similar location info' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2022-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 message. This document defines a new extension to the 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 message structure. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Jan 29 17:00:57 2022 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 731963A07D3; Sat, 29 Jan 2022 17:00:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: draft-ietf-ecrit-similar-location.all@ietf.org, ecrit@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164350445633.30531.10572441517907261963@ietfa.amsl.com> Reply-To: Russ Housley Date: Sat, 29 Jan 2022 17:00:56 -0800 Archived-At: Subject: [Ecrit] Genart last call review of draft-ietf-ecrit-similar-location-17 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2022 01:00:57 -0000 Reviewer: Russ Housley Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-ecrit-similar-location-17 Reviewer: Russ Housley Review Date: 2022-01-29 IETF LC End Date: 2022-02-09 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: None Minor Concerns: The Abstract could be much shorter. I suggest: This document describes an extension to the LoST protocol that is specified in RFC 5222 that allows additional civic location information to be returned in the element of a . This extension supports two use cases. First, when the input location is incomplete, the LoST server can provide a complete intended unique address. Second, when the input location is invalid, the LoST server can identify one or more feasible locations. This extension is applicable when the location information in the request uses the Basic Civic profile as described in RFC 5222. Section 1 says: ... Use of this enhancement increases the likelihood that the correct and/or complete form of a civic location becomes known in those cases where it is incomplete or incorrect. I think it would be more clear to turn the sentence around: ... When incomplete or incorrect civic location information is provided, use of this enhancement increases the likelihood that correct and complete civic location can be learned. Section 1 ends with a discussion about what the document contains, but it is incomplete. Either drop the paragraph, or tell what is coming in all of the coming sections. Section 3 says: ... 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. Can this be turned into a simple MUST statement? Perhaps: ... A server MUST include only Returned Location Information using a location profile that was used by the client in the request. Section 3 says: In a LoST indicating a Valid Location i.e., containing the element with no elements listed as invalid, the LoST server can use this extension to include additional location information in a element. I think this would be more clear if it defined a Valid Location, and then use this definition: A Valid Location contains a element without any elements listed as invalid. In a LoST indicating a Valid Location, the LoST server can use this extension to include additional location information in a element. Nits: Section 2: s/here. ./here./ Section 2: Some definitions end with a period, but one does not. Please add the missing period. Section 3: s/end-user/end user/ Section 3: s/intended by the user/intended by the end user/ Section 4: s/defined in RFC5222/defined in [RFC5222]/ Section 7: s/new threat/new security concern/ From nobody Mon Jan 31 09:11:11 2022 Return-Path: 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 0E34F3A0E0B; Mon, 31 Jan 2022 09:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ddti.net 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 g0Fmjek2SeIW; Mon, 31 Jan 2022 09:11:05 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2062.outbound.protection.outlook.com [40.107.244.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3EB3A0E01; Mon, 31 Jan 2022 09:11:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m4rsFK3yOFqzFopF/hhQtv2KE7LwrEPPBSG+aw5GrAanFK+W9jnrDKP7IIKb1VkQ9aCk3UtQr7fh81vdeF1HwB8j0rn/ken2PtPu1oJsPxRgPGfbSAc85HjN7AL7xCdF9mf8IsUUH3da7NevGvqxQr9egKFNU/XZqZjnwIu0k6kiuxZIHodcVk4Jr7bZZmizuW4OM/3iKiHQusydzvrRajrwj02KhpQrgeKx+I10JMtWuktxb+Ip8+LeMp6WQrftFbWYRE6rGHJEwZ//L7dzonID1BLc288eNuDnNd1W3b4eouL+lNqH+GiuoM05eubCYlucSCTCpyBtmVl37IoAWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=w+H+1SuOvJCLDgDigcUQVQeoFRjHXIXtCvGqdfj6Kd4=; b=KpREWmlqqlJdmH0PsPXKh2zX0wOOmlhtHaSOsiFYhJExiG9u1I8Mm5z/qTV3xzOZASEA9163pjiJ1Y822S1KFCFo7hvTCoeHG76dzFOVXrRVayQbRrIA0l8qwWKVkBl6nvi1pEYwHaR/2ntSqbvn97LiWEFoUOrM3F9HI9UyaizI9sxzJydU+260WFi7MAUmvGVkCIj+kCwerJ8F9+oQXT7TljwBfA2auk2t00fIl4JrWh0uLR/DPsZiw3EiSXXC85MPsAqMbCqfMi7b+iD6TzvvoeLQFqDoNtWVbS93SdN9C1atPEB/1qECt3Id550Y14xRy+39ZZ89uALF0lkNow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ddti.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w+H+1SuOvJCLDgDigcUQVQeoFRjHXIXtCvGqdfj6Kd4=; b=nq94GKnoJd94u8iLwfndYdVZIowGKwtoLpYck71dW2YZR+xy1SJLTKPcmTOb8IBN2R8fQcm5Sbfi/sB6WYvrbicJ/JHznt/IPTnAVxknKCngfBF57tH+wDnz8ZHAS5dwO004T6D83aqWgCII5FDzjJixq+DiXY27PgtNzmjQPO4= Received: from DM5PR1701MB1818.namprd17.prod.outlook.com (2603:10b6:4:1c::19) by BYAPR17MB2120.namprd17.prod.outlook.com (2603:10b6:a02:b8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.21; Mon, 31 Jan 2022 17:10:59 +0000 Received: from DM5PR1701MB1818.namprd17.prod.outlook.com ([fe80::88bd:674f:6740:5632]) by DM5PR1701MB1818.namprd17.prod.outlook.com ([fe80::88bd:674f:6740:5632%11]) with mapi id 15.20.4930.022; Mon, 31 Jan 2022 17:10:58 +0000 From: Dan Banks To: Russ Housley , "gen-art@ietf.org" CC: "last-call@ietf.org" , "ecrit@ietf.org" , "draft-ietf-ecrit-similar-location.all@ietf.org" Thread-Topic: [Ecrit] Genart last call review of draft-ietf-ecrit-similar-location-17 Thread-Index: AQHYFXTbPn1CtMiXGkqZApKZXCWCCqx9W4xw Date: Mon, 31 Jan 2022 17:10:58 +0000 Message-ID: References: <164350445633.30531.10572441517907261963@ietfa.amsl.com> In-Reply-To: <164350445633.30531.10572441517907261963@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ddti.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 73a20ad1-b368-4e98-13ab-08d9e4dca671 x-ms-traffictypediagnostic: BYAPR17MB2120:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iXiBi4E5jt8aeifNSTOn4wGcJ4fKz9rKQbdz0EhwMmNpy2rAGQEsOvfOmusDMdJHV3NMOyVZ9tenkulQGKraocBPPngaiIuTy5WVNKLP6+2LYhTNRhMYcZTOekZpP88/rYgQTpqZ0HCpY/Jf6WJP5bzkEZ/7oFc6nj8rLJFwyUg57zX49kzzDiavEfqEqEnNeTmHujeC0vHofAAVPZAjJv6TXQnYgFA93e/taCc1ThyyoOXXV+QJpl0QuIYl00bIuBSumnmFpJ9mkiDrtLvunx/F2Q9oCVcjwWAZx17siJfI1aclGaFg6ZUkyATv+RGfDCwwUEuWHuaptB43Lys+acZjJYB7pczzqcWB3ksexcOGguWbPZVT/ZsEgYBW2zlMqzDq8WQuBHbQLKoDQvoxM/Mdcg50JxOu6NK/Q2Zu0tjRWbI0jw6X2H2VEQimagW9uJmhH/9PeFb/mAC/spnI3DYeVl+KBvSbuhgYwkpelHliSZr0RPYuZILOTzT/g4BpfNITMaKGOQSBBnt6B9zgXKWrjBagmz4VmNMm4Dnq6QYmNSGWD86S1dBXlSXjjzXLeqNXaBz2lb7wIAiEB3vlC/hnPeYdlwcch7h/+6a9MJmCcvKTQUw0Qz12bJkmM1aF+QwialnCWhrVnZnjb73V/ncrtEJxmI1IEWgvRnL+NN+w3wIXR8lagLsp7x9VMM6UwMOQVhxg9OQRnna58s6I9g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR1701MB1818.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(346002)(39830400003)(376002)(136003)(396003)(38100700002)(55016003)(122000001)(33656002)(5660300002)(83380400001)(6506007)(2906002)(52536014)(7696005)(76116006)(110136005)(8676002)(86362001)(66446008)(66476007)(186003)(66946007)(26005)(66556008)(8936002)(71200400001)(38070700005)(316002)(9686003)(64756008)(54906003)(508600001)(4326008)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?OP+6XR3loIxftzIQRanD2TEyVR4eonvtHU3qaYmd7Dc2MxuCMr4j7gboLac4?= =?us-ascii?Q?wDeWBr8ofsJqqua6Bd1iCJ3EDsaTwvcT3kKrHzWE1qjy+sxCj1+7Rv0sCIUZ?= =?us-ascii?Q?lWgzWLVNCwj6G7b726xG/ibKgTNPtUQolSMaJHexdS0iWkn70EW24ZVWPn0X?= =?us-ascii?Q?49Lc7fenX7fVHi81fypRSen7/kPyd5bhEYs16idE88WTCWsjmetbVOKQfn3y?= =?us-ascii?Q?1Taq9D7ghyCeeZzFm2pV4YbrIQ0ohHhKgmFJDb2iMck/i3EyjPubrjXOx6W9?= =?us-ascii?Q?C6PFMTVGwWk0jcrBNjKGYPtjyXJWJMfqcWCd2NtlvB+ykHAGjhT3vRXzHjk4?= =?us-ascii?Q?d0yOx4BI0exOBRZ3gO3svWMr9OTSEbvVtJZrwJdBwXwdXfK54Q4+KsorLeFO?= =?us-ascii?Q?FqL97Br/q2ruzbk07R7WDFTdV1qHdl9gZb+o+gaRgQtJWm0fLZOOaEoPmFvA?= =?us-ascii?Q?geZJgn+1T4TKxWaN5zbyd/9XEHgqyXkpG/jl+theS+dSrlh1/PrRIZrvIyX8?= =?us-ascii?Q?6RbQjdZBj6JLE95+f8sVSpXpxybY1t8V240WbOZApk/FtYIlQzgobM1aqv5z?= =?us-ascii?Q?RBfcRZkMdRuziYVuvWbsSnSUPeYBx849qJLh9Qe3SAkzFzOjZ5Ss+GGbrY5h?= =?us-ascii?Q?Wr3cqsfhmFC/qnNPLVXNf10Zpbs9ZTthnK0b8m25QpDvMmISfPpOkLRF02aS?= =?us-ascii?Q?vjxrA59RC3XG0Bo5xQY5XUtzN1cLg+yWJni+VFLNs+Ufdmxi4q9KgvC/oY3G?= =?us-ascii?Q?UhQo4m3969k9NkvY8rUrVPm/PntsKejnasNWCLyHsQ47gFLeDH5LNP6saZij?= =?us-ascii?Q?AUCwbSr3d37F5jNtU5GCimtT9dP9ZJtRPpagFpXqGpuDNTp49WlqRbp3LGE0?= =?us-ascii?Q?AdT55SNJUAIx/nDIRrv/7oMIwz8F1yrNCdueBy2TssxskFEIfvCJWWe4hShV?= =?us-ascii?Q?pGGI1/DYodI9l8TazSD/rI14G7k8OhKPNwII5NeKm1kfIzzGMU7rWuE0VDHP?= =?us-ascii?Q?KZPEvag+7c7ABuY4YKD1SEd4Bj9uoTjjpshDeiVQnI4hKwI/A9a0O3o/qqIH?= =?us-ascii?Q?A4vVkQs1eGKYqRqt+pTd2UL+tItnn1mGYKPbO92Df2OKzHSNMcEoM7026IBh?= =?us-ascii?Q?dZAxPKw3f0MU/1hVhRJi3TRRhQf2VfAEeH4D3JQdprdPPl8f6T9d0HmsqcP+?= =?us-ascii?Q?O0texzXTmFtUzaITS72TScmkN/BG8SgBdIFnHjzLzw0pcASqLmvO3jFg6Ud/?= =?us-ascii?Q?MOdnorUZxX3LiWs84ljwoAw0y50vXiFvrX7vnId/hDuzaPXhYgRpOTbZ89a9?= =?us-ascii?Q?iqHO9OJHIXudUx8+nYmYuQhSdYaV1XDdy7dcGByYJNwz3dCUwgR0qT8hIP6Q?= =?us-ascii?Q?ER80Pn8HREE5gtHndfl79Y6K/yZ4l97c5acGRhzyrsLl2K+s6CmBrZ/vBkoC?= =?us-ascii?Q?A2HXeuI+HI85dG+X5jtX/BNYUAuR+8IMBnPhng5aY4DK7tsJD30Em1FgtrWb?= =?us-ascii?Q?02QcocTU60V64BFjwCg1rhurr9I68HtKE1JXNzDbAK6cBvKNRIE6XRX1EGx6?= =?us-ascii?Q?D0YdScEB6oMGQDZps2c=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR1701MB1818.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 73a20ad1-b368-4e98-13ab-08d9e4dca671 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 17:10:58.3502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p6af+cMegBLyfqOQ6YQxqQzq9kzeEuQl5zRae/hp6T0eqQ4tf5isdQzYYvvcIgq1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR17MB2120 Archived-At: Subject: Re: [Ecrit] Genart last call review of draft-ietf-ecrit-similar-location-17 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 17:11:10 -0000 I have a couple comments on the suggested changes, inline: >=20 > Section 3 says: >=20 > ... 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. >=20 > Can this be turned into a simple MUST statement? Perhaps: >=20 > ... A server MUST include only Returned Location > Information using a location profile that was used by the > client in the request. I would prefer to avoid this simplification. Although I think the meaning = is intended to be the same, it is actually not. The query can contain mult= iple locations in different profiles (but that derive from the same baselin= e profile), so the first restriction given is more restrictive than the sec= ond, which only follows as a consequence of the first. The suggested text = eliminates the more important restriction. This could be fixed simply enou= gh, however I also wish to avoid any chance that someone could interpret it= wrongly. I've spent too much time arguing with people over the precise me= aning of language in other specifications, and I believe the current langua= ge provides less opportunity for that. My preference is to keep the original text. But if we were to change it to= a single MUST statement, I would word it as follows: When a server includes Returned Location Information, that Information MUST= use the same location profile as the location used to answer the query. >=20 > Section 3 says: >=20 > In a LoST indicating a Valid Location i.e., > containing the element with no elements listed > as invalid, the LoST server can use this extension to include > additional location information in a element. >=20 > I think this would be more clear if it defined a Valid Location, and then= use > this definition: >=20 > A Valid Location contains a element without any > elements listed as invalid. In a LoST > indicating a Valid Location, the LoST server can use this extension > to include additional location information in a > element. >=20 I'm not opposed to the idea of defining Valid Location, but we already do t= hat in section 2. This description is also in error - the location itself = does not contain a element; the response does. If any= thing, we could refer the reader back to section 2, or even omit the explan= ation entirely: In a LoST indicating a Valid Location, the LoST server can use this extension to include additional location information in a element. But I do think the reminder of what indicates a Valid Location is useful he= re, so I slightly prefer the original text. Dan Banks From nobody Mon Jan 31 14:59:21 2022 Return-Path: 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 B03AD3A1BB0; Mon, 31 Jan 2022 14:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, 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 ocLMl-K3Gu7C; Mon, 31 Jan 2022 14:59:13 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7273C3A1BB1; Mon, 31 Jan 2022 14:59:13 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 31 Jan 2022 14:59:12 -0800 From: "Randall Gellens" To: "Russ Housley" Cc: gen-art@ietf.org, draft-ietf-ecrit-similar-location.all@ietf.org, ecrit@ietf.org, last-call@ietf.org Date: Mon, 31 Jan 2022 14:59:12 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <164350445633.30531.10572441517907261963@ietfa.amsl.com> References: <164350445633.30531.10572441517907261963@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Ecrit] Genart last call review of draft-ietf-ecrit-similar-location-17 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 22:59:19 -0000 (1) I'm fine with the Abstract as it is, I don't think it needs to be shortened, but if Russ' suggestion is taken, I'd want his new text "This extension is applicable when the location information in the request uses the Basic Civic profile as described in RFC 5222" deleted, as the extension can potentially be used with future profiles. (2) Regarding the suggestion to either delete the final paragraph of Section 1 or expand it to list all the sections, an alternative is to edit it down to list only what's most useful to a reader, e.g., change: The structure of this document includes terminology, Section 2, followed by a discussion of the basic elements involved in location validation. The use of these elements, by way of example, is discussed in an overview section, Section 3, with accompanying rationale, and a brief discussion of the impacts to LoST, and its current schema. To something such as: A discussion of the basic elements involved in location validation, along with definitions of certain terms used in this document, is in Section 2. Usage, with examples, accompanying rationale, and a brief discussion of the impacts to LoST and its current schema, is in Section 3. (3) Regarding the MUST NOT text in Section 3, I'm fine with Dan's suggestions, but if we are rewording it, I suggest: The location profile of Location Information returned by a server MUST be the same as the profile of the location used to answer the query. By extension, this means that the profile of Location Information returned by a server MUST be a location profile used by the client in the request. (4) Regarding the suggestion to add a definition of Valid Location, the document currently defines it; perhaps the suggestion is to define a new term such as "Valid Location Response" or "Valid Location Indication"? At any rate, since the document already defines Valid Location, we can just delete the explanatory: i.e., containing the element with no elements listed as invalid, This also aligns with Dan's suggested rewording. I'm also fine with leaving the text as is. --Randall On 29 Jan 2022, at 17:00, Russ Housley via Datatracker wrote: > Reviewer: Russ Housley > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > . > > Document: draft-ietf-ecrit-similar-location-17 > Reviewer: Russ Housley > Review Date: 2022-01-29 > IETF LC End Date: 2022-02-09 > IESG Telechat date: unknown > > Summary: Almost Ready > > > Major Concerns: None > > > Minor Concerns: > > The Abstract could be much shorter. I suggest: > > This document describes an extension to the LoST protocol that is > specified in RFC 5222 that allows additional civic location > information to be returned in the element of a > . This extension supports two use cases. > First, > when the input location is incomplete, the LoST server can provide > a > complete intended unique address. Second, when the input location > is > invalid, the LoST server can identify one or more feasible > locations. > This extension is applicable when the location information in the > request uses the Basic Civic profile as described in > RFC 5222. > > Section 1 says: > > ... Use of this > enhancement increases the likelihood that the correct and/or > complete > form of a civic location becomes known in those cases where it is > incomplete or incorrect. > > I think it would be more clear to turn the sentence around: > > ... When incomplete or incorrect civic location information > is provided, use of this enhancement increases the likelihood > that correct and complete civic location can be learned. > > Section 1 ends with a discussion about what the document contains, but > it is incomplete. Either drop the paragraph, or tell what is coming > in > all of the coming sections. > > Section 3 says: > > ... 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. > > Can this be turned into a simple MUST statement? Perhaps: > > ... A server MUST include only Returned Location > Information using a location profile that was used by the > client in the request. > > Section 3 says: > > In a LoST indicating a Valid Location i.e., > containing the element with no elements listed > as invalid, the LoST server can use this extension to include > additional location information in a element. > > I think this would be more clear if it defined a Valid Location, and > then use this definition: > > A Valid Location contains a element without > any > elements listed as invalid. In a LoST > indicating a Valid Location, the LoST server can use this extension > to include additional location information in a > > element. > > > Nits: > > Section 2: s/here. ./here./ > > Section 2: Some definitions end with a period, but one does not. > Please add the missing period. > > Section 3: s/end-user/end user/ > > Section 3: s/intended by the user/intended by the end user/ > > Section 4: s/defined in RFC5222/defined in [RFC5222]/ > > Section 7: s/new threat/new security concern/