From: Bruce Lilly (blilly@erols.com)
Date: Mon Mar 18 2002 - 12:48:44 CST
Charles Lindsey wrote:
>
> What I cannot understand is why they did not update RFC 2047 so as to
> allow it is be used in parameters. There must be lots of software out
> there that understands RFC 2047, but does not understand RFC 2231.
It's not clear which part of 2047 you are referring to. If
you mean encoding of 8-bit characters in phrases, comments
and unstructured text fields for display, strictly speaking that
doesn't apply to parameters, since a parameter isn't a phrase
(in the RFC 822 sense), comment, or unstructured field.
The particular parts of 2231 that are likely to be of importance
are the continuation of parameters, since that permits values
longer than the recommended 78 character line length (and that
has implications for the character set of unquoted parameters),
and the ability to specify a charset, which would cover use of
various national character sets and UTF-8.
[...]
> So why not
>
> Archive: yes; filename = "dk/test/utf8-æøå"
>
> (or similar stuff in a Content-Disposition header)?
Filenames can be tricky; not all systems support filenames
with 8-bit characters, and there is some potential for
mischief. That aside, the MIME-compliant 2231
equivalent might be:
Archive: yes; filename* = "utf-8'dk'dk/test/utf8-%c3%a6%c3%b8%c3%b5"
Note that the language is optional, but the single quotes are not.
Also note that while a charset may be specified, any characters
not in the us-ascii set must be encoded as MIME (including the
2231 extensions) presumes a 7-bit transport. To permit UTF-8
characters in some sort of extension of MIME for Usenet purposes
would require yet another redefinition of attribute-char which
appears at the top of RFC 2231 page 7 (where tspecial is
defined in RFC 2045). See also the errata at
http://www.rfc-editor.org/errata.html.
And it would be a good idea to coordinate with other area
coordinators to preclude conflicts with future revisions of 2822
or MIME RFCs which might be extended for 8-bit use.
> Essentially, we should treat it the same as we do RFC 2047. So I have now
> modified my NOTE as follows.
>
> Similar considerations apply to non-ASCII characters within the
> values of parameters (which, according to the syntax, MUST be in the
> form of quoted-strings in order for UTF8-xtra-chars to be
> accomodated). Such values MAY be encoded using the MIME mechanism
> defined in [RFC 2231], but this usage is deprecated within news
> articles (even though it is required in email messages) since it is
> less legible in older reading agents which support neither it nor
> UTF-8. Nevertheless, reading agents SHOULD support this usage.
OK in principle, but see above for issues of coordination and
the desirability of a clear definition, preferably in ABNF.