|Pete Wenzel||Dec 14, 2005 2:34 pm|
|Subject:||Notes from Dec 7 Conference Call|
|From:||Pete Wenzel (pete...@Sun.COM)|
|Date:||Dec 14, 2005 2:34:25 pm|
Notes from Dec 07, 2005 ebXML Messaging Services TC conference call. Review of comments received from Hamid & Jacques, http://lists.oasis-open.org/archives/ebxml-msg/200511/msg00024.html
1) In the whole document, replace every occurrence of eb:Message by eb:Messaging
This aligns element with the name of the spec, allows for potential future bundling of messages, and containment of other messaging-related elements other than messages themselves. Tentative agreement; no objections at this time. Ian may follow up and raise issues after reviewing his notes.
2) The title of section 3 (on page 18) should be renamed from Concept of Operation to Operation Mode. Operation Mode is the expression that has been chosen to denote the collection of operation contexts.
Has other issues as prerequisites; defer.
3) The title of subsection 3.3 (Message Service Processing Model) should be renamed to MSH Structure, and this subsection should be under the Messaging Model section (Section 2), not under Section 3 (Operation Mode). Therefore, subsection 3.3 should become subsection 2.4
4) Subsection 3.4 (Examples of Supported Topologies) should not be under section 3 (Operation Mode). It should rather be part of the Messaging Model section (Section 2). Therefore, subsection 3.4 should become subsection 2.5
Some debate. Jacques: To accept Hamid's restructuring requires us to agree that Section 3 is not just abstract/conceptual, but includes more concrete implementation guidance as well. Jacques & Hamid will work on a coordinated proposal.
5) Subsection 5.3 (Signal Packaging) should rather be a subsubsection of subsection 5.2 (Core Header Extension). After all, signal packaging is also about packaging in the header. Therefore, subsection 5.2 (Core Header Extension) should have only two subsubsections, namely eb:UserMessage Element and eb:SignalMessage Element.
Agreed. Will adjust heirarchy of document to match that of the schema elements.
6) Remove paragraph (lines 291-292): Implementors are strongly advised to read and understand the Collaboration Protocol Profile. It is very clear in the specification that such binding is out of scope. In other terms, the specification explicitly allows many different representations of an ebXML agreement without being in favor for any of them (such as a CPA for example).
No consensus; decision deferred. Ian: We need a statement that understanding CPP/A is helpful in doing a proper implementation.
7) Editorial issues previously agreed and completed in CD.
8) On line 674, the paragraph should describe not only the processing by the receiving role but also the processing by the sending role, because the picture above it is supposed to describe the structure of an MSH for both a sending and receiving role.
9) Previously agreed to replace figure; already completed in CD.
10) Subsubsection 5.1.3 (ebXML SOAP Envelope Extension ) should be moved to 5.1.4, and a new subsubsection 5.1.3 should be added having the title Example.
Agreed that a complete example be provided in its own section. Some disagreement as to placement of Example section. Some feel it should be first; others would like the normative specification text first with example following.
11) In many examples, the element eb:Partref still contains the attributes eb:id and eb:idref. It was agreed to remove two attributes and use only one attribute called eb:cid that would point to the value of the Mime Content-ID header (minus the brackets <>).
Pete: Disagree with attribute being named "cid", since we need to refer not only to MIME attachments, but also to payloads contained within the SOAP Body.
Need to confirm that eb:id can be removed, because another base schema already specifies it.
Remove eb:cid and keep eb:idref, which should be of type AnyURI. That will accommodate both xpath/fragment and cid: schemes.
Ric notes that the security examples are incorrect, where the references are supposed to be to the SOAP Body, but instead contain a cid:xxx.
12) It was agreed to remove lines 1074 to 1088 (the concepts of ebXML Next MSH role and To Party MSH roles are inherited from ebMS-2 and are not relevant to ebMS-3, as this will be handled by WS-Addressing in Part 2 (the Advanced part of ebMS-3).
Section 18.104.22.168 / 22.214.171.124: These SOAP Actor values are no longer appropriate: should be "ebms", not NextMSH or ToPartyMSH. Propose at least to remove these 2 sections for the CD. At best to add a short section saying that all headers to be interpreted within the context of ebMS message processing (includingreliability, security headers) should have same actor = "ebms".
Proposal is that we need only a single actor, named "ebms", to appear on any headers that should be processed by an MSH.
Pete: Wonder if it's possible for current software (security and reliability processors) on either sending or receiving end to be aware of such an actor named "ebms".
Jacques: Those modules should be parameterized in such a way that they can be instructed to address their headers to an arbitrary actor. Believe that since there may be several Security headers, those implementations must already support the use of actor specification at runtime. Not sure this is the case for Reliability, since there would normally not be more than one.
Requires more thought, and example topologies that we wish to enable.
@syncresp issue: Indicates whether a correlated SOAP response is expected. Whether or not it is "synchronous" depends on the underlying SOAP MEP and protocol binding in use. At MSH MEP level, such topology is unknown.
eb:ErrorList element: Already removed, except in Figure 8, which needs to be updated, as already noted. We now have eb:Error, which may be repeated if multiple errors need to be reported. If batching of errors is allowed, we can repeat eb:SignalMessage, each containing eb:Errors.
-- Pete Wenzel <pete...@sun.com> Senior Architect, Sun Microsystems SOA & Business Integration Products +1 (626)471-6311, Sun x61311, US-Pacific TZ