[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: A rewritten section 7
Since wholesale rewrites seem to be en vogue (at least for RM :), I'm attaching the revision I had promised a couple of weeks ago. Chris had seen it, but disagreed with the scope of the rewrite, so consider this a "minority report." Attached is HTML, and PDF generated from that. There are two minor open items/questions indicated in the text. /r$Title: ebXML Chapter 7
An ebXML Message is a multipart MIME [RFC2045] document. It is designed to be carried over a variety of protocols such as HTTP or SMTP.
An ebXML message has one or two MIME bodyparts, which MUST appear in this order:
As a MIME document, the ebXML Message has MIME headers, and each bodypart has headers as well. The following example shows all these elements:
Content-Type: multipart/related; type="application/vnd.eb+xml";
version="0.92"; boundary="ebxml-part-wrapper"
This is a multi-part MIME message.
--ebxml-part-wrapper
|
MIME message headers |
Content-Type: "application/vnd.eb+xml"; version="0.92";
charset="utf-8"
|
ebXMLHeader bodypart MIME headers |
<ebXMLHeader xmlns="...">
...
</ebXMLHeader>
--ebxml-part-wrapper
|
ebxmlHeader content |
Content-Type: application/xml Content-ID: <po-request-22222-body@example.com> Content-Transfer-Encoding: base64 |
Payload bodypart MIME headers |
12465AB34C... --ebxml-part-wrapper-- |
Payload content |
The MIME message headers are described in section 7.2. The ebXMLHeader bodypart headers are described in section 7.3 The ebXMLHeader content is desribed in section 8. The Payload bodypart headers and content are described in section 7.4
The purpose of the MIME message headers is to allow the carrying transport to identify an ebXML message and deliver it to the local MSH for processing. The interface between the transport agent and the MSH is not specified in this document. For example, whether or not the MSH acts on the complete MIME object, or if it receives it pre-processed, such that the Content-Type header is unnecessary, is left to the local implementation.
The content-type MUST be "multipart/related", with only these three attributes: boundary, type, and version.
The boundary attribute is used to demarcate the ebXML header and payload bodyparts. It MUST be chosen carefully to ensure that it does not occur within the content area of those bodyparts; see [RFC2045] for guidance on how to do this.
The type attribute identifies the data as an ebXML message, and MUST have the value "application/vnd.eb+xml".
The version attribute identifies the version of this specification to which the document conforms. Carrying transports should treat this as an opaque string and not rely, e.g., on sorting characteristics. It MUST have the value "0.92".
If present, the MIME-Version header MUST be interpreted according to [RFC2045].
If present, the Content-Transfer-Encoding header MUST be interpreted according to [RFC2045].
MIME headers do not have a mechanism comparable to the "mustUnderstand" attribute. Therefore, it is RECOMMENDED that ebXML processors avoid additional headers unless they are confident that all the entities that will be processing the message can properly implement the semantics of those headers.
The ebXMLHeader bodypart is a conforming XML Media Type [RFC3023].
Two headers MUST be present in the MIME headers for the ebXMLHeader bodypart: the Content-ID and the Content-Type.
The semantics of this headerare described in [RFC2045]. <r$>Need a sentence of explanation why this is needed. Or did I get it wrong?</r$>
This header identifies the bodypart as an ebXMLHeader document.
It MUST have the value "application/vnb.eb+xml", with only these two attributes: charset and version.
The charset attribute identifies the encoding used in the ebXMLHeader bodypart. As described in [RFC3023], this attribute is optional and has no default. If present, it MUST match the encoding of the XML document in the bodypart content -- the same encoding value if present in the XML declaration, or "UTF-8" if no encoding declaration appears. Further description of the semantics are decribed in [RFC3023].
The version attribute identifies the version of this specification to which the document conforms. It will always have the same value as the version attribute in the ebXMLHeader XML document, described in section 8. It MUST have the value "0.92". <r$>Why is version here? I would like to leave it in the ebXMLHeader XML document. If it must be here, a sentence of rationalization would help.</r$>
For maximum interoperability, the bodypart SHOULD be in UTF-8 and the charset attribute SHOULD be present with that same value.
If present, the Content-Transfer-Encoding header MUST be interpreted according to [RFC2045].
It is RECOMMENDED that the "#wildcard" element (see section 8.2.3.9) of the ebXMLHeader document be used instead of any headers other than those defined here.
This specification makes no provision, nor limits in any way, the structure or content of the payload. For example, it may be (legacy) binary data, a plain-text object, or a complex nested multiplart MIME object. The syntax and semantics of the payload are left to the application designer.
Two headers MUST be present in the MIME headers for the payload bodypart: the Content-ID and the Content-Type. Their semantics are described in [RFC2045]. The Content-ID is required to ensure that an ebXMLHeader document will always have a way to reference the message payload. The Content-Type is required by the MIME specification.
If present, the Content-Transfer-Encoding header MUST be interpreted according to [RFC2045].
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC