The next version of Microsoft Exchange has ability to decode 2231.
Regards,
Yuri
-----Original Message-----
From: owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Ingo Klöcker
Sent: Wednesday, July 19, 2006 5:40 AM
To: ietf-822(_at_)imc(_dot_)org
Subject: Re: rfc2231 implementations?
Am Mittwoch, 19. Juli 2006 10:38 schrieb Arnt Gulbrandsen:
So far, we have two known writers (kmail and apple mail) and four
known readers (eudora/mac, teamware, kmail, apple mail).
FWIW, Thunderbird (Mozilla Thunderbird 1.0 (X11/20041207)) created the
following non-RFC-2231 headers:
Content-Type: application/pdf;
name="=?ISO-8859-1?Q?kr=FCzzbr=FCr=2Ewpd=2Epdf?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="=?ISO-8859-1?Q?kr=FCzzbr=FCr=2Ewpd=2Epdf?="
So, at least by default Thunderbird doesn't create RFC 2231. But a quick
test shows that Thunderbird seems to understand it. So knownReaders
+= "Thunderbird".
Ingo Klöcker writes:
Am Dienstag, 18. Juli 2006 17:29 schrieb Arnt Gulbrandsen:
I can't remember ever seeing a 2231-encoded message in the wild.
Are there implementations? Is there hope that a message using 2231
syntax will be understood by anyone?
Not sure what exactly you mean, but KMail does, of course, create
2231-encoded headers for attachments with non-ASCII names.
The question could be rephrased as: Can I assume that an attachment
name encoded according to RFC 2231 will be correctly decoded by the
recipient?
Though, much to my dismay, KMail also has a Microsoft-compatibility
mode for creating those headers in Microsoft's RFC-violating
format.
I suspect that means "no, you can't assume that".
Luckily, I can't check whether Microsoft's products do nowadays
understand RFC 2231.
Regards,
Ingo