RE: Conf. Call follow-up

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

Gord,

I believe the ebXML MR&T solution  should be flexible enough to support
batch, interactive, simplex, synchronous, asynchronous, acknowledged,
unacknowledged, signed, unsigned, encrypted, unencrypted, etc. etc.

Let the implementers decide what's best for them.

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


-----Original Message-----
From: Jenkins Gordon [mailto:gjenkins@singnet.com.sg]
Sent: Wednesday, March 08, 2000 5:14 PM
To: Dick Brooks; David Burdett; ebXML Transport (E-mail)
Subject: Re: Conf. Call follow-up


With respect, is not  the Model we must be thinking about for the future
NOT be " batch "or "packet" thinking -
business on the internet will demand "on line"
-meaning instantaneous.
Gord
Gordon Jenkins
Standard Chartered Bank C&IB
Senior Product Manager: Electronic Commerce
51 Bras Basah
SINGAPORE 189554

Email : gjenkins@singnet.com.sg

Tel :65-331 5095
----- Original Message -----
From: Dick Brooks <dick@8760.com>
To: David Burdett <david.burdett@commerceone.com>; ebXML Transport (E-mail)
<ebXML-Transport@lists.oasis-open.org>
Sent: Thursday, March 09, 2000 5:53 AM
Subject: RE: Conf. Call follow-up


> John,
>
> I think the model your're thinking of is the current VAN model where
> multiple "transactions" are contained in a single interchange. I believe
the
> ebXML solution must be flexible enough to let parties "batch" transactions
> into a single payload or operate in a "Request/Response" mode. In the case
> of a batch transaction the payload could contain the same EDI file (X12,
> EDIFACT) that would be sent to a VAN.
>
> 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 David
> Burdett
> Sent: Monday, March 06, 2000 11:01 AM
> To: ebXML Transport (E-mail)
> Subject: RE: Conf. Call follow-up
>
>
> 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
>
>
>