Re: [Nmh-workers] Editing MIMEd messages, etc.
> > > 1. Add an -attach option to mhbuild that is similar to the one that I > > > added to whatnow and send. If set, mhbuild will process attachment > > > headers in addition to the mime-composition file body. This is a > > > bit tricky because the whatnow attach code treats the message body as > > > a normal file, but should work because the user will either be > > > invoking whatnow mime or automimeproc which will mhbuild the message > > > before it gets to the send attach code. > > > > Great. That takes care of send invoking mhbuild again because the > > attachment headers would disappear. I'll do this ASAP and reuse the > > existing attachment header code. Will split it out into another file > > for that, I think. > > > > Alternatively mhbuild could do the attachment header handling for send too, > > and instead send could protect #-beginning lines in any draft it gets. > > Does anyone think that's better? > > Well, mhbuild DOES do the attachment header handing for send. > > This is a bit tricky. I would say that if mhbuild is being run from send > then it should do what the current attachment code does which is to protect > the #s. But, if it is run using whatnow mime then it should not protect > them because it will make it useless. Possibly the thing to do is to have > yet another option to mhbuild that indicates whether or not to process > directives in the body. > > If you do this, then mhbuild may need to so some of the automatic filling > in of things like content-type that the current attachment code now does. > Again, probably an excuse to go option crazy on mhbuild. Not quite what I meant. I certainly don't want to add another option to mhbuild. It's unnecessary. The two possibilities are as follows: 1) Put turn-header-into-mhbuild-directive code in a place that both send and mhbuild can use. End of story. 2) Put turn-header-into-mhbuild-directive code into *just* mhbuild, and have send preprocess #-beginning lines to protect them if it has detected any mhbuild-causing headers, i.e. it's about to hand the message over to mhbuild. It's purely an implementation question. > I have no objection to the new profile components, but would keep the old > options for compatibility. A question though - would you be able to > override these components on the command line? I feel that it's good to > be able to do so, which is why I went with the turn on/of option pairs > when I did the original code. Yes, I said I wanted these components to be overridable. To be honest I hadn't considered a -noattach option but perhaps it's needed for the semantics I'd intended. Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
> Just yesterday I had to construct some messages using both - > description and -disposition. We need to figure out a syntax > extension that will support generating both headers. And once the mhbuild syntax extension is worked out, *then* the attachment header code can be changed... Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
> I was afraid of that.
>
> How about using {} to encapsulate the -disposition parameters:
>
> directive ::= "#" type "/" subtype
> 0*(";" attribute "=" value)
> [ "(" comment ")" ]
> [ "<" id ">" ]
> [ "{" disposition-type 0*(";" attribute "=" value) "}" ]
> [ "[" description "]" ]
> [ filename ]
> EOL
>
> E.g.,
>
> #application/pdf <>{attachment; filename="foo.pdf"}[Adobe PDF v1.3] foo.pdf
>
> This is no longer very easy to implement :-/
My feeling is that a delimited string might not be appropriate for this
because content-disposition has an internal grammar, unlike comments,
ids, and descriptions.
Perhaps something like what mhbuild does with Content-Description in
plaintext is appropriate, i.e. if a Content-Disposition line follows
immediately after a directive it is treated as a header for that MIME
entity. In fact, what might be even clearer is if the Content-Disposition
line is escaped with a #, because then if it's divorced from a directive
mhbuild will treat it as an error. In fact, this might be a way to
do all MIME extension fields. The grammar then becomes
directive::= "#" type "/" subtype
0*(";" attribute "=" value)
[ "(" comment ")" ]
[ "<" id ">" ]
[ "[" description "]" ]
[ filename ]
EOL
[ "#" extension-field ]
where extension-field just can't look like a directive.
Cheers,
- Joel
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Editing MIMEd messages, etc.
> How 'bout this? Why not add another option similar to the -attach > option that I added to whatnow and send? Why not add a -forward > option that would specify the name of another header that would be used > for forwarding messages. So, for example, if you had in your profile > > repl: -forward X-MH-Forward > forw: -forward X-MH-Forward > send: -attach X-MH-Attachment -forward X-MH-Forward > whatnow:-attach X-MH-Attachment > > then if you were reading message inbox/10 and did a repl -mime it would > add the header > > X-MH-Forward: inbox/10 I think it might be nicer to mimic the syntax of the #forw directive here, i.e. be able to say X-MH-Forward: +inbox 10 15 21 There are a couple of reasons for this. Firstly, it allows for grouping of forwarded message into digests, which is exactly what the #forw directive allows. Secondly, it might be nice to permit the full power of message ranges and sequences to be used. As far as I can tell it does not make the implementation any more difficult, since mhbuild still does all the work. I also think it is not any more difficult to read, so it satisfies the aim of keeping these headers intelligible. I think it's a little easier to read, in fact. This seems fine to me. > > As I've stated earlier, I haven't had a problem with the way that things > > are so I'm not motivated to make changes. For those who are motivated, > > I suggest the following: > > > > 1. Add an -attach option to mhbuild that is similar to the one that I > > added to whatnow and send. If set, mhbuild will process attachment > > headers in addition to the mime-composition file body. This is a > > bit tricky because the whatnow attach code treats the message body as > > a normal file, but should work because the user will either be > > invoking whatnow mime or automimeproc which will mhbuild the message > > before it gets to the send attach code. > > Great. That takes care of send invoking mhbuild again because the > attachment headers would disappear. I'll do this ASAP and reuse the > existing attachment header code. Will split it out into another file > for that, I think. > > Alternatively mhbuild could do the attachment header handling for send too, > and instead send could protect #-beginning lines in any draft it gets. > Does anyone think that's better? > > One more thing. Would anyone object to profile components like > Attach-Header: X-MH-Attach > Forward-Header: X-MH-Forward > > When I first started using the attachment handling stuff the fact that > it was done with arguments to whatnow and send confused me. I think it > might be good to keep that so that run-time overriding of the headers > can be done (and perhaps this is an easier hook for frontends), but with > this spreading to other commands now it might be nice to have a common, > but overridable place to configure these. Well, mhbuild DOES do the attachment header handing for send. This is a bit tricky. I would say that if mhbuild is being run from send then it should do what the current attachment code does which is to protect the #s. But, if it is run using whatnow mime then it should not protect them because it will make it useless. Possibly the thing to do is to have yet another option to mhbuild that indicates whether or not to process directives in the body. If you do this, then mhbuild may need to so some of the automatic filling in of things like content-type that the current attachment code now does. Again, probably an excuse to go option crazy on mhbuild. I have no objection to the new profile components, but would keep the old options for compatibility. A question though - would you be able to override these components on the command line? I feel that it's good to be able to do so, which is why I went with the turn on/of option pairs when I did the original code. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Editing MIMEd messages
> As I've stated earlier, I haven't had a problem with the way that things > are so I'm not motivated to make changes. For those who are motivated, > I suggest the following: > > 1. Add an -attach option to mhbuild that is similar to the one that I > added to whatnow and send. If set, mhbuild will process attachment > headers in addition to the mime-composition file body. This is a > bit tricky because the whatnow attach code treats the message body as > a normal file, but should work because the user will either be > invoking whatnow mime or automimeproc which will mhbuild the message > before it gets to the send attach code. Great. That takes care of send invoking mhbuild again because the attachment headers would disappear. I'll do this ASAP and reuse the existing attachment header code. Will split it out into another file for that, I think. Alternatively mhbuild could do the attachment header handling for send too, and instead send could protect #-beginning lines in any draft it gets. Does anyone think that's better? One more thing. Would anyone object to profile components like Attach-Header: X-MH-Attach Forward-Header: X-MH-Forward When I first started using the attachment handling stuff the fact that it was done with arguments to whatnow and send confused me. I think it might be good to keep that so that run-time overriding of the headers can be done (and perhaps this is an easier hook for frontends), but with this spreading to other commands now it might be nice to have a common, but overridable place to configure these. Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Forwarded messages attachment headers (was Re: [Nmh-workers] Should attachment header handling be in send?)
> How 'bout this? Why not add another option similar to the -attach > option that I added to whatnow and send? Why not add a -forward > option that would specify the name of another header that would be used > for forwarding messages. So, for example, if you had in your profile > > repl: -forward X-MH-Forward > forw: -forward X-MH-Forward > send: -attach X-MH-Attachment -forward X-MH-Forward > whatnow:-attach X-MH-Attachment > > then if you were reading message inbox/10 and did a repl -mime it would > add the header > > X-MH-Forward: inbox/10 I think it might be nicer to mimic the syntax of the #forw directive here, i.e. be able to say X-MH-Forward: +inbox 10 15 21 There are a couple of reasons for this. Firstly, it allows for grouping of forwarded message into digests, which is exactly what the #forw directive allows. Secondly, it might be nice to permit the full power of message ranges and sequences to be used. As far as I can tell it does not make the implementation any more difficult, since mhbuild still does all the work. I also think it is not any more difficult to read, so it satisfies the aim of keeping these headers intelligible. I think it's a little easier to read, in fact. Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Should attachment header handling be in send?
> Jon Steinhart wrote: > > > > The attach command is convenient though. Perhaps if the -attach option > > > is not set in .mh_profile, attach could add an mhbuild directive to the > > > body. > > > > I'm not sure what you mean by this. Are you suggesting that if some option > > is not set in the profile, then the whatnow attach command run mhbuild? > > Wouldn't that be the same as running the whatnow mime command? > > Currently, the attach command defaults to printing: > "whatnow: can't attach because no header field name was given." > If a header field name is given it adds the filename to the header. What > I'm suggesting is that the default is to construct an mhbuild directive > - something like `#text/plain; name="foo" <>[] ~/foo' and stick it on > the end of the body of the message draft. That's a little misleading. With the attach command as it currently stands the attachment is guaranteed to be done, or at least not fail silently. With what you are wanting, however, the attachment will not be done until the user explicitly runs the draft through mhbuild, or has automimeproc set. One of the nice things about Jon's scheme is that it effectively saves state in the draft with the presence of a new header, i.e. the state of there being pending attachments, and this header indicates to send that the draft needs extra processing. Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Editing MIMEd messages
Jerry wrote: > > MIMEd messages really shouldn't be edited > > I had to disagree. One of the reasons I like the sort-of arcane > MIME setup in MH/nmh is because I *can* edit the message draft with > vi (or whatever). For instance, after I type "mime" to build the > draft, I can remove the header fields from a forwarded message that > reveal some personal details about my mail-handling setup (such as > the annotations that come from "anno", forwarding, etc.). I can > delete bloated quotes, remove or rearrange body parts, change the > separator string to make multipart/alternative into something else, > and so on. Most monolithic mailers hide those details from me. > I hope nmh never does. You can always use vi to construct mime messages from scratch too; wc is especially useful for getting the content length :) I like the fact that mh allows access to the guts for those who are interested. But, I also like the fact that it's a usable system; I can do show > foo rather than having to learn a special command that saves to a file. 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. I think that there are three issues here, with the rest of the discussion just going off the deep end. #1 Combining both methods (whatnow attach and mime composition file) does not work, #2 Some would like the ease of use of whatnow attach combined with the flexibility of mime composition files, and #3 Because of #1, using whatnow attach and forw/repl -mime doesn't work sensibly. As I've stated earlier, I haven't had a problem with the way that things are so I'm not motivated to make changes. For those who are motivated, I suggest the following: 1. Add an -attach option to mhbuild that is similar to the one that I added to whatnow and send. If set, mhbuild will process attachment headers in addition to the mime-composition file body. This is a bit tricky because the whatnow attach code treats the message body as a normal file, but should work because the user will either be invoking whatnow mime or automimeproc which will mhbuild the message before it gets to the send attach code. This change allows both methods to be combined, and allows the mimed message to be viewed and edited. And, it should be a pretty simple change. 2. Add a -forward option to repl, forw, whatnow, and send as per my earlier email. This will allow the forwarded message to be typed as an 822. 3. Write a shell script that can be run using an editor escape that takes as many or as few options as you like and spits out mime composition file lines. I think that that's the best way to get easier to use functionality than mime composition files without breaking the current whatnow attach functionality. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Should attachment header handling be in send?
Oliver wrote: > Currently, the attach command defaults to printing: > "whatnow: can't attach because no header field name was given." > If a header field name is given it adds the filename to the header. What > I'm suggesting is that the default is to construct an mhbuild directive > - something like `#text/plain; name="foo" <>[] ~/foo' and stick it on > the end of the body of the message draft. Well, I guess that this would work. I see two issues with it. First, there is no "annotate body" function so one would have to be written. But that's no big deal. The harder one is what to do about any existing body content. Should the code scan it looking for #s and parse them to determine which ones are mhbuild directives and double the #s for ones that are not? Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
> > > Perhaps you should create a new utility that writes build directives > > > and works both interactively and non-interactively, depending on the > > > command line options? If it is able to write both directives and > > > attachment headers, whatnow can use it for a *really* versatile way to > > > attach stuff, and it could also be used from many UNIX editors with > > > a shell. > > > > At this point, I don't see sufficient need. Build > > directives are straightforward. I have only ever used two, > > one for text and one for application attachments, and never > > had to change their structure. > > Huh? Then why all this talk about getting whatnow to do this-or-that to > the content parameters? That's what I'm suggesting might be best placed > in a new utility. > > I certainly don't need it, but I'd prefer to see it there rather than > in whatnow, or even a super-smart send or mhbuild. > > Perhaps I've misunderstood your objective. My objective is to be able to use -attach, which is straightforward and safer than dealing with mhbuild directives directly, to generate MIME messages that 1) all versions of Outlook can understand, and 2) are RFC 1806 and 2183 compliant. mhbuild -nocontentid now gets me 1). If we can get mhbuild -contentdisposition going, I'll have 2). David ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Editing MIMEd messages
I haven't been following this discussion very closely (I'm working two jobs these days...), so my comment may be out of order here. I've changed the subject of this message because my comment is sort of tangential to this topic. When I saw this: On 2 February 2006 at 14:26, Joel Reicher <[EMAIL PROTECTED]> wrote "Re: [Nmh-workers] Should attachment header handling be in send?" > > MIMEd messages really shouldn't be edited I had to disagree. One of the reasons I like the sort-of arcane MIME setup in MH/nmh is because I *can* edit the message draft with vi (or whatever). For instance, after I type "mime" to build the draft, I can remove the header fields from a forwarded message that reveal some personal details about my mail-handling setup (such as the annotations that come from "anno", forwarding, etc.). I can delete bloated quotes, remove or rearrange body parts, change the separator string to make multipart/alternative into something else, and so on. Most monolithic mailers hide those details from me. I hope nmh never does. And now back to our regularly scheduled discussion... Jerry ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] mhbuild Content-Disposition header
David Levine wrote: > I want: > > #text/plain <>[attachment; filename="foo.txt"] /tmp/foo.txt > #application/pdf <>[attachment; filename="foo.pdf"] /tmp/foo.pdf I don't see why you can't take something like the following: #text/plain; name="foo.txt"; <>[description] /tmp/foo.txt And pull the name= part out and use it for the filename in Content-Disposition. That'd add backward compatibility with old scripts that generate mhbuild directives automatically. And having to write out "attachment" in full is too verbose. I would make "attachment" the default and use a single character, `-' perhaps, to indicate "inline". > The "almost" part is that mhbuild currently creates > Content-Description instead of Content-Disposition. I > hijacked the Content-Description information and used it to > form the Content-Disposition header (with or without > -attach). (Is that a good idea? Or, should > Content-Description be maintained, and new code and data > fields added to support Content-Disposition? I have no need > for Content-Description.) Content-Description should be maintained. I would prefer if attach left it empty by default. It's supposed to describe the content and not describe the type of the content type that's a different matter. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Should attachment header handling be in send?
Jon Steinhart wrote: > > The attach command is convenient though. Perhaps if the -attach option > > is not set in .mh_profile, attach could add an mhbuild directive to the > > body. > > I'm not sure what you mean by this. Are you suggesting that if some option > is not set in the profile, then the whatnow attach command run mhbuild? > Wouldn't that be the same as running the whatnow mime command? Currently, the attach command defaults to printing: "whatnow: can't attach because no header field name was given." If a header field name is given it adds the filename to the header. What I'm suggesting is that the default is to construct an mhbuild directive - something like `#text/plain; name="foo" <>[] ~/foo' and stick it on the end of the body of the message draft. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?
> > Perhaps you should create a new utility that writes build directives > > and works both interactively and non-interactively, depending on the > > command line options? If it is able to write both directives and > > attachment headers, whatnow can use it for a *really* versatile way to > > attach stuff, and it could also be used from many UNIX editors with > > a shell. > > At this point, I don't see sufficient need. Build > directives are straightforward. I have only ever used two, > one for text and one for application attachments, and never > had to change their structure. Huh? Then why all this talk about getting whatnow to do this-or-that to the content parameters? That's what I'm suggesting might be best placed in a new utility. I certainly don't need it, but I'd prefer to see it there rather than in whatnow, or even a super-smart send or mhbuild. Perhaps I've misunderstood your objective. Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
