Re: Conf. Call follow-up

["Jenkins Gordon" <gjenkins@singnet.com.sg>]

I guess I was not clear enough - not talking about
snip
 "synchronous, asynchronous, acknowledged,
 unacknowledged, signed, unsigned, encrypted, unencrypted, etc. etc."

Point was - the old economy, the EDI way , the VAN way - was packet or
batch.

The new way is online or instantaneous

Lets give the implementers - of which I am one - something they can use.

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: Jenkins Gordon <gjenkins@singnet.com.sg>; David Burdett
<david.burdett@commerceone.com>; ebXML Transport (E-mail)
<ebXML-Transport@lists.oasis-open.org>
Sent: Thursday, March 09, 2000 8:41 AM
Subject: RE: Conf. Call follow-up


> 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
> >
> >
> >
>