RE: i009 - mustIgnore rule for multiple To, ReplyTo, etc.

Hi Tim!
 
from my POV helpful expert comments like yours and Noah's are always welcome
and has to be one of the main reasons why a WG uses a public list for technical 
discussions.
 
You've raised some interesting points here and. Doug Davis also raised the targeted 
role issue offline, so you're not alone with your concerns.
 
In many respects the difficulties you raise around allowing multiple instances of a 
should come as no surprise to me given the explosion of complexity was the 
main reason my raising this issue in the first place. i guess it possibly serves me 
right for looking for an easy way out! i'll noodle on this a little more before our 
discussion on this issue next week.
 
thanks,
Paul

 -----Original Message----- 
 From: public-ws-addressing-request@w3.org on behalf of Tim Ewald 
 Sent: Wed 12/01/2005 19:55 
 To: Downey,PS,Paul,XAGA C 
 Cc: public-ws-addressing@w3.org 
 Subject: RE: i009 - mustIgnore rule for multiple To, ReplyTo, etc.
 
 


 Paul,
 
 Like Noah, I'm not a member of the WSA group, so feel free to tell me to go
 away (unlike Noah I didn't add this disclaimer to earlier posts; sorry).
 
 Speaking as someone who works at a company dedicated to helping people deal
 with interoperability problems, I have to question the wisdom of allowing
 but ignoring multiple instances of these headers. Presumably a SOAP node
 would only inject an additional duplicate header to achieve a desired
 effect. To ensure that effect, the processor would have to check to see
 whether the same header already existed in a message. If it did, the
 processor would presumably either raise an exception or put it's header in
 *before* the present header in order to trump it. There would be little
 reason to put it in after the existing header, since it would just be
 ignored.
 
 This raises two questions in my mind. First, what are the security
 implications? Will this open to WSA to attacks based on shifting relative
 position of a header and require the use of XPath expressions in signatures
 that explicitly specify position relative to soap:Header? If multiple
 instances were disallowed, this issue would go away as injecting a duplicate
 header would invalidate the message.
 
 Second, how does all this work relative to headers targeted at different
 actors/roles (are those allowed with WSA?)?
 
 While I can see applying the mustIgnore rule to content you don't know
 about, it seems kind of strange to apply it to duplicate elements in a given
 spec. If SOAP allowed multiple soap:Header/soap:Body elements in any order,
 with only the first of each in document order having meaning help or hinder
 interoperability? What about understandability?
 
 Thanks,
 Tim-
 
 > -----Original Message-----
 > From: public-ws-addressing-request@w3.org
 > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
 > paul.downey@bt.com
 > Sent: Wednesday, January 12, 2005 11:38 AM
 > To: noah_mendelsohn@us.ibm.com
 > Cc: public-ws-addressing@w3.org
 > Subject: RE: i009 - mustIgnore rule for multiple To, ReplyTo, etc.
 >
 >
 > Noah,
 >
 > Thanks for your help, in particular the quotation from the
 > SOAP 1.2 Rec S2.6[1]. I'm assuming that a similar processing
 > model also applies to SOAP 1.1, though i couldn't find that
 > explicitly stated in the note or the WS-I Basic Profile. As
 > i'm sure you are aware, we are chartered to provide bindings
 > for both SOAP 1.1 and 1.2 and I believe it is desirable to
 > have the same mustIgnore rule for multiple EPRs applied to
 > both bindings.
 >
 > > I'm not recommending one approach or another for ReplyTo
 > and friends,
 > > but just pointing out that the SOAP recommendation provides
 > the option:
 > > if you want to say in the specification for some SOAP header block:
 > > "all occurrences of blocks with this QName must be processed in
 > > document order", the SOAP Rec. says you can do that.
 >
 > That sounds good to me, assuming SOAP 1.1 has the same
 > processing model.
 >
 > > Now, whether most of the widely
 > > deployed implementations of SOAP make it easy to achieve
 > such control
 > > is a different question.
 >
 > Given we're writing a specification I would like to think we
 > can follow correctness here and specify a significance to the
 > order for repeated headers in the wsa namespace.
 >
 > >From a brief look at a couple of SOAP APIs taken at random it seems
 > that you can usually iterate through the SOAP headers in
 > order, though some tools which provide an application
 > binding, generating code for headers directly described in
 > WSDL will have difficulties.
 > Then again such an approach at implementing wsa will
 > encounter many other difficulties. Maybe this isn't such an
 > issue in practice after all.
 >
 > My remaining concern regards a use-case Don Box outlined at
 > our Redmond F2F in which other non-wsa components in a SOAP
 > processing pipeline may trigger off wsa headers, such as EPR
 > parameters and properties.
 > Such side-effects could be oblivious to our mustIgnore rule
 > if they encountered a repeated item, but then they would have
 > to consider other items being repeated anyway - i don't see
 > this as an issue.
 >
 > So I'm happy to rewrite the Option#3 proposal more concretely
 > to state 'subsequent unexpected wsa:Address, wsa:wsa:To,
 > wsa:ReplyTo, wsa:FaultTo items must be ignored", assuming
 > there's no strong disagreement from the WG on this direction?
 >
 > Paul
 >
 > [1] http://www.w3.org/TR/soap12-part1/#procsoapmsgs

 >
 >

Received on Wednesday, 12 January 2005 21:46:38 UTC