Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

[Bob Harold <[e-mail]>]

On Tue, Sep 18, 2018 at 6:01 AM Adrian Farrel <[e-mail]> wrote:

> Yeah :-Z
>
> So my inclination is to say "tabs in artwork are evil" and move on.
> Some folk like to use them when constructing text, but my suggestion is
> that they convert to spaces/LF before posting drafts.
>
> If anyone wants to write another document tabs in json then, erm, knock
> yourselves out. But I would prefer to just exclude them from folding at
> this time.
>
> Cheers,
> Adrian
>
> > -----Original Message-----
> > From: netmod [mailto:[e-mail]] On Behalf Of tom petch
> > Sent: 18 September 2018 10:54
> > To: Carsten Bormann; Robert Wilton
> > Cc: [e-mail]
> > Subject: Re: [netmod] New Version Notification for draft-kwatsen-netmod-
> > artwork-folding-07.txt
> >
> > ----- Original Message -----
> > From: "Carsten Bormann" <[e-mail]>
> > Sent: Friday, September 14, 2018 12:14 PM
> >
> > > On Sep 14, 2018, at 13:05, Robert Wilton
> > <rwilton=[e-mail]> wrote:
> > > >
> > > > If all input files that we might ever want to fold and include in an
> > RFC are guaranteed to never contain tabs then I agree with the position
> > that they can just be rejected.
> > >
> > > Yep.
> > >
> > > > But if there is some future file format that we want to fold that
> > might contain tabs, then I wonder whether it would not be more robust to
> > look at whether they could be handled in some way.
> > >
> > > VT characters (colloquially tabs) should not be significant in any
> > file format designed in the last couple of decades (i.e., they should be
> > replaceable by spaces).  If they (or any other characters not
> > representable in RFCs) are, or preserving byte wise identity is
> > important, follow the lead of RFC 6716 and base64-encode.
> >
> > This confuses me.  This I-D references RFC7991 which clearly defines tab
> > as  9, which RFC20 labels H(orizontal) T(ab).  V(ertical) T(ab) is 11.
> >
> > I would not expect VT to appear in any recent document but when it does,
> > then replacing it by spaces would be wrong, IMHO.  HT I do see, far too
> > much of, because there is no metadata saying what the Horizontal Tab
> > settings should be and while a  value of five is common, there are RFC
> > where replacing tab characters with five spaces yields rubbish.
> >
> > Tom Petch
> >
> > > Grüße, Carsten
>
>
The purpose of folding is to get all lines under a certain max width.  Tabs
were historically set every 8 characters, although terminals and editors
have allowed users to change them.  Changes are typically to reduce them to
4 or 2.  I have not heard of anyone increasing them beyond 8.  So for
purposes of max line length, 8 is the worst case.   Then for folding, count
tabs as filling to the next multiple of 8, (or worst case, assume a full 8)
and fold appropriately.  This should unfold properly.  (Do not attempt to
replace tabs with spaces.)  It won't always be what the author intended,
but it is the best that we can do.  Better and simpler than trying to
enforce "no tabs allowed".

-- 
Bob Harold