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

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: 

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: 

> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

> phone: +1 508 377 9295