From nobody Tue Nov 23 12:11:36 2021 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 3C1DE3A0476; Tue, 23 Nov 2021 12:11:35 -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.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <163769829517.5901.12618340932825315116@ietfa.amsl.com> Date: Tue, 23 Nov 2021 12:11:35 -0800 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-13.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, 23 Nov 2021 20:11:35 -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-13.txt Pages : 17 Date : 2021-11-23 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-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 26 06:00:06 2021 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 DEB233A0490 for ; Fri, 26 Nov 2021 06:00:04 -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 uSkFQijlzX89 for ; Fri, 26 Nov 2021 06:00:02 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3973A048D for ; Fri, 26 Nov 2021 06:00:02 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 26 Nov 2021 06:00:17 -0800 From: "Randall Gellens" To: "Brian Rosen" , ecrit@ietf.org Date: Fri, 26 Nov 2021 06:00:00 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <65F688E4-5454-4083-87B3-E1E269233E86@randy.pensive.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Ecrit] Editorial issues in similar-location-13 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, 26 Nov 2021 14:00:05 -0000 (1) This wouldn't be worth a revision by itself, but I think we need a rev for item (2) so we may as well fix this also: In Section 3, the sixth paragraph starts "Since [RFC5222] currently does not have a way". The "currently" is awkward since an RFC is immutable. Consider rewording by either dropping the "currently" (making the text "Since [RFC5222] does not have a way") or changing "[RFC5222]" to "LoST" (making the text "Since LoST currently does not have a way"). (2) I think this should be fixed before we go to IETF Last Call: There are a few examples in Section 3 that were the focus of emails from several people requesting a comma before the city name. These examples have been changed to use a fictitious city but is still lack the comma. I think these should be fixed before IETF LC since this is a point of confusion. The text in question: Input address: 6000 15th Avenue Leets, WA US Complete Location: 6000 15th Avenue Northwest Leets, WA 98105 US ... Input address: 6000 15th Avenue North Leets, WA US ... Similar address #1: 6000 15th Avenue Northwest Leets, WA 98107 US Similar address #2: 6000 15th Avenue Northeast Leets, WA 98105 US These should all have a comma inserted before "Leets". (3) Since I think we have to fix (2), we may as well fix this also: In the 7th line of the paragraph with first line: As another example of the use of , consider the There is a missing space after a comma in the 13th paragraph of Section 3: have resulted in a uniquely identifiable location,the server can (4) Same as item (1), the "[RFC5222] currently" wording appears in the 10th line of the paragraph starting: As another example of the use of , consider the (5) The 14th paragraph of Section 3 is: To show this, suppose that a slightly modified version of the above address is sent within a Lost : Please move the close angle bracket to be after "findService" rather than "request". --Randall From nobody Mon Nov 29 10:41:13 2021 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 DC3E23A0659 for ; Mon, 29 Nov 2021 10:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 HMNDS6dMhRMZ for ; Mon, 29 Nov 2021 10:41:06 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 87FC53A064E for ; Mon, 29 Nov 2021 10:41:06 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id j21so18486011ila.5 for ; Mon, 29 Nov 2021 10:41:06 -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=5XFpDfEQpTOYLBtIzMx0Hxwlc6Gexu+oICyEhSrl7w0=; b=F8Txxeywk90BELScEwvdw0q1dK20QUmFa9b5xHSdY/ZvMNnokZXK7LW719iF10AJow wujo2+VY46HhAgOl71gNjuFX1VceKm4XeUgaWrAbQushipk85+KMU2nOij0+hazYFv5I 2ZxlRhj7S3OF3aTKVgiqAvwoKkkUaxe+Z25FCbKyQ14bxesWEzDrSnp4dKzI5LxN7qPp ReIPXgfSySsSjcq/lBkSGGeHzrL7e97c+qVIYs4tUWXSEihNKhfHCOSDzp53/pmQIk7a KOQzPH71BNZArFxVwfA3NpNZP+xq6MFmXE/1F0Ys5bULelWk0Q3xVqxF6jdb8y9v8orH Doaw== 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=5XFpDfEQpTOYLBtIzMx0Hxwlc6Gexu+oICyEhSrl7w0=; b=K5L4PdjOFEdJ88CA4V0kh5iAXPFS9axKg+4JPoUaGT3IZ8USaOaGdD5U6gy3IJsAEw 1WxRSXAMBtTObaVquWTOx0GVaPWSz+uqnYRUUf7ro/RM1bDczUzJlQMxMa+rSsK4teE6 rOFXojykyGGwSgatY1ncpVxyAEaUZGunDdynbLHUS9iFw5Cen84VuG+Ij/y4bJVsNnqY 6Q1snzyIYH/Pc8QSr1G8joFyJTbEYafdNDiqK3aze75c+Lta1p2kotVmQzWyoEtZjVIP /erMoBsdmwWJ79e0HN7DBQqzSQS4tX+VM4cgZVmV5Cepf0iCM4ZsA3s0ClqOmGxaC4xW NMMQ== X-Gm-Message-State: AOAM532gtVoi47YkmSvqipG4mVut+LOsy+xhydIl6Dv72wzE3Wdlhg9x BTxkprzJ//vYWBQUxgKRrPRo153jek/FlOlF X-Google-Smtp-Source: ABdhPJyx04QYG9fFcNT17IzJNRJZenRmvP//6dc5ZXYeaIuELpynzR+eS3P1arYMN1EKduFt/TU92g== X-Received: by 2002:a05:6e02:1706:: with SMTP id u6mr49972178ill.300.1638211264067; Mon, 29 Nov 2021 10:41:04 -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 l12sm10247991iow.23.2021.11.29.10.41.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Nov 2021 10:41:03 -0800 (PST) From: Brian Rosen Message-Id: <86BA5CEC-C852-473C-A9A0-DAC70CE42C8D@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B82F5967-4587-4B0C-A124-222794401764" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Mon, 29 Nov 2021 13:41:01 -0500 In-Reply-To: <65F688E4-5454-4083-87B3-E1E269233E86@randy.pensive.org> Cc: ecrit@ietf.org To: Randall Gellens References: <65F688E4-5454-4083-87B3-E1E269233E86@randy.pensive.org> X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Ecrit] Editorial issues in similar-location-13 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, 29 Nov 2021 18:41:12 -0000 --Apple-Mail=_B82F5967-4587-4B0C-A124-222794401764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I thought I had addressed the =E2=80=9Ccomma=E2=80=9D problem in v13. = Turns out there is some kind of tooling problem: the xml2rfc on = tools.ietf.org is different from the one used = in submission, and there is a bug, or at least some confusion, on the = submission version. I created a -14 that fixes it. I did the other fixes also. Brian > On Nov 26, 2021, at 9:00 AM, Randall Gellens = wrote: >=20 > (1) This wouldn't be worth a revision by itself, but I think we need a = rev for item (2) so we may as well fix this also: In Section 3, the = sixth paragraph starts "Since [RFC5222] currently does not have a way". = The "currently" is awkward since an RFC is immutable. Consider rewording = by either dropping the "currently" (making the text "Since [RFC5222] = does not have a way") or changing "[RFC5222]" to "LoST" (making the text = "Since LoST currently does not have a way"). >=20 > (2) I think this should be fixed before we go to IETF Last Call: There = are a few examples in Section 3 that were the focus of emails from = several people requesting a comma before the city name. These examples = have been changed to use a fictitious city but is still lack the comma. = I think these should be fixed before IETF LC since this is a point of = confusion. The text in question: >=20 > Input address: 6000 15th Avenue Leets, WA US >=20 > Complete Location: 6000 15th Avenue Northwest Leets, WA 98105 US >=20 > ... >=20 > Input address: 6000 15th Avenue North Leets, WA US >=20 > ... >=20 > Similar address #1: 6000 15th Avenue Northwest Leets, WA 98107 US >=20 > Similar address #2: 6000 15th Avenue Northeast Leets, WA 98105 US >=20 > These should all have a comma inserted before "Leets". >=20 >=20 > (3) Since I think we have to fix (2), we may as well fix this also: In = the 7th line of the paragraph with first line: >=20 > As another example of the use of , consider the >=20 > There is a missing space after a comma in the 13th paragraph of = Section 3: >=20 > have resulted in a uniquely identifiable location,the server can >=20 > (4) Same as item (1), the "[RFC5222] currently" wording appears in the = 10th line of the paragraph starting: >=20 > As another example of the use of , consider the >=20 > (5) The 14th paragraph of Section 3 is: >=20 > To show this, suppose that a slightly modified version of the above > address is sent within a Lost : >=20 > Please move the close angle bracket to be after "findService" rather = than "request". >=20 >=20 > --Randall --Apple-Mail=_B82F5967-4587-4B0C-A124-222794401764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = thought I had addressed the =E2=80=9Ccomma=E2=80=9D problem in v13. =  Turns out there is some kind of tooling problem: the xml2rfc on tools.ietf.org is = different from the one used in submission, and there is a bug, or at = least some confusion, on the submission version.  I created a -14 = that fixes it.

