On Fri, Apr 08, 2005 at 01:38:46AM +0200, Kjetil Torgrim Homme wrote:
there are a lot of things regarding the composing of the message which
is left to the implementation's discretion. should the Subject use
quoted-printable or base64? should the From header include the full
name of the vacationist or just the e-mail address? and so on. it's
impossible to make an exhaustive list of all these small decisions, and
it would be a distraction.
should the Subject use
quoted-printable or base64?
RFC 2047 says in section 4:
The "Q" encoding is recommended for
use when most of the characters to be encoded are in the ASCII
character set; otherwise, the "B" encoding should be used.
So that's well defined to be optional, but with a suggestion.
Interestingly, the vacation draft does not specify that if non-ASCII
characters are used in the reason, MIME encoding is required, like it
does for the subject. And as you write, sometimes even ASCII characters
need to be quoted. That section still needs some work.
should the From header include the full
name of the vacationist or just the e-mail address?
RFC 2822, section 3.4:
Normally, a mailbox is comprised of two parts: (1)
an optional display name that indicates the name of the recipient
(which could be a person or a system) that could be displayed to the
user of a mail application, and (2) an addr-spec address enclosed in
angle brackets ("<" and ">").
There is no suggestion, it is well defined to be optional, though.
And that's what I say: If something is optional, it should be specified
as such.
How is a MIME entity be used to form a message? A multi part message is
a very different thing from a single part message and what will be used
sounds pretty application specific to me, so the application specification
should say something about it, even if both are fine.
however, it wouldn't hurt if the base spec said that the mechanisms of
_standards track_ extensions can be combined unless otherwise stated in
either of the extensions. such a statement would force extension
writers to review existing extensions before publishing.
Good idea, I agree with that.
Michael