LC76a proposal

I agree with the objecter the difference in prose between (now) 2.2.1 
and 2.2.2 makes it difficult to grasp the differences between the two 
fault rules. To address this objection, as suggest the following rewrite 
of 2.2.2, which now makes the difference explicit:

<proposed section="2.2.2">
Any message, including the first in the pattern, MAY trigger a fault 
message, which MUST have opposite direction. The fault message MUST be 
delivered to the originator of the triggering message, unless otherwise 
specified by an extension of binding extension. Any node MAY propagate a 
fault message, and MUST not do so at most once for each triggering 
message. If there is no path to the originator, the fault MUST be discarded.
</proposed>

FYI, here's the current text for 2.2.1 and 2.2.2:

<current section="2.2.1">
Any message after the first in the pattern MAY be replaced with a fault 
message, which MUST have identical direction. The fault message MUST be 
delivered to the same target node as the message it replaces, unless 
otherwise specified by an extension or binding extension. If there is no 
path to this node, the fault MUST be discarded.
</current>

<current section="2.2.1">
Any message, including the first, MAY trigger a fault message in 
response. Each recipient MAY propagate a fault message, and MUST 
propagate no more than one fault for each triggering message. Each fault 
message has direction the reverse of its triggering message. The fault 
message MUST be delivered to the originator of the message which 
triggered it, unless otherwise specified by an extension or binding 
extension. If there is no path to this node, the fault MUST be discarded.
</current>

Jean-Jacques.

PS. The same proposal also send as comments on today's call agenda, but 
extracted here for easier referenceability.

Jonathan Marsh wrote:
> >> Section 2.1.1 Fault Replaces Message and 2.1.2 Message Triggers
> >> Fault don't allow a fault to go to an alternate location in the
> >> case where a wsa:FaultTo [WS-Addressing] header is specified.
> >> Generalize these rules so that addressing mechanisms can be
> >> accommodated without defining new MEPs.
> >
> > The WG agreed with this issue (LC76a) [34], and adding a clause to
> > the fault rule set that says the destination of the fault may be
> > modified by a binding or extension and to cite WSA as an
> > informative example.
> >
> > [34] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76a
>
>
>  We see that text to allow dynamic redirection of faults was added to
>  Section 2.1 Fault Propagation Rules, but the specific rule
>  definitions in Sections 2.1.1 and 2.1.2 still say "The fault message
>  MUST be delivered to...". Please make sections 2.1.1 and 2.1.2 more
>  consistent.

Received on Thursday, 7 July 2005 10:05:00 UTC