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: Re: Latest packaging spec...

Hi Dick,

This is the basic premise of my argument or thinking:

The "ebXML-Headers part and the ebXML-Payload part(s) encased in the ebXML envelope" is the primary unit of exchange between two ebXML end-points, transported through any transfer mechanism. The message envelope is needed to keep the headers and payload together. We chose MIME based enveloping scheme (or the multipart/related message envelope) as it provided the ideal packing scheme at this point in time. With the potential for use of all XML packaging scheme in the future, the entire message envelope (and contents) should be viewed as an opaque-object that is simply transferred over a transport. Hence transport related headers (MIME or not) should be layered on top of this object based on the needs of the transport and they should not disturb the basic ebXML message structurally.

The ebXML Message Header Specification and the Requirements specifications refer to the "ebXML Message Envelope" as transport independent envelope, and calls for a separate transport envelop, which is also consistent with the above.

If my basic premise is incorrect then I have no case. However, if that is accurate then I would suggest we keep the transport headers layered on top of the whole envelope and not merge the envelope into transport headers.

Breaking up the message envelope at the transport level in a transport dependent way complicates things like saving the entire received message for non-repudiation etc. also. If we were to keep the transported object always consistent and independent of transport, this process would be much simpler.

Please see below some follow up in <PY> also.

"Dick Brooks (E)" wrote:

Hi Prasad,see inline comments marked with <db></db>
-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Tuesday, April 25, 2000 5:07 PM
Hi Dick,

I have couple of comments. Sorry I missed to recognize these last time around.

<PY>  My issue is with merging the ebXML message envelope into the HTTP transport envelope. Multipart/related for ebXML message envelope is good. However, the entire ebXML message envelope (and contents) should be preserved as part of the transfer mechanism. If we don't do it, we have already separated out the headers and payload at the transport level itself and removed the message envelope prior to transfer.

We are supposed to save the entire received message for non-repudiation. How do you define what constitues a  received message unambiguously if what exactly is received changes with the transport?

The new Message Header Specification puts the "Check Message Structure" step, that checks for proper MIME formation of the message after the save step for the same reason, in the "ebXML Aware Software Layer". This is consistent with the transport layer simply transferring complete ebXML-Message-Envelope as is.

We should not make the delivered goods variable based on the transport used. This would complicate and  make inconsistent the processing steps from both specification and implementation perspectives.

As I stated above, the processing steps as specified in the "ebXML Aware Software Layer" of the "Message Header Specification" become highly transport dependent and confusing. We should avoid that by all means.

<PY> This calls for regeneration of ebXML message envelop on the receiving side.  If you regenerate the ebXML message envelope on the receiving side in a transport dependent way, we would have potentially different  versions of the same ebXML message (envelope) received by different partners through different transports. How does a sending side really reconcile in case of a dispute?
By the current mechanism, adding the ebXML Message envelope is selectively handled by the transport layer (either on the sending or receiving side), which should not be case.
<PY> O.k. I was not sure also. Not an issue to worry about anymore. </PY>
<PY> If we keep the transport headers  really independent of the payload type, and payload envelope independent of transport mechanism, I see no reason to change the transport envelop later on.
<db> In summary, I understand your concern, but I'm having trouble seeing how an additional level of enveloping helps solve the issues you raise above.The added envelope appears redundant with respect to FTP, plus the ebXML group would have to register a new MIME type and define it's behavior/structure/semantics, and this could take a fair bit of time. I really believe the current packaging is capable of meeting the needs you identify.</db>
<PY> I am beginning to think we have some disconnect here. I am not calling for additional level of enveloping. I am suggesting we keep the transport and message envelopes really separate and not merge one into the other. What I am proposing does not require FTP to have additional redundant envelop (MIME headers).

I am not sure if we really need a new MIME type? The ebXML-Message-Envelop would still be of multipart/related. It is just the HTTP / SMTP transport level would have an "application/x-ebxml" type.

The use of  "application" content-type is appropriate IMHO here since it is really data for the ebXML application and with the use of "x-ebxml" subtype we do not require to register a new MIME type. The use of the application type is also consistent with the MIME specifications.

Thanks again.



Dick Brooks 


Hence I would like to suggest that we use a different "fixed" content-type for the HTTP transport. For example "application/x-ebxml". Then the example would look like,

Thanks, Prasad

[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