Bug 41558

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 24 April 2002 09:28 sibskull@mail.ru wrote:
<snip>
> When I compose messages with subject and attacments using non-latin
> symbols I get message with encoding subject and attachment's name like
> koi8-r''%F0%D2%C9%CC%CF%D6%C5%CE%C9%D1%20%CB%20%D0%C9%D3%D8%CD%D5%20%F2%E1%
>EF%2Ezip

Actually the subject should look like
Subject: =?koi8-r?q?=F0=D2=C9....?=
and the attchments filename is encoded with the %-thingy? Right?

That's valid rfc2047/rfc2231 and the only way to encode these things.

> But users who read my e-mail by Outlook Express get wrong subject (not in
> koi8-r encoding) and attachments like ATT00*.
<snip>

Is the specific charset (koi8-r) the problem? You can change that in Configure 
KMail->Composer->charsets.
If it's not the charset it's Outlook's fault. Complain to Microsoft to add 
support for the (already 4 1/2 years old) rfc2231 standard.
Actually it's also Microsoft's problem if they don't recognize the koi8-r 
charset but I guess they do if you use the right locale there...

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8xnPH3oWD+L2/6DgRAodEAJ9OLMNsaKIOY91JUpvH0SjteLlZ3QCeLZtf
XN6cU54TPJD3180xg9vAtYE=
=Tvsh
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

reopen 41558
retitle 41558 KMail put rfc2231-encoded parameter values into DQUOTES.
severity 41558 grave
quit

On Wednesday 24 April 2002 12:58 Andrey S. Cherepanov wrote:
<snip>
> Compare two attachment header with smae name and look on difference!
> Outlook Express:
> Content-Type: application/msword;
> name="=?koi8-r?B?Q8/XxdQuZG9j?="

