Re: [netmod] Last Call: <draft-ietf-netmod-artwork-folding-07.txt> (Handling Long Lines in Inclusions in Internet-Drafts and RFCs) to Best Current Practice

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 02 August 2019 00:09 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8B2120073; Thu, 1 Aug 2019 17:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 v70qfCHEGCfR; Thu, 1 Aug 2019 17:08:59 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 3F54912001A; Thu, 1 Aug 2019 17:08:59 -0700 (PDT)
Received: from MacBook-Pro.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x7208tXx010115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Aug 2019 20:08:56 -0400
To: Kent Watsen <kent@watsen.net>
Cc: IETF discussion list <ietf@ietf.org>, Ignas Bagdonas <ibagdona@gmail.com>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, "netmod@ietf.org" <netmod@ietf.org>
References: <156451937390.14101.5438428659513611953.idtracker@ietfa.amsl.com> <1e399e65-4cc9-1e46-018f-5d6427e953c9@alum.mit.edu> <0100016c498d2a40-f6b9bf13-15c9-4d20-9be2-bea7147d60e5-000000@email.amazonses.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <53836925-6f9a-0c04-28fd-4471328db345@alum.mit.edu>
Date: Thu, 1 Aug 2019 20:08:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <0100016c498d2a40-f6b9bf13-15c9-4d20-9be2-bea7147d60e5-000000@email.amazonses.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wAGqrS0Y5IzNCkKpLOT54rgFJN4>
Subject: Re: [netmod] Last Call: <draft-ietf-netmod-artwork-folding-07.txt> (Handling Long Lines in Inclusions in Internet-Drafts and RFCs) to Best Current Practice
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2019 00:09:01 -0000

Kent,

On 7/31/19 3:41 PM, Kent Watsen wrote:
> Hi Paul,
> 
> Thanks for your comments!
> 
> 
>> 1) Section 6.2 recommends only using double backslash folding if 
>> single backslash folding doesn't work. But all the examples in section 
>> 9 violate this.
> 
> True, but these example illustrate the algorithm itself, and so seem 
> okay, or is your suggestion to add text stating this?

My suggestion is to use an example that would force the use of double 
backslash folding. This would mean that the the examples wouldn't be for 
the same text, but I don't think that is a problem. This would allow you 
to show the various forms that force use of double backslash folding.

> FWIW, the `rfcfold` script in the appendix of the draft was used on all 
> the examples in Section 9.  By default, the `rfcfold` script follows the 
> recommendation (i.e., single before double), but also accepts a 
> command-line option to specify the folding strategy to use.  For the 
> examples in section 9, this command-line option  was used.
> 
> 
>> 2) Regarding forced folding in section 8.2.1: step 1 (Determine where 
>> the fold will occur) could benefit from some elaboration regarding 
>> lines that require forced folding. In particular, when an input line 
>> flagged for forced folding ends in backslash, then it must indeed be 
>> folded before the last character, while in all other cases it can be 
>> folded at any position prior to the max line length. (While this is 
>> obvious if you think about it, some might miss this.)
> 
> Your comment goes to step 1, are you suggesting a modification such as 
> the following?
> 
> OLD
>      1. Determine where the fold will occur. This location MUST be 
> before or at the desired maximum column.
> 
> NEW
>      1. Determine where the fold will occur. This location MUST be 
> before or at the desired maximum column.  In the case of a forced 
> folding, the location MUST be before or at the end of the line.

Not quite. I think:

      1. Determine where the fold will occur. This location MUST be 
before or at the desired maximum column.  This (of course) MUST be prior 
to the last character on the line. In the case of a forced folding, this 
may precede the desired maximum column.

(Or do you want to allow the degenerate case where the line is folded at 
the end, so the continuation contains nothing?)

>> Also, there should be examples of forced folding.
> 
> Agreed.

If forced folding example(s) are *added* then I think it is fine to 
retain the existing example done both ways.

	Thanks,
	Paul