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

I think that extensibility would require that the spec state something like:

"This spec does not define behaviour upon use of more than one instance 
of a ws:addressing header in a message".

Other specs , using ws addressing, could add their own semantics in the 
context of their use.

Tom Rutt

paul.downey@bt.com wrote:

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

-- 
----------------------------------------------------
Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Wednesday, 12 January 2005 22:31:15 UTC