Re: [core] draft-ietf-core-links-json

[Carsten Bormann <[e-mail]>]

On Jul 2, 2017, at 08:25, Jim Schaad <[e-mail]> wrote:
> 
> While I realize this document is with the IESG, I was trying to work on my
> link format implementation so I decided to read this document to see if I
> could get it implemented for CBOR at the same time.  While doing this I came
> up with the following:
> 
> 1.  I believe that it would be worthwhile to say why the decision not to
> encode items which match the "Cardinal" rule are not using the CBOR integer
> types.  If I made a guess I would guess it is because JSON does not handle
> integers correctly but I do not know that for a fact.  If this was used then
> the encoding would be smaller.

Well, we do say:


Note that the conversion is unable to convert the string-valued "ct"
attribute to a number, which would be the natural type for a
Content-Format value; similarly, both "foo" values are treated as
strings independently of whether they are quoted or numeric in syntax.


We do not quite say a lot about why.  RFC 6690 core-link does not have type information, and we don’t know whether

foo=3

means that foo is the number 3 or that foo is a text string that happens to byte wise the same as the string representation of the number 3.  So all items are represented as text strings (or true, if there is no value given).

> 2.  I would like to verify that the following was intended.  In the CDDL,
> value appears to be able to support an array that contains both strings and
> Booleans mixed together.  That seems to be a strange source and I don't know
> it is real.

How do you encode

<http://example.com>;foo=1;foo;foo;foo=“Wirtshaus”;foo

?  The reference implementation says:

[
  {
    "href": "http://example.com",
    "foo": [
      "1",
      true,
      true,
      "Wirtshaus",
      true
    ]
  }
]

But I note that the reference implementation doesn’t correctly handle the conversion back to link-format, so we’ll need to fix this.

Grüße, Carsten