Re: [core] RD: Registration update/removal request without location

[Christer Holmberg <[e-mail]>]

Hi Christian,

    >> Section 5.3 of draft-ietf-core-resource-directory-19 says:
    >> 
    >>    “The registration interface MUST be implemented to be
    >>    idempotent, so that registering twice with the same endpoint
    >>    parameters ep and d (sector) does not create multiple registration
    >>    resources.”
    >> 
    >> Section 5.3 also says:
    >> 
    >>    ”Success:  2.01 "Created" or 201 "Created".  The Location-Path option
    >>    or Location header MUST be included in the response.  This
    >>    location MUST be a stable identifier generated by the RD as it is
    >>    used for all subsequent operations on this registration resource.”
    >> 
    >> Section 5.4 (including sub sections) then describe how the location is
    >> used in subsequent registration update/removal requests.
    >> 
    >> QUESTION: If a client DOES NOT use the location in the update/removal
    >> request, but the client DOES use the same endpoint parameters ep and
    >> d, is the RD supposed to handle the requests in the same way as if the
    >> location would have been provided? I assume the RD should be able to
    >> find the registration resource based on ep and d.
    >
    > Just to verify I got the question correctly I'll write this as an
    > example (with content-format and similar options elided for brevity):
    >
    >  Req: POST /rd?ep=node1
    >  Payload:
    >  </hello>
    >
    >  Res: 2.01 Created
    >  Location: /reg/1234
    >
    > Now the expected behavior would be for the registrant to refresh the
    > registration like this:
    >
    >  Req: POST /reg/1234
    >  (No payload)
    >
    >  Res: 2.04 Changed
    >
    > What I understand you asking about is what would happen if the
    > registrant ignored the Location options but tries to perform the refresh
    > operation on the /rd resource:
    >
    >  Req: POST /rd?ep=node1
    >  (No payload)
    >
    >  Res: 2.01 Created
    >  Location: /reg/1234

Correct.

    > That can succeed on a CoAP level (depending on the precise handling of
    > absent content formats), but would not give the desired results: It is
    > interpreted as the registrant trying to create a new registration (to
    > override its previous one) *without any links in it* -- rather than
    > refreshing the existig registraion.
    >
    > What a registrant that did not remember its location *could* do is to
    > repeat the complete registration (copy-pasted from above):
    >
    >  Req: POST /rd?ep=node1
    >  Payload:
    >  </hello>
    >
    >  Res: 2.01 Created
    >  Location: /reg/1234
    >
    > which has the same effect as refreshing it -- but is less efficient, and
    > not so much intended to be used like this. (That this is works this way
    > at all is a result of making the registration operation idempotent to
    > allow some optimizations, and to accomodate rebooting registrants). A
    > client that can not be bothered to parse and remember the location
    > should rather use the simple registration right away, which does allow
    > more efficient operation.

The use-case I have in mind is not about the registrant "not bothering to remember", but the registrant not receiving the 2.01 response to begin with.

Assume there is one or more proxies between the registrant and the RD. For some reason it takes time for the RD to send the 2.01, so one of the proxies times out and sends a 5.04 response to the registrant. The same proxy will then (I assume) drop the 2.01 response once it receives it. So, the RD has created a location, but the registrant didn't receive it.

Client        Proxy         RD

 ---- POST -->
                    ---- POST-->
 <---- 5.04---
                   <-- 2.01------

Now, the registrant would obviously try to repeat (not update, as I wrongly indicated) the registration. But, based on your explanation above, that will not cause problems - the new registration will simply overwrite the old one, and everything should be fine.

Thanks!

Regards,

Christer