>>>>> Bjørn Mork wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> I've modified Gnus so as to use UTF-8 by default for decoding
>> text/calender parts.

> Probably good, but may cause problems with pre-RFC (version 1.0)
> text/calendar parts.  Let's hope everybody using those were sending
> strict US-ASCII (possibly using QP to encode other charsets)

Well, if the text/calendar part is encoded by arbitrary charset
other than UTF-8 but has no charset spec in the Content-Type
header, there will be no way to detect it automatically.  Though,
we can guess it and apply it through the `K C' command.

> But it still doesn't work.  The attachment is encoded as
> quoted-printable and gets this header:

>  Content-Type: text/calendar; charset=iso-8859-1; name=meeting.ics
>  Content-Transfer-Encoding: quoted-printable

> But it is not converted from utf-8, so that 'æ' is coded as '=C3=A6',
> 'å' as '=C3=A5' etc.

> Everything would have been fine if Gnus had just used

>  Content-Type: text/calendar; charset=utf-8; name=meeting.ics
>  Content-Transfer-Encoding: quoted-printable

> Any idea where this confusion comes from?

I probably have understood what is a prerequisite when one hands
iCalendar files to others.  The text/calendar part that has been
encoded by the iso-8859-1 charset is indeed a valid MIME message.
However, when a recipient saves the part in a file and passes it
to the calendar program, or passes it to the program through the
pipe, the charset is unlikely to be notified to the program.
Therefor, there needs to be an implicit agreement.  That is just
UTF-8, isn't it?

I've changed Gnus' encoder so that UTF-8 is most preferred when
encoding text/calendar parts.  Actually, now Gnus will never use
the charset other than UTF-8.

It is not a matter that the Content-Transfer-Encoding is QP or
base64, is it?  Gnus may use base64 as the case may be.  If it
has to always be QP, I have a plan: