Re: Latest ebXML Message Envelope Specification-version 0-5

[Prasad Yendluri <pyendluri@vitria.com>]

Hi Dick,

I mostly have the same basic comments I had on the previous version (except the last one):

1. RFC conformant use of the "type" paramater with multipart/related type. That is specify the root document type in the "type" parameter, instead of the current value "ebxbl". This you also listed as open issue in this email.Could we flag this as an open issue in the specification.

2. How do we provide for consistent reference of what is sent and what is received between sending and receiving entities so that a verifiable non-repudiation of receipt can be generated. The issue I had was with the pushing the MIME headers from ebXML Message Envelope into the transport level MIME headers. The examples in sections 4.7 and 4.8 show the "Content-Type" and other headers from "ebXML Message Envelope" being used at the tranport level, effectively removing them from the transport level payload (a.k.a ebXML Message Envelope).  It was suggested one could simply add (prepend) these headers back on the receiving side, to recreate the original ebXML Message Envelope. The problem I see with that approach  is, SMTP and HTTP transports do not necessarily preserve the order, case, spacing and other attributes of the MIME headers.  For example how does the receiving side "ebxmlhandler" entity know in which order the original "ebXML Message Envelope" had the Content-Length, Content-Type, Content-Description and MIME-Version (etc.) headers? Also was the casing like Content-Type (vs) content-type? Was the "bondary" listed on the same line as the "Content-Type" or was it split on a separate line etc. All these factors are not significant w.r.t. HTTP or SMTP transport. However they are significant when one needs to generate a non-refutable receipt. The digest computed would be different (obviously) if the received message is not exactly identical to the sent one.

3. Wondering if using "application/vnd.ebxml" in place of application/xml is better. I mean ebXML is not a "vendor" and the subtype "xml"  is more likely to have a readily available support than "vnd.ebxml".

My few cents however.

Best Regards,

Prasad
 
 

Dick Brooks wrote:

Thanks to Ian Jones and Chris Ferris for improvements in structure and
verbage throughout the attached, revised document.

Ian/Chris, I had formatting problems with the graphics used to describe the
nested enveloping structure in section  4.2 and have made some adjustments.
I've also added a few names to the contributors section.

There remain a few open issues with the current enveloping specification,
most notably:

- possible mis-use of the type parameter within the multipart/related header

According to section 3.1 of RFC 2387 the type parameter must contain the
MIME media type of the root body part. The current ebXML enveloping spec
does not follow RFC 2387 recommended usage for the type parameter. One
possible solution that has been discussed is the use of an ebXML MIME media
type to identify the ebXML header document (application/vnd.ebxml). The
application/xml media type currently associated with the ebXML header
document would be replaced with application/vnd.ebxml. The ebXML enveloping
specification would be modified to require the type parameter of the
multipart/related header to contain "application/vnd.ebxml" (media type of
the root body part), in accordance with section 3.1 of RFC 2387.

- possible mis-use of the Content-ID header within the header and payload
envelopes

According to section 7 or RFC 2045 the value associated with Content-ID must
be globally unique. The current ebXML enveloping specification does not
adhere to RFC 2045 specifications. One possible solution is to replace the
Content-ID header with the Content-Description header. The identifiers
"ebxmlheader" and "ebxmlpayload" would be associated with the
Content-Description header.

If anyone has comments or other suggestions related to the revised
specification or these outstanding issues and possible solutions please feel
free to comment/reply to this message.

Thanks,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions