Process EM Messages Behavior

The Process EM Messages Behavior Tree is shown below.

---
title: Process EM Messages Behavior Tree
---
flowchart LR
    seq["→"]
    is_E_msg(["is E* msg?"])
    seq --> is_E_msg
    fb["?"]
    seq --> fb
    is_EK_msg(["is EK msg?"])
    fb --> is_EK_msg
    seq2["→"]
    fb --> seq2
    fb2["?"]
    seq2 --> fb2
    ee_seq["→"]
    fb2 -->|A| ee_seq
    is_EE_msg(["is EE msg?"])
    ee_seq --> is_EE_msg
    ee_emit_GI["emit GI"]
    ee_seq --> ee_emit_GI
    et_seq["→"]
    fb2 -->|B| et_seq
    is_ET_msg(["is ET msg?"])
    et_seq --> is_ET_msg
    et_fb["?"]
    et_seq --> et_fb
    em_x(["EM in X?"])
    et_fb --> em_x
    et_seq2["→"]
    et_fb --> et_seq2
    em_a_r(["EM in A or R?"])
    et_seq2 --> em_a_r
    et_em_to_X["EM → X"]
    et_seq2 --> et_em_to_X
    er_seq["→"]
    fb2 -->|C| er_seq
    is_ER_msg(["is ER msg?"])
    er_seq --> is_ER_msg
    er_fb["?"]
    er_seq --> er_fb
    em_none(["EM in N?"])
    er_fb --> em_none
    er_seq2["→"]
    er_fb --> er_seq2
    em_p(["EM in P?"])
    er_seq2 --> em_p
    er_em_to_n["EM → N"]
    er_seq2 --> er_em_to_n
    viable_seq["→"]
    fb2 -->|D| viable_seq
    cs_in_pxa(["CS in ...pxa?"])
    viable_seq -->|D1| cs_in_pxa
    handle_viab["handle viable embargo"]
    viable_seq -->|D2| handle_viab
    non_viable_seq["→"]
    fb2 -->|E| non_viable_seq
    cs_not_in_pxa(["CS not in ...pxa?"])
    non_viable_seq --> cs_not_in_pxa
    terminate["terminate embargo"]
    non_viable_seq --> terminate
    emit_ek["emit EK"]
    seq2 --> emit_ek
    emit_ee["emit EE"]
    fb --> emit_ee

It is a child of the fallback node started in Receiving Messages Behavior. A precondition check for EM message types is followed by a fallback node. EM acknowledgment messages (EK) receive no further attention and return Success.

Messages That Lead to a Simple Acknowledgment

Next is a branch handling all the messages that will result in a simple acknowledgment (EK).

(A) First, we handle embargo error messages (EE), which additionally trigger a general inquiry (GI) message to attempt to resolve the problem.

(B) Second are embargo termination messages (ET). If the Participant is already in the EM eXited state (X), no further action is taken (aside from the EK). Otherwise, if the Participant is in either Active or Revise EM states, the ET message triggers a state transition \(q^{em} \xrightarrow{t} X\).

(C) Embargo rejections are handled next in a simple sequence that returns the state from Proposed to None.

Handling Viable Embargo Messages

(D) The final chunk of the simple acknowledge branch handles EM messages received when the case state permits embargo viability (\(q^{cs} \in \cdot\cdot\cdot pxa\)). A variety of actions can be taken in this case state, as shown in the next diagram.

---
title: Handling Viable Embargo Messages
---
flowchart LR
    fb["?"]
    ep_seq["→"]
    fb -->|D2a| ep_seq
    is_EP_msg(["is EP msg?"])
    ep_seq --> is_EP_msg
    ep_fb["?"]
    ep_seq --> ep_fb
    ep_em_p(["EM in P?"])
    ep_fb --> ep_em_p
    ep_seq2["→"]
    ep_fb --> ep_seq2
    em_none(["EM in N?"])
    ep_seq2 --> em_none
    ep_em_to_p["EM → P"]
    ep_seq2 --> ep_em_to_p
    ea_seq["→"]
    fb -->|D2b| ea_seq
    is_EA_msg(["is EA msg?"])
    ea_seq --> is_EA_msg
    ea_fb["?"]
    ea_seq --> ea_fb
    em_a(["EM in A?"])
    ea_fb --> em_a
    ea_seq2["→"]
    ea_fb --> ea_seq2
    ea_em_p(["EM in P?"])
    ea_seq2 --> ea_em_p
    ea_em_to_a["EM → A"]
    ea_seq2 --> ea_em_to_a
    ev_seq["→"]
    fb -->|D2c| ev_seq
    is_EV_msg(["is EV msg?"])
    ev_seq --> is_EV_msg
    ev_fb["?"]
    ev_seq --> ev_fb
    ev_em_r(["EM in R?"])
    ev_fb --> ev_em_r
    ev_seq2["→"]
    ev_fb --> ev_seq2
    ev_em_a(["EM in A?"])
    ev_seq2 --> ev_em_a
    ev_em_to_r["EM → R"]
    ev_seq2 --> ev_em_to_r
    ej_ec_seq["→"]
    fb -->|D2d| ej_ec_seq
    is_EJ_msg(["is EJ or EC msg?"])
    ej_ec_seq --> is_EJ_msg
    ej_ec_fb["?"]
    ej_ec_seq --> ej_ec_fb
    ej_ec_em_A(["EM in A?"])
    ej_ec_fb --> ej_ec_em_A
    ej_ec_seq2["→"]
    ej_ec_fb --> ej_ec_seq2
    ej_ec_em_r(["EM in R?"])
    ej_ec_seq2 --> ej_ec_em_r
    ej_ec_fb2["?"]
    ej_ec_seq2 --> ej_ec_fb2
    ej_seq["→"]
    ej_ec_fb2 --> ej_seq
    ej_is_EJ_msg(["is EJ msg?"])
    ej_seq --> ej_is_EJ_msg
    ej_em_to_A["EM → A"]
    ej_seq --> ej_em_to_A
    ec_seq["→"]
    ej_ec_fb2 --> ec_seq
    ec_is_EC_msg(["is EC msg?"])
    ec_seq --> ec_is_EC_msg
    ec_em_to_A["EM → A"]
    ec_seq --> ec_em_to_A

(D2a) An embargo proposal (EP) results in either a move from None to Proposed or stays in Proposed, if that was already the case.

(D2b) An embargo acceptance (EA) transitions from Proposed to Active.

(D2c) Similar to the EP behavior, an embargo revision proposal (EV) either moves from Active to Revise or stays in Revise, as appropriate.

(D2d) Finally, we deal with revision rejection (EJ) or acceptance (EC) when in the Revise state.

Climbing back up the tree, we see that Success in any of the branches in this or the previous paragraph results in an acknowledgment message EK.

Messages That Require More than a Simple Acknowledgment

(E) Returning to the the tree at the top of the page, we come to a branch focused on handling EM messages when an embargo is no longer viable---in other words, when the case has reached a point where attacks are occurring, or either the exploit or the vulnerability has been made public (\(q^{cs} \not \in \cdot\cdot\cdot pxa\)). This branch takes us to the Terminate Embargo tree, which may lead to other messages being emitted.

Finally, back at the end of the tree at the top of the page, when no other branch has succeeded, we emit an embargo error (EE) message to relay the failure.