Re: Clarified one-way MEP

Christopher B Ferris wrote:

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

That seems somewhat out of scope, but I suppose it's worth mentioning,
since it manifestly has caused confusion.  As far as I can tell, that's
generic to /any/ definition of SOAP one-way MEP, not just this one.

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

I'm a bit confused.  Again, I'm not trying to make any such distinction,
and I agree it doesn't seem useful.  Perhaps I'm just not being
consistent in terminology.  What particular text seems to make this
distinction?

In any case, the only relevant events are the sender trying to send a
message with a given set of properties (it can do this as many times as
it likes for a given set) and each receiver having a corresponding set
of properties populated.

If you look at the traces for each party, in the normal case each
receiver will have one "properties populated" event for each "send
message" event by the sender and the properties for corresponding events
will match.  Abnormally, the traces won't match up, due to duplication,
omission or corruption.  Getting a corrupted message is different from
getting a message twice or not getting a message at all, so I think we
need to note that all three can happen.

As to the specific changes (please let me know if I've missed any)

    * I've deliberately not talked about mappings to transport-level
      entities.  Naturally, most bindings (but maybe not "loopback"
      bindings or other virtual creatures) will talk about such
      mappings, but (I claim) that's not what we care about here.  We
      care about an information-carrying event happening at one place as
      a result of one at another.  How it happens, whether by putting
      packets on the wire, just invoking a callback method, or whatever,
      we don't care (but the binding does).
    * Saying that messages may be ill-formed neglects that messages may
      be well-formed but have the wrong content.
    * I'm slightly leery of requiring, as opposed to allowing, nodes to
      fault on ill-formed messages.  If we make it a MUST, then we need
      a tight definition of "ill-formed" to go with it.  Otherwise we
      have a MAY in MUSTy clothing.

That said, the fact that we're having this conversation, and not a
different one, indicates to me that the approach of reducing the
property set and just talking about events can work.

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