Re: Version 0.6 of the ebXML packaging spec is now ready forreview/comment

[Prasad Yendluri <pyendluri@vitria.com>]

Hi Dick,

Precise and very well defined document.  I have a few requests for clarification.

1. The type "application/vnd.eb+xml" is asked to be used. I think this deserves more "introduction" than what is provided. That is, what are the semantics of this type? How is this different from application/xml (or text/xml) and the need for this special type. Is the "ebXML" header only place that this type could be used?

This type (subtype) is first introduced in 4.4.1.1 (page 10) and specified in section 4.5.3 (page 12). Either one (probably latter) is a good place to add some detail regarding this type.

2. We discussed this before but, multipart/related type is asked to be used with parameters "version" and "charset" (section 4.4.1.2 & 4.4.1.3). As we identified before, these are not defined for this type (RFC 2387). I know we are taking great care to be compliant with the standards in general. Am I wrong or does it make sense to state these exceptions in the spec? BTW has anyone checked if HTTP passes such (private) parameters through? HTTP can be strict some times.

3. BTW what does charset specification at message envelope level (multipart/related) mean? Does it imply, the spec is applicable to all parts in the message (hdr + payload)? I mean what is the purpose of specifying it at that level, as opposed to individual parts (e.g. application/xml, that already supports encoding attribute).

4. What is the specification on "start" parameter for multipart/related type? Is it ok to have that or not? To be complete, I think we need to state a direction on that.

5. Section 4.6.3 "The Content-type for an ebXML header is determined by the implementor ". Shouldn't  that be "payload"?

6. Section 4.5.4 Optional support for signed headers. If the headers are signed (using say multipart/signed type), the "type" parameter to multipart/related (message envelope) must also change to "multipart/signed" from "application/vnd.eb+xml".

7. It is recommended that headers and payload be signed separately always? Or can they be signed together? Do your ever forsee a case where they must be signed together?

That is all I have.

Thanks, Prasad
 
 

Dick Brooks wrote:

This version contains the following changes:

- Replaced the ebXML header envelope MIME media type with
"application/vnd.eb+xml"
- Reflect use of "application/vnd.eb+xml" in the type attribute of the
multipart/related Content-type header of the message envelope
- Added charset attribute to the Message Envelope Content-type header
- Content-ID changed to use unique values within the header and payload
envelopes
- Defined the signature block to use when calculating message digests
- Added more acknowledgements
- Fixed some grammatical errors

Rik, please inform the appropriate parties to make this document available
for public review. 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

  ------------------------------------------------------------------------
                                                           Name: ebXML Message Envelope Specification v0-6.doc
   ebXML Message Envelope Specification v0-6.doc           Type: WINWORD File (application/msword)
                                                       Encoding: base64
                                                Download Status: Not downloaded with message