Attachments problems

[Jochen Bern]

maf@tkrat.org wrote:
> On 15 May, Jochen Bern wrote:
> > As you can see from the extracted per-part MIME headers
> > below, TkRat is lenient about throwing in a transfer encoding (it
> > encodes the cedille, but not the periods, like Mozilla)
> The not encoding the period is a bug. 

(It is ... ? I'm not used to reading ABNFs, but I thought I'ld
be able to spot a period in
| attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
|                      "*", "'", "%", or tspecials>
(from RFC2231), resp.
| tspecials :=  "(" / ")" / "<" / ">" / "@" /
|               "," / ";" / ":" / "\" / <">
|               "/" / "[" / "]" / "?" / "="
(from RFC2045). Note that encoding less chars, especially
chars as ubiquitous as a period, reduces the problem ...
Or are there any (receiver side) MUAs that insist on periods
being encoded?)

> It is rfc2231. The rfc's are pretty clear on the encoding of parameters.
> Rfc2047 says (section 5):

Oops, missed that. Sorry.

> The solution will probably be to have an option which controls if TkRat
> should be standards-compliant or not in this regard.

More precisely, one would hope that non-RFC2231 MUAs fail to
understand the RFC2231 specific 'name*="value"' syntax (note the
asterisk) and ignore that param; That'ld allow a sending MUA to
give, e.g.,

Content-Type: what/ever;
	name*="iso-8859-1'de'B%FCro";
	name="=?iso-8859-1?Q?B=FCro?="

which should work with RFC2231-capable, RFC2047-addicted, and
mixed receiver side MUAs.

Which leaves those MUAs which correctly implement RFC2047 (re-
fusing to do the decoding in the param) but aren't RFC2231
aware. :-}

Regards,
								J. Bern