RE: New Issues

A related issue may be that I think we have been leaning towards letting
it up to the binding to determine how the envelope as a whole is
represented, whether it involves an XML 1.0 representation or something
else. As we seem to have settled on the binding not being a SOAP node
but a part of one, I think the question boils down to the issue of what
exactly we mean by representing. 

Representing an envelope potentially includes not only representing
individual header blocks and the body, but all parts of the envelope
including cross-references and other interdependencies that may be
defined outside the SOAP 1.2 specification. 

One potential problem in our current specification is that XML Infoset
doesn't define any conformance rules but leaves it up to the
specification that uses it to define which parts are being used. In the
context of a binding, I think at a minimum we have to talk about which
parts of the infoset we use and what requirements we impose on parts
that we don't use. One approach would be to say that the binding must
pass through all unused information items unchanged. If this is the
case, then I think a great deal of my concern would go away although
this seems to be at least editorially located in another place than the
current ednote.

FWIW, for the reason that intermediaries are SOAP nodes, I think even
though this may be related, the issue of what intermediaries can do is
different, simply because they are first class objects.

Henrik

>This was the subject of an unresolved "debate", leading to the 
>inclusion of the ednote as a marker that further consideration 
>is needed.  I tend to side with you:  the transport binding 
>specs should have freedom to (re)express features in a 
>binding-specific manner, even if they started out as simple 
>headers.  Others strongly disagree, presumably based primarily 
>on the (sensible, IMO) concern that lower layers of the 
>architecture shouldn't be messing with an encaspulated 
>message.  It's possible that the answer may yet be indirectly 
>related the issue Henrik and I started discussing on 
>yesterday's call, as to how much discretion intermediaries 
>have to mess with the envelope.  It's not the same concern, 
>but both affect the rules by which an envelope does or doesn't 
>get looked at or changed while flowing through the network.

Received on Thursday, 24 January 2002 14:23:58 UTC