Charles Lindsey wrote:
In <3E2019AA(_dot_)30805(_at_)Sonietta(_dot_)blilly(_dot_)com> Bruce Lilly
<blilly(_at_)erols(_dot_)com> writes:
Charles Lindsey wrote:
But for some purposes (followups) the header gets used as the basis of
headers in a new message, and at that point the starting point has to be
the decoded form (since how else is the user to edit the new message).
I don't follow your argument; could you please explain the circumstances
under which some individual would need to edit an encoded-word which is
part of another person's display name in a header field. There is no
need to decode and re-encode in order to use a From field content to generate
a new To, Cc, etc. field.
The situation is going to arise most commonly within Subject-headers,
which the user will most certainly expect to be able to edit.
Here there are two issues:
1. "editing" dealt with below
2. the "Re: " hack, which effectively makes Subject structured to some
extent.
It will need to be copied into To or Cc fields if the user wants to email
his followup as well as to post it. I expect most user agents will expect
the user to edit his To or Cc fields too.
"Editing" doesn't necessarily mean inserting and removing random characters
at random places. One might want to insert or remove entire mailboxes from
a list of mailboxes, but that does not require decoding and re-encoding.
That is
clearly the intent of RFC 2047. The design flaw, as has been already
mentioned, is decoding encoded-words for transmission.
But nobody is proposing to do that.
The Usefor draft permits it by allowing raw untagged 8-bit data to be
transmitted between generating user agents and gateways.
If some raw untagged 8-bit data is produced then, by definition, it is not
in the form of an encoded-word,
I.e. it is in decoded form. Header fields must use 2047/2231 for non-ASCII
characters; any raw untagged 8-bit data is therefore referred to as "decoded"
for purposes of this discussion.
so the question of "decoding it for
transmission" cannot possibly arise.
Yes it can; if a user agent transmits raw untagged 8-bit data (rather than
the standard 2047/2231 encoded-words).
> If, at some gateway, it gets encoded,
Can't be done there. Encoding requires charset and (optionally) language
information plus header field syntax information. Charset and language
information isn't available to gateways, and syntax information might not
be available.
then it is now in RFC 2047 form (hopefully correct), and then it will
remain so
That is why the correct form (2047/2231) must be produced by the user
agent (which does have the necessary information).