In <1021014180654(_dot_)ZM28416(_at_)candle(_dot_)brasslantern(_dot_)com> "Bart
Schaefer" <schaefer(_at_)brasslantern(_dot_)com> writes:
On Oct 14, 1:01pm, Charles Lindsey wrote:
} OTOH, both those views of Interpetation B seem to presuppose that the
} user agent was familiar with the syntax of Usefor.
If the user agent is not familiar with the syntaxt of Usefor, it has no
business assigning any semantics at all to the Mail-Copies-To field, so
whether or not encoded words appear there is irrelevant.
A sending agent does not assign semantics to anything (but, in any case,
sending agents are not the problem, because they would not usually be
generating that header if they were not already Usefor-aware).
The real problem is email receiving agents. The only semantics expected in
that case is for the encoded-word to be decoded and displayed (assuming
the charset is known). It is highly desirable that should be done, but it
seems impossible unless the agent either recognizes the syntax, or it is
prepared to decode things that it is not required to decode by RFC 2047
(yes, I know that most agents do decode considerably more than RFC 2047
requires, but I don't like having to rely upon such liberality).
The user agent is not supposed to know. The user agent is not supposed
to look for or apply encodings/decodings inside header fields for which
it does not know the semantics. All fields for which the semantics are
unknown are to be treated as unstructured upon receipt.
Eh? Where does it say that unknown headers are to be treated as
unstructured? If that were the case, things would be much simpler, but I
don't think it is.
} Interpretation D:
}
} The wording "rules in RFC 822" includes the rules for 'extension-field'
} and 'user-defined-field'.
This is the correct interpretation.
OK.
} Hence "must parse the message" means that the rules in the document
} defining the extension are to be applied.
Exactly.
} OTOH, Interpretation D seems to require that all user agents be
} magically aware of all new extension headers as soon as their defining
} documents are published.
No. It requires only that user agents DO NOT ATTEMPT TO PARSE header
fields for which they do not know the semantics.
If you know what a header means, you may parse it and act on it. If you
don't know, you should ignore it completely (pass it through unchanged,
hide it from the user, whatever).
It is not a question of "acting on it". All I want is for it to be
displayed (or displayable) correctly. Most usage of encoded-words is only
intended for human consumption anyway.
I cannot accept that "hiding a header from the user" can ever be a proper
thing to do (yes, the user should be able to select which headers he sees,
but if he wants to see them all, then that MUST be possible).
The intent of 2047 is that an application that chooses NOT to implement
2047 can still parse the resulting tokens according to their definition
in the appropriate document. Thus most of the restrictions in 2047 are
on applications that GENERATE 2047 header fields, to assure that they
remain interoperable with non-2047-compliant applications
No problems with that.
Whether an application that receives a 2047 encoded-word chooses to decode
it is a quality of implementation issue.
But my problem is that 2047 places seemingly unnecessary restrictions on
what is decoded (restrictions which most implementations seem to ignore,
because they make life too difficult when keeping up with new extensions).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5