[Nmh-workers] Re: Should attachment header handling be in send?
Jon Steinhart <[EMAIL PROTECTED]> writes: > OK, I think that I understand now. You're right, this is somewhat ugly. > Here's a first crack at a solution. Despite the earlier complaint about > using the file command, it correctly identifies mail messages. So I > would be inclined to use it to set the content type. Now, this doesn't > work real well with the current mhshow-suffix scheme since it's not a > suffix, so I would think about adding some other profile entries that > give the content type to use for particular file command results. Since the file command doesn't always get it right, MH-E has code to "fix" it. In particular Excel and Powerpoint files get tagged as application/msword, Openoffice documents get tagged as application/x-zip, and vCards get tagged as text/plain. nmh should probably do something similar if it goes the file route. My own personal feeling is to prefer the extension if it matches one in /etc/mime.types and use the file command as a fallback rather than vice-versa, but that isn't the consensus with the MH-E developers. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
Date:Fri, 03 Feb 2006 17:21:11 -0500 From:David Levine <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | My intent was to allow the value of the field to be | anything, for future expansion. It seems that RFCs issue at | a faster rate than nmh can support. I think Joel's point was that that wasn't what your grammar achieved, it required the value of the field to be a sequence of attribute=value tuples, whereas some new field that might want to be added (and whose name need not necessarily start with "Content-" I would have thought) might have some entirely different syntax, or perhaps no syntax at all. kre ps: Also remember, if you're using RFC ABNF grammars (as opposed to the semi-defined thing that was in RFC822) then you also need to be explicit about where white space is to be permitted, if anywhere. Using RFC ABNF, the example you gave didn't fit your grammar, as you included (in the example) spaces between "Disposition:" and "attachment", and again between "attachment;" and "filename=" (and in the actual directive line, between "pdf;" and "<>" and between "]" and "/tmp/foo".) ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Re: Editing MIMEd messages
Joel Reicher <[EMAIL PROTECTED]> writes: > One more thing. Would anyone object to profile components like > Attach-Header: X-MH-Attach > Forward-Header: X-MH-Forward I haven't followed the discussion about these fields, but I can speak to the proposed names. Note that RFC 2822 and MH call individual header fields "header fields" or just "fields". The "header" refers to the entire message header or the show header. While we might use header casually when we mean a field (although it would be better to get into better habits), let's keep the user-visible stuff consistent to avoid possible surprise or confusion. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
> | My intent was to allow the value of the field to be > | anything, for future expansion. It seems that RFCs issue at > | a faster rate than nmh can support. > > I think Joel's point was that that wasn't what your grammar achieved, > it required the value of the field to be a sequence of attribute=value The "="value portion is optional, and the grammar doesn't further define attribute. > tuples, whereas some new field that might want to be added (and whose > name need not necessarily start with "Content-" I would have thought) RFC2045 extension-fields are defined as starting with "Content-". We could support arbitrary field names, but then let's call it something beside extension-field. > might have some entirely different syntax, or perhaps no syntax at all. It admits at least one attribute, which can be any characters except CRLF, SPACE, and HTAB. The only syntax it doesn't admit is simply the header name. We could allow that, but I don't think it's necessary. > ps: Also remember, if you're using RFC ABNF grammars (as opposed to the > semi-defined thing that was in RFC822) then you also need to be explicit > about where white space is to be permitted, if anywhere. Using RFC ABNF, > the example you gave didn't fit your grammar, as you included (in the > example) spaces between "Disposition:" and "attachment", and again > between "attachment;" and "filename=" (and in the actual directive > line, between "pdf;" and "<>" and between "]" and "/tmp/foo".) This is mhbuild, not RFC, syntax. The mhbuild composition file grammar doesn't explicitly show whitespace. For example, directive starts with: "#" type "/" subtype, but this is supported: # text/ plain foo.txt David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Re: suppress Content-ID's with new mhbuild option?
Peter Galbraith <[EMAIL PROTECTED]> writes: > Jon Steinhart <[EMAIL PROTECTED]> wrote: > >> If you decide to make these additions, keep in mind that they have to >> be done in the send code, not in the whatnow code. This is because >> the design of the attachment code was such that it would work >> independent of the user interface. In particular, I know people who >> have hacked mh-e to add attachment headers. > > I'm sure Bill will chime-in here... MH-E now can use either mhn > attachment directives, or gnus directives. The Content-Type is (for the > most part) filled-in automatically using `file -i'. Don't need to when the other MH-E developers do so for me ;-). Note that MH-E calls mhbuild/mhn to expand the directives before calling send. I haven't been following this discussion close enough to know how that impacts the design. p.s. We've started calling MH-E as such with all uppercase since version 7. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Re: Editing MIMEd messages
Jon Steinhart <[EMAIL PROTECTED]> writes: > The mhbuild stuff allows access to the guts. But, it is not a viable > user interface for non-geeks, and is too difficult to use for casual > attaching files to messages. > > Nothing in the attachment code that I added eliminated the mhbuild stuff. > It just adds an easier-to-use user interface that invokes mhbuild. Sounds like MH-E already does what you propose. We call mhbuild implicitly upon sending, but the user, such as Jerry ;-), can always invoke it manually (`C-c C-e') before sending to see (and edit) the MIME stuff. -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
> > directive::= "#" type "/" subtype
> > 0*(";" attribute "=" value)
> > [ "(" comment ")" ]
> > [ "<" id ">" ]
> > [ "[" description "]" ]
> > [ filename ]
> > EOL
> > [ "#" extension-field ]
> >
> > where extension-field just can't look like a directive.
>
> Like this?
>
> extension-field::="Content-" fieldname ":"
> attribute [ "=" value ]
> 0*(";" attribute [ "=" value ])
>
> #application/pdf; <>[ Adobe Portable Document Format (PDF) v1.2 ] /tmp/foo.pd
> f
> #Content-Disposition: attachment; filename="foo.pdf"
Yes for the example, no for the grammar, although I got the grammar I wrote
wrong anyway. :) Firstly, how does the example look to you? The colon
isn't really necessary, and keep in mind that the line might be immediately
followed by another directive.
Regarding your grammar, I think it's wrong as a general RFC2045 grammar
because the value of the field can be any text, no? It's the right grammar
for Content-Disposition though.
Another reason I suggested this grammar is that I think the parsing of
it will be quite easy to fit into the existing mhbuildsbr.c code.
Cheers,
- Joel
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
