[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: PATCH: Outlook compatible attachment naming
From:       Marc Mutz <mutz () kde ! org>
Date:       2004-04-30 19:36:39
Message-ID: 200404302136.44825.mutz () kde ! org
[Download RAW message or body]

On Thursday 29 April 2004 08:08, Till Adam wrote:
> > Sorry, but there's nothing I can add to this thread. I've stated my
> > opinion. I and a few others code, and so I and those few others
> > decide. Feel free to fork KMail and implement RFC 2184.
<snip>
> In short, I think we should consider implementing this, even if it
> means we optionally produce mails that are not adhering to the latest
> rfcs, but to an obsoleted one.
<snip>

THERE IS NO STD FOR RFC2047 IN PARAMETER NAMES PERIOD.

mentioned rfc is the predecessor of rfc2231. It certainly does _not_ use 
rfc2047 for parameter names.

My only contribution to this thread will be to support Don's initial
patch and Ingo's comments.

The vote isn't valid, since there is no such RFC. Please rephrase as:
"Support for OL-bug-workaround in attachment encoding of non-usascii 
letters, by breaking compliance to RFC2231, and any of it's 
predecessors (which include 2184, which no-one seems to have looked 
at)".

Marc: against, except when implemented as a non-defaultable, per-message 
option in Composer "Use broken attachment filename encoding" with a 
non-skippable messagebox shown, describing the problem and asking to 
bug MS.

Refs:
RFC2183:
   Current [RFC 2045] grammar restricts parameter values (and hence
   Content-Disposition filenames) to US-ASCII.  We recognize the great
   desirability of allowing arbitrary character sets in filenames, but
   it is beyond the scope of this document to define the necessary
   mechanisms.  We expect that the basic [RFC 1521] `value'
   specification will someday be amended to allow use of non-US-ASCII
   characters, at which time the same mechanism should be used in the
   Content-Disposition filename parameter.
RFC2184:
   This memo defines extensions to the RFC 2045 media type and RFC 2183
   disposition parameter value mechanisms to provide

    (1)   a means to specify parameter values in character sets
          other than US-ASCII,
[...]
4.  Parameter Value Character Set and Language Information
[...]
   Asterisks ("*") are reused to provide the indicator that language and
   character set information is present and encoding is being used. A
   single quote ("'") is used to delimit the character set and language
   information at the beginning of the parameter value. Percent signs
   ("%") are used as the encoding flag, which agrees with RFC 2047.
[...]
      Content-Type: application/x-stuff;
      title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

-- 
I am Bush of USA. You will be pacified. Resistance is futile.
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]