That's completely invalid stuff. encoded-words are not allowed in 
quoted-strings. I can cite the RFCs if you like me to.
Oh well Microsoft is always right yes? Please believe me when I say that 
it's Outlook's fault :-(

> ----------------------
> KMail [version 1.4] :(
> Content-Type: application/msword;
>   name*="koi8-r''C%CF%D7%C5%D4%2Edoc"

Eeek. Are the double quotes really there?

Except for the double quotes that's completely correct encoding according to 
rfc2231.
Please type "rfc:2231" into konqueror's location field read the document that 
comes up then and report the bug to Microsoft where it belongs.

I see if I can fix the double quotes problem in KMail.

> Subject was encoded well but attachments - wrong. And what's parameter
> 'name*' ??
>
> Outlook Express show Subject correct but attachment name wrong :(

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8xtGT3oWD+L2/6DgRApVDAKD36QLNF1ix5HxtDW7+J4eterSqagCfUAp4
lIBbE/ZGgRPZPhow4AQ2rPk=
=S8aX
-----END PGP SIGNATURE-----

Created attachment 5658 [details]
KMail patch for Outlook comppatible attachment names encoding

I reopen this bug because I still need to send files with russian names to my
partners who have Outlook Express. Tested on KMail 1.6.1 from KDE 3.2.1.
Additionally I put option in configuration tab for pure russian people who has
similar problem. Now attachment name encode by RFC2047 only if option "Outlook
compatible attachment encoding".
Possible this option name is ugly. Please, correct me.

I create the patch. It fix problem, described in this bug. Now I guess, this bug must be reopened.

The problem is that AFAIK using RFC2047 to encode attachment names is 
not valid, it's RFC non-compliant, and it's the general consensus of 
the KMail team that having KMail send RFC non-compliant mails is not 
acceptable even as an option.

Personally I think your patch is fine, but I'm pretty sure I'm 
outvoted here. Hence I work on an alternative patch that renames 
attachment. Unfortunately this is limited to working on extended 
ascii characters only, hence cyrillic will still be a problem.

Don.

Don, in what way priority is higher: non-official standart (BTW, RFC instead of ECMA standarts IS NOT official standarts!) or real user work? Outlook/Mozilla/Opera encode 'inline' block (note: only KMail put 'attachment' definition) in RFC2047. It's RFC compatible, because MIME block in these proucts is defined as 'inline', not 'attachment'. Why KMail must be incompatible e-mail client, even them users are ready to help developers to make really BEST e-mail client!?
I don't understand your religious fanaticism!

> Don, in what way priority is higher: non-official standart
> (BTW, RFC instead of ECMA standarts IS NOT official standarts!)

(About RFC vs ECMA is that relevant? Is there some kind of ECMA/RFC 
conflict? This is a bit offtopic but what makes you say ECMA is 
official over RFC?)

> or 
> real user work? 

In my opinion real user work always comes before standards compliance.

However in this case Ingo, and Marc have said that Content-Disposition 
filenames shall be restricted to US-ASCII or encoding as specified in 
RFC2231. So it's 2-1 and I'm outvoted.

> Outlook/Mozilla/Opera encode 'inline' block (note: 
> only KMail put 'attachment' definition) in RFC2047. It's RFC
> compatible, because MIME block in these proucts is defined as
> 'inline', not 'attachment'.

After scanning RFC 2045, 2047, 2231, 2183, and 2184 again I get the 
impression that the only valid way to encode non US-ASCII 
content-disposition filenames is by using the method described 
RFC2231.

What makes you say that if message parts are defined to have an 
'inline' content-disposition then it's ok to encode the filename 
using RFC2047? I can't see anything in the RFCs that support this 
position.

> Why KMail must be incompatible e-mail 
> client, even them users are ready to help developers to make really
> BEST e-mail client!? I don't understand your religious fanaticism!

As I said personally I agree with you, and I find the current 
situation to be unsatisfactory for cyrillic language uses. But I'm 
outvoted.

BTW there's no simple algorithm to create a latin string to 
approximate a cyrillic string is there? If so that could be used to 
rename cyrillic filenames to US-ASCII filenames.

Don.

> > Don, in what way priority is higher: non-official standart
> > (BTW, RFC instead of ECMA standarts IS NOT official standarts!)
>
> (About RFC vs ECMA is that relevant? Is there some kind of ECMA/RFC
> conflict? This is a bit offtopic but what makes you say ECMA is
> official over RFC?)
Because RFC is not product of official standartization organization.

> After scanning RFC 2045, 2047, 2231, 2183, and 2184 again I get the
> impression that the only valid way to encode non US-ASCII
> content-disposition filenames is by using the method described
> RFC2231.
> What makes you say that if message parts are defined to have an
> 'inline' content-disposition then it's ok to encode the filename
> using RFC2047? I can't see anything in the RFCs that support this
> position.
Ok! Look in RFCs together:
RFC2183: "It specifies the "Content-Disposition" header field, which is 
optional and valid for any MIME entity ("message" or "body part")."
In section 2: "Parameter values longer than 78 characters, or which contain 
non-ASCII characters, MUST be encoded as specified in [RFC 2184]."
Go to RFC2184...
"This memo also defines an extension to the encoded words defined in RFC 2047 
to allow the specification of the language to be used for display as well as 
the character set."

I think, software corporations use this two RFCs. You said about KMail MUST 
support standart. Why KMail doesn't support they NOW?


> > Why KMail must be incompatible e-mail
> > client, even them users are ready to help developers to make really
> > BEST e-mail client!? I don't understand your religious fanaticism!
>
> As I said personally I agree with you, and I find the current
> situation to be unsatisfactory for cyrillic language uses. But I'm
> outvoted.
>
> BTW there's no simple algorithm to create a latin string to
> approximate a cyrillic string is there? If so that could be used to
> rename cyrillic filenames to US-ASCII filenames.
It isn't acceptable! Don, please, read RFC2183/2184. 

> Ok! Look in RFCs together:
> RFC2183: "It specifies the "Content-Disposition" header field,
> which is optional and valid for any MIME entity ("message" or "body
> part")." In section 2: "Parameter values longer than 78 characters,
> or which contain non-ASCII characters, MUST be encoded as specified
> in [RFC 2184]." Go to RFC2184...
> "This memo also defines an extension to the encoded words defined
> in RFC 2047 to allow the specification of the language to be used
> for display as well as the character set."

Going to RFC2184 and reading it to see what the defined extension is 
leads me to section 4.

"4.  Parameter Value Character Set and Language Information

   Some parameter values may need to be qualified with character set
   or language information....

   Specifically, an asterisk at the end of a parameter name acts as an
   indicator that character set and language information may appear at
   the beginning of the parameter value. A single quote is used to
   separate the character set, language, and actual value information  
   in
   the parameter value string, and an percent sign is used to flag
   octets encoded in hexadecimal.  For example:

     Content-Type: application/x-stuff;
      title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A
"

As can be seen in bug:18062 the format used in the example in RFC 2184 
is the one used by KMail. Which makes sense since RFC2231"Obsoletes: 
2184", that is RFC2231 replaces but does not contradict RFC2184.

> I think, software corporations use this two RFCs. You said about
> KMail MUST support standart. Why KMail doesn't support they NOW?

Personally I interpret RFC2047 and RFC2184 as showing that KMail is 
strictly compliant, while Outlook is not. I believe this is 
consistent with Marc and Ingo's interpretations.

> > > Why KMail must be incompatible e-mail
> > > client, even them users are ready to help developers to make
> > > really BEST e-mail client!? I don't understand your religious
> > > fanaticism!
> >
> > As I said personally I agree with you, and I find the current
> > situation to be unsatisfactory for cyrillic language uses. But
> > I'm outvoted.
> >
> > BTW there's no simple algorithm to create a latin string to
> > approximate a cyrillic string is there? If so that could be used
> > to rename cyrillic filenames to US-ASCII filenames.
>
> It isn't acceptable!

This is a shame.

> Don, please, read RFC2183/2184. 

I doubt discussing the RFCs further is going to be productive. 

I agree the current situation is unsatisfactory for cyrillic language 
users, and feel bad about this. If anyone (Ingo?) has a suggestion 
for how to improve the situation I'm interested.

Don.

> > > BTW there's no simple algorithm to create a latin string to
> > > approximate a cyrillic string is there? If so that could be used
> > > to rename cyrillic filenames to US-ASCII filenames.
> >
> > It isn't acceptable!
>
> This is a shame.
No, it's real require from my partners.

> > Don, please, read RFC2183/2184.
>
> I doubt discussing the RFCs further is going to be productive.
>
> I agree the current situation is unsatisfactory for cyrillic language
> users, and feel bad about this. If anyone (Ingo?) has a suggestion
> for how to improve the situation I'm interested.
I also glad to discuss this situation. In my opinion, there are two option in 
KMail settings: encode by RFC2231 standart (by default, right way :) and 
encode Content-Disposition by RFC2047 (only for other proprietary client 
compatibility!). But second variant MUST be realized. Possible, through my 
patch or another way.

*** Bug 80123 has been marked as a duplicate of this bug. ***

RFCs are no standards? So you don't recognize the Internet Society as standardazation organisation? I advice that you read http://www.ietf.org/rfc/rfc2026.txt because you obviously don't know what you are talking about. Basically _all_ Internet related protocols and standards are made by the Internet Society and are published in form of RFCs. So your claim that RFCs are no standards and therefore don't need to be followed (that's what you wanted to imply with your claim, isn't it?) is outrageous.

And your talk about "inline" vs. "attachment" is also complete nonsense because this is in no way related to the way the MIME parameter values are encoded. Did you actually read (and understand) http://www.ietf.org/rfc/rfc2183.txt?

> RFCs are no standards? So you don't recognize the Internet Society as
> standardazation organisation? I advice that you read
> http://www.ietf.org/rfc/rfc2026.txt because you obviously don't know what
> you are talking about. Basically _all_ Internet related protocols and
> standards are made by the Internet Society and are published in form of
> RFCs. So your claim that RFCs are no standards and therefore don't need to
> be followed (that's what you wanted to imply with your claim, isn't it?) is
> outrageous.
>
> And your talk about "inline" vs. "attachment" is also complete nonsense
> because this is in no way related to the way the MIME parameter values are
> encoded. Did you actually read (and understand)
> http://www.ietf.org/rfc/rfc2183.txt?
I'm very sorry for my irascibility. I agree with you about meaning RFC as 
Internet standarts.

I read RFC 2183 and I understand what Microsoft/Mozilla teams think about 
preferred show attachment inline (heh! although their products don't support 
this feature in most cases) :)

Ingo, I don't want to dispute about valid RFC's support with you: you better 
developer aginst me. I only want to solve my very little problem. Will you 
help me?

The "Outlook-compatible attachment naming" option has been added to the development version.