OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-msg] latest errata?


Attached is the latest that I edited last year,
we reformatted it to be based on docbook...

Mike
mike@drummondgroup.com
817 875 0794 (cell)



-----Original Message-----
From: Matthew MacKenzie [mailto:mattm@adobe.com] 
Sent: Thursday, February 19, 2004 9:49 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] latest errata?

Is this it?

http://www.oasis-open.org/committees/ebxml-msg/documents/ 
ebMS_v2_0_errata.html


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgro
up.php.

Title: OASIS ebXML Message Service Specification Errata

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.



1. Introduction

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.

2.  Document Conventions

2.1.  Sources

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.

2.2.  Terminology

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.

2.3.  Audience

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

3.  Known Errors

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

5.  Clarifications

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.108 January 2003 
Port to docbook.

References

NonNormative

[ebMS] Message Service Specification version 2.0 . OASIS (Organization for the Advancement of Structured Information Standards).



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]