Re: Handling HTAB in artwork/sourcecode, was: [art] New RFCs text formatting

[John C Klensin <[e-mail]>]

--On Tuesday, December 3, 2019 15:13 +0100 Julian Reschke
<[e-mail]> wrote:

> On 30.11.2019 06:22, Julian Reschke wrote:
>> On 29.11.2019 23:34, Carsten Bormann wrote:
>>> On Nov 29, 2019, at 23:18, John C Klensin
>>> <[e-mail]> wrote:
>>>> 
>>>> identified a weakness in rfcdiff
>>> 
>>> The RFC 7386/7396 accident was also caused by this (root
>>> cause was apparently the use of HT characters, which need to
>>> be expunged from the universe, but rfcdiff helped in not
>>> detecting the problem before publication).
>>> 
>>> Grüße, Carsten
>> 
>> 
>> rfc2629.xslt has been warning about HTAB since 2014-10-16
>> (likely triggered by that accident). xml2rfc has a ticket
>> open about that:
>> <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/403>
>> (dated 2019-04-14, still in status "new").
>> ...
> 
> FWIW, rfc2629.xslt used to output the HTAB into the HTML
> content; this
> is now changed, it will place a (red) U+2409 character instead
> - that
> should make it easier to spot the issue in the source (see
> <https://github.com/reschke/xml2rfc/commit/58dca914d1489f25b4b
> e8220c30e13f1cb23e46e>).

Helpful but, if we are concerned about what the final output
looks like, wouldn't it be easier to have authors just convert
HT to the widths they prefer and to modify the nits checker to
notice their presence?  And for the RFC Editor to be sure that
none of them make it into final output?  Those are just
questions -- I haven't thought through what bad side effects
that might have.

best,
   john