Subject: [core] draft-ietf-core-links-json-04

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Mar 2016 19:01:27 +0200

Hi all,

I read through draft-ietf-core-links-json-04. The document is
conceptually fairly easy and I believe the document is in good shape.

The core assumption of the document is that there is a need to encode
the link formats in different formats, namely JSON and CBOR, rather than
plain-text. I don't know whether this working assumption is a good idea
since it will obviously reduce interoperability since now devices will
suddenly have to deal with three different formats rather than just one.

Additionally, the document contains mapping of the formats defined in
RFC 7390 "Group Communication for CoAP" into CBOR. While this sounds
reasonable the text somehow does not fit into this document. I
personally would prefer if that text gets added to a revised version of
the group communication draft instead.

There are a few TODO's in the document:

  * Page 6 says "Is this the right list of attribute names?" and I
wonder whether the attribute names actually matter that much.

  * Page 7 says "(more examples to be added.)". There are, however,
plenty of examples in the document and so I was wondering whether this
is line is just a left-over from past times.

  * The acknowledgement section is almost empty and I am wondering
whether this is a reflection of the review status. If that's the case
then the situation is not looking good. How strong is the support for
this document?

  * The security consideration section also says TBD but since we are
only defining alternative encodings of already existing functionality I
cannot see additional concerns.

  * Page 13 states "Should the IP address/port number information be
represented in a more compact way?". I am wondering whether this
question hasn't surfaced already in other discussions about CBOR encoding?
  Additionally, since you are referencing the mapping rules from RFC
74049 I am not sure it makes sense to change those in this section.

  * Appendix A points to a simple reference implementation. That's a
good idea. What is the status of it?

I prefer that these TODOs are added to the issue tracker, if they are
still valid.

One additional remark: The document uses the term 'Information Model'
and I wonder whether you would call CDDL an information modelling
language. I prefer graphical representations, such as an UML class
diagram or an entity relationship diagram since you are less likely to
generate code form these simple structures.

Since you brought CDDL again into the picture there is the obvious
question about the status of CDDL. The structure described here is
really simple and hence there is the question whether CDDL is needed at
all.

Ciao
Hannes

---

From: Michael Koster <[email-masked]>
Date: Wed, 30 Mar 2016 10:55:28 -0700

The default media type for links in CoRE is CoRE Link-format (RFC6690), which is not the same as text/plain. There is a fairly simple state machine parser which is not so different from processing other serializations. FWIW, I process link-format into a map (or right into triples), which is how the JSON and CBOR representations work.

I believe that offering CoRE link-format in JSON and CBOR serializations improves the broader interoperability picture, as it will enable link-format and Resource Directory to be usable across other ecosystems that already use CoAP with JSON or CBOR formats (OCF, ZigBee clusters) and to interoperate with web tools that use JSON serializations. 

It seems to be more effective to offer multiple serializations than to try to force everyone to use one serialization. This way, we can all share a common data model and lexicon for link attributes and relations, and use common implementations of Resource Directory, helping to unify discovery. This vocabulary can be used by other discovery methods as well, e.g. URL beacons. At the same time, some ecosystems may choose to specify content formats and some of those that do so far are going for CBOR.

I think the draft should focus on the mapping and not try to go too much into optimization. JSON and CBOR are both important, CBOR for constrained "ecosystems" and JSON for ease of integration into web and enterprise based systems.

Best regards,

Michael

> On Mar 30, 2016, at 10:01 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Mar 2016 21:32:17 +0200

Hannes Tschofenig wrote:
> language. 

I certainly wouldn't.  CDDL is a language for describing data
structures, and thus belongs to the data model level.  It just so
happens that the data structures chosen in this specification to
represent RFC 6690's information model are simple enough that CDDL is
sufficient to illustrate them in a concise form.

> I prefer graphical representations, such as an UML class

Non sequitur -- can you explain the "since"?
(The section header of 2.2 is indeed somewhat misleading, because after
quickly discussing the RFC 6690 information model, it focuses on how to
map that to JSON's (and CBOR's) data model.)

> really simple and hence there is the question whether CDDL is needed at

(I think we already noticed in COSE that you don't like formal
techniques such as ABNF or CDDL that much.) Some people benefit from them.

Is it "needed"?  Formal definitions are never needed, you can do
everything in English.  The entirety of mathematical notation is just a
shortcut to make math more comprehensible to those that practice it.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Mar 2016 21:58:27 +0200

Hi Hannes,

here is a bit more detail information:

> the group communication draft instead.

I don't think there is an intention to revise RFC 7390 soon.
Of course, we could make a separate document out of this material, but
it is pretty straightforward to put it in here.  I don't really care
much either way, it just seemed expedient.

> wonder whether the attribute names actually matter that much.

With RD potentially still moving, this is a running to do.
We probably want to ship this one together with RD, at which point the
to do is done.

> is line is just a left-over from past times.

The example doesn't have an attribute that is present more than once
(array-formed on the JSON/CBOR side); it also has no attribute without a
value (true on the JSON/CBOR side).  Maybe still worth doing another
example.

> then the situation is not looking good. How strong is the support for

The early reviewers became co-authors, and there wasn't too much change
needed after that.  But we can probably dig out the names of the
previous reviewers.

> cannot see additional concerns.

Again, more like a running to do.

> 74049 I am not sure it makes sense to change those in this section.

RFC 7049 says:

   This section gives non-normative advice about converting between CBOR
   and JSON.  Implementations of converters are free to use whichever
   advice here they want.

So the question is whether something should be added here.  Input would
be useful from those who care about the RFC 7390 data structures.
(By now, we have other CBOR mappings of IP addresses, so maybe we can
simply borrow from, say, GRASP:

     ipv4-address = bytes .size 4
     ipv6-address = bytes .size 16

and combine that with an optional port number, as in

     groupaddress = [ address: ipv4-address / ipv6-address,
                      ? port: uint .size 2]

Maybe.)

> good idea. What is the status of it?

It was meant to be part of the CoAP gem, but then the maintainers of
that decided not to do link-format at all for the moment.  So it is
still not published.  Would you like to see it here?  Most of it is a
link-format parser; parsers tend to be arcane...

Grüße, Carsten