Re: [rfc-i] I-D Action: draft-rpc-rfc7322bis-00.txt

Jean Mahoney <jmahoney@amsl.com> Fri, 05 May 2023 22:17 UTC

Return-Path: <jmahoney@amsl.com>
X-Original-To: rfc-interest@ietfa.amsl.com
Delivered-To: rfc-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C475C14CEFE for <rfc-interest@ietfa.amsl.com>; Fri, 5 May 2023 15:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAwsk6hhV8_g for <rfc-interest@ietfa.amsl.com>; Fri, 5 May 2023 15:17:20 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C883CC152DAD for <rfc-interest@rfc-editor.org>; Fri, 5 May 2023 15:17:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id BA538424CD3E; Fri, 5 May 2023 15:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xp19nCpi6lL; Fri, 5 May 2023 15:17:20 -0700 (PDT)
Received: from [192.168.1.203] (unknown [47.186.48.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 8CA48424CD3C; Fri, 5 May 2023 15:17:20 -0700 (PDT)
Message-ID: <0b7d320f-55ad-321a-9a9a-5d8c9151ba14@amsl.com>
Date: Fri, 05 May 2023 17:17:19 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1
Content-Language: en-US
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, RFC Interest <rfc-interest@rfc-editor.org>
References: <168298351605.49415.8898708942774388283@ietfa.amsl.com> <03b8e483-e737-d97c-ceb2-2d326e0609b3@gmail.com> <a277f053-66f0-c1fa-fc99-42b9441e250c@nostrum.com> <8786e042-0a8f-1d88-30ca-e386160ffa27@amsl.com> <98a4178a-a4e9-46f9-0497-7a75578ff788@gmail.com>
From: Jean Mahoney <jmahoney@amsl.com>
In-Reply-To: <98a4178a-a4e9-46f9-0497-7a75578ff788@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-interest/ubLrHz5VuMco3Ts3Ro42uy9qzcA>
Subject: Re: [rfc-i] I-D Action: draft-rpc-rfc7322bis-00.txt
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2023 22:17:24 -0000

Hi Brian,

Thanks for your feedback! Comments below --

On 5/4/23 6:05 PM, Brian E Carpenter wrote:
> On 05-May-23 03:16, Jean Mahoney wrote:
>> Hi all,
>>
>> The I-D draft-rpc-rfc7322bis replaces draft-flanagan-7322bis. 
>
> Thanks Jean. I had a look at the diffs since RFC7322 itself and
> most of them seem fine to me. Some quibbles, however:
>
>> Angle brackets are strongly recommended around URIs [STD66], e.g.,
>>
>> <https://example.com/>
>
> I understand the need for a delimiter, but I have a use case where
> the intent is to refer to a URI as a string, so "https://example.com/"
> is much more appropriate. 
[JM] Gotcha

> Could that be:
>
>   Delimiters such as angle brackets are strongly recommended...
>
> As a matter of fact, STD66 says this:
>
>    In practice, URIs are delimited in a variety of ways, but usually
>    within double-quotes "http://example.com/", angle brackets
>    <http://example.com/>, or just by using whitespace:
>       http://example.com/
>
> so double quotes are just as "legal" as angle brackets.
[JM] Some clarification can be added to this section, which shouldn't be 
interpreted as guidance for the formatting of URIs when discussing their 
uses in a protocol.  This guidance applies more to the creation of 
hyperlinks, and we would like to have a consistent look for those. The 
RFCXML <eref> element, which creates hyperlinks in the HTML and PDF 
outputs, has a brackets attribute that supports the values "angle" and 
"none" (see <https://authors.ietf.org/en/rfcxml-vocabulary#eref>).


>
>> The use of HTTPS rather than HTTP is strongly encouraged.
>
> I'm not sure that is an editorial or style issue. Also, it should
> never lead to an editorial change, only to a query, since there
> may be cases where HTTP is intended. Again, I have a use case in
> a current draft.
[JM]  The guidance on the use of HTTPS is for the construction of 
hyperlinks. Perhaps this guidance can move to the Security 
Considerations section -- "The use of HTTPS when constructing hyperlinks 
is strongly recommended to protect readers when they access those links 
via a web browser."

I can definitely see valid cases for discussing HTTP URIs in the text, 
and those shouldn't be modified.

I've created an issue: 
<https://github.com/rfc-editor/draft-rpc-rfc7322bis/issues/26>

>
>> 7.  A citation may A) follow the subject to which the citation
>> applies or B) be read as part of the text.  For example:
>>
>>  a.  As part of the transition to IPv6, NAT64 [RFC6146] and DNS64
>>      [RFC6147] technologies will be utilized by some access
>>      networks to provide IPv4 connectivity for IPv6-only nodes
>>      [RFC6144].
>>
>>  b.  Note that SAVI raises a number of important privacy
>>      considerations that are discussed more fully in [RFC6959].
>>
>> 8.  For a document referenced multiple times in running text, the
>>     citation anchor must be at first use outside the abstract.
>>     Additional citations are allowed at the author's discretion.
>>
>> We recommend using A) and strongly recommend consistent use of one
>> style throughout.
>
> A nit here is that the "We recommend" sentence should surely be part
> of item 7, not after item 8. 
[JM] Ack, we will move the text.


> More substantively, I don't agree with
> the *strong* recommendation for consistency. 
[JM] If an author uses both styles, we don't make updates to make the 
style consistent, so perhaps we're not as insistent on consistency as 
the guidance indicates.

> I agree that A) is generally
> better practice, but in a long document, cases where B) leads to more
> readable text can occur. Something like:
>
>   We recommend using A) in most cases, and limiting B) to cases where
>   it enhances readability.
[JM]  Note that the example for style A) isn't great because the 
placement of the cite tags disrupts the flow, and we will be replacing 
it with something like the following: "This document defines a YANG data 
model [RFC7950] that can be used to configure and manage Network Time 
Protocol version 4 [RFC5905]."

The issue with style B) (citation as part of the text) is that it can 
lead to poor constructions, like RFCs as compounds (covered in Section 
3.2.1) or possessive citations (e.g., "[RFC3107]'s procedures for 
withdrawing the binding …"), which is why style A) is recommended.

The RPC will take a look at rewording the statement. I've opened 
<https://github.com/rfc-editor/draft-rpc-rfc7322bis/issues/27>

Best regards,
Jean



>
> Regards,
>    Brian
>
>
>
>
>
>
>
>
>