[core] Listing and testing RFC6690 implementations

Christian Amsüss <christian@amsuess.com> Thu, 18 October 2018 19:30 UTC

Return-Path: <christian@amsuess.com>
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 C2B8B130DE4 for <core@ietfa.amsl.com>; Thu, 18 Oct 2018 12:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 KZWgk-pZs-g2 for <core@ietfa.amsl.com>; Thu, 18 Oct 2018 12:30:44 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B681286D9 for <core@ietf.org>; Thu, 18 Oct 2018 12:30:44 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id A200241BA1 for <core@ietf.org>; Thu, 18 Oct 2018 21:30:42 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A8D1A2A for <core@ietf.org>; Thu, 18 Oct 2018 21:30:40 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 728B87A for <core@ietf.org>; Thu, 18 Oct 2018 21:30:40 +0200 (CEST)
Received: (nullmailer pid 26925 invoked by uid 1000); Thu, 18 Oct 2018 19:30:40 -0000
Date: Thu, 18 Oct 2018 21:30:39 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: "core@ietf.org WG" <core@ietf.org>
Message-ID: <20181018193038.GA12642@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/D_kuIq6QoBZ86FNniN7G_6d1Rtg>
Subject: [core] Listing and testing RFC6690 implementations
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: Thu, 18 Oct 2018 19:30:48 -0000

Hello CoRE group,

I'm looking for and evaluating implementations of the RFC6690 discovery
process to help making decisions on the document formats usable for the
Resource Directory.

So far, I'm aware of RIOT, coap.me, Copper4Cr, leshan, wakaama, ncoap,
californium, CoAP.NET, and the coap Ruby gem.

I've also looked at other SDO's use of 6690: OMA LWM2M appears not to
use anchor at all[8]. OCF are the first I found who actually build a
link from resolving the href relative to the anchor (which is one of the
RFC6690 peculiarities I'm trying to find users of), but use a
serialization that is neither RFC6690 nor links-json exactly (judging
from [9]).


Please send me any links you have on

* consumers of link-format data,
* producers of link-format data that actually output anchor values, or
* other SDOs that rely on the precise resolution rules of RFC6690.

Thanks in advance
Christian


---

Notes from looking through the known ones:

* RIOT: Tested by advertising an RD with <rd> instead of </rd> (which
  are equivalent in 6690); then it fails to register.
* Copper4Cr: not tested, but the absence of 'anchor' in [1] and its
  callers indicates it won't represent links correctly when anchor is
  set (and does not ignore them if it can't handle them either).
* leshan: like Copper, see [2], plus tokenizes wrongly.
* wakaama: like Copper, see [3]
* ncoap: similar to Copper, see [4], though to be fair, it exposes the
  URI via a getUriReference indicating the caller would need to know how
  to resolve it. I found no caller whom I could check for whether it's
  using it right.
* californium: similar situation, see [5]. The href gets passed out as a
  WebLink, whose getURI method only considers the href.
* CoAP.NET: <scnr my family are all teachers>I don't grade copied
  homework, please look at californium's sheets</sorry>
* coap Ruby gem: same situation at [7], href is passed out as uri via
  accessor while anchor is passed along in atteribute if present. 

I had looks at contiki, libcoap, lobaro, txThings -- but none of them
appears to implement link-format parsing in the library.

[1]: https://github.com/mkovatsc/Copper4Cr/blob/9a015d62da0aa9a2cdbe756ed54d11252bc7cb82/shared/utils/StringUtils.js#L138
[2]: https://github.com/eclipse/leshan/blob/13ee2cb236b5c8ef7658205fcf6f16d300a39853/leshan-core/src/main/java/org/eclipse/leshan/Link.java#L106
[3]: https://github.com/eclipse/wakaama/blob/3e038d3abb8d398bba2373815a05308d41774aa1/core/registration.c#L822
[4]: https://github.com/okleine/nCoAP/blob/15d5a76260ffc195571b0efe5cde3616c234e193/ncoap-core/src/main/java/de/uzl/itm/ncoap/application/linkformat/LinkValue.java#L60
[5]: https://github.com/eclipse/californium/blob/9f6f90e53668ea5d5f8946f9f952d3f3892e24de/californium-core/src/main/java/org/eclipse/californium/core/coap/LinkFormat.java#L247
[6]: https://github.com/smeshlink/CoAP.NET/blob/7ffdb9420d282d6cd4c1abd0eea04b0995157ed9/CoAP.NET/LinkFormat.cs#L109
[7]: https://github.com/nning/coap/blob/20d9ce39ee527c3e8e48c4116aab8dae142e4dd3/lib/core/link.rb#L13
[8]: http://openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.pdf
[9]: https://openconnectivity.org/draftspecs/ocf2.0/CR_ATG_1970_Semantic_Tags.pdf

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom