* Partial message handling in pterodactyl gnus? @ 1999-04-20 15:46 Hamish Macdonald 1999-06-12 2:27 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 9+ messages in thread From: Hamish Macdonald @ 1999-04-20 15:46 UTC (permalink / raw) TM had mechanisms for sending/handling split messages (message/partial MIME stuff). I don't see anything in pterodactyl gnus 0.83 pertaining to this. I don't like sending split messages, but I sometimes receive them from people and it would be nice if pgnus could grok them. Is any work being done on this? Thanks, Hamish. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Partial message handling in pterodactyl gnus? 1999-04-20 15:46 Partial message handling in pterodactyl gnus? Hamish Macdonald @ 1999-06-12 2:27 ` Lars Magne Ingebrigtsen 1999-06-12 13:01 ` Hrvoje Niksic 0 siblings, 1 reply; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-06-12 2:27 UTC (permalink / raw) Hamish Macdonald <hamish@sybarus.ca> writes: > TM had mechanisms for sending/handling split messages (message/partial > MIME stuff). I don't see anything in pterodactyl gnus 0.83 pertaining > to this. No, there is nothing in Pterodactyl for handling message/partial. I don't even know if I want Gnus to be able to create message/partial, but it certainly should be able to grok it... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Partial message handling in pterodactyl gnus? 1999-06-12 2:27 ` Lars Magne Ingebrigtsen @ 1999-06-12 13:01 ` Hrvoje Niksic 1999-06-13 1:24 ` Lars Magne Ingebrigtsen [not found] ` <oq674t5sa6.fsf@titan.progiciels-bpi.ca> 0 siblings, 2 replies; 9+ messages in thread From: Hrvoje Niksic @ 1999-06-12 13:01 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > No, there is nothing in Pterodactyl for handling message/partial. I > don't even know if I want Gnus to be able to create message/partial, Oh yes. Some sendmails simply refuse to grok emails larger than a number of bytes (often set quite low), in which case having a MIME mechanism for sending larger things is very useful. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Partial message handling in pterodactyl gnus? 1999-06-12 13:01 ` Hrvoje Niksic @ 1999-06-13 1:24 ` Lars Magne Ingebrigtsen [not found] ` <oq674t5sa6.fsf@titan.progiciels-bpi.ca> 1 sibling, 0 replies; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-06-13 1:24 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > Oh yes. Some sendmails simply refuse to grok emails larger than a > number of bytes (often set quite low), in which case having a MIME > mechanism for sending larger things is very useful. Okidoke; so support for creating message/partial will have to be added. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <oq674t5sa6.fsf@titan.progiciels-bpi.ca>]
* Re: Partial message handling in pterodactyl gnus? [not found] ` <oq674t5sa6.fsf@titan.progiciels-bpi.ca> @ 1999-06-13 6:36 ` Lars Magne Ingebrigtsen 1999-06-14 3:03 ` Aaron M. Ucko 0 siblings, 1 reply; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-06-13 6:36 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2146 bytes --] François Pinard <pinard@iro.umontreal.ca> writes (to me, but I'm answering on the list): > We would most probably like to find some way to receive and re-assemble > them, however. I agree that it is not easy to solve that problem elegantly, > yet you already made notable efforts in Gnus to reassemble split shars. Yes, but I don't think that we should do it that way. I've now read the bits in RFC2046 that talks about message/partial, and it's quite explicit in how it feels that these messages should be displayed. In short, the user should not see several messages -- the user shouldn't even see one encapsulated message. The user should only see one message, and that message should have the headers from the encapsulated message coupled with some of the headers from the messages themselves. (Yes, I know that that probably doesn't make sense the way I said it, but just read RFC2046. :-) So the obvious way to attack this problem would be to have Gnus, on group entry, looking for message/partial messages, and if it finds a complete one, it should present the user with just one message in the summary buffer, which, when selected, should be the unencapsulated message. But... how would one do that? Gnus only knows about The Nine Headers (and certainly not the Content-Type header) when generating the summary buffer. So, let's say we don't do that, but only have Gnus assemble the partials when you select one partial. How is Gnus supposed to do even that? It seems to me that that would require a traversal of all the articles looking for the other message/partials that have matching IDs. (The way gnus-uu does its work is by just guessing, and even though it guesses correctly most of the time, that's not good enough.) Here's an idea: How about defaulting gnus-extra-headers and nnmail-extra-headers to `(Content-Type)'? That would allow Gnus to do the assembly during summary buffer generation... but it wouldn't work, for instance, when assembling message/partials from nntp servers that have NOV. Hmm. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Partial message handling in pterodactyl gnus? 1999-06-13 6:36 ` Lars Magne Ingebrigtsen @ 1999-06-14 3:03 ` Aaron M. Ucko 1999-06-14 3:21 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 9+ messages in thread From: Aaron M. Ucko @ 1999-06-14 3:03 UTC (permalink / raw) RFC 2046, section 5.2.2.1 (fragmentation and reassembly) reads in part (2) All of the header fields from the initial enclosing message, except those that start with "Content-" and the specific header fields "Subject", "Message-ID", "Encrypted", and "MIME-Version", must be copied, in order, to the new message. which means that all the partials corresponding to a given original message will have the same From: and Date: headers, which should narrow the search adequately in all but pathological cases. -- Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Partial message handling in pterodactyl gnus? 1999-06-14 3:03 ` Aaron M. Ucko @ 1999-06-14 3:21 ` Lars Magne Ingebrigtsen 1999-06-14 4:47 ` Aaron M. Ucko 0 siblings, 1 reply; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-06-14 3:21 UTC (permalink / raw) amu@MIT.EDU (Aaron M. Ucko) writes: > (2) All of the header fields from the initial enclosing > message, except those that start with "Content-" and > the specific header fields "Subject", "Message-ID", > "Encrypted", and "MIME-Version", must be copied, in > order, to the new message. > > which means that all the partials corresponding to a given original > message will have the same From: and Date: headers, which should > narrow the search adequately in all but pathological cases. No, it's the other way around. The assembled message should copy the headers from the partial messages. The partial messages may have completely different headers in all respects. Well, except for the Content-Type headers. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Partial message handling in pterodactyl gnus? 1999-06-14 3:21 ` Lars Magne Ingebrigtsen @ 1999-06-14 4:47 ` Aaron M. Ucko 1999-06-15 1:56 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 9+ messages in thread From: Aaron M. Ucko @ 1999-06-14 4:47 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > amu@MIT.EDU (Aaron M. Ucko) writes: > > > (2) All of the header fields from the initial enclosing > > message, except those that start with "Content-" and > > the specific header fields "Subject", "Message-ID", > > "Encrypted", and "MIME-Version", must be copied, in > > order, to the new message. > > > > which means that all the partials corresponding to a given original > > message will have the same From: and Date: headers, which should > > narrow the search adequately in all but pathological cases. > > No, it's the other way around. The assembled message should copy the > headers from the partial messages. The partial messages may have > completely different headers in all respects. Well, except for the > Content-Type headers. Hmm. On closer inspection, that quote does sound more like it's describing reassembly, but the introductory text says the rules are for "_generating_ and reassembling" (emphasis added), and I'd certainly be surprised if the From: header ended up varying among parts. -- Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Partial message handling in pterodactyl gnus? 1999-06-14 4:47 ` Aaron M. Ucko @ 1999-06-15 1:56 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-06-15 1:56 UTC (permalink / raw) amu@MIT.EDU (Aaron M. Ucko) writes: > Hmm. On closer inspection, that quote does sound more like it's > describing reassembly, but the introductory text says the rules are > for "_generating_ and reassembling" (emphasis added), and I'd > certainly be surprised if the From: header ended up varying among > parts. I wouldn't be, because I know how many weird MIME "implementations" there are out there. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-06-15 1:56 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-04-20 15:46 Partial message handling in pterodactyl gnus? Hamish Macdonald 1999-06-12 2:27 ` Lars Magne Ingebrigtsen 1999-06-12 13:01 ` Hrvoje Niksic 1999-06-13 1:24 ` Lars Magne Ingebrigtsen [not found] ` <oq674t5sa6.fsf@titan.progiciels-bpi.ca> 1999-06-13 6:36 ` Lars Magne Ingebrigtsen 1999-06-14 3:03 ` Aaron M. Ucko 1999-06-14 3:21 ` Lars Magne Ingebrigtsen 1999-06-14 4:47 ` Aaron M. Ucko 1999-06-15 1:56 ` Lars Magne Ingebrigtsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).