I did = the other fixes also.

Brian


On Nov = 26, 2021, at 9:00 AM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

(1) = This wouldn't be worth a revision by itself, but I think we need a rev = for item (2) so we may as well fix this also: In Section 3, the sixth = paragraph starts "Since [RFC5222] currently does not have a way". The = "currently" is awkward since an RFC is immutable. Consider rewording by = either dropping the "currently" (making the text "Since [RFC5222] does = not have a way") or changing "[RFC5222]" to "LoST" (making the text = "Since LoST currently does not have a way").

(2) I think this should be fixed before we go to IETF Last = Call: There are a few examples in Section 3 that were the focus of = emails from several people requesting a comma before the city name. = These examples have been changed to use a fictitious city but is still = lack the comma. I think these should be fixed before IETF LC since this = is a point of confusion. The text in question:

  Input address: 6000 15th Avenue Leets, WA US

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

...

  Input address: 6000 15th Avenue = North Leets, WA US

...

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

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

These should all have a comma inserted before = "Leets".


(3) Since I think = we have to fix (2), we may as well fix this also: In the 7th line of the = paragraph with first line:

  As = another example of the use of <similarLocation>, consider the

There is a  missing space after a comma = in the 13th paragraph of Section 3:

=   have resulted in a uniquely identifiable location,the server = can

