Re: [core] Comments on draft-hartke-t2trg-coral-reef-03

[Klaus Hartke <[e-mail]>]

Jim Schaad wrote:
> [JLS] Endpoint and Domain provide a way to give a "name" to an endpoint and to associate that name to the entry in the RD.  For a third party, among other things this means that you only need to find the name of the endpoint to get and update the entry in the resource directory.  You do not need to both remember and share the location path to other entities.

There are two sides: the lookup interface and the registration
interface. On the lookup interface side, if you want to get all the
registered resources associated with one CoAP endpoint, I guess the
authority (IP address/DNS name and port) is the natural endpoint
identifier. On the registration interface side, you have the
registration units in -reef. If you want clients to give these units a
name, then you immediately run into namespace coordination problems.
So I think the best solution here is to let the server decide the name
of a registration unit. That indeed means you have to pass the
server-generated name around if want other parties to make
modifications, but the same applies to a client-generated name, no?

> [JLS] Yes I meant component not comment.  In theory there is no reason why you should no be able to do so.  In practice it is going almost always be an indication that there is an error in the registration.  The only entity this should be true for is the RD itself.

That seems like an issue of how you want to set up policies for your
resource directory, but not an interoperability issue.

>> If you have, for example, a commissioning tool that registers the resources of lots of servers in a resource directory and wants to register all of them as a single unit, then I don't see why shouldn't be allowed to do so (given proper authorizations).
>
> [JLS] Well - you are going to have a hard time returning the location-path to each of those different servers that you just registered into the RD.

On the lookup interface side, if multiple resources on different
servers match the query, then you'll need to return URIs to all those
different servers. On the registration interface side, if a
commissioning tool registers many resources on different servers at
once, then this single unit has only a single location in -reef.

Maybe this is part of the endpoint/domain thing that I don't understand...

>> Section 4.2.2 [5] currently says:
>>
>>    On success, the server returns a 2.05 (Content) response with a
>>    representation of the list of resources (see Section 4.1.1), but
>>    containing only the subset of links that has resource metadata of
>>    type <http://coreapps.org/reef#rt> with the specified text value.
>
> [JLS] That does not answer my question.  Do rt and <http://coreapps.org/reef/#rt> map to the same information, and if so where is this stated so that I don't get confused about other things that have similar looking names.  This is going to be really an issue if you start getting rid of abbreviations and go to <http://coreapps.org/reef/#resource-type> instead because the strings no longer match.  Given that the RD needs to support arbitrary strings in the link format, knowing if the list is closed or open ended in some manner helps.

There are four different namespaces here: The names of attributes that
RFC 6690 allows you to put in a Link, the name of query parameters
that RFC 6690 allows you to use for filtering, the name of query
parameters that -reef allows you to use for filtering, and the
resource metadata vocabulary in -reef.

* The list of attributes that RFC 6690 allows you to put in a Link is
basically open ended. There are a few attributes defined in RFC 6690
("rel", "anchor", "rev", "hreflang", "media", "title", "title*",
"type", "rt", "if", "sz") but any number of additional attributes can
be defined as long as the name conforms to the `parmname` rule and is
not "href". [1]

* The list of query parameters that RFC 6690 allows you to use is the
same as the list of attributes with the addition of "href" [2].

* The list of query parameters that -reef allows you to use currently
includes only "rt" [3] and "if" [4]. These map to
<http://coreapps.org/reef#rt> and <http://coreapps.org/reef#if>,
respectively [3][4]. The idea is that you can query by any other
metadata by using FETCH [5] instead of using GET with query parameter.

* The list of resource metadata vocabulary supported by -reef is open
ended. (The vocabulary "includes but is not limited to" the items in
section 3.)

Now there are those attributes defined in RFC 6690 and a bunch of
others that have been defined in a number of different places. When we
create the vocabulary for -reef, it would be nice if we had an
equivalent to each of them. But I think (and that was the conclusion
of a discussion with Christian a while ago) that we'll probably don't
want to do a mechanical mapping but rather a semantic one. For
example, have readable names instead of acronyms, do not use decimal
strings for integers, do not use whitespace-separated strings for
lists, etc. So the list of items in that mapping can only closed: If
you convert from Link Format to CoRAL, you really need to understand
each of the attributes you're converting.

Our conclusion was that this is a viable way forward even if new
attributes get defined in the future; those would just need to define
their mapping to existing or new CoRAL vocabulary. You can then easily
query by them using FETCH. For queries using GET with query parameter,
I guess we can choose if we want to have a fixed list or rather a
mechanism for discovering an open ended list of query parameter names
that are supported by a server.

Klaus

[1] https://tools.ietf.org/html/rfc6690#section-2
[2] https://tools.ietf.org/html/rfc6690#section-4.1
[3] https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-5.3.2
[4] https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-5.3.3
[5] https://tools.ietf.org/html/draft-hartke-t2trg-coral-reef-03#section-5.3.4