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

This is why I prefer that wsa define behaviour for when there is only 
one of the headers of each type present, but leave
it open for future protocols to add the defined behaviour in their 
specific context.

Version 1 senders would not send two headers of any wsa defined header 
type, and if a v1 server received an extra it could decide
on its own what to do, in lack of any specific other protocol context 
which does define the behaviour specifically for the multiple presence case.

Most version 1 implementations on the server side wuould probable ignore 
the extra header, if they do not also implement the extension protocol.

Tom Rutt
Fujitsu

Tim Ewald wrote:

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

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

Received on Sunday, 16 January 2005 11:43:15 UTC