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

Erik Auerswald <auerswal@unix-ag.uni-kl.de> Fri, 02 August 2019 13:22 UTC

Return-Path: <auerswal@unix-ag.uni-kl.de>
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 B0EA31200EF; Fri, 2 Aug 2019 06:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 Yy749Exs2evt; Fri, 2 Aug 2019 06:22:24 -0700 (PDT)
Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 CCE1312008C; Fri, 2 Aug 2019 06:22:23 -0700 (PDT)
Received: from [172.20.10.2] (x2e7205cf.dyn.telefonica.de [46.114.5.207] (may be forged)) (authenticated bits=0) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x72DM6ax037417 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 2 Aug 2019 15:22:16 +0200
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Kent Watsen <kent@watsen.net>
Cc: Ignas Bagdonas <ibagdona@gmail.com>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, draft-ietf-netmod-artwork-folding@ietf.org, IETF discussion list <ietf@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> <53836925-6f9a-0c04-28fd-4471328db345@alum.mit.edu>
From: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
Message-ID: <99a7009d-7ec4-f4b1-c157-961f2566a6ad@unix-ag.uni-kl.de>
Date: Fri, 2 Aug 2019 15:22:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <53836925-6f9a-0c04-28fd-4471328db345@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/qICQhgifOYfGLe5rwsm3SZaRM9U>
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 13:22:28 -0000

Hi Paul,

I'll try to elaborate on my understanding of "forced folding" below:

On 02.08.19 02:08, Paul Kyzivat wrote:
> On 7/31/19 3:41 PM, Kent Watsen wrote:
>> [...]
>>> 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.)

If the original text data contains the folding sequence, one line of
that text data ends in a backslash. If such a line is folded before
the backslash, the folded data still contains the folding sequence that
came from the original text data (in addition to the folding sequences
inserted by folding).

As I see it, forced folding would insert a new folding sequence inside
of the original folding sequence.

Example before folding:

foo\
   \bar

Example after folding:

== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ==

foo\\
\
   \bar

A line that requires forced folding and that is already of maximum
length would be lengthened by forced folding, thus it would need to
be folded twice.

This, of course, shows that unfolding must not recursively try to
unfold an already unfolded part of a line again.

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

I'd say that this degenerate case is required for forced folding to
work.

Thanks,
Erik