Protocol Specification Open Questions
The whole specification on one page
The specification is also published as a single page that holds every section and annex in order, for printing or for searching the whole text at once.
This page collects the questions the Vultron Protocol Specification leaves unresolved. Several concern the Case State (CS) dimension Vendor aware, Fix ready, fix Deployed (VFD) and the Participant Embargo Consent (PEC) machine.
Open Questions
Each question below is unresolved at the time of issue. Every one also appears inline at the point in the specification where it first matters, so a reader meeting the gap in context sees it there rather than only here.
Open question: CS ordering constraints are unspecified
CS ordering constraints — including the pX→PX invariant (exploit-public
implies public-aware) and the rule that CP must precede ET where public
disclosure triggers embargo teardown — exist in three non-normative places:
a code docstring, a measurement-oriented reference document
(Possible Histories),
and a design note. No spec group covers them normatively.
A conformance claim cannot meaningfully cover CS ordering until this gap is closed. Treat the material cited here as informative until a normative spec is issued.
Open question: who may assert that a vendor became aware
The first VFD transition — v→V, vendor becomes aware — has no
trigger-side specification and no implementation. Design intent is a
third-party assertion ("I notified this Vendor"), not a self-report.
Open questions: who may assert it, whether the subject Vendor may dispute it, and whether transport-level delivery success, a Hypertext Transfer Protocol (HTTP) 200 response, suffices to constitute the assertion.
Do not infer a rule from this document's silence.
Open question: negative-acknowledgment semantics are unspecified
Error message types (RE, EE, CE) are deliberately unmodeled
(ADR-0049). Unprocessable inbound messages are dead-lettered with no sender
notification. The three-way fault partition
(§4.6 Error and Acknowledgment Messages, ADR-0083) provides
structured error signaling where it is implemented, but whether the
protocol needs a normative negative-acknowledgment facet — and if so,
what the expected sender behavior (retry, suppress, escalate) should be —
remains open.
Open question: which HTTP responses a receiving actor returns
This version does not say which HTTP status code a receiving actor returns when it refuses a message. For example, it does not say whether an invalid activity gets 422, an activity addressed only to other actors gets 400, or a message that cannot be decrypted gets 400.
One option is for the protocol to specify these responses, so that a sending actor can rely on them and act on them. The other is to leave them to each server implementation. A Vultron actor built on a stock ActivityPub server returns whatever that server returns, so a protocol rule could conflict with the server it runs on.
Until this is settled, these codes are recorded as the reference implementation's choices, not as protocol requirements. The codes that HTTP itself defines, such as 405 for an unsupported method and 413 for a body that is too large, are not part of this question.
Open question: acquiring a role after joining a case
This specification says how the Case Owner assigns a role and how a role is offered and accepted. It does not say how a participant already in a case asks for an additional one.
A participant admitted as a Vendor that later also needs the Coordinator
role has no protocol path to request it. In practice the request is made out
of band, or as a Add(Note) on the case, and the Case Owner then issues a
role offer. Neither is a specified mechanism.
Open: whether the protocol should define a role-request activity, whether a participant may decline a role it was assigned, and how a role that is removed rather than added is represented in the case history.
Open question: Case Owner discretion once a termination condition is canonical
Terminating a case-level embargo requires Case Owner authorization by default, and the CASE_MANAGER effects the teardown as the single writer of canonical case state. What is settled is who may terminate: any Participant may initiate termination (report a public/exploit/attacks condition, or notify intent to exit) and may terminate its own compliance, but only the Case Owner authorizes ending the embargo for the case.
What is not settled is whether the Case Owner retains any discretion once
a termination condition has been adopted as canonical case state. When public
awareness or exploit publication (\(q^{cs} \in \{\cdots P \cdots, \cdots X
\cdot\}\)) is canonical, VP-14-001/VP-14-002 read as a mandatory consequence —
the embargo no longer protects anything — and the working position of this
specification is that teardown is then mandatory, with the Case Owner's
authority exercised at the point the condition is adopted (guarding against
a false report) rather than as a second, separate decision to keep the
embargo. This matches the automatic-teardown path (a canonical CS.P set by
the Case Owner triggers teardown).
Open: whether the Case Owner may decline to tear down even after the
condition is canonical; whether the "attacks" condition (SHOULD, VP-11-006)
differs from the "public/exploit" condition (SHALL) in this respect; and how
a deliberate decision to keep an otherwise-terminable embargo would be
recorded. This is expected to be a matter of discussion; the resolution MUST
be reflected in this reference and in specs/vultron-protocol-spec.yaml
(VP-11, VP-14) once reached.