Boy, do I hate e-mail wars. Sorry to flame on one more time.
If you want to skip the bulk of this message, the key points are:
I still think the right thing to do is move the X.400 Content-Types
to a different RFC.
Optional things are often interpreted as "you don't have to do this
but if you do do this, this is how to do it". Leaving in the X.400
definitions might be taken as how to do it.
Let's at least put a note in RFC-XXX that says X.400 Content-Types
are examples only -- not officially part of the RFC.
Are there any strong objections to the last?
There's also the issue of whether the X.400 mapping should be discussed
here or on ifip-gtwy. Any opinions?
Pete
---- Now onto the details:
> 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.
Believe it or not, I read it fairly carefully. I just don't agree with
all of it.
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.
Perhaps I wasn't clear. The point is that we can't have two standard
each defining "message" (as a Content-Type) in contradictory ways. I
want "message" defined in RFC 1148++ to mean what I said above. If
it's defined in RFC-XXX as is, there's a conflict. If your
implementation gets a message with "Content-Type: message" how is it
going to interpret it? As specified by RFC-XXX or by RFC 1148++?
Of course we could use some non-intuitve name in RFC 1148++ as an
alternative for "message", but why preempt such a nice name for
something that nobody's going to use? (I prey that I'm not starting
another "what should we name ASCII" war.)
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.
Generally optional things are interpreted as "you don't have to do this
but if you do do this, this is how to do it". (Is this our major point
of disagreement?)
Since RFC-XXX contains EBNF of
type := [...] / x400-type / [...]
x400-type := "IA5-Text / ; [0] IA5Text, IA5TextBodyPart
"Voice" / ; [2] Voice, VoiceBodyPart
"G3-Fax" / ; [3] G3Fax, G3FacsimileBodyPart
"Teletex" / ; [5] TTX, TeletexBodyPart
"Videotex" / ; [6] Videotex, VideotexBodyPart
"Nationally-Defined" / ; [7] NationallyDefined,
; NationallyDefinedBodyPart
"Encrypted" / ; [8] Encrypted, EncryptedBodypart
"Message" ; [9] ForwardedIPMessageMessage,
; MessageBodyPart
someone could legitimately conclude that, if they are going to carry
ForwardedIPMessages, that this is the way to do it. "Otherwise",
they'd wonder, "why is it there"? Where is there any indication that
this is *not* to be used? As you said
There are two reasons to specify a given content-type:
[...]
(2) It is specified because people might possibly want to send such a
thing, and if two people decide to send it, they should do it in
the same way. All of the X.400 bodypart content-types fall into
this category.
Although, you go on to say "There is no clear evidence that an X.400
mapping would ever use these content-types", people think this way.
There going to think "Gee RFC-XXX defines a way to carry P2 as an part,
we better use that in order to be compatible with everyone else".
Or, arguing from the other side, if we removed it, what's the problem?
I know that you proposed an example of how it might be used (multimedia
multipart mail as a transport). But is there really any reason to
believe that this is the right definition for that use? Wouldn't it be
better to let the writers of that transport RFC define the body parts
they are going to use?
Perhaps the compromise is to have a note in RFC-XXX like:
Note: The definitions of the X400 parts are examples only and and
are not to be taken as authoritative. See [RFC 1148++] for the
mapping of X.400 into RFC-XXX.
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.
For "message" as defined in RFC-XXX, I completely agree.
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.
Sorry but I don't think it's complete (eg my "message" type is missing).
And why provide them here rather than in RFC 1148++ where we will know
what 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?
How can we be in so much agreement but reach totally different
conclusions? Again, I'd say that, since we can't predict now "what
will be useful and what will not be", let's delay the definition until
we 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.
Again, I disagree. I believe that many interpret optional things as
"you don't have to do this but if you do do this, this is how to do
it".
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. [...] 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.
I'm sorry but how is it that you know that this way of sending
X.400-style FAX bodyparts is "more likely to be interoperable than
another approach"? If you-all choose to use something else, aren't you
giving the wrong message?
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.
I agree that RFC-XXX should contain the tools. But I don't think those
tools need include Content-Type definitions. All the IFIP group needs
of the Content-Type mechanism is the mechanism itself and the
definitions for text (mail-ascii), multipart (the way I want it
defined) and message (again the way I want it). The rest should be
defined in RFC-XXX.
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.
I've got three implementations (commercially available) behind me, have
been associated with many X.400 committees (OIW X.400 SIG, MHS-MD,
XAPI) and have contributed to the RFC 987-1148 process. I know what
I'm talking about (or at least I think I do :-)). I don't want to
discuss future products but I have more than a passing fancy concerning
the X.400 mapping. I'm willing to work on it too. Let's channel our
email energy into what the X.400 mapping should look like. Maybe we
can give Steve a "wedding present" of an X.400 mapping.
> 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!
Well, that's not the way I read it, obviously.
I suspect that the general readership of this list is not interested in
the X.400 map while those on the ifip-gtwy are, but if the consensus is
to it here, let's do it.
Pete