RE: MIME Envelope Optional?

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Marc asks "Why do away with the MIME envelope now?"

  1) Because SOAP 1.1 maintains independence from MIME.  If you need (or
want) to use MIME, you may.  No change to SOAP 1.1 is required to use MIME.

  2) Because there is no technical necessity for a MIME envelope when all of
the content is in XML syntax.

  3) Because the resulting package is simpler.  Many applications of ebXML
might always be XML-only applications.  Why should they have to add a
technically unnecessary envelope?

  4) Because it meets the KISS principle

  5) Because it is the right thing to do from a technical perspective.

  6) Because when in SOAP, do as SOAP would do.

Marc says "there is no 'ebXML payload'".  I disagree:

  A) The payloads associated with Acknowledgement, etc. are by definition
ebXML (internal) payloads.

  B) A payload derived from ebXML Business Process modelling, constructed
using Core Components and other data elements defined in accordance with
ebXML rules (and whose defintions are stored in ebXML Registries), and
rendered in XML in a manner compliant with ebXML rules for rendering
transactions, is in my opinion an ebXML (business) payload. An ebXML
message, with or without an ebXML payload, may be accompanied by one or more
non-ebXML (bsusiness and/or internal) payloads.  An application payload may
consist of (from my knowledge of ebXML specifications) at most one ebXML
(business) payload, and zero or more other payloads  Herein, I define a
payload rendered anything other than XML (e.g., in EDIFACT) as an ebEDI
payload, just to make it absolutely clear that such rendering is not what I
have termed an ebXML (business) payload.  IF we've overloaded payload, we
can use some other terminology. I don't care what we choose to call it.  The
important thing to observe is that an ebXML (business)payload, as I herein
define it, is rendered in XML, and so is eligible to be carried in
SOAP-ENV:Body, which after all is where the SOAP examples in their
specification carry the application payloads. 

Finally, Chris states: "Better to allow the MSH to not have to deal with
application payload at all, regardless of its type."

An intermediate MSH (should one exist) need not deal with the payload,
unless it plays an Actor role that requires it to deal with the payload.  In
that case, it can consult a Manifest in the header asociated with that Actor
role (or perhaps alternatively, it can consult a Manifest in the header
associated with the end recipient) to locate the parts of the payload it
needs to deal with. 

A recipient MSH has to provide an interface to the recipient application to
pass the payload to the recipient.

Cheers,
       Bob
-----Original Message-----
From: Marc Breissinger [mailto:marcb@webmethods.com]
Sent: Tuesday, February 27, 2001 2:19 PM
To: Miller, Robert (GXS)
Cc: ebXML Transport Mailing List
Subject: RE: MIME Envelope Optional?


Again, I must go back to KISS and the idea of deviating as little as
possible from the original specification.  The case Chris brings up (i.e.,
no application payload) was entirely possible before the adoption of SOAP.
We did not do away with the MIME envelope then.  Why would we do away with
it now?  So, my vote on this issue is no.

Bob, we need to be careful in characterizing "payload."  There is no such
thing as 'ebXML payload', only application payload - and we have *always*
placed application payload in a separate MIME part.  It has never be part of
the same XML document as the ebXML header information.  IMHO, that is a very
simple rule and eloquent.  If we were to say payload always goes into the
SOAP Body, then we have to deal with the dirty work of encoding non-XML
application payload in the MSH (TRP is payload independent), or worse still,
forcing the application to do it.  Better to allow the MSH to not have to
deal with application payload at all, regardless of its type.

marc

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Tuesday, February 27, 2001 2:35 PM
To: Miller, Robert (GXS)
Cc: ebXML Transport Mailing List
Subject: RE: MIME Envelope Optional?


Chris,

As I read the argument for disallowing any payload in the SOAP-ENV:Body, it
was that then the ebXML data would always be in the same place.  This flowed
from a concern that one might place the ebXML payload in EITHER the
SOAP-ENV:Body or in an attachment.  As you note below, ebXML payloads
containing acknowledgements etc would still show up in SOAP-ENV:Body.  So
where is the eloquence in all that?  Eloquence is always placing the ebXML
payload (if one exists) in SOAP-ENV:Body.  That is, eloquence in sense you
use it is brought to the table by my proposal, not by the proposal to place
the (user) ebXML payload in an attachment!

Cheers,
        Bob

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Tuesday, February 27, 2001 1:16 PM
To: Miller, Robert (GXS)
Cc: ebXML Transport Mailing List
Subject: Re: MIME Envelope Optional?


"Miller, Robert (GXS)" wrote:
>
> I did not here any discussion in Vancouver whether the MIME envelope might
> be optional in cases where the message payload contained only XML syntax.
> It seems logical to me that the MIME envelope would be optional in such
> cases.
>
> Cheers,
>         Bob
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org

If we disallow any "payload" in the SOAP-ENV:Body element, as has been
suggested and eloquently argued, then this would never be the case.

However, an acknowledgment, error (SOAP:Fault) or StatusData message
which have no business "payload" *could* be sent absent the MIME
packaging. Now the question becomes, is this what we want?

Cheers,

Chris

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org