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

Recursion vs. different views

From: David Hull <dmh@tibco.com>
Date: Thu, 30 Nov 2006 16:21:44 -0500
To: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-id: <456F4B68.3000102@tibco.com>

In cases like the security-based examples under discussion, it's
tempting to focus on the idea of one binding using another recursively. 
This looks to be useful, but I'm concerned about a slightly different

Consider a message path consisting of:

   1. A sender
   2. A logging intermediary, which simply persists its incoming message
      and forwards it along.
   3. An encrypting intermediary
   4. A decrypting intermediary
   5. A receiver

There are several views of interest here:

   1. (IMO, the most interesting):  The view consisting of (1) and (5). 
      At the end of the day I'm trying to get a message from (1) to
      (5).  That is, I want to know that something is providing the
      one-way MEP with (1) as sender and (5) as receiver.
   2. The view consisting of (1),(3),(4),(5), which provides the one-way
      MEP, given that something provides the one-way MEP from (1) to
      (3), (3) to (4) and (4) to (5).  This is indeed a recursive
   3. The view consisting of (1) and (2), if I'm interested in logging.
   4. If you really need to know what's going on, you'll need to look at
      the individual hops from (1) to (2), (2) to (3), etc.  Some of
      these may be no-ops, but no one else needs to know that.

I don't see any of those views as being primary or more fundamental. 
Which one you look at depends on what you're interested in.

One can argue that only the individual hops in D are really one-way
message exchanges, but IMHO that leaves things like (1) to (5) and (1)
to (3) as operations-that-look-a-whole-lot-like-one-way (but aren't
allowed to be).  My strong intuition is that this would be bad, but
perhaps not everyone shares that intuition.
Received on Thursday, 30 November 2006 21:21:54 UTC

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