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

[Jim Schaad]

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

[Carsten Bormann]

Post by Jim Schaad
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
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).

Post by Jim Schaad
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

[Carsten Bormann]

Post by Carsten Bormann
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

[Jim Schaad]

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Sunday, July 2, 2017 12:23 AM
To: Jim Schaad <***@augustcellars.com>
Cc: draft-ietf-core-links-***@ietf.org; ***@ietf.org
Subject: Re: [core] draft-ietf-core-links-json

Post by Jim Schaad
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
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).

[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".

Post by Jim Schaad
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

[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


? 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