RE: Conf. Call follow-up

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

John

I agree but ...
1. What do people think of the probability that current EDI enabled
companies when transitioning to ebXML, will run their web servers so that
they can only accept data during a single narrow window. One of the major
benefits of going to the web is to shorten the "supply chain cycle", if they
don't "open the window" they will not get this benefit.
2. Why can't the web server that is accepting the messages simply batch up
the messages it receives so that they are made available to existing systems
in the time window it wants?

Item 1 tells me most companies won't want to do it. Item 2 tells me if they
want to do it they can easily add the functionality themselves. So, I think
we should have a **rule** that a transport wrapper can only have one MIME
message. Doing otherwise just adds to the complexity.

Thoughts?

David
PS. I've taken John's email address off the list as I'm sure he's fed up,
like me of getting multiple copies of the same message.


-----Original Message-----
From: john_ibbotson@uk.ibm.com [mailto:john_ibbotson@uk.ibm.com]
Sent: Monday, March 06, 2000 8:51 AM
To: David Burdett
Cc: ebXML Transport (E-mail)
Subject: RE: Conf. Call follow-up





David,
The situation I was anticipating was the EDI batching one where a number of
separate messages are assembled are sent in a single envelope. This is
widely used in the EDI community where one partner only accepts messages
during a particular time window.
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/06/2000 04:35:12 PM

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

To:   John Ibbotson/UK/IBM@IBMGB, David Burdett
      <david.burdett@commerceone.com>
cc:   "ebXML Transport (E-mail)" <ebXML-Transport@lists.oasis-open.org>
Subject:  RE: Conf. Call follow-up




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