ietf-822
[Top] [All Lists]

Re: X.400 bodyparts and related matters

1991-05-02 18:59:01
On Ned's mapping:

 [...] The way you
 determine how to map an RFC-XXXX attachment to a corresponding X.400
 attachment goes like this:
 
 (0) If the content-type is multipart, the RFC-XXXX attachment maps to an
     X.400 forwarded-ipm attachment unconditionally.

I hope this is true within a multipart only.  At the outer level, the
content-type multipart should map to a normal P2 message (not to a
message that contains a forwarded-ipm).

On Ned's analysis:

 (2) Peter's mapping maintains more the X.400 in a more obvious way when
     it gets mapped to RFC-XXXX.  X.400 types probably won't like my
     mapping as much as his.
 
     This topic, plus the following one, implicitly raises the question
     of how far we want to go to make X.400 mapping easy versus making
     our lives marginally harder.

Some of the issues I bring up do not affect only X.400 but also UA and
other gateway implementations.  In general, if there's a difficulty for
X.400, it will probably be a difficulty for others unless it has to do
with something that's particularly strange about X.400.

Also, I don't see my scheme being harder.  Both have implementation
difficulties but I actually think my scheme is *easier* overall.

 (3) The structure of a very common entity in the 822 world, a digest,
     gets more complex with Peter's proposal.  Here an example of what
     Peter's digest format would look like:

Ned goes on to point out that there would be an extra

    Content-type: message\n\n

at the beginning of each attachment.  While this may be more verbose, is
it really more complex?  I think the fact that an implementation can
tell that this thing is a message by looking at this header, rather than
having to deduce it from presence of 822 headers, is a simplification.

We should pick a format that works best for UAs, MTAs and gateways, not
one for human readers who happen to be looking at the raw bits.  While
backwards compatibility is a key requirement, it is not applicable in
this case.

If it's really important to eliminate the Content-Type header, then we
can define a Content-Type of "digest" which is exactly the old
"multipart".  In this case, the implementation knows that each part is a
message and that it just can't be that one of the parts might be just
data.  (For more on this, please see my "et VISUAL=emacs" (:-()
message).

Finally, it seems to me that one can use exactly the same routines for
parsing digests and multiparts.  The difference is in how the data
between delimiters is handled.

 (4) Another case where things are more complex using Peter's scheme is
     where you have a multipart content-type that contains two multipart
     content-types.
     [...]
     Here's Peter's (I'm assuming here that Peter want to forbid
     multipart except at top-level and with a message content-type):

As discussed in previous messages, there are three ways I'd handle
multipart parts.  For the case of using forwarded-ipms (as Ned does) or
a new X.400 part, the 822 message is exactly the same between our two
schemes.

For the case where multipart parts were disallowed, the basic RFC-XXX
model would be that a message contains a sequence of parts, not a tree.
UAs would be built to this model.  Ned's example would only come up if an
end user "forced" his UA to represent a tree structure by using the
message part as the recursive mechanism.  But this would be true for
Ned's scheme also (as it's a UA issue, not a gateway issue).

Earlier Ned had mentioned

 One point you did not discuss here is how to deal with a nested
 multipart content-type. I assume that you're not going to allow it to
 be nested, except when it appears inside of a message RFC-XXXX
 attachment? If you allow multipart content-types anywhere other than at
 top-level or within a message RFC-XXXX attachment, there's an ambiguity
 -- you have to map it to a forwarded-ipm on the X.400 side, since
 there's no other way to represent a multipart entity within a multipart
 entity in X.400. But the reverse mapping will take this to a message
 attachment that contains a multipart attachment, and bang, you've
 created structure out of nowhere.

Clearly if we use my preferred new body part scheme, the mapping is
completely reversible and easy to implement.

Even if we use the scheme of mapping to forwarded-ipm as Ned does, the
reverse mapping could detect that this isn't a "real" message by
noticing that the this-IPM heading field is missing and, thus, map it
back to the original form.

Let me note that Ned's scheme too has difficulty recognizing the
difference between a message and a multipart part.  It's easy at the
gateway because the two forms are syntactically the same.  But the UAs
are more complicated because they have to recognize that 822-headers
imply message and no-822-headers imply multipart (see my recent
"messages vs data" message for more details).  If we do settle on using
forwarded-ipms for multipart parts, my scheme would place the complexity
at the gateway rather than at every UA (a win).

 (5) Are there cases where Peter's mapping is simpler? The answer is yes;
     this happens when you have an X.400 message that contains one
     attachment which is itself a forwarded-ipm. Here's Peter's mapping
     for such a thing:

Ned then shows that his scheme needs a multipart while mine doesn't --
in mine, you have Content-Type: message at the top level with the
message following and no delimiters.

     Now, I argue that the delimiters that you end up with by using
     multipart are far from being superfluous, since they provide a clean
     set of delimiters for the included part.

But you don't really need the delimiters since there's only one part --
what's to delimit?

But more importantly, note that my scheme is more consistent.  It is
always the case that a single part message is specified at the outer
level and does not need "multipart".

With Ned's scheme, some single part message use multiparts while others
don't.  Clearly we want the single text body part to look like a normal
RFC 822 message so that existing software can handle it.  So at least
single text part should not use multipart.  But to represent a single
message part, Ned's scheme uses multipart.

 (6) One way to look at this is to say that Peter is explicitly applying
     a restriction of X.400 to RFC-XXXX -- the inability of X.400 to
     specify a nested multipart structure without also specifying a full
     forwarded-ipm.  I simply state this; you can draw your own
     conclusions.

I don't think this is quite fair.  I did *not* explicitly say any such
thing in the message to which Ned was replying.  And in the previous
message where I discussed this, I gave three options of which this was
second in preference.

I think this is still an issue.  Is the multipart part a useful thing?
Are UAs going to implement it?  I've seen UAs that can handle multiple
parts at the top level (like as attachments) but that cannot handle
parts that are multipart -- these UAs embody the linear model.  Are they
going to switch to the tree model?  Are there UAs that currently
implement the recursive model?  Are the digestifiers recursive?  If not,
then disallowing the multipart part would be the right thing to do.

 Well, that's enough for now. 

Ditto.

 Comments from persons other than Peter or myself?

Should we be probing other lists or moving this discussion?

Pete

<Prev in Thread] Current Thread [Next in Thread>