Re: PASWA, Include and Protocol Bindings

Mark Nottingham writes:

> Hi Noah,

Hi.  You raise some interesting points, I think.
 
> I should probably respond to this, as I pushed for
> doInclude.
> 
> I agree that doInclude does need to be handled
> carefully, especially in respect to the processing
> model and its ordering. However, I think that the
> issues brought to light are common to many features
> exposed as SOAP headers, not just this one.

> Could you expand upon why you think that the processing
> model would need to be re-run, and why multiple
> applications views of the infoset would be required? To
> me, inclusion seems like a very similar problem to
> message encryption; you need to perform a particular
> type of processing on the message before you can
> continue processing other headers, so you decrypt (or
> include, as the case may be) beforehand, and then
> continue. I know that we've discussed this before, but
> it may be helpful to have it written down...

This point of yours gives me some pause, but let's be careful to work 
through this methodically:

1. We have indeed considered using headers for activities such as 
encrypt/decrypt
2. In most of the discussions I've seen, the decrypting node is modeled as 
an intermediary.  No one node rewrites the input infoset and then 
reprocesses.  The intermediary takes an input infoset, as a result of 
processing relays a modified one.  In principle, the relay could be to a 
piece of software in the same physical machine, or even on the same thread 
in the same address space.
3. I would also agree that we give a lot of latitude to header-functions 
in altering the processing model, though I don't think we say anywhere 
that such processing can modify the input infoset in a manner that alters 
the input to the processing at the same node.  My tentative conclusion 
from this is:  the specification for the decryption header (or doInclude) 
could call for the equivalent of SOAP processing on the results of the 
decrypt (include), but the spec for that header would in some sense have 
to restate the SOAP spec.  I'm not even sure if it's doable, at least in 
the case of decryption.  What if decryption exposes an mU header you don't 
understand.  It's at best a somewhat tricky thing to specify properly.

4.  Here's the real point:  just because it might be possible to spec 
things this way, doesn't mean it's a good idea to do this above the 
binding level.  See below.
 
> I'm uncomfortable with shifting the responsibility for
> inclusion to the binding because it sets a precedent of
> performing what could be accomplished by a header in
> bindings, to avoid the complexities of integrating them
> into the processing model; if this example is followed
> by others, it may will lead to an explosion of
> bindings.

I think there's a very key point to consider:  in my view, what's above 
the binding is portable across transports, and is visible to (some level) 
of SOAP application.  Indeed, it's part of the contract between senders 
and receivers of envelope infosets.   What's in the binding is private to 
a single hop, unless the bindings conspire to play games through 
intermediaries. 

My key point is:  I don't want the applications to see the Include. 
Indeed, my understand of PASWA is that the whole point is that 
"attachments" are modeled by value as children.  It's not the doInclude 
that bothers me, as I said, it's the xbinc:Include element.  That violates 
the whole notion that PASWA models things by value.  I think it also 
raises many, many architectural complexities.   Does a signature sign the 
child data or the include element?  Indeed, one of the claimed benefits of 
PASWA (and it's one I quite like) is that the infoset can be carried by 
bindings that don't play tricks:  our own HTTP binding can send the 
character children. 

What happens if an xbinc:Include makes it over a "smart" binding to an 
intermediary, and then has to go through a regular HTTP hop?  Putting the 
includes in the bindings (if at all) makes everything come out right.  The 
first binding uses the Include optimization and sends the children in 
binary.  The intermediary node relays the envelope through the regular 
HTTP binding, the implementation of which (we presume) calls for the 
characters in the children.  This (we presume) causes conversion from 
binary form to canonical lexical. 

> I don't think this is "shifting" the responsibility

On the contrary, I don't think we're shifting anything.  The PASWA model 
is that the envelope is full of characters.  The only time you can play 
the include game is if the binding is using a collection mechanism such as 
multipart MIME or DIME that allows for carrying multiple parts and 
referencing those parts with a URI.  Since it's the binding that knows 
whether it's doing that, it seems to me that the binding starts out as the 
natural place to make the decision to do the tricky encoding.

As I said in my original note.  I don't have a strong objection if the 
binding signals it has done this using a doInclude header, as long as 
everyone realizes that is more or less private to the binding, and isn't 
visible from the outside anyway.  I claim it should not be processed by 
the soap processing model, for the reasons given above.

> Furthermore, decomposing the specifications (into a
> binding that modifies the URI dereference function, and
> and a header that activates the Include) gives us the
> benefits of modularity and follows the principle of
> least power; it may be that some people want to include
> external representations, whilst others will want
> attachments to not be evident in the message.

There is a separate header that provides this separation of concerns, I 
think, and that is the swa:Representation element.  that lets you get some 
transparency between attachments in the message and other web resources, 
and it lets all of them be accessed "by reference" using a URI.  I have no 
problem at all with that one being in a header, and in fact I quite like 
what's proposed.
 
> In any case, I agree very much that our discussion
> should be framed by the terminology and concepts in
> SOAP 1.2.

Good.  I think the choices that make sense to me are:

* If there is consensus that I am right and that the xbinc:include should 
be a binding level function, then a PASWA redraft should be done to 
reflect that.

* If there is still interest in perusing an xbinc:include/xbinc:doInclude 
visible at the actual SOAP processing level, then I suggest that someone 
do a PASWA redraft that illustrates how this can be done, in the form of a 
SOAP module specification, and making reasonably rigorous use of the 
mechanisms of SOAP 1.2.
 
> Regards,
> 

Thanks!

Noah

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Monday, 5 May 2003 20:45:40 UTC