Bob, Steve, and Marshall,
Thanks for this note. You'll be amused to note that Kev Jordan and I
were about to write a THIRD version of this, but a message from Harald
caught things just in time. This is clearly a document whose time
has come!
A lot of people will be interested in this meeting, so we should
either decide on a shortlist of interested parties or schedule an open
meeting.
I think that your text is the best base to start from, but there are a
few points in Harald's document which need considering. Let me make
some general comments about what is needed.
1) I think that your selection of options of mapping and mutual
encapsulation is right. However, I think that where possible, a
mapping should be done. The encapsulation should be a fallback.
2) In view of 1), there needs to be mappings for a few more body parts
a) ODA - this should be straightforward, but need to note different
88 and 84 treatment
b) General text - need to bite at those character set mappings.
This is going to turn out to be quite groesque, and we should
put it into a separate document so that it does not bog everything
else down. The character set enthusiasts can set to....
3) I think that we should define X.400 body parts for:
a) JPEG
b) GIF
c) Audio (might use the standard X.400 body part)
d) MPEG
e) octet-stream (might use the standard X.400 body part)
f) postscript
g) rich text
This is not hard to do, and must be useful. The parts can be much
more natural than the MIME encapsuslation. I think that pure X.400
users will want to use these things, and this is better than referring
back to the general MIME encapsulation. This should be a separate
document to the basic mapping. Having these separate will facilitate
conversion within X.400, where the UA capabilities are not known to
the gateway.
4) If the gateway knows the UA capabilities of the recipient (either
the X.400 or MIME UA), the mappings should be different. There is no
point in encapsulating a message into a format that the recipient
can't handle. It is better to map it, perhaps with some loss of
information. When going from MIME to X.400, this will also allow an
intelligent mapping to be made for alternate.
5) It is probably appropriate to relate this to EIT conversion within X.400.
6) The multipart and messsage types and subtypes should be represented
in X.400 by use of an X.400 heading extension. This will allow a
clean reverse mapping, and also allow (with minimal effort) an X.400
UA to utilise this information.
See you in San Diego!
Steve