Unicast with optional security

Continuing the discussion at the end of today's call:

Consider the following scenarios:

   1. I construct a SOAP envelope and send it to you using the
      two-tin-cans-and-a-string (2TCS) SOAP binding.  You receive the
      same message.
   2. I construct a SOAP message, encrypt it to a blob, send it using
      raw 2TCS.  You receive the blob and decrypt it to get the SOAP
      message I sent.
   3. I construct a SOAP message, use WSS to construct a secure SOAP
      message and send it to you via the 2TCS SOAP binding.  You receive
      the WSS SOAP message and from it construct the plaintext SOAP
      message that I used to construct the WSS SOAP message.

As far as I can tell, these are all three instances of the SOAP one-way
MEP as we currently describe it.  I can identify a sender (myself) and a
receiver (you), an InboundMessage and an Outbound message (the
plaintext), I know that the InboundMessage is the same as the
OutboundMessage, and I can handwave over the other properties because we
don't impose any requirements on them.

If these aren't all three legitimate examples of the one-way MEP, I
would like to know what text prohibits them from being so.  If they're
currently permitted but shouldn't be, I'd like to know what text we'd
add or change to prohibit them.

If you just look at the middle part of scenario 3 -- the transmission of
the WSS SOAP message over 2TCS -- then you can also see a different
instance of the one-way MEP, but that just seems (to me at least) like
an interesting fact of life.

I would certainly /like/ them all three to be instances of the one-way
MEP.  I wouldn't want to have to change the application's view of
sending a SOAP message from point A to point B just because I changed
the means in which it's delivered.  Nor would I want to develop a
separate "SOAP one-way or maybe it's some policy-driven manipulation in
conjunction with an actual SOAP one-way" abstraction in order to
describe what I'm actually doing.

/Entia non sunt multiplicanda praeter necessitatem.
/

Received on Wednesday, 29 November 2006 21:40:31 UTC