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 <> Wed, 31 July 2019 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5DAB1203B9; Wed, 31 Jul 2019 08:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GSXpBKx5JvZf; Wed, 31 Jul 2019 08:55:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B7691203A1; Wed, 31 Jul 2019 08:55:53 -0700 (PDT)
Received: from PaulKyzivatsMBP.localdomain ( []) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x6VFtoAQ022531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Jul 2019 11:55:51 -0400
References: <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Wed, 31 Jul 2019 11:55:49 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
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-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jul 2019 15:56:06 -0000

Note: I just noticed this work for the first time, and I don't follow 
netmod. But I find the subject interesting and relevant, so I took a 
look at it. I have a couple of comments/concerns:

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.

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.)

Also, there should be examples of forced folding.


On 7/30/19 4:42 PM, The IESG wrote:
> The IESG has received a request from the Network Modeling WG (netmod) to
> consider the following document: - 'Handling Long Lines in Inclusions in
> Internet-Drafts and RFCs'
>    <draft-ietf-netmod-artwork-folding-07.txt> as Best Current Practice
> 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
> mailing lists by 2019-08-13. Exceptionally, comments may be
> sent to instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> Abstract
>     This document defines two strategies for handling long lines in
>     width-bounded text content.  One strategy is based on the historic
>     use of a single backslash ('\') character to indicate where line-
>     folding has occurred, with the continuation occurring with the first
>     non-space (' ') character on the next line.  The second strategy
>     extends the first strategy by adding a second backslash character to
>     identify where the continuation begins and thereby able to handle
>     cases not supported by the first strategy.  Both strategies use a
>     self-describing header enabling automated reconstitution of the
>     original content.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list