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

From: Jim Schaad <[email-masked]>
Date: Sat, 1 Jul 2017 23:25:30 -0700

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.

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.

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 2 Jul 2017 09:23:03 +0200

> 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).

> Booleans mixed together.  That seems to be a strange source and I don't know

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

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 2 Jul 2017 10:09:23 +0200

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

Fixed in:

https://svn.tools.ietf.org/svn/wg/core

Specifically

https://svn.tools.ietf.org/svn/wg/core/link-format.rb

and the formatted result:

https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-links-json-xx.txt

(No change needed for this to the markdown sources, which are also there.)

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Sun, 2 Jul 2017 11:39:17 -0700

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Sunday, July 2, 2017 12:23 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [core] draft-ietf-core-links-json

On Jul 2, 2017, at 08:25, Jim Schaad <[email-masked]> 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.

foo=3

[JLS] If it looks like a duck....   

I would probably have expected to see the statement about the conversions in section 2.2 on the information model and not appended to the end of an example section.  Yes I did see the text and that was part of why I was looking for a rational.  

I don't need one, it is just a "nice to have".

> 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

[JLS] I would probably say that this is invalid and scream bloody murder.   I had thought of this case and decided that it was bloody stupid and I did not care if it was supported or not.  That said, I was just verifying author intent so it is not a  problem for me.

Jim

[
  {

Grüße, Carsten