ietf-822
[Top] [All Lists]

messages vs data

1991-05-02 16:41:16
Ned, Good work.  I'll reply to specific points later but first I'd like
to discuss what I think is the major difference between our approaches.

Let me note that this is *not* just an X.400 issue.  I think that
RFC-XXX as is will cause problems for UA implementors as well as all
kinds of gateway implementors.

It has to do with the difference between a part that is

    data

and a part that is

     a message that contains data.

These two things are semantically very different.  UAs will want to
handle messages differently from data, like invoking a message reader
for messages and a fax viewer for faxes.  Similarly, the UA might want
to use different icons for messages and data.

Clearly the gateway is also interested in the difference.  In X.400, a
message should map to a message body part while a fax should map to a
fax body part.

The problem is that with the RFC-XXX scheme, these are nearly identical.
The only difference is that a message part has 822 headers and a data
part doesn't.  I think this is going to be a hard distinction to
implement.

Using an example from last week,

    From: mumble
    To: other-mumble
    Content-Type: multipart; 1-S; asdfgh

    --asdfgh
    Content-type: G3Fax
    Content-Encoding: Base64

    ... fax data ...
    --asdfgh
        
is a message with one fax part whereas

    From: mumble
    To: other-mumble
    Content-Type: multipart; 1-S; asdfgh

    --asdfgh
    Content-type: G3Fax
    Content-Encoding: Base64
    To: new-mumble

    ... fax data ...
    --asdfgh

is a message with one message part that contains a FAX.  

(If you're tempted to move the G3Fax up to the outer level, please
consider a similar example but with two parts:  text and fax verses text
and message containing fax.)

As Ned says for the X.400 translation

 (1) If the content-type is something other than multipart but is
     accompanied by one or more headers that map to P2 content
     information, the RFC-XXXX attachment is mapped to an X.400
     forwarded-ipm attachment

 (2) If the content-type is something other than multipart and is not
     accompanied by any P2 content information, the RFC-XXXX attachment
     maps to a simple X.400 attachment of the appropriate type [..].

The thing is, it seems difficult to recognize these headers.  A few
points:

    (1) Just about all headers are optional.  You can't count on there
    being "To", "From" or "Subject" headers.  So what do you look for?

    (2) There are non-P2 headers that would also indicate that the part
    is a message rather than data -- "Received"  and
    "X400-MTS-Identifier" are examples.

    (3) How do you tell the difference between a message with no headers
    and data?  Coming from X.400, the only header you're guaranteed to
    have is "Message-ID".  Is there a guaranteed header in RFC-822?

    (4) How do you distinguish between extended part headers and
    extended 822 headers.  For example, X-Face should be treated as an
    822 header but X-Label as a part header (giving a label to the
    part).

In my scheme it's really easy: there's an explicit

    Content-Type: message

iff it's a message.  The message with one message part that contains a
FAX is represented

    From: mumble
    To: other-mumble
    Content-Type: multipart; 1-S; asdfgh

    --asdfgh
    Content-Type: message

    Content-type: G3Fax
    Content-Encoding: Base64
    To: new-mumble

    ... fax data ...
    --asdfgh

You don't have to scan the headers.  You can easily tell the diffference
between a message with no headers and data.  You can distinguish between
extended part headers and extended 822 headers because the former are up
with the Content-Type header, while the later are down in the message.

I'm not saying you can't do it your way but it does seem much harder to
implement.

On a comment from Nathaniel

 RFC-XXXX -> X.400:  A very naive gateway could just turn each of the
 multipart parts into an encapsulated message X.400 body part.  No
 problem, but maybe not exactly what you want (there's no point in using
 an encapsulated message just to contain a simple one-part thing like
 text or fax).

From an X.400 viewpoint, this solution is just downright unacceptable.
An X.400 recipient will expect a fax to be in a g3fax body part, not
hidden away in a message.  Also, it appears to not be symetric:  a P2
containing text and fax will map to multipart which will map back to P2
containing two messages.

 A gateway that is just a teeny weeny bit smarter could
 look at the Content-type and, if it corresponds to an X.400 body-part,
 translate it into that instead of into an encapsulated message.

This doesn't work either.  In the example above, the Content-Type is
"g3fax" in both cases.  The gateway would have to look for the headers
as described above.

Obviously there's another approach to implementing RFC-XXX:  if there's
any header in a part that isn't a part header then it's a message.  If
there are only part headers, it's data.  The part headers are
Content-Type and Content-Encoding.

However, this rules out allowing for extended part headers.  These are
headers that may be defined in the future to be associated with a part.
Examples are Text-Type, to indicate the codeset and encoding of text
within the data part, Content-Label, to indicate a label to put on an
icon or X400-EITs, to indicate what X.400 EITs are present in the data.
Please don't argue with my examples but rather with whether or not we
want to propose an extensible system.  I think we do.

(Sure you can try to cram everything into the resource-ref or some such
but what justifies the increased complexity?)

There's also the issue of RFC-XXX as defined being convenient for
digests.  I addressed this in a message sent Saturday with the
embarassing subject "et VISUAL=emacs" (please change it to 
"Digest vs Multipart" if you reply to it).

My conclusion was that my scheme isn't harder to implement for digests
and that, in any case, we could introduce a "digest" Content-Type.

So just to summarize, I suggest the following changes to RFC-XXX:

    1.  Content-Type "multipart" implies that the message body is
        structured as a series of parts of the following form with
        no useful information before, between or after the parts.

        -- delim
        <Part headers, if any>

        <data of form depending on the value of Content-Type>
         -- delim

    2.  Content-Type "message" implies that the message body is a
        message formatted according to RFC-XXX.  (Details as to whether
        the "From " line is allowed/required is TBD).
            
Pete

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