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

[Robert Wilton <[e-mail]>]

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:

    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.

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


On 21/09/2018 12:48, tom petch wrote:
> ----- 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
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod