RE: Resolving the Ed Note in Part 1 section 5.1 (was New Issues)

Henrik, Noah,

Just thought that I would self identify as one of the 'Others...' that Noah
mentions, althoug 'strong' disagreement :

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

In a discussion between TBTF participants (archived at [1]) I made the
following proposal for resolving the ednote in Section 5.1 of part 1 [2],
which I think is related to this thread of discussion.

<quote>
Proposal:
---------

"The combination of the SOAP extensibility model and the SOAP binding
framework provide some flexibility in the way that particular features can
be expressed . Features expressed within the SOAP envelope MUST be expressed
in accordance with the relevant SOAP Module specification. Features
expressed outside of the SOAP Envelope (typically in a manner that is
specific to the underlying protocol) MUST be expressed in accordance with
the relevant protocol binding specification. In cases where, for a given
message exchange, a given feature is made available by more than one SOAP
module and/or protocol binding, a SOAP node has complete discretion over
which particular SOAP module or protocol binding it delegates provison of
the given feature for the given message exchange. The particular choice may
be influenced by the combination of features require by the message exchange
and any other local factors, such as application preferences."

Possible addition constraining the behaviour of a protocol binding:

"A SOAP binding is required to convey an XML infoset representing a SOAP
envelope and its contents between peer SOAP nodes without modification. An
instance of a SOAP binding MAY inspect, but not alter, the XML infosets
being exchange."
</quote>

I think the additional piece if included (and wordsmithed) comes close to
addressing Henrik' concern:

> 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

The rationale I offer for the inclusion of the additional sentences is also
given in [1] as:

<quote>
The second, perhaps grayer question, is whether a binding can recognise the
elements with the envelope that provide a feature that the binding itself is
capable of supporting and having recognised such elements, remove them from
the envelope and substitute it's own mechanisms for providing the *same*
functionality - after all... who would know? 

My own answer to that question is NO. The SOAP provider has made the choice
of which provider of a feature to use, Module or Binding (indeed possibly
selected between many modules and many bindings that provide overlapping
functionality). Having made that choice, it is not possible for the binding
to know whether the elements it snoops on were introduced by the SOAP
provider or whether they originate from the SOAP User. Basically, I believe
that the role of the binding is to convey an XML Infoset representing the
SOAP enevlope and its contents from one binding peer to another without
altering the content of that infoset (there are unresolved questions about
infoset equivalence concerning the lexical devices such as ns prefixes and
lexical representation of schema datatypes of equivalent value, let alone
issues related to signatures and encryption).
</quote>

Regards,

Stuart
[1] http://lists.w3.org/Archives/Public/www-archive/2002Jan/0111.html
[2] http://www.w3.org/TR/soap12-part1/#NA54

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 24 January 2002 19:23
> To: Noah Mendelsohn; Marc Hadley <marc.hadley
> Cc: xml-dist-app
> Subject: 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 Friday, 25 January 2002 08:40:15 UTC