(4) Same as item (1), the "[RFC5222] = currently" wording appears in the 10th line of the paragraph = starting:

  As another example = of the use of <similarLocation>, consider the

(5) The 14th paragraph of Section 3 is:

  To show this, suppose that a slightly modified = version of the above
  address is sent within a = Lost <findService request>:

Please = move the close angle bracket to be after "findService" rather than = "request".


--Randall

= --Apple-Mail=_B82F5967-4587-4B0C-A124-222794401764-- From nobody Mon Nov 29 10:57:19 2021 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 0B3803A0781; Mon, 29 Nov 2021 10:57:02 -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.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <163821222190.27313.17395475038405297463@ietfa.amsl.com> Date: Mon, 29 Nov 2021 10:57:01 -0800 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-14.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: Mon, 29 Nov 2021 18:57:02 -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-14.txt Pages : 18 Date : 2021-11-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 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-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 29 14:11:27 2021 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 DC1DD3A0A92 for ; Mon, 29 Nov 2021 14:11:24 -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, HTML_MESSAGE=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 mBgRFTMOW2ty for ; Mon, 29 Nov 2021 14:11:20 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 818E23A0A81 for ; Mon, 29 Nov 2021 14:11:20 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 29 Nov 2021 14:11:39 -0800 From: "Randall Gellens" To: "Brian Rosen" Cc: ecrit@ietf.org Date: Mon, 29 Nov 2021 14:11:19 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <86BA5CEC-C852-473C-A9A0-DAC70CE42C8D@brianrosen.net> References: <65F688E4-5454-4083-87B3-E1E269233E86@randy.pensive.org> <86BA5CEC-C852-473C-A9A0-DAC70CE42C8D@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_04F1F264-1332-4793-A59F-876A64F4B50B_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[521, 3646], "plain":[173, 2558], "uuid":"E1E4A798-77CC-411D-9846-1B902DEBC1BF"}] Archived-At: Subject: Re: [Ecrit] Editorial issues in similar-location-13 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, 29 Nov 2021 22:11:25 -0000 --=_MailMate_04F1F264-1332-4793-A59F-876A64F4B50B_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I've checked -14 and confirmed it looks good. Thank you for fixing it. Just out of curiosity, what was the bug? --Randall On 29 Nov 2021, at 10:41, Brian Rosen wrote: > I thought I had addressed the “comma” problem in v13. Turns out > there is some kind of tooling problem: the xml2rfc on tools.ietf.org > is different from the one used in submission, > and there is a bug, or at least some confusion, on the submission > version. I created a -14 that fixes it. > > I did the other fixes also. > > Brian > > >> On Nov 26, 2021, at 9:00 AM, Randall Gellens >> wrote: >> >> (1) This wouldn't be worth a revision by itself, but I think we need >> a rev for item (2) so we may as well fix this also: In Section 3, the >> sixth paragraph starts "Since [RFC5222] currently does not have a >> way". The "currently" is awkward since an RFC is immutable. Consider >> rewording by either dropping the "currently" (making the text "Since >> [RFC5222] does not have a way") or changing "[RFC5222]" to "LoST" >> (making the text "Since LoST currently does not have a way"). >> >> (2) I think this should be fixed before we go to IETF Last Call: >> There are a few examples in Section 3 that were the focus of emails >> from several people requesting a comma before the city name. These >> examples have been changed to use a fictitious city but is still lack >> the comma. I think these should be fixed before IETF LC since this is >> a point of confusion. The text in question: >> >> Input address: 6000 15th Avenue Leets, WA US >> >> Complete Location: 6000 15th Avenue Northwest Leets, WA 98105 US >> >> ... >> >> Input address: 6000 15th Avenue North Leets, WA US >> >> ... >> >> Similar address #1: 6000 15th Avenue Northwest Leets, WA 98107 US >> >> Similar address #2: 6000 15th Avenue Northeast Leets, WA 98105 US >> >> These should all have a comma inserted before "Leets". >> >> >> (3) Since I think we have to fix (2), we may as well fix this also: >> In the 7th line of the paragraph with first line: >> >> As another example of the use of , consider the >> >> There is a missing space after a comma in the 13th paragraph of >> Section 3: >> >> have resulted in a uniquely identifiable location,the server can >> >> (4) Same as item (1), the "[RFC5222] currently" wording appears in >> the 10th line of the paragraph starting: >> >> As another example of the use of , consider the >> >> (5) The 14th paragraph of Section 3 is: >> >> To show this, suppose that a slightly modified version of the above >> address is sent within a Lost : >> >> Please move the close angle bracket to be after "findService" rather >> than "request". >> >> >> --Randall --=_MailMate_04F1F264-1332-4793-A59F-876A64F4B50B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I've checked -14 and confirmed it looks good. Thank you fo= r fixing it.

