[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Packaging items to be discussed in Dallas.
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.
Powered by eList eXpress LLC