Re: Clarified one-way MEP

Okay, if the retransmission is s separate instance of the MEP, then I 
think that we need to make that clear.

I still maintain that the changes I suggested are closer to what needs to 
be specified. I don't think that we
need to get into the specifics of the distinction between receive and 
notification of receipt. I think that all
we need to say are that a message is either received or not (e.g. in the 
case where the message is 
ill-formed due to truncation, lost packets, etc.)

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

David Hull <dmh@tibco.com> wrote on 07/18/2006 12:18:02 PM:

> Chis,
> 
> Thanks for the feedback.  Comments inline.
> 
> Christopher B Ferris wrote: 
> 
> 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. 
> Sure, but we don't need to model both.  The important event is the 
> properties being populated.  I'd tend to call this "notification of 
> receipt", but that might be my WSN background creeping in.  If 
> "receipt" seems better, that's fine with me.
> 
> How would you model receipt as distinct from population-of-
> properties?  Would it be a separate event?
> 
> 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...
> That would be two instances of the MEP:  "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."
> 
> In answer to a later comment:  There are zero or more receivers in 
> the general case (multicast).  In the unicast case, there will be 
> only one, and the mapping from ImmediateDestiation to receivers will
> be N:1 (or maybe 1:1 in some cases, but that probably doesn't 
> matter).  Other than that particular, I don't see a significant 
> difference between the unicast and multicast cases.
> 
> As far as I can see all the other text works fine in either case. 
> If not, it might be worth calling out the unicast/multicast 
> distinction more explicitly.  It's probably worth calling out a bit 
> more explicitly anyway, as many readers will have unicast in mind 
> and may not make the somewhat implicit connection to multicast.
> 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. 
> Take your pick.  If the upper levels are handling retransmit (as 
> would be expected WS-RX is in effect), then the binding will 
> potentially be told to send more than once and receivers may hear 
> the message more than once.  In this case (which I expect would be a
> common one), there is no one-to-one correspondence between 
> application-level MEP instances and binding-level MEP instances, but
> this is nothing new (the "async request-reply" case would be 
anotherexample).
> 
> If the binding is handling retransmit, then the sender sends once, 
> the binding puts the message on the wire as many times as it needs 
> to, and (normally) each receiver receives it once.   This would be 
> the norm for, e.g., TCP-based protocols, such as jabber, where 
> normally a message sent will be received exactly once.
> 
> It's also possible that both levels are doing retransmits (e.g., WS-
> RX is providing reliability across connections while the binding 
> protocol is, perhaps redundantly, providing reliability within 
> connections).  This makes no difference.  Higher-level retransmits 
> are still separate MEP instances, lower-level retransmits are still 
invisible.
> 
> A perhaps more pertinent difference is whether the binding is able 
> to guarantee that it will either deliver normally or signal an 
> error.  TCP-like bindings will generally be able to, UDP-like ones, 
> including many multicast implementations, generally won't.  This is 
> why I leave the base semantics open and say that "Bindings MAY 
> define more detailed behavior in the case of abnormal operation."

> 
> 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 agree.  Again, I think the main disconnect was over whether a 
> retransmission is a new instance of the MEP.  That was my 
> assumption, and I believe it makes life much, much easier.
> 
> 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.