----- Original Message ----- From: "Carsten Bormann" <c...@tzi.org> Sent: Friday, September 14, 2018 12:14 PM
> On Sep 14, 2018, at 13:05, Robert Wilton <rwilton=40cisco....@dmarc.ietf.org> 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
