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

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Oct 2019 11:33:01 +0000

Hi,

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.

Regards,

Christer

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 25 Oct 2019 09:16:18 +0200

Hello Christer,

On Tue, Oct 22, 2019 at 11:33:01AM +0000, Christer Holmberg wrote:
> 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

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.

Does that answer your question?

KR
c

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Oct 2019 07:51:57 +0000

Hi Christian,

    > operation on the /rd resource:

Correct.

    > 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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Oct 2019 08:00:20 +0000

Hi Christian,

One more thing.

>    refreshing the existig registraion.
  
Maybe it would be good to point that out in the document?

Currently the draft says that the RD MUST return the location, but AFAIK there is no explicit MUST for the registrant to use it in updates (there is only a "must return the location that the registrant will later use in its updates" statement) will, so I think it would be good to make it more clear.

Thanks!

Regards,

Christer

    
      Req: POST /rd?ep=node1
      Payload:
      </hello>
    
      Res: 2.01 Created
      Location: /reg/1234

    
    KR
    c