RE: Conf. Call follow-up

["Dick Brooks" <dick@8760.com>]

I agree with David, and Chris with regard to a single payload. This
simplifies the Transport mechanism and doesn't constrain the payload. A
implementer is free to place ANYTHING into the payload bodypart, including a
complex multipart/mixed, which can contain any number and type of body
parts.

Dick Brooks
http://www.8760.com/

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of
Christopher Ferris
Sent: Monday, March 06, 2000 12:19 PM
To: ebXML Transport (E-mail)
Subject: Re: Conf. Call follow-up


I too was going to respond to this, but David seems to have captured
my points nicely. Of course, shortning the supply chain cycle isn't the
only benefit. It is much easier for those without benefit of (or is it
burden
of)
some pre-existing batch-oriented legacy software which is currently churning
out or consuming batches of EDI message traffic to get in on the action for
starters.

There is also the tracking aspect to consider. If a "batch" of messages is
treated as a single message, how does one track the status of an individual
member of the batch? What is the status of the 99 messages which could be
processed if there's an error with the 100th? Should the entire batch be
resent

if there's an error with only a small subset of the total? These are
precisely
the
sorts of problems which I don't think we want to be addressing as they over
complicate
the model.

I concur with David, we should be dealing with one payload message per
transport
wrapper (MIME or otherwise).

Cheers,

Chris

David Burdett wrote:

> 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