Re: [ws-rx] NEW ISSUE: misplaced guidance on fault handling

[Christopher B Ferris <chrisfer@us.ibm.com>]

DougD pointed out that the same text
is present under Request Acks section.

I would therefore amend my proposal
to add:

Strike sentence beginning on line 537
and continuing through 539.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

Christopher B Ferris/Waltham/IBM@IBMUS wrote on 03/23/2006
06:30:55 AM:

> 
> Title: Misplaced guidance on fault handling 
> 
> Description: 
> 
> Line 566 CD3 WS-RM spec (SeqAck section 3.6) reads: 
> 
> If a non-mustUnderstand fault occurs when processing an RM Header
> that was piggy-backed on 
> another message, a fault MUST be generated, but the processing of
the original
> message MUST NOT be affected. 
> 
> First point, this text isn't very clear. Second, it is IMO 
> misplaced. It really should be called out separately 
> as it applies to more than just SequenceAcks. 
> 
> Justification: 
> 
> This guidance is in the SeqAck section and really deserves to stand
> on its own as it applies to any 
> RM header block that is piggy-backed on a message unrelated to the
Sequence. 
> 
> Target: core 
> 
> Proposal: 
> 
> Strike sentence beginning on line 566, through line 568. 
> 
> Insert, after line 232: 
> 
> When processing of an RM protocol element generates a fault and that
> RM protocol element 
> pertains to a Sequence that is otherwise unrelated to the message
in
> which the protocol element is contained,   
> (i.e. the RM protocol element is a SequenceAcknowledgement or 
> AcksRequested element) the receiving endpoint MUST continue 
> normal processing the message unless the generated fault is a SOAP
> MustUnderstand fault. 
> 
> After matter: 
> 
> Note that this says nothing about transmission of the generated 
> fault. I personally believe that we 
> should leave well enough alone, however, I recognize that this MAY
> present interoperability 
> issues, especially in the case where both the [reply] endpoint and
> the [fault] endpoint are 
> anonymous. I COULD see adding guidance that says that when the above
> criteria are met 
> that the endpoint MUST NOT transmit the fault to the anon endpoint
> UNLESS there is 
> no response message to be transmitted. 
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295