Re: utf8 messages

> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822