current list of comments and pending updates on CD1

Consolidated comments on CD1: previous (Dec 7) + new comments

-----------------------------------------------------------------------

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.

STATUS: consensus for it, need finalize.

-----------------------------------------------------------------------

2) 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.

STATUS: agreed.

-----------------------------------------------------------------------

3) 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.

STATUS: Agreed.

-----------------------------------------------------------------------

4) 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).

See also Monica's comments.

Note that a CPA binding could be in appendix of Part 2.

STATUS: No consensus; decision deferred.

Ian: We need a statement that understanding CPP/A is helpful in doing

a proper implementation.

-----------------------------------------------------------------------

5) 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.

STATUS: 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.

-----------------------------------------------------------------------

6) In examples, the element eb:Partref still contains the attributes:

5.a- eb:id : agreed to remove (replaced by XML Id)

5.b- eb:idref. Keep it as AnyURI type. Will use a cid scheme when referring

to MIME parts, and an XML fragment ( #if-of-fragment) when referring to parts in the SOAP body.

STATUS: agreed.

Minor modification suggested by Hamid (see last email on ebMS-3 mailing list): replace eb:idref by the

SOAP 1.1 attribute href. Also rename "eb:Partref" to "eb:Part" (Partref and href would be redundant when put together)

-----------------------------------------------------------------------

7) remove sections related to SOAP actors:

In Part 1:

- Remove sections 5.1.3.8 , 5.1.3.9, 5.1.3.10 about SOAP actors & mustUnderstand, as the related topologies that such actors

support are relevant to Part 2. (see proposed changes for Section 3 below)

In Part II:

- introduce the additional topologies that are handled.

- address the routing issue for MEPs in a more generic way, and add SOAP actors as needed.

STATUS: To be discussed.

-----------------------------------------------------------------------

8) Remodeling of Section 3:

8.a- remove section 3.4 (supported topologies), and remind in Intro (1.2 "Scope")

that Part 1 only supports the point-to-point topology (1st bullet in 3.4)

Part 2 will take care of expanding on other topologies.

8.b- move section 3.3 "Message Service Processing Model" at the end of

Section 2 (Messaging Model), replace "Message Service " with "Messaging Service "

or "MSH " (Prefer MSH than Messaging Service). 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).

8.c- After some thought, the 3.2 section should be removed, in particular

not give any semantics to an "absent AgreementRef". AgreementRef is just a meaningful

place holder that has no semantics for this specification - like Service and Action.

The notion of Default Operation Mode still makes sense, but is more related to

default operation contexts defined in 3.1:

when any individual OpCtxt is unspecified or not agreed upon between parties

(or more precisely, when a message to be sent does not fall under any existing

Op COntext between the parties) then the MSH falls back on what is the "default OpCtx".

E.g. the default Security OpCtxt is No security at all. Same for default Reliabiity.

Etc. The default OpCtx-BusinessColaboration will use a dummy service/action used for

ping/pong.

So each Op context will define what is its "default", i.e. what is the related

MSH behavior when it is absent.

8.d- Section 3 should then be renamed "Operation Modes"

STATUS: To be discussed.

-----------------------------------------------------------------------

9) @soapresp attribute:

- should it be removed?: it Indicates whether a correlated SOAP response is expected,

meaning for the ultimate MSH using an HTTP standard binding, whether a connection should be kept open.

Two reasons weaken this feature:

(a) implementations can "know" which MEP a message is involved in, based on op contexts (agreements). They may decide to keep connections open anyway, for a short time regardless of MEPs.

(b) as decided for SOAP actor features, there should be a more generic way (outside ebMS header)to indicate a req-resp MEP to a SOAP node. Once decided, can be used instead.

STATUS: to be discussed

------------------------------------------------------------------

10) Security:

- too many examples that may not add value, redundant with WSS examples?

- 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.

STATUS: to be discussed

ebxml-msg message