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

[Robert Wilton <[e-mail]>]

On 13/09/2018 22:43, Joel Jaeggli wrote:
>
>
>> On Sep 10, 2018, at 12:51 AM, Robert Wilton 
>> <rwilton=[e-mail] 
>> <mailto:rwilton=[e-mail]>> 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.
>>
>> 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.
>
> 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

>
> It’s not really anyones business that I have
>
> |set tabstop=2 shiftwidth=2 expandtab|
> In my vimrc nor should it be.
>> Thanks,
>> Rob
>>
>>
>> On 08/09/2018 13:39, Adrian Farrel wrote:
>>> 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
>>>
>>>> -----Original Message-----
>>>> From: netmod [mailto:[e-mail]] On Behalf Of Kent Watsen
>>>> Sent: 07 September 2018 22:59
>>>> To: [e-mail] <mailto:[e-mail]>
>>>> Subject: [netmod] FW: New Version Notification for 
>>>> draft-kwatsen-netmod-
>>>> artwork-folding-07.txt
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>