This having been said, I'm not opposed to splitting the X.400
content-type definitions out into a companion RFC.
This is the right way to go for the reasons I'll state below. The
companion RFC should be the X.400 <-> 822 RFC (which I'll call RFC
1148++).
1. It is important to avoid wrong definitions. We can't have RFC-XXX
and RFC 1148++ specifying contradictory things. But that is exactly
the course we're on right now, because RFC-XXX specifies that the
Content-Type "message" denotes the ASN.1 encoding of the BodyPart,
whereas RFC-1148++ is likely to specify it as a recursive mapping of P2
to 822.
NO NO NO NO NO NO !!!
PLEASE read what I post before you respond! This is the third time I've posted
this material. Let me say it again -- there's NO contradiction because there's
NO intention expressed or implied about HOW a mapping from X.400 to RFC-XXXX
should be done! Just because there's a "message" bodypart does NOT mean that's
what will be used for an X.400 to RFC-XXXX mapping. Look at RFC-XXXX. Do you
see where it says "thou shalt map an P2 bodypart to a 'message' content-type"?
You cannot find it because it is not there.
This community probably specify eventually, in some RFC, a way to do Japanese
characters in e-mail; perhaps it will be the ISO2022 business used now. Would
you then interpret it as a specifying a mapping for Chinese? They do share a
lot of characters, after all... Of course you wouldn't! Well, the same thing
applies here. We're providing tools and that's it. How they get used will be
decided in additional specifications and operations.
I would not recommend mapping X.400 P2 bodyparts to a "message" content-type.
It does not sound like a good thing to do in general. I presented a scenario
where such a mapping might be a good idea. It was only a scenario; nothing
more. I was extremely careful to say that I did not advocate this approach.
I expect that the successor to RFC1148 will specify a mapping that takes a P2
bodypart into some type of multpart RFC-XXXX message in general, decomposing
all the various parts into various pieces of RFC-XXXX material. The only thing
that RFC-XXXX provides is the tools needed to map the various non-decomposable
bodyparts and whatnot of X.400 to something reasonable. Since I don't know for
sure what parts will be used and what parts will not be, I provided a complete
set so Steve or whoever can use what they want to use. They'll probably
recommend some of them not be used. There may even be various different
mappings that are appropriate for different purposes (actually, I think that
this is extremely likely to be the case), and I don't want to try to predict
what will be useful and what will not be, because I don't know how this is all
going to eventually fit together. Can you say for sure that you do?
ONCE AGAIN, THE SPECIFICATION OF A CONTENT-TYPE SHOULD NOT BE INFERRED TO IMPLY
THAT IT IS SUITABLE FOR ANY PARTICULAR USE, ESPECIALLY WHEN SUCH USAGE IS NOT
SPECIFIED OR CONDONED IN THE RFC.
Similarly, I'm pretty sure the FAX format used by existing
tools is not the ASN.1 form as specified in RFC-XXX.
Quite true, but irrelevant. The question is, do you want your X.400 to RFC-XXXX
gateway doing the FAX format conversion. Maybe you do and maybe you don't. But
the NETFAX working group is waiting to see what gets done in RFC-XXXX before
selecting a content-type (I'm on that mailing list and I attended the session
in March; one of my coworkers here is likely to be very active in that work in
the future). We may choose to use the X.400 FAX specification. We may choose to
use something else and specify a mapping from the X.400 FAX specification. It
this is what gets done, it is quite likely that we'll want gateways to support
material encoded in the X.400 FAX format, although it may get converted right
away. Or maybe not. But once again, specification does not imply that this is
the right format or the wrong format. It simply says that if you want to send
X.400-style FAX bodyparts, this is a way to do it that is standardized and more
likely to be interoperable than another approach. And that's all it says.
2. It is also important to avoid misinterpretations. If we leave in
the X.400 Content-Types, those not "in the know" might think that
RFC-XXX defines an agreed upon X.400 <-> 822 mapping.
If you can find where RFC-XXXX specifies any sort of X.400 mapping, I'll eat my
hat. No such mapping is specified. If you like I'll put in a note saying "we're
not specifying an X.400 mapping here". I happen to think this is obvious, but
if a note will clear this issue up, fine.
3. RFC-XXX is properly an open-ended framework which allows new
Content-Types to be defined well after RFC-XXX itself has stabilized.
We should use this mechanism so that when agreement is reached on the
X.400 <-> 822 mapping, *then* the X.400 Content-Types are defined.
That's why I've offered to put the X.400 stuff in a separate companion RFC, if
enough people really think this is a good idea.
I'll point out, however that we were asked to provide these mappings in this
RFC and not in another. The IFIP folks, and Steve Kille especially, are waiting
to find out what tools they have to work with. To quote Steve's posting to the
IFIP list on this:
Two questions:
1) What, if any, note will RFC-1148/bis be taking of the current work
on SMTP extensions?
(if the answer is "none", new question: How should we work on it?)
By reference. I will be pointing at the output document of this group.
I believe that it will be an improvement on RFC 934. I think that it is
important that 1148bis does not try to compete with this effort. I would
ecnourage people with X.400 expertise to contribute to the IETF-SMTP effort.
Well, I have X.400 expertise (not as much as Steve does, since he has not only
written the mapping specification but an implementation of it, whereas I just
have one implementation of the mapping to my credit), and that's why I'm doing
this work here -- Steve Kille asked for it to be done and I agreed with him
that it should be done.
Doing so before agreement is reached serves no useful purpose and may
be detrimental.
It is difficult to see why they're detrimental when support for them and use
for them is entirely optional. The only thing that's detrimental is this
totally fallacious argument that we're specifying an X.400 mapping, when
there's no evidence of it any form in the text of RFC-XXXX.
I'm very interested in what Steve has to say, technically, about how we've done
the bodypart mapping, and you can rest assured that we'll be very careful to
make sure that the followon to RFC1148 and RFC-XXXX are interoperable. Steve
was also part of the initial subgroup that put together RFC-XXXX along with
Nathaniel and myself. He is aware of the approach we're taking. I cannot say
that he agrees with it, since he's on his honeymoon right now. I expect
he'll have plenty to say once he returns.
I'd like to continue
the discussion of this material on this list, however, since I think
these bodyparts are generally useful -- no matter how much you happen
to hate X.400, there are some bodyparts there that you may want to use
(G3Fax, for instance). And if the FAX people _don't_ want to use the
G3Fax bodypart, we need to know that too. Further than this I'm not
willing to go, since I happen to think that these bodyparts are
IMPORTANT and NEED to be specified.
I too would like to hear from the FAX people -- are they on this list?
No, they have a separate list (I'm on it; I also have done a fair amount of
work on an e-mail to FAX gateway). However, they are watching this list since
they are also waiting to see what sorts of tools we provide in this RFC before
proceeding! (I'll dig out the messages from that list that say this if you
really want to see them.)
But for the X.400 types in general, I think we should move the
discussion to something like ifip-gtwy.
And the folks over on IFIP (see above) said to do the discussion here!
We've got to do it somewhere.
Pete
I'll try to get back into the issues involved with how X.400 gets mapped to
RFC-XXXX and whether or not we're providing an adequate framework for it
tomorrow. I don't feel up to it right now.
Ned