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

Carsten Bormann <cabo@tzi.org> Sun, 02 July 2017 07:23 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B7A12EB34; Sun, 2 Jul 2017 00:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAr0BWkmOKdh; Sun, 2 Jul 2017 00:23:20 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2C712EB31; Sun, 2 Jul 2017 00:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v627N4Hc014762; Sun, 2 Jul 2017 09:23:04 +0200 (CEST)
Received: from client-0239.vpn.uni-bremen.de (client-0239.vpn.uni-bremen.de [134.102.107.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x0hZ04bTDzDKrx; Sun, 2 Jul 2017 09:23:04 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <00e101d2f2fc$023b0b30$06b12190$@augustcellars.com>
Date: Sun, 02 Jul 2017 09:23:03 +0200
Cc: draft-ietf-core-links-json@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 520672983.547293-1c7a4be3246a1dc7ef4afba94b6ef9b5
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1900090-7239-4DF7-8447-C2373025DCE3@tzi.org>
References: <00e101d2f2fc$023b0b30$06b12190$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/os7L5r19tjcwdu0IYpznDnVfgsM>
Subject: Re: [core] draft-ietf-core-links-json
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Jul 2017 07:23:23 -0000

On Jul 2, 2017, at 08:25, Jim Schaad <ietf@augustcellars.com> 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