Just out of curiosity, what was the bug?

--Randall

On 29 Nov 2021, at 10:41, Brian Rosen wrote:

I thought I had addressed the =E2=80=9Ccom= ma=E2=80=9D problem in v13.  Turns out there is some kind of tooling= problem: the xml2rfc on too= ls.ietf.org is different from the one used in submission, and th= ere is a bug, or at least some confusion, on the submission version. &nbs= p;I created a -14 that fixes it.

I did the other fixes also.

Brian

<= br class=3D"">
On Nov= 26, 2021, at 9:00 AM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
<= br class=3D"Apple-interchange-newline">
(1= ) This wouldn't be worth a revision by itself, but I think we need a rev = for item (2) so we may as well fix this also: In Section 3, the sixth par= agraph starts "Since [RFC5222] currently does not have a way". The "curre= ntly" is awkward since an RFC is immutable. Consider rewording by either = dropping the "currently" (making the text "Since [RFC5222] does not have = a way") or changing "[RFC5222]" to "LoST" (making the text "Since LoST cu= rrently does not have a way").

(2) I think t= his should be fixed before we go to IETF Last Call: There are a few examp= les in Section 3 that were the focus of emails from several people reques= ting a comma before the city name. These examples have been changed to us= e a fictitious city but is still lack the comma. I think these should be = fixed before IETF LC since this is a point of confusion. The text in ques= tion:

  Input address: 6000 15th = Avenue Leets, WA US

  Complete Lo= cation: 6000 15th Avenue Northwest Leets, WA 98105 US

...

  Input address: 60= 00 15th Avenue North Leets, WA US

...

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

  Si= milar address #2: 6000 15th Avenue Northeast Leets, WA 98105 US

These should all have a comma inserted before "Leets".<= br class=3D"">

(3) Since I think we have to = fix (2), we may as well fix this also: In the 7th line of the paragraph w= ith first line:

  As another exam= ple of the use of <similarLocation>, consider the
There is a  missing space after a comma in the 13th para= graph of Section 3:

  have result= ed in a uniquely identifiable location,the server can

(4) Same as item (1), the "[RFC5222] currently" wording appears= in the 10th line of the paragraph starting:

  As another example of the use of <similarLocation>, c= onsider the

(5) The 14th paragraph of Sectio= n 3 is:

  To show this, suppose t= hat a slightly modified version of the above
  a= ddress is sent within a Lost <findService request>:
<= br class=3D"">Please move the close angle bracket to be after "findServic= e" rather than "request".


--R= andall

=
--=_MailMate_04F1F264-1332-4793-A59F-876A64F4B50B_=--