[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Version 0.6 of the ebXML packaging spec is now ready forreview/comment
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 188.8.131.52 (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 184.108.40.206 & 220.127.116.11). 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
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.
Dick Brooks wrote:
This version contains the following changes:
- Replaced the ebXML header envelope MIME media type with
- 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
- 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.
110 12th Street North
Birmingham, AL 35203
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)
Download Status: Not downloaded with message
Powered by eList eXpress LLC