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

[tom petch <[e-mail]>]

----- Original Message -----
From: "Bob Harold" <[e-mail]>
Sent: Wednesday, September 19, 2018 8:12 PM
On Tue, Sep 18, 2018 at 6:01 AM Adrian Farrel 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
> >
> > ----- 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".

<tp>

Bob

My experience of tabs is different, which is why I think that Adrian has
it right when he says
....say "tabs in artwork are evil" and move on.

All the text processors I can recall had a default of tab meaning 5
spaces, never 2 or 4 or 8.  And the prime use of tabs has been to
achieve vertical alignment in artwork, tables and such like, where the
tab settings might be
10 23 49 68
allowing a suitable amount of space for the different fields of the
table.  (I see this usage going beyond text processing).

So, banish tabs; require the submitter to turn them into whatever they
mean by them first.

Tom Petch







--
Bob Harold