Attendees :
Doug Bunting
Jacques Durand
Ian Jones
G Neelakantan Karta Sterling (part time)
Eric Van Lydegraf

Telephone attendees:
(various times and duration)
Cliff Collins
Mike Dillon
Brian Gibb
Mike Kass
Matt Mackenzie
Dale Moberg
Jeff Turpin
Pete Wenzel

1. Proposed agenda accepted with one concern from Doug about attendance as we did not have a quorum to be able to vote on any issues.
2. Due to the low attendance no need for formal secretary etc. was identified (Ian took minutes)
3. Ian described current requirements and discussion on the nature and scope of the requirements followed to validate if these were still requirements.
4. New requirements were added to the list – see web sit for the additions.
5. The requirements were then prioritised and initial level of impact identified to try and identify which requirements would be suitable for a version 2.X release (i.e. bug fix and minor semantic changes) and which would be major changes resulting in a version 3.0 specification.
6. During the discussions Relationships with WS-security and/or W3C groups were discussed and added to the requirements list. This is not strictly a requirement but could impact on several relating to SOAP version, security and multi-hop messaging.
7. The WS-Security team currently schedule to release version 1.0 in March 03. This release is currently planned to include Digital Signature, Encryption of Soap header and attachments and carrying authentication tokens.
8. Action Submit requirement to WS-Security TC to use our definition of signature transform as an option to allow us to remain upwardly compatible. The current draft proposes a different signature definition which would require us to change and make messages potentially incompatible between the existing Version 2.0 and any new release including the WS-security work. (See note below)
9. Dale is arranging a conference call with the of WS-Security TC and Ian will present our requirements to the TC.
10. Action Dale to talk to Karl about formal liaison to WS-Security. A preferred solution would be for the MSG TC to Security Joint Committee.
11. Action Jeff to ask vendors with multi-hop issues that were identified during the Drummond Group interoperability testing to contact the TC with details.

Thursday

12. After discussion is was felt a sensible position to wait for SOAP 1.2 to become a recommendation before deciding if, how and when we would migrate to it.
13. Action: Doug will begin to look at the issues list and ensure it is still relevant and accurate.
14. Proposal: Sync reply requirement 20.

Amending the definition of reliable messaging to explicitly state that messages received out of sequence will not be made available to the application until all preceding messages have been received in the sequence.
This clarifies the semantics of the "Acknowledgement" element.
Amend "MessageOrder" element presence rule to explicate state that the CPA must set either SyncReply to "none " or "MSH Signals only"
Section 9.2 need reworking to include an error message of inconsistent should be returned if the message setting and CPA do not match.
Also make the use of "MSH signals only" the only mandatory "core" feature provided the underlining transport is synchronous.
15. Mike Dillon raised a question about SOAP Action in the HTTP headers. A clarification on its inclusion in the reply may be required. This is believed to be an ambiguity in the SOAP 1.1 specification and therefore may be out of the scope of this TC. Also this may be superseded in SOAP 1.2 to be investigated as mandatory nature of SOAP Action is one of the items likely to change in the current drafts..
16. Mike Dillon identified a conflict of the Soap HTTP content type when a message with no payload being multipart/related a simple change to the HTTP binding could fix this. This must be checked prior to any change to ensure consistency throughout the specification.
17. No explicit exclusion of syncreply in a synchronous reply – This must be addressed as it is an potential problem if this is used although all identified implementations spotted that this was not a sensible implementation.
18. For MIME headers they should be case insensitive. This requires clarification from the IETF MIME RFC’s before this is included.
19. Use of the "@" in content Id and message Id, this may be a MIME spec reference issue. The spec is not consistent with use of this. As a minimum the specification must be made self consistent and validated against the MIME RFC’s
20. Doug lead discussion on modularization of the existing structure of the message.

Proposal: Split message data and duplicate elimination from the message element and make them top level elements in their own right. Group CPAId and conversation into a new a top level element.
Implication: For a SOAP message to be an ebXML conformant message it would have to contain all the top level elements and it would also increase the size of each message and the speciofication.
21. Dale re-joined the call and a discussion on CPP/A and messaging use of intermediaries. No current requirements to support mult-party transaction with intermediate CPAs.
22. CPP/A have deferred work on WSDL as BPSS have asked them to wait until they had finished some investigating of how they will or may use WSDL. Also WSDL 1.2 is still very fluid and CPP/A will wait for a more stable version. Must effort is to complete the negation spec.
23. X.12 will be using ebXML infrastructure in the future and will require a method to transfer from X.12 ISA structures etc. to ebXML messaging. This work will be subject to further discussion between X.12 people and this team. Currently Bob Miller is likely to move this forward.
24. The work plan (below) was started and the first month of items identified.
25. The Messaging TC thanks ASC X.12 for their support by hosting the meeting and especially to Ralph Berwanger for arranging this for us.
26. The Meeting closed with a thanks to those that attended, your participation was appreciated and progress was made toward our goal of constant improvement of our specification

1. Mike Dillon to own and lead on the Errata document to the 2.0 specification. Initial version within 1 month.
2. Ian to announce errata document and start of version 3.0 with rational for noting being a 2.x release.
3. Set-up liaisons with other teams mainly Security & BPSS.

  Initial action that within 1 month the liaison with the appropriate security team will be established.
  Submit security requirements to the appropriate team
4. People to review existing issue list.
5. People to review the requirements list that was prioritised.
6. Set up a conference calling schedule the initial suggestion is 1 hour every 2 weeks on Wednesdays.

Related documents:
Requirements list & Issues list on web site: http://oasis-open.org/