W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2005

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

From: Tom Rutt <tom@coastin.com>
Date: Wed, 12 Jan 2005 17:28:38 -0500
Message-ID: <41E5A496.5020107@coastin.com>
To: paul.downey@bt.com
CC: tim@mindreef.com, public-ws-addressing@w3.org

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:01 GMT