RE: [bt-spec] BTP Issue 19 : FAULTs from RESIGNED ?

[Peter Furniss <peter.furniss@choreology.com>]

 

BTP Issue 19 : FAULTs from RESIGNED ?

Category: minor technical
Submitter: Gordon Hamilton, AppliedTheory
Reference: Page 36 Para last Sentence 1
Current text: No FAULT messages are issued on receiving RESIGNED.????
Question: Even if you did not ask to RESIGN?

---

 

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