Subject: [core] Comments on draft-ietf-core-resource-directory-09

From: Jan Newmarch <[email-masked]>
Date: Sat, 03 Dec 2016 19:42:58 +1100

Hi

Not sure if I am following protocol posting to [email-masked]. Previous
email to [email-masked] had no response. I
haven't been able to track down many past discussions on this draft, it
may be that my comments have been answered already, if so, apologies.

re: 5.1 Simple publishing to an RD

This says that POST can be made to ./well-known/core on the RD. It
doesn't say if the required parameter 'ep' in 6.3 is required for this
method of registration.

Why does the RD have to support filtering? This is optional for other
CoAP agents. It does add a burden to the RD that is not required for
other agents.

Why does an endpoint sending a POST request to an endpoint have to have
an empty body? Couldn't it include resources? Then the RD wouldn't need
to make a request to the server. Could you say "If the body is empty
then it triggers a GET request. If it has a non-empty body then these
are the resources being registered."

Section 5.1 POSTS to an RD. POST would normally expect a return value
which is the uri of the newly created resource. This return value is
not mentioned in  draft-ietf-core-resource-directory-09. Is it the same
value that would be returned by a 6.3 Registration such as 

    Res: 2.01 Created
   Location: /rd/4521

If not, then what? if yes, then presumably the RD has created a new resource with empty values (possibly with an endpoint name?). 5.1 states that later the RD will query the endpoint with a GET, and then presumably the value stored on the RD will be updated. Could the endpoint have in the meantime done a 6.4 update based on the uri it got back? What happens in such cases?

Before the RD has updated the value in its directory, can a 3rd party client have queried the RD lookup service and got back some info about this endpoint? If so, what will it get? It can't get a CoAP entry showing the uri path to the resources on the endpoint because it doesn't know them yet.

Most of these issues go away if the initial 5.1 POST is allowed to be non-empty.

In section 6.3 POST is used both for new entries and for updating
existing ones. I know that REST is not prescriptive on this, but I am
of the camp that says updates should be done by PUT and that POST is
reserved for new resources only. You don't give PUT as an option. It
seems to have been in version 5, but vanished later and the CHANGES
don't mention this change.

In section 6 it uses 'rd' for registering and updating resources using
POST, but a separate resource 'rd-lookup' to GET resources. Normal REST
usage would use GET on 'rd'. Why is there a separate resource?

It is not clear why it is mandatory that an endpoint have a name. I can
see it is often convenient, but mandatory?

Regards

Jan
-- 
Dr Jan Newmarch,
Head of Higher Education (ICT) @ Box Hill,
Adjunct Professor @ University of Canberra

P 61 3 9286 9971
M +61 4 0117 0509
F 61 3 9286 9100
W www.boxhill.edu.au
W jan.newmarch.name
E [email-masked]
E [email-masked]

---

From: peter van der Stok <[email-masked]>
Date: Wed, 14 Dec 2016 09:20:05 +0100

Hi Jan,

Thanks for your interest.
Mailing list is correct medium for these suggestions for improvement.
See below.

> doesn't say if the required parameter 'ep' in 6.3 is required for this

Thanks, this looks like an omission.
Unless someone remembers a counter argument I will add the ?ep to the 
post
> 
> Why does the RD have to support filtering?

This remark reads like a major rewrite of the RD Spec.
I don't think that will happen.

> which is the uri of the newly created resource.
>     Res: 2.01 Created
>    Location: /rd/4521
> 
The returned location is provided for updates.
No updates are expected in this case.

> 
> Before the RD has updated the value in its directory, can a 3rd party
> client have queried the RD lookup service and got back some info about
> this endpoint? If so, what will it get? It can't get a CoAP entry
> showing the uri path to the resources on the endpoint because it
> doesn't know them yet.

Agree, There is no info.

> existing ones.
Use of POST and PUT in RD is in agreement with RFC7252 spec, and 
reflects current consensus.

> usage would use GET on 'rd'. Why is there a separate resource?

Section 3 is supposed to explain these design choices. Anything missing?

Greetings and thanks,

Peter