It should be made more obvious in IS-04 that Nodes must update the Registration API with any changes to their resources.
We have a section entitled "Initial Registration" in Behaviour: Registration but nothing like "Updating Registration".
This update process is completely fundamental to the whole interaction between the Node and the Registry (and thus Clients, who receive Query WebSocket events), especially as relates to IS-05 requirements on updates to Sender/Receiver subscription and version after activations.
It is tested by the IS-05-02 (IS-05 Interaction with IS-04) test suite used as part of JT-NM Tested, so it's well known.
However, in the spec, although the Registration API describes the 200 OK response to POST /resource for such updates, and the Behaviour: Registration page has a section on what to do if you get an unexpected200 OK (rather than 201 Created), there really ought to be a section describing the expected scenario.
I suggest adding a sub-section in Behaviour: Registration with links from Behaviour: Nodes and the version docs. If we write this in the same style (statements of fact rather than conformance language) this can be done as an editorial change in a v1.3.x patch release.
It should be made more obvious in IS-04 that Nodes must update the Registration API with any changes to their resources. We have a section entitled "Initial Registration" in Behaviour: Registration but nothing like "Updating Registration".
This update process is completely fundamental to the whole interaction between the Node and the Registry (and thus Clients, who receive Query WebSocket events), especially as relates to IS-05 requirements on updates to Sender/Receiver
subscriptionandversionafter activations.It is tested by the IS-05-02 (IS-05 Interaction with IS-04) test suite used as part of JT-NM Tested, so it's well known.
However, in the spec, although the Registration API describes the
200 OKresponse toPOST /resourcefor such updates, and the Behaviour: Registration page has a section on what to do if you get an unexpected200 OK(rather than201 Created), there really ought to be a section describing the expected scenario.I suggest adding a sub-section in Behaviour: Registration with links from Behaviour: Nodes and the
versiondocs. If we write this in the same style (statements of fact rather than conformance language) this can be done as an editorial change in a v1.3.x patch release.