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

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Sep 2018 21:59:20 +0000

An update to the "artwork-folding" draft has been posted.
  - the solution is now using the "/.../" format.
  - the included script has been updated as well.

We believe that this draft is ready for an adoption poll.

Kent (and Adrian and Qin)  // authors

-----Original Message-----

A new version of I-D, draft-kwatsen-netmod-artwork-folding-07.txt
has been successfully submitted by Kent Watsen and posted to the
IETF repository.

Name:		draft-kwatsen-netmod-artwork-folding
Revision:	07
Title:		Handling Long Lines in Artwork in Internet-Drafts and RFCs
Document date:	2018-09-05
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.org/id/draft-kwatsen-netmod-artwork-folding-07.txt
Status:         https://datatracker.ietf.org/doc/draft-kwatsen-netmod-artwork-folding/
Htmlized:       https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-07
Htmlized:       https://datatracker.ietf.org/doc/html/draft-kwatsen-netmod-artwork-folding
Diff:           https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-artwork-folding-07

Abstract:
   This document introduces a simple and yet time-proven strategy for
   handling long lines in artwork in drafts using a backslash ('\')
   character where line-folding has occurred.  The strategy works on any
   text based artwork, but is primarily intended for sample text and
   formatted examples and code, rather than for graphical artwork.  The
   approach produces consistent results regardless of the content and
   uses a per-artwork header.  The strategy is both self-documenting and
   enables automated reconstitution of the original artwork.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 8 Sep 2018 13:39:57 +0100

Speaking as a co-author, I agree with Kent that this version is ready for the WG
to pick up.

I think that discussions at f2f meetings indicated that there was interest in
the WG in addressing this issue, and after much back and forth, the authors have
come together with an approach that they agree on and it incorporates some
suggestions made in Montreal.

Thanks,
Adrian

> From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: 07 September 2018 22:59
> To: [email-masked]
> Subject: [netmod] FW: New Version Notification for draft-kwatsen-netmod-
> artwork-folding-07.txt
> 
> 
> Htmlized:
https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-
> 07
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-artwork-
> folding-07
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Robert Wilton <[email-masked]>
Date: Mon, 10 Sep 2018 08:51:03 +0100

I've read -07, and would also support an WG adoption call for this 
draft.  In fact, I think that it would be quite good if we can move this 
document through to WG LC fairly expediently as well.

A couple of minor review comments:

Introduction: RFC7994 reference listed twice.

Rather than banning tabs, another option would to be convert them (of 
course, the question is then whether a tab is 2, 4, or 8 spaces ...), 
although assuming 4 spaces seems reasonable, and could be controlled via 
an input parameter.

Thanks,
Rob

On 08/09/2018 13:39, Adrian Farrel wrote:
> .

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 13 Sep 2018 14:43:27 -0700

> On Sep 10, 2018, at 12:51 AM, Robert Wilton <rwilton=[email-masked]> wrote:
> 
> I've read -07, and would also support an WG adoption call for this draft.  In fact, I think that it would be quite good if we can move this document through to WG LC fairly expediently as well.
> 
> Rather than banning tabs, another option would to be convert them (of course, the question is then whether a tab is 2, 4, or 8 spaces ...), although assuming 4 spaces seems reasonable, and could be controlled via an input parameter.

This does seem like the sort of classical place to have argument about the size of a tab. To me the 7991 position is compelling. The onus is the formatter to use an element which is not ambiguous.

It’s not really anyones business that I have

set tabstop=2 shiftwidth=2 expandtab
In my vimrc nor should it be.

---

From: Robert Wilton <[email-masked]>
Date: Fri, 14 Sep 2018 12:05:32 +0100

On 13/09/2018 22:43, Joel Jaeggli wrote:
>
>
>> On Sep 10, 2018, at 12:51 AM, Robert Wilton 
>> <rwilton=[email-masked] 
>> <mailto:rwilton=[email-masked]>> wrote:
>>
>> draft.  In fact, I think that it would be quite good if we can move 
>> this document through to WG LC fairly expediently as well.
>>
>> although assuming 4 spaces seems reasonable, and could be controlled 
>> via an input parameter.
>
> This does seem like the sort of classical place to have argument about 
> the size of a tab. To me the 7991 position is compelling. The onus is 
> the formatter to use an element which is not ambiguous.

I would rather not get involved in any argument/discussion/debate on how 
many spaces a tab should represent, or even whether they should be used.

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.

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.

Thanks,
Rob

> |set tabstop=2 shiftwidth=2 expandtab|
>>>> To: [email-masked] <mailto:[email-masked]>
>>>> Name:draft-kwatsen-netmod-artwork-folding
>>>> Revision:07
>>>> Title:Handling Long Lines in Artwork in Internet-Drafts and
>>> RFCs
>>>> Document date:2018-09-05
>>>> Group:Individual Submission
>>>> Pages:16
>>>>       https://datatracker.ietf.org/doc/html/draft-kwatsen-netmod-
>>>> artwork-folding
>>>> Diff:
>> [email-masked] <mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Sep 2018 13:14:27 +0200

On Sep 14, 2018, at 13:05, Robert Wilton <rwilton=[email-masked]> 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.

Grüße, Carsten

---

From: tom petch <[email-masked]>
Date: Tue, 18 Sep 2018 09:53:56 +0000

----- Original Message -----
From: "Carsten Bormann" <[email-masked]>
Sent: Friday, September 14, 2018 12:14 PM

> On Sep 14, 2018, at 13:05, Robert Wilton
<rwilton=[email-masked]> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Sep 2018 11:01:20 +0100

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

> From: netmod [mailto:[email-masked]] On Behalf Of tom petch
> Sent: 18 September 2018 10:54
> To: Carsten Bormann; Robert Wilton
> Cc: [email-masked]
> Subject: Re: [netmod] New Version Notification for draft-kwatsen-netmod-
> artwork-folding-07.txt
>

---

From: Bob Harold <[email-masked]>
Date: Wed, 19 Sep 2018 15:12:17 -0400

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

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

---

From: tom petch <[email-masked]>
Date: Fri, 21 Sep 2018 11:48:09 +0000

----- Original Message -----
From: "Bob Harold" <[email-masked]>
Sent: Wednesday, September 19, 2018 8:12 PM

> > where replacing tab characters with five spaces yields rubbish.

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 21 Sep 2018 13:58:24 +0100

So, I'm slightly regretting bringing this up in the first place because 
I'm not convinced it is worth the discussion time.  Bob Harold's 
solution is fine with me, and one that I was also considering 
suggesting, so is the 'tabs are banned' solution currently in the draft.

I do strongly agree that using tabs to align genuine artwork (i.e. 
diagrams and the like) is not a wise idea.  However, the abstract from 
the draft is:

    text based artwork,*but is primarily intended for sample text and formatted examples and code*, rather than for graphical artwork.  The

So, this draft is intended is intended to cover text, formatted 
examples, and code; and I'm not completely convinced that these will 
never contains tabs, putting aside any discussion of what is best practice.

However, I'm happy to leave the final decision to the discretion of the 
authors, or other WG members.

Rob