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

[Dick Brooks <dick@8760.com>]

Prasad, please accept my apologies for the long delay, see responses inline.

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Monday, July 24, 2000 7:39 PM
To: Ebxml
Subject: Re: Version 0.6 of the ebXML packaging spec is now ready for review/comment

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.
[Dick Brooks]  

I will add a paragraph or two to section 4.4.1 describing the decision to create the application/vnd.eb+xml media type and its intended usage. I'll also include references to the ebXML header spec as part of this description.  Thanks..

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.
[Dick Brooks] 

I'll address the charset question in the answer to # 3.

The "version" parameter was added during the Dallas meeting in April and your observation is correct, it's non-standard, relative to RFC 2387. It has always bothered me to have the version identified at this level, I believe it would be more appropriate as part of the ebXML header definition ("application/vnd.eb+xml"). 

How does the group feel about moving the version attribute from the message envelope content-type header to the ebXML header content-type (e.g. Content-type: application/vnd.eb+xml version="0.1")? Doing so would also eliminate any potential "risk" of the web server not passing this data through.  

 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).
[Dick Brooks] 

Several people have provided feedback that a charset parameter would make life easier on implementers. I investigated the use of this attribute in both MIME (RFC 2046 section 4.1.2) and HTTP (RFC 2616, section 3.4). Both strongly encourage its use, especially for text entities.  The HTTP spec states:

"Applications SHOULD limit their use of character sets to those defined by the IANA registry."

RFC 2387, the multipart/related spec, does not include a "charset" parameter and use of this parameter at the ebXML message envelope level appears to be a non-standard use of the multipart/related media type.

The character set of the payload body part is determined at runtime, and cannot be "set" within the context of the ebXML packaging spec. I suppose the packaging spec could "RECOMMEND"  that payload envelopes include the charset attribute when appropriate. I'll be happy to include this "suggestion" under the section describing the payload, if the group thinks this would help. Do I hear a Yea or a Nay?

With regard to the ebXML header document, it is a given that this document is expressed in XML and all XML compliant processors must be capable of handling both UTF-8 and UTF-16 (ref section 2.2 of XML 1.0 spec). The XML prolog contains an attribute (called "encoding") to identify the character set used in the document. It seems to me the information regarding character set is of most value to the XML processor and for this reason the identification of character set should be stated within the XML prolog as opposed to the MIME envelope. By placing the encoding into the XML prolog the XML parser will then have access to the information and can invoke proper processing. If the character encoding were placed into the MIME envelope then the program used to parse the XML document would have to be made "aware" of the encoding either programmatically or by altering the XML document prolog to include the encoding attribute, set to the character set that was identified in the Content-type header. BUT, making such alterations is risky, especially when dealing with signed documents. 

The bottom line is this; It appears the character set encoding for the ebXML header should be identified within the XML prolog of the ebXML  header document. The ebXML payload envelope Content-type is dynamic and germane to the type of object contained in the payload, in other words. the Content-type is determined by the implementer at runtime. It would appear the BEST we can do within the packaging spec is RECOMMEND that implementers specify the charset attribute within the Content-type of all payload body parts whenever appropriate.

I feel like I'm rambling, but hopefully this diatribe will help you understand my conclusions.

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.
[Dick Brooks] 

Already resolved thanks to Prasad and Marc. 

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

Good catch Prasad, I've already made the correction. 

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".
[Dick Brooks] 

Implementers should follow the packaging conventions specified in section 3.4.3 of RFC 2311 if using S/MIME or section 5 or RFC 2015 is using PGP. These specifications "wrap" the "signed object" with a multipart/signed, just as you've indicated. One point of clarification, the application/vnd.eb+xml is not "changed" it is simply "wrapped" by the multipart/signed, for example:

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42

--boundary42
Content-Type: application/vnd.eb+xml

<?xml version="1.0" encoding="UTF-8"?>

........ebXML header document

--boundary42

Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
--boundary42--

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?
[Dick Brooks]  

I believe this is an implementation decision. If a party wishes to sign both header and payload then I recommend that the entire ebXML message be contained in the signature block and the packing of this output follow RFC 2311 or 2015 as appropriate. Does anyone else have another position on this?

That is all I have.
[Dick Brooks] 

Great work Prasad.... 

Thanks, 
Dick    
 

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