Re: [core] [T2TRG] Review of CoRAL

[Klaus Hartke <[e-mail]>]

Hej Christian,

again, thanks a lot for your feedback. I'll start with some
low-hanging fruits and create separate threads for larger topics.

As part of the IETF103 Hackathon this weekend, I've started doing some
basic interop testing of our two CoRAL implementations. There was one
blocking issue and a few minor issues, the blocking issue being this
one from your review:

> * How are compressed URIs expressed in CBOR? Flat [6, "foo", 6, "bar"]
>   or nested [[6, "foo"], [6, "bar"]]? My first reading (and current
>   implementation) resulted in "nested", supported by the `(option,
>   value) = href[0]` line in C4, but reading C.1 with the CDDL spec next
>   to it (and running the cddl tool) rather indicates "flat" to me.

The representation of the list of options is indeed different in the
draft for CBOR and Python. In Python, it feels natural to me to
iterate over the list as a list of pairs, while in CBOR I don't see a
need to wrap each pair in an extra array. So, in CBOR, the array
should be flat: [6, "foo", 6, "bar"].

If it improves clarity, the Python code could be updated to operate
on flat lists instead, e.g., using the grouper function from
<https://docs.python.org/3.6/library/itertools.html#itertools-recipes>:

-        for option, _ in href:
+       for option, _ in grouper(href, 2):

Minor interop issues:

body.py:
>                if ':' in i.relation:
>                    rel = i.relation
>                else:
>                    rel = 'http://www.iana.org/assignments/relation/' + i.relation

When a relation is provided as a string, the intention is that the
string always contains the IRI. I don't think the current set of
IANA-registered link relation types is relevant enough in the context
of IoT that it should get special treatment.

body.py:
>            elif isinstance(i, BaseDirective):
>                base = base / i.iri

The draft currently specifies that a base IRI is resolved against the
current context IRI, not the previous base IRI.

Editorial issues:

> * Is there a difference between a CoRAL registry and a CoRAL profile?
>   Both terms are used.

The draft uses the "profile" media type parameter defined in
<https://tools.ietf.org/html/rfc6906> to indicate the CoAL registry,
which I think makes more sense to define a new "registry" parameter
with essentially the same semantics. So "profile" should appear only
as the parameter name. I've replaced all instances where "profile"
appeared without this meaning with "registry".

> * Why is <http://TBD/> used for attrs, but <urn:ietf:rfc:XXXX#...> used
>   for the core form relations? They could at least share structural
>   similarity.

In general, I think URNs would make more sense for identifiers than
HTTP URIs, as the latter always look like they could be successfully
dereferenced. But it seems that HTTP URIs are more popular in the
Semantic Web...

Right now, both <http://TBD/...> and <urn:ietf:rfc:XXXX#...> (which
I've replaced with <http://TBD2/...> and <urn:TBD1#...> in my working
copy, respectively) are just visually distinct placeholders until
IETF-controlled IRIs are assigned.

> * If the first use of the http://www.iana.org/assingments/relation/
>   prefix for rel values pointed to RFC4287, it would be clearer to the
>   reader that this is already established practice.

The whole Examples section probably needs an overhaul, but I've moved
the text about expressing registered link relations into its own
section and added a note that the prefix is already established
practice.

> * Any test vectors or examples to get started on the binary format would
>   be helpful, and could be augmented by (CDDL automatically?) annotated
>   extended diagnostic notation, like (as in the above, assuming a
>   navigation profile where someone forgot that favicon is a typical rel)

My idea was to maintain a collection of test vectors in a GitHub
repository, so that the test vectors can be more numerous and more
easily fixed than in an RFC. Now that we creating a bunch of examples
for use cases like RD, it would actually be a good time to start that.

Best regards,
Klaus