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 <[e-mail]>]

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