[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Minutes of last call and agenda for Today
Hi all, For todays call, attached is updated errata draft in docbook format. Also attached is a list of outstanding issues, I have gone through a little more than half (of 228). About 50 have been implemented and resolved. About 50 still unresolved, and about 25 seem like low priority, but still unresolved. Mike Dillon mike@drummondgroup.com 817 875 0794 -----Original Message----- From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com] Sent: Wednesday, January 22, 2003 12:29 PM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Minutes of last call and agenda for Today Team, I have posted the minutes of the last call to the web site at: http://www.oasis-open.org/committees/ebxml-msg/minutes/TeleConference_01_08_ 2003.html AGENDA for January 22 1. Role of attendees 2. Report Progress on errata - Mike Dillon 3. Issue list Doug 4. New Item - LZJU90 Compressed Encoding 5. Work Schedule Sorry for the late posting and the lack of prior updates to the web pages. Ian Jones Chair OASIS ebXML Messaging Services TC Email: ian.c.jones@bt.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>Title: OASIS ebXML Message Service Specification Errata
Version 4.1Working Draft 4.1, 08 January 2003
Copyright © 2003 The Organization for the Advancement of Structured Information Standards [OASIS] Table of Contents
AppendixesThis 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 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. 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 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 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 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 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 This section details any additional information that has been found useful during prior implantations that does not belong in any of the previous sections. 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 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 NonNormative[ebMS] Message Service Specification version 2.0 . OASIS (Organization for the Advancement of Structured Information Standards). |
Attachment:
IssuesListNotesJan22.doc
Description: MS-Word document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC