Subject: [Ecrit] Editorial issues in similar-location-13

From: "Randall Gellens" <[email-masked]>
Date: Fri, 26 Nov 2021 06:00:00 -0800

(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

---

From: Brian Rosen <[email-masked]>
Date: Mon, 29 Nov 2021 13:41:01 -0500

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 <http://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 <[email-masked]> 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:
> 
> (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:
> 
> There is a  missing space after a comma in the 13th paragraph of Section 3:
> 
> (4) Same as item (1), the "[RFC5222] currently" wording appears in the 10th line of the paragraph starting:
> 
> Please move the close angle bracket to be after "findService" rather than "request".
> 
> 
> --Randall

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 29 Nov 2021 14:11:19 -0800

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 
> <http://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.
>
>> (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:
>>
>> (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:
>>