W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2006

Re: ISSUE: Inconsistency in number of properties

From: David Hull <dmh@tibco.com>
Date: Wed, 06 Sep 2006 17:48:04 -0400
To: noah_mendelsohn@us.ibm.com
Cc: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-id: <44FF4214.1030200@tibco.com>
noah_mendelsohn@us.ibm.com wrote:
> I can see your point here, but if I were to fix this at all, I think I'd 
> split the table into a "Sender Properties", which would have Immediate 
> Destination and Outbound Message, and a "Reciever Properties" table which 
> would have only InboundMessage and ImmediateSender.  The terms 
> InboundMessage and OutboundMessage are already established for other MEPs, 
> and I quite strongly want to keep things consistent when the concepts are 
> similar.
That would indeed be consistent.  I mentioned it because the status quo
has so far made (I think) three pieces of text somewhat harder to write.
> This does remind me of a new issue I hadn't noticed.  This MEP as drafted 
> seems to obligate the binding to convey the identity of the sender to the 
> receiver.  It's not at all clear to me that all the protocols you'd want 
> to use with one-way have such "caller id" function.  I think that 
> populating the ImmediateSender property at the receiver should be made 
> optional with a MAY, and an explanation that some bindings will and some 
> bindings won't do this.
I'd be fine with that.

In practice, though, there generally seems to be a natural fit for these
terms.  It's just that the natural fit may differ depending on which end
you're on.  It's not always caller ID because the transport may re-write
(in the case of chat, that's an explicit feature, protecting privacy).


    * XMPP: Sender is "from", receiver is "to".  Depending on whether
      the message type is "normal" or "chat|groupchat", the sender and
      receiver may see different values of these.
    * Email: Sender is "from", receiver is "to" (or, perhaps, resent-to:
      if present -- that would be for the binding to decide)
    * Pub/sub: The "topic" or "subject" is a natural Receiver for the
      sender and Sender for the receiver.
    * UDP packets carry a sender and receiver.

> In any case, I agree with David's suggestion that these questions are 
> largely orthogonal to the multicast question.
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> David Hull <dmh@tibco.com>
> Sent by: xml-dist-app-request@w3.org
> 09/01/2006 03:22 PM
>         To:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
>         cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        ISSUE: Inconsistency in number of properties
> There are currently four properties: InboundMessage, OutboundMessage, 
> ImmediateSender and ImmediateDestination.  The sender and receivers each 
> have a private copy of ImmediateSender and ImmediateDestination, but 
> OutboundMessage is only visible to senders and InboundMessage only to 
> receivers.
> Since each node has its own copy of the properties, it would be more 
> consistent to have a single Message property.  The distinction of inbound 
> and outbound proved awkward in trying to write a binding [1] and in 
> describing possible differences between sender and receiver views of the 
> MEP [2].
> Proposed change:
> Delete the row in the property table for OutboundMessage
> Rename InboundMessage to Message in the first row.
> In the Property Description for Message, change
> This property is populated if and only if the message is successfully 
> received.
> to
> This property is populated at a receiver if and only if the message is 
> successfully received.
> (By the way, we don't seem to say whether the ImmediateSender and 
> ImmediateDestination properties are only populated on success).
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0035.html
> [2] (not archived yet, probably 52)
Received on Wednesday, 6 September 2006 21:48:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:30 UTC