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

David,

I see where you are coming from with this example, but I'm not sure I agree.
Specifically, while allowing multiple ReplyTo/FaultTo headers but ignoring
extras would make WSA.1 and WSA.Next syntactically backward and forward
compatible, I'm not convinced they'd be semantically compatible. If I build
a V1 message and send it to a V1 receiver, that receiver will ignore any
extra *To headers. If the receiver is upgraded to WSA.Next, however, it
might start use one of the extra *To headers (at it's discretion as you
say). My V1 message sender isn't prepared for that, because that isn't the
semantic of WSA.1. If I were inserting extra headers secure in the notion
that they would never be processed (don't ask me why), then I'd break,
right? So if this is really the intent, I think you have to say something
more than the extra headers are ignored. Somehow you have to indicate that
in the future they might not be.

Thanks,
Tim-


> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> David Orchard
> Sent: Wednesday, January 12, 2005 6:27 PM
> To: paul.downey@bt.com; tim@mindreef.com
> Cc: public-ws-addressing@w3.org
> Subject: RE: i009 - mustIgnore rule for multiple To, ReplyTo, etc.
> 
> 
> One of the scenarios that I imagine is a future version of 
> WS-Addressing.  IF WS-Addressing V1.0 builds in a 
> "substitution mechanism", then I think it can enable a 
> WS-Addressing V.Next to be forwards and backwards compatible 
> with V1.0.
> 
> Imagine WS-A V.Next decides that for
> reliability/scalability/performance/protocol/whatever 
> reasons, that there can be multiple ReplyTos or FaultTos in a 
> message.  The meaning of multiple *Tos is that the client can 
> select which to use at its discretion.  
> 
> Because these *Tos are both backwards and forwards 
> compatible, WS-A V.Next decides to re-use the WS-A namespace 
> name for this compatible change to the semantics of multiple *Tos.  
> 
> We have the best of both worlds now: WS-A V.Next receivers 
> can receive *Tos from WS-A V1.0 and V.Next senders, and WS-A 
> V1.0 receivers can receive *Tos from WS-A V1.0 and V.Next senders.
> 
> If there is no "ignore" mechanism in place, the situation is 
> harder, though not impossible.  WS-A V.Next would need to 
> introduce new QNames, perhaps wsav2:ReplyTo and 
> wsav2:FaultTo.  These Qnames have the same functionality 
> described earlier, multiples are allowed and client can 
> choose.  These Qnames must say that they replace the wsav1 
> Qnames in the case of where messages contain both v1 and v2 
> *Tos.  To enable compatibility, 2 things must be specified.  
> Forwards compatibility requires that the sender must send 
> both wsav2:*To AND wsav1:*To in messages.  The wsav2:*To 
> would obviously be marked with mU="false".
> Backwards compatibility requires that the sender must 
> understand both wsav1:*To and wsav2:*To elements.
> 
> I think that design #1, which is roughly Must Ignore Extras, 
> allows for a simpler and more natural backwards and forwards 
> compatibility.
> 
> Cheers,
> Dave
> 
> > -----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 1:48 PM
> > To: tim@mindreef.com
> > Cc: public-ws-addressing@w3.org
> > Subject: 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 Thursday, 13 January 2005 14:23:36 UTC