RE: Conf. Call follow-up

[David Burdett <david.burdett@commerceone.com>]

John says ...

>>>I assume we would be able to support multiple MIME envelopes within a
single transport wrapper?<<<

We can, but I'm not sure we should include this requirement in our work. The
only reason I can think of doing it is if we want to send multiple
un-related messages at the same time, and I don't see sufficient benefit in
doing this compared with the extra complexity involved. I'm willing to be
convinced though.

>>>Is further nesting necessary or simply being over complex ?<<<

As far as our work is concerned, I don't think we should "design in" any
extra nesting. However if someone want's to put a complete MIME message (no
matter what it contains) as part of another MIME message in order to meet a
specific design requirement, then MIME supports this and they are entitled
to do so.

To my mind, these two requirements both fall the wrong side of the KISS
principle.

Regards

David
PS John didn't send the original to the ebxml list, but I'm assuming he
intended to !



-----Original Message-----
From: john_ibbotson@uk.ibm.com [mailto:john_ibbotson@uk.ibm.com]
Sent: Monday, March 06, 2000 1:25 AM
To: David Burdett
Subject: RE: Conf. Call follow-up





I like David's view of the message structure since it matches my own. I
assume we would be able to support multiple MIME envelopes within a single
transport wrapper ?
Is further nesting necessary or simply being over complex ?
John

MQSeries Technical Strategy & Planning,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: +44 (0)1962 815188
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com


David Burdett <david.burdett@commerceone.com> on 03/05/2000 12:09:37 AM

Please respond to David Burdett <david.burdett@commerceone.com>

To:   "'ian.c.jones@bt.com'" <ian.c.jones@bt.com>,
      ebXML-Transport@lists.oasis-open.org
cc:    (bcc: John Ibbotson/UK/IBM)
Subject:  RE: Conf. Call follow-up




Ian said ...

>>>  I also support the idea that we define the header, routing, manifest
structure then define how we put this in MIME for both SMTP and HTTP (as
Dick pointed out there are 2 variants), AND a XML wrapped version.  This I
believe this is what David was proposing in the XML Messaging requirements
paper. i.e. We are transport protocol independent and provide "mappings" to
them if needed.<<<

This is, I think, not *quite* what I meant. What I envisaged was the
following type of structure:

Transport Wrapper (e.g. SMTP or HTTP)
|  MIME Envelope Start (or Outer XML Envelope)
|  MIME Envelope Parameters ...
|  MIME (or XML) separator ...
|  |  <MessageHeader>
|  |    ...
|  |  </MessageHeader>
|  MIME (or XML) separator ...
|  |  <MessageRoutingInfo>
|  |    ...
|  |  </MessageRoutingInfo>
|  MIME (or XML) separator ...
|  |  <FirstDoc>
|  |    ...
|  |  </FirstDoc>
|  MIME (or XML) separator ...
|  |  <SecondDoc>
|  |    ...
|  |  </SecondDoc>
|  MIME (or XML) separator ...
|  | etc ...
|  MIME Envelope (end)
Transport Wrapper End

The point I'm trying to make is that I have always thought of the Message
Header as being an XML document containing the types of information we have
been identifying. I did not anticipate the information being held as
name-value pairs in the MIME Envelope Parameters. The main reason for this
is if you want to sign the information it contains. You can only sign
information in the parameters (I think) if you sign the complete message.
On
the other hand if you sign only the message parts, then you have a better
chance of being able to break up the MIME message, throw away the MIME bits
and keep the rest safely stored away on disk. I always tend to think of the
MIME enevelope as just that, an envelope, which can be thrown away once you
opened it.

Regards

David