Subject: [core] Change the default path option in the href document

From: Jim Schaad <[email-masked]>
Date: Tue, 10 Dec 2019 13:16:28 -0800

I would like to change the default path option value in the href document.
It is currently PathOption.Relative and I would like to make it
PathOption.Append.

Relative is the right answer if the primary schema is going to be http.  If
you do a GET on the resource </CoffeePot/main.html> and get back

#status open
#menu -> <menu.html>
#order -> <order.html>

This makes complete sense.  In http, CoffeePot is a directory and the files
main.html, menu.html and order.html are all children of that directory.
This means that a substitution of "menu.html" for "main.html" is what is
expected to happen. 

For CoAP, you can do something similar and have the structure

/CoffeePot
	/coffee
	/menu
	/order

In this case doing a relative resolution of the target will give the correct
answer.  In CoAP there is not the ability to do a redirect, however for the
coffee pot, if that is all it does then one can put all of the resources at
the root and things are fine.  However, most of the applications that I have
been seeing are using a tree structure so that one would have the structure

/CoffeePot
	/menu
	/order
	/queue

Doing the GET on the resource /CoffeePot then needs to return a CoRAL
document that looks like

#status open
#menu -> <CoffeePot/menu>
#order -> <CoffeePot/order>

When using CIRI, this can be simplified slightly to [ PathType, Append-Path,
Path, "menu"].  If append-path because the default value for PathType, then
this becomes [Path, "menu"] which is going to be the shortest possible
encoding.  In that case if you want the same semantics as http, you would
need to encode it as [PathType, RelativePath, Path, "menu"].  I think that
the major criteria that needs to go into making this change is if the
default model for CoAP devices is to be flat like http or hierarchical as I
believe it normally is based on the small set of things that I have looked
at.

Jim

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 17 Dec 2019 17:04:28 +0100

Hi Jim!

> [...]
> encoding.

I had a similar hunch, but resisted the temptation to just make that
change without further confirmation. But now that we have a small
number of real CoRAL-based applications specified (like
draft-hartke-t2trg-coral-pubsub-00 and the upcoming
draft-tiloca-ace-oscore-gm-admin-01), maybe we could start building
the collection of real-world CoRAL documents and use your
implementation to benchmark changes to the encoding like this?

Klaus