Re: [Nmh-workers] (no subject)
Date:Tue, 19 Aug 2014 22:59:39 -0400 From:David Levine levin...@acm.org Message-ID: 11370-1408503579.500072@A_1p.VkY5.6m-M | multipart/alternative IS different than any other content. All the different content types are different in some way or other, that's why they have different names... | The question is how mhlist/mhstore should present the part ordering | to the user. I cannot really see how it is possible to rationally argue for anything different than the order the parts appear in the message being the same order they're listed (unless the user expressly has configured things to do something different). I had no idea that it was different (before this discussion) - but then again, I don't use mhlist, mhstore or mhshow, I mostly look at mime messages with exmh (which presents the alternatives in the order they appear in the message) or with vi (wrapped in scripts/sh functions which give it mh type arg conventions). | It makes sense to me to list the most preferred | part first as part 1, the next second as part 2, and so on. In that case, text/plain would be first, text/html somewhere near last, and application/msword deleted completely... | The parts are stored in reverse order in the message to make | them easier to view with non-MIME-conformant viewers. That's the rationale for building messages with alternatives in the order they are built, yes. | That is irrelevant to a user of mhlist/mhstore. Why expose it? Because (like all of MH) more than the MH (nmh) comands get used to process messages, and commands that are just sh scripts, that look for the boundaries, and count them, don't know about some fancy reordering that mhlist is doing because it thinks we prefer it that way (which we quite possibly don't in any case). Even with reversing, you cannot just blindly assume that the first alternative listed is going to be the html variant (it might be in many messages, but there's no guarantee) - you have to look at a listing of the message structure and pick the part that you want to view, or store - given that, does it really make a difference if what you store is 1.3 rather than 1.1 (and every now and again it happens to be 1.2) ? In this, I totally agree with Ken, presenting anything to the user other than what is actually in the message is just perverted. Of course, I also agree (with everyone I think) that the ordering used should be consistent, what is part 1.2 for one command must be 1.2 for every command that understands this terminology. kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] (no subject)
Ken wrote: [David:] The parts are stored in reverse order in the message to make them easier to view with non-MIME-conformant viewers. That is irrelevant to a user of mhlist/mhstore. Why expose it? I guess it's all about what you mean by reverse order. The same as RFC 2046 §5.1.4 means. So, why expose it? Well, everywhere else we display the exact MIME structure as it exists in the message. We do here, too. Maybe my point about non-MIME-conformant viewers isn't coming through. When using MIME tools, I want the MIME structure that the tools, such as mhshow, use. When using less(1), I get what's in the file, but I'm on my own to impose any kind of structure on it. I found the exception for multipart/alternative confusing, and it's non-obvious behavior if you know about MIME. I disagree, especially after seeing the rationale in the RFC. I wasn't actually proposing to change just mhlist; what would happen would be to simply delete the reverse_parts() function. Please don't. I would have done it back when I first discovered this, And maybe there's an nmh user out there who's glad you didn't :-) David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] (no subject)
kre wrote: [David:] | It makes sense to me to list the most preferred | part first as part 1, the next second as part 2, and so on. In that case, text/plain would be first, text/html somewhere near last, and application/msword deleted completely... That's not right: 1) I use preferred the same way that RFC 2046 §5.1.4 uses it: multipart/alternative entities must place the body parts in increasing order of preference, that is, with the preferred format last. For fancy text, the sending user agent should put the plainest format first and the richest format last. 2) The sender decides the preference. 3) It's not up to mhlist to delete alternatives. | That is irrelevant to a user of mhlist/mhstore. Why expose it? Because (like all of MH) more than the MH (nmh) comands get used to process messages, and commands that are just sh scripts, that look for the boundaries, and count them, don't know about some fancy reordering that mhlist is doing because it thinks we prefer it that way (which we quite possibly don't in any case). Boundaries are at a low level, MIME structure is at a higher level. mhlist doesn't present the boundaries, even with -verbose. It presents the MIME structure in the way that I think is more useful; see below. And see my previous comments about non-MIME-conformant viewers (that term is also in the RFC). The MH and nmh behavior has been this way for at least 22 years and is (recently) documented. The reordering is not fancy, it's trivial and discussed by the RFC. And, my whole point: because scripts rely on MH/nmh commands, don't change those commands (when not necessary). Even with reversing, you cannot just blindly assume that the first alternative listed is going to be the html variant (it might be in many messages, but there's no guarantee) - you have to look at a listing of the message structure and pick the part that you want to view, or store - given that, does it really make a difference if what you store is 1.3 rather than 1.1 (and every now and again it happens to be 1.2) ? If I was writing a script that relied on output of mhlist to choose a part of a multipart/alternative, I would iterate over the parts until I found the one that I wanted (based on type, not part number), then break out of the loop. Just what mhshow does. If mhlist ordered multipart/alternative parts in increasing order of preference, I'd have to iterate from the back. Doable but takes (me, but maybe not you and Ralph :-) more work. In this, I totally agree with Ken, presenting anything to the user other than what is actually in the message is just perverted. mhlist does show what is actually in the message. Nothing is lost with the presentation. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
Ken Hornstein k...@pobox.com writes: The same goes for, show, mhshow, next and prev. They should go into nmh-1.7 pretty much as is, but deprecated, and be absent from nmh-1.8. Hm, that's not what I was thinking. I was thinking show, next, and prev would still stick around (they wouldn't even change that much). They'd get some new switches that mhshow had (and presumably pass them down to mhl).' I believe that what I say below is consistent with your original message, which is where I got the idea. I hope and believe that not much more coding than you envisioned is entailed, though perhaps some refactoring might be involved. In my humble opinion, mhshow already has too many switches and does too many things. In my fantasy, the new version of mhshow (call it 'see' ?) would normally take as its stdin the stdout of the new version of mhl (call it 'mhmime' ?). That is, mhmime would be responsible for understanding a message, and see would be responsible for displaying the message to a user. So the switches to mhmime would control how the message was interpreted and the switches to see would control how the message was displayed. In the era when MH began, interpretation was trivial, so it was not perceived as a special function. Though, perhaps even then, it should have been. In retrospect it is clear (at least to guy like me who doesn't have to write the code :-) ) that interpretation and display are separate functions and should be furnished by separate commands. Do one thing and do it well. Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] I need to learn more about MIME
In order to participate more meaningfully in these discussions I need to learn more about MIME. Studying and becoming familiar with the relevant RFCs is much more than I want to or am able to do. I tried starting with http://en.wikipedia.org/wiki/MIME, but the tree of links overwhelmed me. Can anybody suggest a course of study so that I can learn enough about MIME to able to participate, meaningfully, in most of these discussions? Norman Shapiro ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] Items for nmh 1.7
In my humble opinion, mhshow already has too many switches and does too many things. In my fantasy, the new version of mhshow (call it 'see' ?) would normally take as its stdin the stdout of the new version of mhl (call it 'mhmime' ?). That is, mhmime would be responsible for understanding a message, and see would be responsible for displaying the message to a user. So the switches to mhmime would control how the message was interpreted and the switches to see would control how the message was displayed. Well, my view was that the relationship between show and mhl is kind of like send and post; send has a lot of switches, but most of them are passed down to post. send takes care of picking the message, doing some MIME processing if necessary, but the actual message submission gets done by post. Also, some practical concerns arise: - As we've seen in repeated examples, people don't read the documentation about new commands or features. So if new commands are required to handle MIME messages (and nowadays, that's pretty much all of them) then they will get little use and people will continue to think our MIME support is lousy. I think our experience with show in 1.6 has shown we can do better with the existing interface. - I'm unclear about what exactly these new mhmime and see commands are going to do, exactly. Right now 'show' handles things at the folder level; you give it a folder, message numbers, sequence names, and it handles folder level tasks like interpreting sequence names, removing messages from the unseen sequence, etc etc. mhl takes filenames from show and interpets them and displays them. My proposal is really about making mhl smarter. But I don't know what 'mhmime' is supposed to output; the interpreted MIME contents of the message? Would that be some more structured content of the message? Just the text parts, like mhshow does now by default? What would this 'see' command exactly be doing? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] I need to learn more about MIME
In order to participate more meaningfully in these discussions I need to learn more about MIME. Studying and becoming familiar with the relevant RFCs is much more than I want to or am able to do. I tried starting with http://en.wikipedia.org/wiki/MIME, but the tree of links overwhelmed me. Can anybody suggest a course of study so that I can learn enough about MIME to able to participate, meaningfully, in most of these discussions? We have a set of links here: http://www.nongnu.org/nmh/rfc.html RFC 2045 is sort of a broad overview of the format of a MIME message. That explains the extra headers you need for a MIME message. It's going to be pretty dry reading, though. As a companion with that, look at RFC 2046 to cover the common media types (like multipart). I see the Wikipedia entry is a bit confusing, as it covers a lot of MIME types that are not used by email (HTTP also uses MIME types). My advice is: - Take a look at this message, and compare the headers here to the descriptions in RFC 2045. This should be a pretty simple message, so it should be easy enough to undertand. I know, I know ... you're reluctant to look at the RFCs. At least give RFC 2045 a try; looking at an example message might make it more concrete. I wouldn't try reading the whole thing from start to finish; jump around and read the text for specific headers. - Take a look at a multipart message, and see the description in RFC 2046 how multipart messages are formatted. - There is a pretty good example of a more complicated message in RFC 2049, Appendix A. The basic framework is actually not very complicated; it's just a lot of stuff you need to know is spread out over multiple documents. At this stage you can ignore much of the extra stuff until you master the basics. And of course feel free to ask questions if you're confused! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] I need to learn more about MIME
On Wed, Aug 20, 2014 at 09:40:44AM -0700, n...@dad.org wrote: In order to participate more meaningfully in these discussions I need to learn more about MIME. Studying and becoming familiar with the relevant RFCs is much more than I want to or am able to do. I tried starting with http://en.wikipedia.org/wiki/MIME, but the tree of links overwhelmed me. Can anybody suggest a course of study so that I can learn enough about MIME to able to participate, meaningfully, in most of these discussions? There's an O'Reilly book called _Programming Internet Email_ http://shop.oreilly.com/product/9781565924796.do that has a whole chapter on MIME. That might be a good tutorial. The book is from 1999, but I suspect it's still mostly correct. -- Peter Davis The Tech Curmudgeon www.techcurmudgeon.com ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] (no subject)
Date:Wed, 20 Aug 2014 09:46:18 -0400 From:David Levine levin...@acm.org Message-ID: 15304-1408542378.667...@nzlb.vy7x.fqve | 1) I use preferred the same way that RFC 2046 §5.1.4 uses it: OK, but that's (as you said) from the sender's perspective. When I am using these tools, I'm not the server, and it is my preference that should matter. Of course, if I have no preference, then using the sender's is fine, but in this case, I do. | 3) It's not up to mhlist to delete alternatives. Of course .. that was a (kind of, and fairly weak) attempt at humour... | Boundaries are at a low level, MIME structure is at a higher level. The boundaries define the MIME structure (along with the associated headers) so they're really at the same level - forming the content of them might be a lower level but that's not relevant here. | mhlist doesn't present the boundaries, even with -verbose. No, but it uses them. | And, my whole point: because scripts rely on MH/nmh commands, | don't change those commands (when not necessary). I agree with that principle, but here it really is necessary - the current behaviour can't really be justified as anything other than a bug. That it was recently documented doesn't change that characterisation. | If mhlist ordered multipart/alternative parts in increasing | order of preference, I'd have to iterate from the back. You could, but I wouldn't - better to simply iterate over all the alternatives, and remember which one is the one you want to display. There are not going to be so many that optimising by exiting the loop early is going to be of any measurable benefit, and looking at all the alternatives makes it easy to allow the user to set their own preference to override the sender's (which seems to be a much requested feature - hard to implement at the minute (I assume) because the code is not looking at all the alternatives). | mhlist does show what is actually in the message. Nothing is | lost with the presentation. No it doesn't, for a message I have ... msg part type/subtype size description 47 multipart/alternative 27K 1 text/html 10K Message in HTML form 2 text/plain9984 Message in clear text but when I look inside the message, the first alternative is text/plain and the second is text/html - mhlist is lying to me. If I were to write a script (not using mhstore, but sed) to save the text/plain part, I'd get the html variant instead. That's just broken. kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] (no subject)
kre wrote: Date:Wed, 20 Aug 2014 09:46:18 -0400 From:David Levine levin...@acm.org Message-ID: 15304-1408542378.667...@nzlb.vy7x.fqve | 1) I use preferred the same way that RFC 2046 §5.1.4 uses it: OK, but that's (as you said) from the sender's perspective. When I am using these tools, I'm not the server, and it is my preference that should matter. That's fine. But these tools MUST support my preference, which is to display the most preferred, as determined by the sender, alternative that I can display. mhshow does. mhlist's output agrees with it, as I tried to explain to Ken here: # Now that you bring up multipart/mixed: mhshow and mhlist # display and list, respectively, the parts of multipart/mixed in # the same order. mhshow and mhlist also (attempt to) display and # list, respectively, the parts of multipart/alternative in the # same order. This is just another way of looking at why I think # it would be wrong to change mhlist. We'd have inconsistent # behavior. | Boundaries are at a low level, MIME structure is at a higher level. The boundaries define the MIME structure (along with the associated headers) so they're really at the same level - forming the content of them might be a lower level but that's not relevant here. I disagree, and it is relevant. It's easy to show that boundaries are at a lower level: other mechanisms could have been used to delineate message parts while supporting what we now recognize as MIME structure. The user of tools for doing expected manipulations with the message wouldn't know, and shouldn't care, about that mechanism. | mhlist doesn't present the boundaries, even with -verbose. No, but it uses them. Of course, but just internally. There's no need for it to present them. | And, my whole point: because scripts rely on MH/nmh commands, | don't change those commands (when not necessary). I agree with that principle, but here it really is necessary - the current behaviour can't really be justified as anything other than a bug. That it was recently documented doesn't change that characterisation. I haven't seen any justification for calling it a bug. All I've seen is that it's a preference. It is not necessary to impose a new preference for display order on owners of existing scripts. I just found that it's documented in Jerry's book: http://oreilly.com/openbook/mh/limimepa.htm Last change $Date: 1996/06/06 15:11:06 $ | If mhlist ordered multipart/alternative parts in increasing | order of preference, I'd have to iterate from the back. You could, but I wouldn't - better to simply iterate over all the alternatives, and remember which one is the one you want to display. That's fine. But also not as simple as search until you find one you can use. looking at all the alternatives makes it easy to allow the user to set their own preference to override the sender's (which seems to be a much requested feature - hard to implement at the minute (I assume) because the code is not looking at all the alternatives). mhlist does display all of the alternatives and mhstore can store any of them, and mhshow can display any of them. Any user preference is currently supported, using -part or -type. All we're talking about is the order of display of alternatives of a multipart/alternative by mhlist (with consistent use by mhstore). | mhlist does show what is actually in the message. Nothing is | lost with the presentation. No it doesn't, for a message I have ... msg part type/subtype size description 47 multipart/alternative 27K 1 text/html 10K Message in HTML form 2 text/plain9984 Message in clear text but when I look inside the message, the first alternative is text/plain and the second is text/html - mhlist is lying to me. mhlist isn't lying. You define the order of alternatives differently than it does. You don't have to like it, but it's not lying. If I were to write a script (not using mhstore, but sed) to save the text/plain part, I'd get the html variant instead. That's just broken. The sed script would be broken, not mhlist. No doubt we disagree on that, but you and Ken haven't been able to convince me otherwise. When I asked: Is there anything *wrong* with the current behavior? Ken's response was about preference. Our preferences our different, but neither is wrong. Therefore, I see no reason to change a 22-year, at least, precedent. If you guys want to add an -alternatives best-first switch, or maybe better, some profile component to display in that order, have at it. Just don't change the default behavior. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] I need to learn more about MIME
Norm wrote: In order to participate more meaningfully in these discussions I need to learn more about MIME. Jerry's book has a no-nonsense intro to MIME: http://oreilly.com/openbook/mh/tocs/intmime.htm David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
