Re: Clarified one-way MEP

David wrote:

        A mechanism for receiving nodes to be notified of receipt of a 
message.

Clearly, the receiving node needs to have a mechanism to actually receive 
the message, not just be
notified of its receipt.

It is also not clear to me why you believe that there need to be 
constraints on the mechanism for
notification of receipt of a message (exactly once). If the sender happens 
to retransmit the message, then
clearly the message may be received more than once... it would be up to 
higher levels to make any determination
as to whether it were a duplicate and as to whether that duplicate message 
should be dropped on the floor
or processed.

At least as I read this, the constraint would preclude the use of 
WS-Reliable Messaging (or any of the RM
protocols, for that matter) because the sending endpoint might indeed 
retransmit messages.

Note that we are talking here about a transport-level MEP, not an 
application-level MEP and I would
include infrastructure goop at the "application" level in many cases.

I would think that the description would be more along the lines of:
2.2 Description
The SOAP One-way MEP defines properties for the transmission of a SOAP 
message between a sending and a receiving SOAP node.
In an instance of this MEP, a sending SOAP node establishes a message 
consisting of a set of properties as defined below and transmits the 
message in a binding-specific manner.  A binding to this MEP MUST define:
A mapping of the message properties onto the transport-specific PDU 
format.
A mapping of the ImmediateDestination property of the message to one or 
more receiving SOAP nodes.  This mapping MAY vary from instance to 
instance of the MEP. [note: I couldn't understand why you think that it 
might be zero SOAP nodes. Additionally, I don't understand the second 
sentence unless you meant to say that such a mapping may vary dependent 
upon the binding chosen.]
In normal operation
The received message is well-formed. [note: I could envisage that an 
intermediary might add to the message things such as a trace route entry 
as it transits between the sending SOAP node and the ultimate receiver 
SOAP node. I think that all that we can say is that in normal operation, 
that the received message is well-formed. We may need to add some form of 
constraint that a receiving node be capable of determining whether a 
received message is well-formed.].
Each receiving SOAP node processes received messages according to the SOAP 
Processing Model (see SOAP 1.2 Part 1 [SOAP Part 1]Processing SOAP 
messages). 
In abnormal operation, any of the following may happen:
A receiving node might receive messages that are ill-formed. In such a 
case, it MUST generate a fault.
The sending node and/or any of the reciving nodes MAY generate a fault, 
regardless of whether nodes in the receiving set have been notified of 
receipt.
Bindings MAY define more detailed behavior in the case of abnormal 
operation.  Bindings MAY choose to support multiple instances of this MEP 
simultaneously.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

xml-dist-app-request@w3.org wrote on 06/16/2006 08:46:04 AM:

