Registration take-over

[chrysn]

Friday's plug test has spurred discussion as to whether a registration can be "taken over" by a CT. There, a client registers simply in 3, and then something else (a CT?) finds its registration and deletes it in step 12.

This describes a procedure that we do not describe, that is, a CT jumping in at a simple registration and treating it as a third party registration from there on -- whereas we say that "[a]dditional operations on the registration resource cannot be executed because no registration location is returned".

I suggest we change the test procedure not to include behavior we don't specify, and to test the explicit deregistration with the full or third party registration instead. Then, the text we already have on that there can't be additional operations on the registration resource should suffice to indicate that such behavior is not expected.

(One thought that had led to the discussion was that registration resources might not be available on all URI schemes, for whereas an RD serving on coap, coap+tcp and http might have three equivalent directory resources at ${scheme}://${ip}/rd for all values of scheme, a registration resource might still only be available to the client at a particular scheme.)

[petervanderstok]

sorry, I am not exactly clear what you mean by:
There, a client registers simply in 3, and then something else (a CT?) finds its registration and deletes it in step 12.. Is that a legal interpretation of the test spec? I don't think so.
So, yes, simple registrations can only expire and not be deleted. But that is already in the RD spec itself, correct?

[chrysn]

simple registrations can only expire and not be deleted. But that is already in the RD spec itself, correct?

Yes. Even more so: "Additional operations [that'd include read-endpoint-links] on the registration resource cannot be executed"

The test spec reads as a sequence of operations that culminate in a lookup that verifies that all had the desired effect. The read-endpoint-links operation in test 11 reads out the data submitted in the simple registration of test 3. No matter whether it's the "simple" EP that suddenly grew sophisticated, or a CT that tried to meddle with the simple EP's registration, that's out of spec.

(But yes, I think the spec is clear enough, we'll just need to change the test description, but I'd like to do that in the frame of F-Interop, so no need to fully process this for the WGLC document.)