Re: How omniscient is "omniscient"?

David Hull writes:

> This is why I've been pushing the view that, so long as the message 
> is the same at the receiving end as at the sending end, you've got a
> one-way MEP.

The reason I'm unhappy with this line of reasoning is that it seems to be 
reopening design work that was settled during the original design of SOAP. 
 The definition and implications of an MEP are set out in a section 
that's, as far as I know, not up for review in this round.  It defines the 
term MEP and sets out what MEPs convey [1]:

3.2 SOAP Message Exchange Patterns (MEPs)
A Message Exchange Pattern (MEP) is a template that establishes a pattern 
for the exchange of messages between SOAP nodes. MEPs are a type of 
feature, and unless otherwise stated, references in this specification to 
the term "feature" apply also to MEPs. The request-response MEP specified 
in SOAP 1.2 Part 2 [SOAP Part 2] illustrates the specification of a MEP 
feature.
The specification of a message exchange pattern MUST:
As mandated by 3.1.1 Requirements on Features, provide a URI to name the 
MEP.
Describe the life cycle of a message exchange conforming to the pattern.
Describe the temporal/causal relationships, if any, of multiple messages 
exchanged in conformance with the pattern (e.g. responses follow requests 
and are sent to the originator of the request.)
Describe the normal and abnormal termination of a message exchange 
conforming to the pattern.
Underlying protocol binding specifications can declare their support for 
one or more named MEPs.
MEPs are SOAP features, so an MEP specification MUST conform to the 
requirements for SOAP feature specifications (see 3.1.1 Requirements on 
Features). An MEP specification MUST also include:
1.      Any requirements to generate additional messages (such as 
responses to requests in a request/response MEP).
2.      Rules for the delivery or other disposition of SOAP faults 
generated during the operation of the MEP.

Note my highlighting of the second bullet.  It does not say:  "If the 
original sender and the final receiver can't tell the difference, you've 
satisfied the MEP", which seems to be what you're recommending.  It says: 
"Describe the life cycle of a message exchange conforming to the pattern." 
 While the tone of the spec is sometimes a little bit informal, that to me 
pretty much says what I suggested in my previous note in this thread. [2]  
An MEP doesn't just tell you how the message looks when you sent it out 
and when it arrived.  It tells you where the message is, where it can be 
processed and fault, etc. along the way. 

I'm afraid I'm finding it difficult to continue this discussion.  For the 
reasons stated above, I believe it's out of scope.  Certainly it's been 
worth clarifying what the SOAP Recommendation says, but not changing it. 
MEPs are what they are.  I believe that the exisiting MEPs such as 
request/resp are conformant with the definition, though as I've 
acknowledged they miss the chance to provide for intermediaries.  I think 
the scope of our current effort should be to design and publish a one way 
MEP that is in the style of our existing MEPs.  Full stop.  Honestly, and 
please don't take this amiss, I don't have time to continue the discussion 
of anything else. 

Can we please clearly decide as a group whether I am right or wrong about 
the scope of the effort.  If I'm right, then I would like to stop this 
thread and similar ones, and go on to wrap up our publication.  If I'm 
wrong, then please accept my apologies, and let's get our scope clarified 
accordingly.  Thank you!

Noah

[1] http://www.w3.org/TR/soap12-part1/#soapmep
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2006Dec/0000.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------