Peter wrote:
Ok, that's a protocol violation. We could send
FAULT(wrongstate) to the Superior, since that's where the RESIGNED came from
presumably (mind you, if there's random messages flowing about, anything could
have happened). If it's a disordering carrier protocol, we would normally
ignore out-of-sequence messages, though in this case the message can't have been
delayed.
The 0.9 draft (going
back to whenever it was I added the fault details to all the messages), does not
return FAULTs for messages that are responses (i.e. messages sent to the
reply-address of an earlier message, which may be required to be carried on the
lower-layer response if that reply-address was empty (vide response to issue
7)). RESIGN/RESIGNED are unusual in that they are not treated as a
request/reply pair (RESIGN doesn't have a reply-address) - at one time they
were, and there was a corresponding role "Resigner", but that got dropped and
the RESIGNED will always be sent to the Inferior.
I suggest we allow
FAULT (wrongstate) and FAULT(general) as possible from RESIGNED, to be sent to
the Superior address.
Proposed Solution:
Allow FAULT (wrongstate) and FAULT(general) as
possible from RESIGNED, to be sent to the Superior
address
In particular:
At the end of the definition of the RESIGNED message
change
"No
FAULT messages are issued on receiving
RESIGNED"
to
"FAULT
(wrongstate) and FAULT(general) may be issued on receiving RESIGNED, to be sent
to the Superior address, if the Inferior had not sent RESIGN or there was some
other problem with the RESIGNED message (such as a parameter not understood or
message malformed) respectively."