- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Fri, 25 Jan 2002 08:54:39 -0500
- To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
- CC: "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, xml-dist-app <xml-dist-app@w3c.org>
+1! Williams, Stuart wrote: > 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:55:56 UTC