> In a spare moment, I put together a revision of the one-way MEP which
> tries to be more explicit about the questions I mentioned before.  The
> formatting may be a bit funky, due to the HTML editor I was using.
> 
> SOAP 1.2 Part 3: One-Way MEP
> Editors Copy $Date: 2006/03/30 09:53:43 $ 16 June 2006
> This version:
> /
> Editors:
> David Orchard, BEA Systems
> David Hull, TIBCO Software Inc
> © 2006 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, 
trademark
> , document use, and software licensing rules apply.
> 
> Abstract
> SOAP Version 1.2 Part 2 provides a request-response MEP and a 
> response-only MEP. This, the SOAP 1.2 Part 3, provides a one-way MEP.
> Status of this Document
> This document is an editors' copy that has no official standing.
> This section describes the status of this document at the time of 
> its publication. Other documents may supersede this document. The 
> latest status of this document series is maintained at the W3C.
> Table of Contents
> 1 Introduction
>     1.1 Notational Conventions
> 2 SOAP One-way Message Exchange Pattern
>     2.1 SOAP Feature Name
>     2.2 Description
>     2.3 Property Description
>     2.4 Fault Handling
> 3 References
>     3.1 Normative References
>     3.2 Informative References
> Appendix
> A Change Log (Non-Normative)
> 
> 1 Introduction
> SOAP Version 1.2 Part 2 provides a request-response MEP and a 
> response-only MEP. This, the SOAP 1.2 Part 3, provides a one-way MEP. 
> 1.1 Notational Conventions
> The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119 [RFC 2119].
> With the exception of examples and sections explicitly marked as 
> "Non-Normative", all parts of this specification are normative.
> 2 SOAP One-way Message Exchange Pattern
> This section defines the message exchange pattern (MEP) called "One-
> way". The description is an abstract presentation of the operation 
> of this MEP. It is not intended to describe a real implementation or
> to suggest how a real implementation should be structured.
> 2.1 SOAP Feature Name
> This message exchange pattern is identified by the URI (see SOAP 1.2 
Part 1 
> [SOAP Part 1]SOAP Features):
> "http://www.w3.org/2006/03/soap/mep/one-way/"
> 2.2 Description
> The SOAP One-way MEP defines properties for the exchange of a SOAP 
message.
> In an instance of this MEP, a single sending SOAP node establishes a
> message consisting of a set of properties as defined below and sends
> it in a binding-specific way.  A binding MUST define
> A  mechanism for sending nodes to send a message.
> A mapping from the ImmediateDestination property of the message to 
> zero or more receiving SOAP nodes.  This mapping MAY vary from 
> instance to instance of the MEP.
> A mechanism for receiving nodes to be notified of receipt of a message.
> In normal operation
> Each receiving node is notified of receipt of the sent message exactly 
once.
> The properties of each received message are identical to the 
> properties of the sent message.
> Each receiving node processes the received message according to the 
> SOAP Processing Model (see SOAP 1.2 Part 1 [SOAP Part 1]Processing 
> SOAP messages). 
> In abnormal operation, any of the following may happen:
> Nodes in the receiving set MAY fail to be notified of message 
> receipt or may be notified more than once.
> Nodes in the receiving set MAY receive messages not identical to the
> sent message.
> Nodes not in the receiving set MAY be notified of message receipt, 
> regardless of whether nodes in the receiving set have been notified 
> of receipt.
> The sending node and/or any of the reciving nodes MAY receive a 
> fault, regardless of whether nodes in the receiving net have been 
> notified of receipt.
> Bindings MAY define more detailed behavior in the case of abnormal 
> operation.  Bindings MAY choose to support multiple instances of 
> this MEP simultaneously.
> 2.3 Property Description
> The One-way MEP defines the properties described below.
> 
> Property definitions for One-way MEP
> 
> Property Name
> 
> Property Description
> 
> Property Type
> 
> http://www.w3.org/2003/05/soap/mep/OutboundMessage
> 
> An abstract structure that represents the current outbound message 
> in the message exchange. This abstracts both SOAP Envelope and any 
> other information structures that are transferred along with the 
envelope.
> 
> Not specified
> 
> http://www.w3.org/2003/05/soap/mep/ImmediateDestination
> 
> The identifier of the immediate destination of an outbound message.
> 
> xs:anyURI
> 
> http://www.w3.org/2003/05/soap/mep/ImmediateSender
> 
> The identifier of the immediate sender of an inbound message.
> 
> xs:anyURI
> 
> There may be other properties related to the operation of the 
> message exchange and are processed according to their own feature 
> specifications. 
> 2.4 Fault Handling
> This MEP makes no claims about the disposition or handling of SOAP 
> faults generated by the sending SOAP node or the receiving SOAP nodes.
> 3 References
> 3.1 Normative References
> SOAP Part 1
> W3C Proposed Recommendation "SOAP Version 1.2 Part 1: Messaging 
> Framework", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-
> Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (See http:
> //www.w3.org/TR/2003/REC-soap12-part1-20030624/.)
> SOAP Part 2
> W3C Proposed Recommendation "SOAP Version 1.2 Part 2: Adjuncts", 
> Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, 
> Henrik Frystyk Nielsen, 24 June 2003 (See http://www.w3.
> org/TR/2003/REC-soap12-part2-20030624/.)
> RFC 2119
> IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement 
> Levels", S. Bradner, March 1997. (See 
http://www.ietf.org/rfc/rfc2119.txt.)
> RFC 2396
> IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax",
> T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http:
> //www.ietf.org/rfc/rfc2396.txt.)
> 3.2 Informative References
> SOAP Part 0
> W3C Proposed Recommendation "SOAP Version 1.2 Part 0: Primer", Nilo 
> Mitra, 24 June 2003 (See 
http://www.w3.org/TR/2003/REC-soap12-part0-20030624/
> .)
> XMLP Comments
> XML Protocol Comments Archive (See http://lists.w3.
> org/Archives/Public/xmlp-comments/.)
> XMLP Dist-App
> XML Protocol Discussion Archive (See http://lists.w3.
> org/Archives/Public/xml-dist-app/.)
> XMLP Charter
> XML Protocol Charter (See 
http://www.w3.org/2000/09/XML-Protocol-Charter.)
> RFC 2045
> IETF "RFC2045: Multipurpose Internet Mail Extensions (MIME) Part 
> One: Format of Internet Message Bodies", N. Freed, N. Borenstein, 
> November 1996. (See http://www.ietf.org/rfc/rfc2045.txt.)
> RFC 2026
> IETF "RFC 2026: The Internet Standards Process -- Revision 3", 
> section 4.2.3, S. Bradner, October 1996. (See http://www.ietf.
> org/rfc/rfc2026.txt.)
> A Change Log (Non-Normative)
> 
> Who
> 
> When
> 
> What
> 
> Changes
> 
> DBO
> 
> 20041208
> 
> Initial Revision
> 
> DBO
> 
> 20060330
> 
> 2nd Revision
> 
> DBO
> 
> 20060530
> 
> Adding sending and receiver MUSTs
> 
> DMH
> 
> 20060616
> 
> Clarified semantics.