Packaging items to be discussed in Dallas.

["Dick Brooks" <dick@8760.com>]

Packaging Sub-group Open Items List
April 3, 2000

The packaging sub-group of the ebXML Transport, Routing and Packaging group is responsible for 
developing specifications describing the format and syntax of "envelopes" used to transport 
ebXML  request and response messages. The group has reached consensus with regard to an outside 
envelope "standard" for request messages. Multipurpose Internet Mail Extensions (MIME) and the MIME 
content-type multipart/related were selected by the group as the standard outside envelope of all 
ebXML request messages. MIME was choosen due to its ability to meet the set of requirements identified 
by the packaging sub-group and the apparent lack of a "pure XML" based standard for packaging/enveloping. 

Additionally, the packaging sub-group has defined two top level body parts within the multipart/related envelope:
1. An ebXML header "container"
2. An ebXML payload "container"

The ebXML header "container" is a MIME body part with a content-type of text/xml. A MIME Content-ID header, 
with a vlue of "ebXMLheader", is associated with this body part. The content of this body part is a instance of an 
ebXML header document, as defined by the ebXML header group. 
Consensus has not been reached on this proposed ebXMLheader packaging, and there are open issues.

The ebXML payload "container" is a MIME bodypart whose Content-type is determined by each implementer and
is based on the type of data being enveloped. A MIME Content-ID header, with a vlue of "ebXMLpayload", is 
associated with this body part. It is the sending parties responsibility to assign the content-type to the 
ebXMLpayload container.For example, a company sending a plain text file would identify the content type as text/plain. 
The same plain text file, in encrypted form (using PGP), would be identified with a Content-type of 
multipart/encrypted; protocol="application/pgp-encrypted". 
Consensus has not been reached on this proposed ebXMLpayload packaging.


OPEN ISSUES:

Should the ebXMLheader container be a multipart/related content type instead of text/xml in order to allow a mix of 
signed/unsigned, dynamic and static headers? Depends on header group decisions.

Should the outside envelope include a Content-Length? It will help companies enforce limits on the maximum message they're 
willing to receive! Can also be used to determine if sufficient disk space is available.

Need to define the outer envelope and structure of a response message?

Reach consensus on ebXMLheader and ebXMLpayload packaging.

Decide on whether to allow multipart/form-data for the outside envelope and content-disposition with a "name" 
attribute to identify the ebXML header and ebXMLpayload body parts.

Define error messages and error reporting associated with enveloping. 

Need to define "transport specific headers to accompany the outside envelope. For example, with HTTP
should Connection: Keep-Alive be used in all POSTED requests or only 
those sessions with an immediate acknowledgement using synchronous processing? 
One way and asynchronous processing modes do not require this header to be present.