OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: many envolopes



 dear All
In my experience the windows have opened or at least there are many
instances of windows. One envelope is enough.
Matti Vasara

> -----Alkuperäinen viesti-----
> Lähettäjä:	David Burdett [SMTP:david.burdett@commerceone.com]
> Lähetetty:	6. maaliskuuta 2000 19:01
> Vastaanottaja:	ebXML Transport (E-mail)
> Aihe:	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
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC