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