> The RFC is fuzzy on the issue, but I want to discourage too lax > treatment of encoded data. Lax treatment create opportunities for > side channel attacks, and make implementations complex since they have > to deal with various ill-formed input. So without --wrap, I > definitely think the file should be opened as binary. But with wrap > it is less clear. The RFC doesn't discuss what "newline" means. So I > think we should open it as text. More thoughts appreciated.
One thing to remember is that many RFCs expect \r\n (consider SMTP, HTTP, etc), so it might be nice to allow that even on Unix systems where only \n is normal! Maybe it is worth a command-line argument, where on encoding you can change the default line-ending (this requires opening in binary mode to guarantee that the OS doesn't change your wishes), and on decoding you can choose whether to be lax on any line-ending or robust to only allow one type of line-ending (again, this implies binary mode). But it's your call (esp. since you are the editor of RFC 3548 :). How about -l/--line-ending ENDING where ending is 'crlf', 'cr', 'lf', or 'any', and omitting -l or using -lany on encode defaults to lf, and omitting -l on decode defaults to any. -- Eric Blake _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
