some editorial clean-up to prepare issues #1, #1a, #1b, #5,

Title: some editorial clean-up to prepare issues #1, #1a, #1b, #5, 

As a preamble to resolve issues #1, #1a, #1b, #5, here is a proposal

to straighten up our terminology about:

- MEPs (application-level / WSDL)

- underlying protocol

Jacques

Two editorial proposals:

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

1. Describe user-level message exchanges (e.g. WSDL) in terms of RMP usage 

(Submit/Deliver/Respond/Notify). Then we can make abstraction of any user-level

choreography, and express everything in relation to RMP.

That means:

- In the case of WSDL, explicitly define - meaning decide of - the mapping of WSDL MEPs 

(or operation types) to RMP invocations.

That is simply done as follows:

Given a payload (p) to transfer from RMP1 to RMP2,

- a WSDL operation of type One-Way maps to an RMP invocation sequence of the form:

{ RMP1.Submit(p) + RMP2.Deliver(p)} 

We will refer to this as the "One-way RMP invocation pattern".

- a WSDL operation of type Request-Response maps to an RMP invocation sequence of the form:

{ RMP1.Submit(p) + RMP2.Deliver(p) + RMP2.Respond(p2) + RMP1.Notify(p2) }

We will refer to this as the "Two-way RMP invocation pattern", where the payload p2 is

the response to p.

Once this mapping is defined (inside WS-Reliability specification for WSDL, or outside spec for other

choreography dialects), we don't need to talk further about application-level MEP or WSDL MEP.

 we only talk of RMP invocation patterns, which relates better to WS-R works.

Impact on spec: everywhere we talk of "One-way application level MEP" or "WSDL One-way MEP",

we replace by: One-way RMP invocation pattern. 

Same for Request-Response application level MEP...--> Two-way RMP invocation pattern.

2. The "underlying protocol" (defined also as SOAP binding protocol, in SOAP 1.2) 

is still something too vague, on which we have little grasp

when it comes to defining how we can use it (how to bind our RM headers to it)

At the same time we don't want to get too transport-specific.

I propose to only define the SOAP protocol (including its binding) used by the RMP 

in terms of what type of MEP it supports for SOAP messages, which is what 

really matters to us. 

I call these "SOAP MEPs" (again, although SOAP is essentially one-way, SOAP MEP

refers to properties of its binding). So we would say that a SOAP protocol binding is:

- Supporting a Request-response SOAP MEP if:

(a) a node that received a message with a SOAP envelope (called a request) 

can send back a message with a SOAP envelope (called a response).

(b) the request-originating SOAP node can correlate the received response 

with the request it sent.

- Used by a Request-response SOAP MEP if:

a response message is sent back, which contains a SOAP envelope.

- Supporting a one-way SOAP MEP if: 

the SOAP node is simply able to initiate the sending of a SOAP envelope over 

the underlying protocol (so not as resulting from a previous protocol action,

such as an HTTP POST or even GET).

- Used by a one-way SOAP MEP if:

In case a response message is sent, it does not contain a SOAP envelope.

So according to these defs, the SOAP HTTP binding (defined in SOAP) is supporting

both Request-response SOAP MEP and one-way SOAP MEP.

Impact on spec: there are many places in the spec where an underlying "request-response"

protocol is implicitly assumed (e.g. "...is sent over the request of the underlying p.."

or " ... sent over the response of the underlying p..".

If we introduce the above definition of SOAP MEP, we can then rewrite the definition

- as an example - of Response reply pattern (terminology section) :

" When the Response RM-Reply pattern is in use, the request-response SOAP MEP

must be supported. The outbound Reliable Message is sent in  a request of a SOAP MEP instance 

and the RM-Reply is sent in the response message of the  same SOAP MEP instance."

When describing an RM feature, we can first say which SOAP MEP is required or assumed, 

and then say how it is used.

That way we do not need make any reference to the nature of the underlying protocol,

nor use unclear implicit assumption. Only its ability to support SOAP-level MEPs is described.