I am using the implementation of rfc2231-parse-string in
lisp/gnus/rfc2231.el in the Emacs CVS at
[EMAIL PROTECTED]:/cvsroot/emacs. This is file version
1.10, which is the latest available today. The latest Gnus
development version of this function might be different.
Bug #1: The invocation
(mail-header-parse-content-type "message/external-body;
name*1*=plugh%2fhello-sailor%2fbing.pdf;
name*0*=us-ascii''~%2ffoo%2fbar%2fbaz%2fxyzzy%2f;
access-type=LOCAL-FILE")
raises an error with this message:
Invalid coding system: plugh%2fhello-sailor%2fbing\.pdfus-ascii
Bug #2: The invocation
(mail-header-parse-content-type "message/external-body;
name*0*=us-ascii''~%2ffoo%2fbar%2fbaz%2fxyzzy%2f;
access-type=LOCAL-FILE;
name*1*=plugh%2fhello-sailor%2fbing.pdf")
returns this result:
("message/external-body"
(name . "~/foo/bar/baz/xyzzy/")
(access-type . "LOCAL-FILE")
(name . "plugh/hello-sailor/bing.pdf"))
According to the RFC 2231 standard, both invocations listed above
should instead yield the same result (modulo reordering of the
association pairs) as the invocation
(mail-header-parse-content-type "message/external-body;
name*0*=us-ascii''~%2ffoo%2fbar%2fbaz%2fxyzzy%2f;
name*1*=plugh%2fhello-sailor%2fbing.pdf;
access-type=LOCAL-FILE")
which returns this:
("message/external-body"
(name . "~/foo/bar/baz/xyzzy/plugh/hello-sailor/bing.pdf")
(access-type . "LOCAL-FILE"))
I hope this bug report is helpful.
--
Joe
_______________________________________________
Emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
