From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: org-mime - issues and remarks Date: Tue, 27 Apr 2010 13:26:45 -0600 Message-ID: <87hbmw66iy.fsf@gmail.com> References: <877hny4084.wl%dmaus@ictsoc.de> <874oiy6w03.fsf@gmail.com> <87zl0o930r.wl%dmaus@ictsoc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6qRa-0002cV-Ik for emacs-orgmode@gnu.org; Tue, 27 Apr 2010 15:27:42 -0400 Received: from [140.186.70.92] (port=49406 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6qRY-0002aW-Sr for emacs-orgmode@gnu.org; Tue, 27 Apr 2010 15:27:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6qRU-00020p-In for emacs-orgmode@gnu.org; Tue, 27 Apr 2010 15:27:40 -0400 Received: from mail-px0-f169.google.com ([209.85.212.169]:36925) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6qRU-00020Z-AD for emacs-orgmode@gnu.org; Tue, 27 Apr 2010 15:27:36 -0400 Received: by pxi15 with SMTP id 15so2806741pxi.0 for ; Tue, 27 Apr 2010 12:27:35 -0700 (PDT) In-Reply-To: <87zl0o930r.wl%dmaus@ictsoc.de> (David Maus's message of "Tue, 27 Apr 2010 20:14:12 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: David Maus Cc: org-mode David Maus writes: > At Mon, 26 Apr 2010 10:04:12 -0600, > Eric Schulte wrote: >> David Maus writes: >> >> > While skimming the source code of org-mime I noticed two severe issues >> > with regards to the MIME specifications: >> > >> > - when creating an attachment for a image org-mime (still) uses the >> > file extension as MIME media subtype for Gnus messages. This not >> > in compliance with RFC 2046. As mentioned before org-mime >> > should/could use the function to determine MIME media type of >> > message-mode and mime-edit-mode respectively. >> > >> > For SEMI the function is `mime-find-file-type', called with the >> > file name as argument and returns a list whose first element is a >> > string with MIME media type and second element is MIME media >> > subtype. >> > >> >> Alright, >> >> once I find the appropriate similar function in mml/gnus I will make >> this change. > > Well, I tried to change it for SEMI but this would require a complete > rewrite of `org-mime-replace-images' because `mime-find-file-type' > modifies the match-data and the `replace-regexp-in-string' get's > confused (i.e.: throws an error). I'll see if I can come up with > something w/o rewriting to much. > The `save-match-data' macro should fix this. > >> > >> > Furthermore there are some minor glitches: >> > >> > - the "filename" parameter is only defined for the >> > content-disposition header field; because images are attachments >> > they can/should be easily send with >> > >> > content-disposition: attachment; filename="" >> > >> > For SEMI (replace _ by -): >> > >> > __[[type/subtype >> > content-disposition: attachment; filename=""][base64]] >> > >> >> could you expand upon this point, what's the problem? > > Hm. I noticed that in the test mail of Eric Fraga[1] images where attached as: > > ,---- > | Content-Type: application/octet-stream; type=image/png > | Content-ID: _home_ucecesf_s_test_mip.png; filename="/home/ucecesf/s/test/mip.png" > | Content-Transfer-Encoding: base64 > `---- > > I.e. with the 'filename=' parameter in the Content-ID MIME header > field. That wouldn't be correct or, say, not entirely correct because > the filename option is only defined in a Content-Disposition MIME > header field. So, the old story: It's out of the scope of MIME so you > don't know what receiving clients will do. > > Anyway, org-mime currently does not put a filename parameter at all so > what's only left is to send attached images with SEMI is Disposition: > attachment like Gnus does. > > The difference: The Content-Disposition MIME header field contains an > optional hint for the receiving MUA what to do with attached files. > > - 'inline' :: Show attachment without user interaction. > > - 'attachment' :: Show attachment only with explicit user > interaction. > > For the attached images we don't want them to be shown without user > interaction but rendered in the html markup. Sending them with > Disposition: inline could result in a MUA showing the images inside > the html markup and again maybe at the bottom of the message. > Alright, it shouldn't be hard to add the "attachment" content disposition to the attachment strings. And if I'm reading you correctly we should also place a filename parameter in the "Content disposition" header? > >> >> > >> > - org-mime uses `reporter-compose-outgoing' to open a new message >> > draft. This is not a could solution because (a) org-mine does not >> > want to send a bug report and (b) would depend on reporter.el >> > without necessity. >> > >> >> I don't think this is a problem, I think reporter.el is the best >> approach here. > > Yes, I admit this is somewhat pedantic and hypothetical: If you depend > on reporter that you should say so (require 'reporter) and you will > depend on this particular implementation of > `reporter-compose-outgoing'. As soon as this function does something > else or something more, strange things might happen. It's like taking > a detour: When we prepare the message draft we already know which > functions are required depending on `org-mime-library'. > The (require 'reporter) string is present in org-mime.el, so I think we're all set here. Thanks -- Eric > > HTH > -- David > > > [1] mid:87hbndq0ym.wl%ucecesf@ucl.ac.uk > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber.... dmjena@jabber.org > Email..... dmaus@ictsoc.de