Re: Conf. Call follow-up

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

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