Re: utf8 messages
Daniel Vargha <[email protected]> Fri, 15 Aug 2014 12:38:58 +0000
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <D013B9C1.1972E%[email protected]> |
On 14/08/2014 01:56, "Ned Freed" <[email protected]> wrote: >> 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? Received: headers are not very reliable, and the syntax is is not well defined. = Successfully parsing a Received: header itself requires a lot of heuristics. = To be honest I would not be happy to rely on them. Also, when a message is = transferred between archive stores no new Received: header is normally added. > >> 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. Is this a serious argument? Why would you bother writing a standard if you don't = expect people to read 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? I don=B9t understand this comment. What example are you referring to? (Of course I am familiar with the MIME-Version: header, I have read the corresponding RFC = many times) Daniel _______________________________________________ ietf-822 mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-822