Issue - maint-11 - Allow repeat CANCELLED

[btp issues list maintainer<peter.furniss@choreology.com>]

This issue has been added to the btpm issue list. The issues list is posted as a Technical Committee document to the OASIS BTP TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the BTP TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - maint-11 - Allow repeat CANCELLED

Status: open
Date added: 22 Mar 2004
Submitter: Peter Furniss
Date submitted: 22 March 2004
Description: The existing state tables insist that an Inferior that has cancelled must immediately go to a state where there is no knowledge of the transaction (z) and respond to a repeated CANCEL with an INFERIOR_STATE/unknown message. In reality, an iimplementation is likely to still hold state which would allow it to reply CANCELLED again, for some time - eventually it will probably forget the cancelled transaction completely. Forcing immediate ignorance is unnecessary - implementations should be allowed, but not required to send a repeat CANCELLED if a repeat CANCEL is received.
Submitter's proposal: Add additional state z2, entered on sending CANCELLED where this currently transits  to z. If an imbound message is received, transit to a new query state (y3), which is exitted by resending CANCELLED, reverting to z2.  Disruption (loss of volatile information) should cause a transition to existing z. (Thus the current behaviour can be treated as a disruption I.)
Changes: 22 Mar 2004 - new issue

---

To comment on this issue, please follow-up to this announcement on the business-transaction@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - maint-11 - [anything]" or is a reply to such a message.

To add a new issue, please email to the issues list maintainer (Peter Furniss).