Re: Latest packaging spec...

[Prasad Yendluri <pyendluri@vitria.com>]

Hi,

Another reason we need to have what is sent and what is received identical to each other, is for the "non-repudiation of receipt" purposes.

The way "non-repudiation of receipt" is accomplished is by "the receiving party" putting the digest on the received message in the Acknowledgment  and signing the Ack message sent back to the "originating party". The originating party then makes sure the digest in the Ack matches the digest they generate on the copy of the message they originally sent out. This is feasible only if the "ebXML Message" sent and the one received are identical to each other. If the Message Envelope is removed (and merged into transport envelope) by the sending side and is regenerated by the receiving side, both entities are not necessarily identical and we will not be able accomplish non-repudiation of receipt.

Just another issue I can think of. Hence IMHO, the transport mechanism should not mess with the "message envelope" and should be left independent of and untouched by the transport mechanism.

Best Regards,

Prasad

Prasad Yendluri wrote:

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.

• The Message Structure (sec 4.2) shows the "Transport Envelope" encasing the "ebXML Message Envelope", which is consistent with the (latest) Message Header Specification also. However section 4.7 "complete example of .. ebXML message .. sent via HTTP POST", brings in the complete ebXML Message Envelope into the transport envelope. I mean the headers like, "Content-Type: multipart/related; type=ebxml", "Content-Length" etc. are made part of the MIME headers for the HTTP POST. This, I think is undesirable for the following reasons:

1. This blurs the distinction between the two envelops. The transport mechanism should simply "transport" and "deliver" the entire "ebXML Message Envelope" with its constituent parts as is.

<db> Yes, I see your point. However the alternative to the current approach would require us to create and register a new multipart content-type (because we are defining a multipart object). If we were to create a "multipart/ebxml" content type, as a replacement for multipart/related, would this remove the "blur"?</db>

<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.
</PY>

1. When other transports like FTP are used, we will deliver the entire mime/multipart message with the message envelope headers. That would make the delivered goods inconsistent between the two kinds of transports.

<db> I disagree, the FTP transport is simply different from other transports in that it is not "MIME aware" and does not attempt to define the type of data being sent (other than generically binary or ascii). ebXML implementers will have to "adjust" to the requirements of each transport they plan to support. In the case of FTP the "RAW" ebXML message is sent without prepending any transport specific MIME headers whereas SMTP and HTTP, being "MIME aware", makes it appear like the transport and message envelopes are one. This is simply a side effect of "MIME aware" transports. </db>

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

1. An organization receiving ebXML messages from via different transports corresponding to say different partners, might want to deliver them all into an input queue processed by a common processing logic. The messages delivered from all transport mechanisms need to be in identical format for this to be possible.

<db>I believe this will be possible using the current packaging, however all ebXML implementers must be prepared to handle transformations to ebXML messages caused by specific transports.

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

1.  When SSL is used,  if I am correct the HTTP POST / GET related headers are not protected by SSL. Only the content is.

<db>Reference an earlier post to this issue - RFC 2246/page 31 appears to indicate that ALL data is encrypted.</db> 

<PY> O.k. I was not sure also. Not an issue to worry about anymore. </PY>

1. Last but probably not least.  With this mechanism, if the type of the ebXML message ever changes (e.g. from MIME to XML), we will need to rehash the transport envelop all over. It would be desirable to ship either XML or MIME formatted ebXML message using the same transport envelope type.

<db>It's difficult to say what changes would be needed with a "pure XML" enveloping scheme because one does not exist. However I do believe there could be lots of changes to the current MIME based ebXML specification.  I really don't believe we can avoid changing the current specification and code base when/if an XML packaging standard arrives and is adopted by ebXML.Even if we adopted a scheme like you describe below, it too would be vulnerable to change under a pure XML approach.</db>

<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.
</PY>

<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.
 </PY>

Thanks again.

Prasad

 

Dick Brooks 

http://www.8760.com/

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,

POST /ebxmlhandler HTTP/1.1
Content-Type: application/x-ebxml; <any params?>
Content-Length: 9293
...........etc..........

{ The entire MIME multipart/related message goes here}
 

• The content-type of the ebXML header container also needs to be of a flexible type like the payload and not fixed at application/xml since,

1. We expect more than one header part in the ebXML header. Per the latest Header specification sent out by David Burdett, the header can have parts for "Message Routing Info", "Message Routing History", "Signatures", "Errors?" etc.
2. Even if we think some of these headers can be sub-elements/sections of the same XML document, it seems other parts (e.g. signatures) need to be separate at least as of now (since xml-dsig specifications / implementations are not mature yet). Also, it might be needed to put the routing headers in a separate (XML) document so that it can be updated (and signed) independent of the rest of the header sections.


Hence I would also like to recommend we make the header content-type also flexible with Content-Id value of "ebxmlheader" clearly identifying it as ebXML header.
<db> Actually I think this is already the case, reference section 4.5.1 at the bottom of page 11.</db>

Thanks, Prasad