Re: [core] [T2TRG] Review of CoRAL

Klaus Hartke <hartke@projectcool.de> Sun, 04 November 2018 14:57 UTC

Return-Path: <hartke@projectcool.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0C1130DD9; Sun, 4 Nov 2018 06:57:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MefZTPs6SWGW; Sun, 4 Nov 2018 06:57:07 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E8B130E0E; Sun, 4 Nov 2018 06:57:07 -0800 (PST)
Received: from mail-qk1-f172.google.com ([209.85.222.172]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJJpl-00083f-Or; Sun, 04 Nov 2018 15:57:01 +0100
Received: by mail-qk1-f172.google.com with SMTP id u68so10673699qkg.9; Sun, 04 Nov 2018 06:57:01 -0800 (PST)
X-Gm-Message-State: AGRZ1gLePBOe+5MAZAd6RHdEERxKVajSAPN3U4Cej6yk/pXflX5DJ5OM yH8aE2TpyJ4gPY5qK6RAaobGQpHziy1uc3l06NY=
X-Google-Smtp-Source: AJdET5d0mm2+vCHWWwJM26EpDdUPzTpmLsxGgKyN/TipXjL23ghGi5538EkYg+Rsu/W0fM9K+RJEsQgCWHjCw3T6vf0=
X-Received: by 2002:aed:26a3:: with SMTP id q32mr5953642qtd.106.1541343420651; Sun, 04 Nov 2018 06:57:00 -0800 (PST)
MIME-Version: 1.0
References: <20181031164534.GA4995@hephaistos.amsuess.com>
In-Reply-To: <20181031164534.GA4995@hephaistos.amsuess.com>
From: Klaus Hartke <hartke@projectcool.de>
Date: Sun, 4 Nov 2018 15:56:28 +0100
X-Gmail-Original-Message-ID: <CAAzbHvYPRLMZFh2Yi7jwM8ZzVMXcLmqe20Qeo2LjD9xCu4=9QA@mail.gmail.com>
Message-ID: <CAAzbHvYPRLMZFh2Yi7jwM8ZzVMXcLmqe20Qeo2LjD9xCu4=9QA@mail.gmail.com>
To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= <christian@amsuess.com>
Cc: T2TRG@irtf.org, draft-hartke-t2trg-coral@ietf.org, "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541343427; 880428d0;
X-HE-SMSGID: 1gJJpl-00083f-Or
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/oPJD5LyEfx7wMQTqJcF0ubWwclo>
Subject: Re: [core] [T2TRG] Review of CoRAL
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2018 14:57:09 -0000

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