Re: PASWA, Include and Protocol Bindings

Hi Noah,

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

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.

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.

In any case, I agree very much that our discussion should be framed by the
terminology and concepts in SOAP 1.2.

Regards,


> My comment here is neither to endorse nor to discourage consideration of
> such a mechanism.  Rather, I would like to suggest that the proposal
needs
> to be better related to the mechanisms of SOAP 1.2.  Specifically, SOAP
> refers to an envelope infoset, and gives responsibility to a Protocol
> Binding Specification for determining how the data will actually look
"on
> the wire".
>
> I think what's intended by PASWA might better be layered in the
following
> manner:
>
> * The envelope infoset invariably represents (what we have previously
> called) attachments as character children in the infoset.
>
> * (here's the change) Protocol bindings MAY use a wire representation in
> which (a) the envelope infoset transmitted on the wire has such element
> children replaced with an <xbinc:Include> element and (b) that element
MUST
> refer to a URI that the binding warrants will resolve to a binary
stream,
> which has as its base64 canonical form the original characters.
>
> Of course, there are other ways to present the architecture, but I think
we
> need to always refer to the normative SOAP model, which deals with only
one
> infoset.  There is nothing in the SOAP architecture that says: "take the
> received infoset, rewrite it, and then rerun the SOAP processing model."
> One could claim that the xbinc:DoInclude element [4] carries that rather
> elaborate semantic, but it seems to be a big, big extension to the SOAP
> processing model.  It wouldn't be surprising that it would raise all
sorts
> of edge cases for intermediaries, signatures and the like down the road.
> Certainly it would need to be specified very carefully and formally.
>
> It seems to me that our precedent in SOAP is: there is one application
view
> of the infoset.  I really don't think I want applications or the SOAP
> processing model itself to see the xbinc:Include elements.
Optimizations
> of representions for efficient transmission belong in the bindings.
Note
> that the doInclude element can be retained, if you like, as there's
nothing
> to prevent a binding from being aware of the presence of headers (though
it
> doesn't use the processing model on them.)  On the other hand, I'm not
sure
> that keeping it is necessary.  I think we should at least explore that
> layering of the PASWA proposal.  Thanks!

Received on Monday, 5 May 2003 17:02:57 UTC