Re: rfc1495

[John Haxby <[e-mail]>]

> > ------------
> > 3.2.1.2.  Message/Partial
> 
> 	...
> 
> In practice I've found that the only viable approach is to reassemble
> message/partial objects before passing them off to X.400. However, I think
> we still need to provide for a means of carrying them in the X.400 world.

This, however, is still fraught with problems.  Well, at least one problem,
suppose that a message is broken into 1000 1Mb chunks ... you're lucky if you
can find something that can cope with 1Mb in one go, I doubt you'll manage
to store 1Gb (actually, probably 2 or 3Gb) on a good many nodes.  And even
if you do, I'll just up the number of chunks :-)  Even if local storage is
not a problem, it might be that the destination MTA will only accept smaller
chunks.

The problem you mention, Ned and Justin, is that the broken up original
message might have some structure than can be legitimately mapped by RFC1495/
RFC1494.  If you could do the mapping piecemeal (ie a chunk at a time) then
there would be a way around the problem, but you can't (in general), and
anyway, you might get the first part last (after you've store away the other
6Tb of this huge message).

Message/partial is a fine idea, in principle, but there's no good way to
deal with it at an X.400 gateway.  It could be that you could adopt a compromise
approach and assemble the entire message if it's small enough and just send
through literal chunks if it isn't.   Mind you, there are still problems, I
might decide to send a diary in 365 parts, one a day, and by the time the whole
message is assembled, the first part will have been sitting around on the
gateway MTA for a year -- this might be considered poor quality of service.

The difficulty with message/partial is that whilst the common cases can be
handled easily, the uncommon, odd cases can't be.  Spotting these weirdos could
be a little difficult ... and then there's the question of what to do when you
pop back into MIMEland.

									jch