Keith Moore writes:
For that matter, suppose you want to answer a message that has some
other kind of invalid header field - maybe one that isn't encoded at
all, and has illegal characters.
Right.
The basic answer is that what you do with illegal input is generally
not specified - but clearly you aren't expected to make the subject
of the reply match the subject of the message being replied to in
that case.
Right.
What I cannot see is how to make something reasonable, correct and
fairly simple.
In most cases I have code that is right when the input is good, and not
wrong when the input is bad. RFC 2047 just doesn't seem to make that
simple.
Suppose I want to answer with "subject: re: <original> <ticket id>",
then I risk having two encoded-words separated only by whitespace,
and must do magic in order to preserve that space.
why not just use an ASCII ticket id?
Why should I make "always ASCII" a requirement for that case, in code
that otherwise allows all of Unicode?
--Arnt