Subject: Re: [core] I-D Action: draft-ietf-core-links-json-01.txt

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Sep 2014 06:33:26 +0200

On 08 Aug 2014, at 09:20, Likepeng <[email-masked]> wrote:

> Hi Carsten,
> 
> In section 2.1 "examples", the original link is ct=40, 40 is an integer.
> </sensors>;ct=40;title="Sensor Index",
> 
> But after conversion to JSON, it becomes "40", which is a string. 
> {"href":"/sensors", "ct":"40","title":"Sensor Index"}
> 
> I use cbor.me to convert the JSON example to CBOR, it also becomes "text string"
>      62                                # text(2)
>         3430                           # "40"
> 
> I think it should be kept as integer for JSON and CBOR.

Hi Kepeng,

this message fell through the cracks before I went on vacation.  Sorry about that.

I need to add text to links-json motivating why ct is, like all other attributes, kept as a string.
(We have had this discussion before, but I don’t know an efficient way to look it up right now.)

The reason links-json keeps all attributes as strings is that link-format does not have data types.
There is no way for a link-format to link-json translator to know which attributes are meant to be a number.
While this could be hardwired for ct, other attributes would not benefit from this.
Detecting number-form values and converting them would be possible, but that creates round-tripping issues (foo=0123 would become foo=123 after a roundtrip) and questions about range/precision (see the I-JSON discussion in the JSON WG); it is also not clear how an implementation would react to, say, if=123 if that is suddenly encoded as a number.

So the last time this discussion came up, we decided to take the small hit and represent ct as a string like all other attributes.

Grüße, Carsten