Well, I have to agree with Peter that these mapping definitions of how
to put X.400 body parts and X.400 content types into RFC-XXXX standard
messages sounds like a job for RFC987/1148/+++, which Steve Kille is
working on now, at some kind of snails pace. I expect that he could
use some help, and it sounds to me like Ned is able and ready.
[Unfortunately, until May 20, Steve is out of circulation, on his
[Honeymoon without any computers within reach. We should offer him
[our very best CONGRATULATIONS, and BEST WISHES, and line up to help
[him when he gets back.
I see no problem with discussing the X.400 specifications here, or in
IFIP-GTWY(_at_)ics(_dot_)uci(_dot_)edu (which is more or less idle for the
moment, but
I would hope that we could settle RFC-XXXX down before we spread out
to into new territory. So, I would suggest that we concentrate on
whether we have the right model for handling X.400 body parts, and
other body parts from other sources that we have to reckon with.
I do agree with Ned on the need to in fact specify all the X.400
carriage rules, and mapping rules, in due course. Hopefully only
once!
I guess I see it as a reasonable way to structure RFC-XXXX effort to
specify the skeleton in RFC-XXXX, and have it specify what kinds of
additional RFCs should also be written to deal with X.400, and other
interesting stuff.
Can we not do this, and approach Mark Crispin's suggested target of
getting the basics done and under way, while we fall back and fill in
the other stuff. If we deliberately leave a set of well formed holes
(or connectors) for additional RFC specifications, have we not then
managed to create a living standard that is designed to both accept
growth, and even encourage and nurture it, in defiance of the Internet
tendency to not go beyond the limit of the first RFC.
Best...\Stef