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

[tom petch <[e-mail]>]

Not about tabs!

When I look at YANG modules, which I have done a bit of this year, I
have two problems with line lengths, making it harder for me to review
the I-Ds.

One is the lengthy lines in the YANG tree diagram and that this I-D
clearly addresses.

The other is lines that are too long, for an RFC, in the YANG module,
typically in description clauses and in comment lines.  I don't know
what the editors are doing to get such lines into an I-D but they do so
I would like a paragraph in this I-D to the effect that editors should
take care of this and that this phenomenon is nothing to do with the
technique described here, a sort of non-Applicability statement so that
we do not, in future, get too long lines as

      /* optical interface func needs to expand for Fiber Channel,\
\ SONET and SDH */

instead of turning them into

      /* optical interface func needs to expand
          for Fiber Channel, SONET and SDH */

I tried to explain this to an editor recently and had great difficulty
in getting across that there was a problem, and this is not an isolated
case; hence my wish to have something to point to about it.

Tom Petch


----- Original Message -----
From: "t.petch" <[e-mail]>
To: "Carsten Bormann" <[e-mail]>; "Robert Wilton"
<rwilton=[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, September 18, 2018 10:53 AM

> ----- 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
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>