I fully agree with Brandon, the standard SHOULD consider the use case when a
message is transferred from one system to another as a blob (e.g. flat file)
and
the only available "metadata" is that the message is in MIME format. Having
some sort of well defined UTF8 indicator in the header section of the message
would make it much simpler to adopt the new standard as it would require
substantially less development effort in most cases.
I'm skeptical of the claim, but if you absolutely have to have something, why
not add a Received: field containing a "with smtputf8" clause, assuming one
isn't there already?
Regarding Ned's concern about inconsistent states I think it would be a
workable
solution to only honour the UTF8 indicator in the headers when the UTF8 flag
is not available from metadata. In a well known UTF8 context where the SMTP
protocol or the message store already "knows" that the message is UTF8 the
indicator in the headers can be ignored.
That assumes people will read the standard. It's far more likely that,
given an obvious indicator, they will simply use it.
I think it is generally desirable to reduce (or at least not increase) the
amount
of heuristics required to successfully parse a MIME message. We should try to
learn from previous mistakes instead of repeating them.
That's the absolute worst example you could have picked, because the most
serious design error in MIME is the MIME-Version: field. You know, the field
that tells you whether or not a given message is a MIME message. Sound
familiar?
You might want to jot down the hall and ask Nathaniel Borenstein about it. He's
far more emphatic about how stupid that was than I am.
Ned
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822