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

[tom petch <[e-mail]>]

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