Notes from Dec 7 Conference Call

[Pete Wenzel <pete.wenzel@Sun.COM>]

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

and

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.

Accepted.

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 5.1.3.8 / 5.1.3.9: 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.wenzel@sun.com>
Senior Architect, Sun Microsystems
SOA & Business Integration Products
+1 (626)471-6311, Sun x61311, US-Pacific TZ