OASIS ebXML Message Service Specification Errata
Version 4.1
Working Draft 4.1, 08 January 2003
- Document identifier:
ebxml-ms-errata-4.1
- Abstract:
This document details errors, omissions and clarification identified for the ebXML Message
Service Specification version 2.0.
This errata document MUST only be used in conjunction with the specification detailed above.
Its purpose is to improve the quality of the specification, reduce inconsistancies and improve
the interoperability of solutions based on the specification.
Copyright ©
2003
The Organization for the Advancement of Structured Information
Standards [OASIS]
This document details errors, omissions and clarification identified for the ebXML Message Service Specification version 2.0.
This errata document MUST only be used in conjunction with the specification detailed above. Its purpose is to improve the quality
of the specification, reduce inconstancies and improve the interoperability of solutions based on the specification.
This document contains 4 major sections:
Known errors - details errors in the specification.
Minor typographical errors - details textual and grammatical errors in the specification.
Clarifications - details areas that required additional information to aid implantation.
Miscellaneous - details any other relevant information.
All sections are ordered by the section number of the affected section of the original specification.
During Draft phases of this document, the source of the Errata item will be tracked,
this information will be removed for the final draft of the document.
The key words
must
,
must not
,
required
,
shall
,
shall not
,
should
,
should not
,
recommended
,
may
, and
optional
in this document are to be interpreted as described in rfc2119.
The target audience for this specification is the community of
software developers who will implement the ebXML Message Service
2.4. Caveats and Assumptions
It is assumed the reader has an understanding of communications
protocols, MIME, XML, SOAP, SOAP Messages with Attachments and security technologies
This section details all the errors in the specification identified by the
date on this document together with their resolution or impact.
They are ordered by their section number in the original specification.
3.1. Section 3.1.9 Message Header Sample
The example in this section shows a MessageID that does not appear to conform to RFC 2822.
In section 3.1.6.1 MessageId Element, lines 878 - 879 the specifcation states
“The REQUIRED element MessageId is a globally unique identifier for each message
conforming to MessageId [RFC2822].”
Within RFC 2822, a BNF shows the format as "<" id-left "@" id-right ">".
All examples in the specification follow this BNF notation, except for the example in
Section 3.1.9 lines 932 to 936 as below.
<eb:MessageData>
<eb:MessageId>UUID-2</eb:MessageId>
<eb:Timestamp>2000-07-25T12:19:05</eb:Timestamp>
<eb:RefToMessageId>UUID-1</eb:RefToMessageId>
</eb:MessageData>
RECOMMEND that this example be changed to read :
<eb:MessageData>
<eb:MessageId>UUID-2@example.com</eb:MessageId>
<eb:Timestamp>2000-07-25T12:19:05</eb:Timestamp>
<eb:RefToMessageId>UUID-1@example.com</eb:RefToMessageId>
</eb:MessageData>
Source: DGI ebXML Messaging Interop Trials
3.2. Section 2.1.2 Message Package
The example in this section has a misformatted start element. 2 other examples in the specification
that reference the start element are correct.
Currently lines 507 – 511 read as below ;
Content-Type: multipart/related; type="text/xml"; boundary="boundaryValue";
start=messagepackage-123@example.com
--boundaryValue
Content-ID:<messagepackage-123@example.com>
RECOMMEND that lines 507 - 511 be changed to read ;
Content-Type: multipart/related; type="text/xml"; boundary="boundaryValue";
start=”<messagepackage-123@example.com>"
--boundaryValue
Content-ID: <messagepackage-123@example.com>
Source: Japan ECOM ebXML Messaging Interop Trials
4. Minor Typographical Errors
This section details minor errors in the text of the specification.
They are ordered by their section number in the original specification
This section contains additional information to clarify the specification due to ambiguities,
conflicts or as a result of prior implementations
5.1. Section B.2.2 Sending ebXML messages over HTTP
Lines 2456 - 2458 state
“The rules for forming an HTTP message containing an ebXML Service Message are as follows:
The Content-Type: Multipart/Related MIME header with the associated parameters,
from the ebXML Service Message Envelope MUST appear as an HTTP header.”
RECOMMEND that lines 2456 – 2458 be changed to read
“The rules for forming an HTTP message containing an ebXML Service Message are as follows:
The Content-Type: MIME header with the associated parameters, from the ebXML Service Message
Envelope MUST appear as an HTTP header.”
As they read currently, these lines insinuate that all messages must specify Multipart/Related.
The 2.0 specification makes allowances for “simple SOAP” messages where no payload is present,
therefore allowing for the presence of non Multipart messages, including SOAP faults.
Source: DGI ebXML Messaging Interop Trials
5.2. Section B.3.2 Sending ebXML messages over SMTP
Similar to the HTTP clarification above, lines 2622 - 2623 state
"The Content-Type: Multipart/Related MIME header with the associated parameters,
from the ebXML Message Envelope MUST appear as an eMail MIME header.”
RECOMMEND that lines 2622 - 2623 be changed to read
"The Content-Type: MIME header with the associated parameters,
from the ebXML Service Message Envelope MUST appear as an eMail MIME header”.
As they read currently, these lines insinuate that all messages must specify Multipart/Related.
The 2.0 specification makes allowances for “simple SOAP” messages where no payload is present,
therefore allowing for the presence of non Multipart messages, including SOAP faults.
Source: DGI ebXML Messaging Interop Trials
6. Miscellaneous, Non-Normative Recommendations
This section details any additional information that has been found useful during prior implantations
that does not belong in any of the previous sections.
6.1. Section B.3.2 Sending ebXML messages over HTTP
Lines 2461 - 2463 state
“The mandatory SOAPAction HTTP header field must also be included in the
HTTP header and MAY have a value of "ebXML”
For example, SOAPAction: "ebXML".
These lines are vague on whether or not synchronous responses are also required
to contain a SOAPAction header.
RECOMMEND that sending MSHs act liberally in allowing the presence and or absence of SOAPAction in synchronous
responses, and that implementers refer to the SOAP 1.1 specifications for guidance.
Source: DGI ebXML Messaging Interop Trials
6.2. Section 4.3.1 SyncReply Element
Line 1392 states that
“The SyncReply element MAY be present as a direct child descendant of the SOAP Header element”.
The specification does not forbid the presence of the SyncReply element in a synchronous response.
RECOMMEND that sending MSHs act liberally in allowing the presence and or absence of SyncReply
element in synchronous responses.
Source: DGI ebXML Messaging Interop Trials
A. Revision History
| Revision History |
|---|
| Revision 4.1 | 08 January 2003 | |
| Port to docbook. |