[core] Listing and testing RFC6690 implementations

[Christian Amsüss <[e-mail]>]

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