Nat, Ned et al,
I'm back! There has certainly been a lot of discussion. Thanks for all the
good wishes.
I think that you have been doing a good pice of work, and like the way that
this is going. Let me make some comments, and suggestions wrt to X.400.
I'm going to suggest some quite major restructuring, without substantially
altering the technical choices.
First let me state what I see as an overall goal. We want to deploy
structured non-text messages on the Internet. RFC-XXX is being written so
that this can be done using the existing SMTP/822 infrastrcture. This is
important, as it can decouple work on multi-media UAs from other messaging
issues. This work should be done is such a way that it will be as
straightforward as possible to utilise an X.400 infrastructure. Ideally,
there should be multimedia messages, and the use of X.400 or SMTP transport
should be transparent to the end user.
It is important the the transformation between X.400 and 822 is a mapping
and not an encapsulation. We need to have a end service which is protocol
independent. Not just a means to wrap X.400 body parts in RFC-XXXX or to
wrap RFC-XXX parts into X.400.
RFC 1148 defines a mapping between X.400 and 822. These specifications
were fixed, and so 1148 had to use their parameters to define a mapping.
We do not have the same case here. RFC-XXXX is being defined to extend 822,
but facilitate X.400 mapping. Therefore the X.400 mapping of these aspects
should be defined with the specification (either as an appendix or a
companion RFC). As one of the goals of RFC-XXXX is a straightforward
mapping with X.400, it is important to write the mapping in parallel to
verify that this really is the case. More on this in a bit.
I'd like to look at structure now, and the discussion between Pete
Vanderbilt, Ned Freed, and message from Neil Katin. X.400 defines an IPM
(Interpersonal Message), which contains a heading and a set of body parts.
Each body part is typed (the Encoded Information Type). IPM is one specific
(X.400) content type for the MTS.
An RFC-XXX message can either be single part (with an (RFC-1049)
content-type) or multi-part. A single part can just have a content type, or
can have other headers.
RFC-XXX (Ned) is proposing the message as the lowest common unit. A message
with only a content type is functionally equivalent to a body part. Neil and
Pete are proposing changing this to have message and body part as separate
abstractions.
Ned's approach has the advantage of being slightly simpler, and I quite like
the idea of the message as the basic block.
Neil/Pete's suggested change has the following advantages:
- easier to map with X.400
- there is a difference between body parts and messages (Neil's point)
The difference occurs for messages with a single body part. I think that
Ned's format (single header) looks neater. I think that with some careful
name changes, we can keeps this format, but have a model which distinguishes
between messages and body parts (this is sort of suggesting a comprimise).
I suggest that we align terminology with X.400. This RFC is defining terms.
Where they align to X.400 terms, it will help everyone to use the same words.
"Part" should be changed to "Body Part", in all references.
"Content Type" is used differently to X.400, and this is confusing to those
familiar with X.400. I'd suggest a change to "Body-Part-Type:" and
"Body-Part-Encoding:" (We could use the X.400 "Encoded Information Type", but
I don't like this - I'm contradicting my earlier suggestion). If only these
headers are present, the object is a body part. If any others are present,
it is a message with a singly body part. Structured messages should not be
indicated by use of "Body-Part-Type:". Rather, the 1148 field
"Message-Type: Multiple Part" should be used (1148 p 62). If this is
present, there will be no "Body-Part-Type". If this is present two more
optional fields are present.
1) "Body-Part-Ordering:". This can have value "Sequential" or "Parallel",
and defaults to "Sequential". It is probably useful to define an X.400 IPM
heading extension, so that this can be cleanly represented in X.400.
2) "Body-Part-Seperator:" This should define a separator. There should
be a default value if this field is omitted.
RFC-XXXX should concern itself only with structure and Body Part Encoding.
The mapping to X.400 should be defined in an appendix or companion RFC
(probably the former, as the mapping is quite straightforward).
There should be a definition of body part types for use on the Internet.
This should be done by two RFCs. The first defines a pro-forma for
resgistering new body parts. This should allow for both internet-wide and
private definitions. The second is a document defining a list of body part
types definitions for in use on the Internet. This would be a document
which would be updated at intervals.
The defintion of a body part type should contain.
1) A string name (e.g., "Postscript"). Private body part types will not
have unique strings. They should beging "X-" to indicate this.
2) An object identifier.
3) An description of the body part type, giving its abstract syntax, and
pointers to formal definitions of the syntax.
4) Any parameterisation associated with the body part type. This
is a feature of X.400 body part types, and a hook should be added to RFC-XX
to allow this to be represented (in an earlier message, I suggested doing
this by use of a new header field).
5) How to map the body part onto RFC-XXXX. Which body-part-encodings are
valid for this body part type.
6) How to map this body part onto X.400 (this may use a standard or extended
a body part type). Where it exists, the former should be used.
7) The level of support for this body part on the Internet. We might use
the RFC levels: Standard; Proposed Standard; Experimental. Probably need to
make IA5 mandatory for all systems.
By working in this way, we are defining (automatically) a means to map each
body part type between RFC-XXX and X.400.
It is probably worth extending RFC-XXX a little, so that any extended X.400
body part has a default mapping. Thus if Microsoft define a way to carry
WORD documents in X.400, then this definition can be used implicitly by
RFC-XXXX. I noted how to do this in a previous message (straightforward).
Couple of minor points.
If you are concerned about compressing ASN.1 encoded documents, you should
define use of the new Packed Encoding Rules (PER) instead of BER.
X.400 extensibility (Ned's message). 88 is a lot more extensible than 84.
RFC 1148 makes use of one aspect of this (private headings).
Bob Smart's comment. The directory will define Supported Encoded
Information Types for a UA. This should be usable for RFC-XXX as well as
for X.400, assuming that you go with my proposal to give every internet body
part type an object identifier.
I hope that I've not missed too many points in all those messages!
Steve