Re: Latest packaging spec...

[Prasad Yendluri <pyendluri@vitria.com>]

Dick Brooks wrote:
> Here it is folks, let me know if I
> missed anything.

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.
2. 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.
3. It would be desirable to allow for the flexibility of de-coupling, delivering the ebXML Message and processing of it. With the envelope headers merged into transport the HTTP receiving entity (e.g. servlet) is forced to process the message as it is posted.
4. 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.
5. When SSL is used,  if I am correct the HTTP POST / GET related headers are not protected by SSL. Only the content is.
6. 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.


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.

Thanks, Prasad