the 2pc can't get to
confirm (or at least, can't confirm this inferior) because that would
require a PREPARED from the inferior, and the inferior canr resign
after its said its
prepared.
If
there's something in the specification that says a RESIGN *cannot* be sent
after PREPARED has been sent, then that's OK. In the 0.6 version there was,
but I don't have access to the 0.9 version at the moment so can't tell.
It's in the state table, and also the
text for RESIGNED.
What are the other
cases ?
I
was thinking about security implications, but since we completely ignore
security anyway ...
Generalising - wouldn't a security
violation receive a security-related fault ? It would be similar to
(and arguably is a particular form of) a communication failure - "your message
was not processed because it was not authenticated" is similar at one level to
"your message was not processed because it never got there" (and very
different at another level). As far as the btp state (at the intended
receiving end), it didn't happen. Well, perhaps either might hint to the btp
process that a reminder (repeat of the previous message or the appropriate
*_STATE mesage) would be helpful, but sending those doesn't change the state
proper.
(this message sequence had got
detached from the spec-list thread)
Peter
------------------------------------------
Peter
Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:
peter.furniss@choreology.com
phone: +44 20 7670 1679
direct: +44
20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N
2JX