+1 to generalizing the guidance,
Concern about over-specifying to
underlying protocols where the response channel goes away after one use.
We are going through a lot of gyrations
due to the HTTP 1.1 restriction that a response is a single response entity
IMO.
Thanks
-bob
From: Christopher B
Ferris [mailto:]
Sent: Thursday, March 23, 2006
6:31 AM
To: WS-RX TC
Subject: [ws-rx] NEW ISSUE:
misplaced guidance on fault handling
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
