Re: [core] draft-bormann-core-links-json: call for adoption

Carsten Bormann <cabo@tzi.org> Wed, 22 May 2013 07:13 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 B938421F9339 for <core@ietfa.amsl.com>; Wed, 22 May 2013 00:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.042
X-Spam-Level:
X-Spam-Status: No, score=-105.042 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWJg6nxb9bPq for <core@ietfa.amsl.com>; Wed, 22 May 2013 00:13:37 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 978FC21F9232 for <core@ietf.org>; Wed, 22 May 2013 00:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4M7DM2a027734; Wed, 22 May 2013 09:13:22 +0200 (CEST)
Received: from [192.168.217.105] (p54892E88.dip0.t-ipconnect.de [84.137.46.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 43DF2335F; Wed, 22 May 2013 09:13:22 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset="gb18030"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D762C0F@szxeml558-mbx.china.huawei.com>
Date: Wed, 22 May 2013 09:13:21 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A071C7EE-C6A2-408B-9D21-1F7BF0026AF6@tzi.org>
References: <CAPRuP3mzM07-LY1c1on7iRa+dGiaSeRw-U8NGNobAM0U0DqqPg@mail.gmail.com> <D60519DB022FFA48974A25955FFEC08C0515CDFC@SAM.InterDigital.com> <46A1DF3F04371240B504290A071B4DB63D762C0F@szxeml558-mbx.china.huawei.com>
To: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
X-Mailer: Apple Mail (2.1503)
Cc: "core@ietf.org" <core@ietf.org>
Subject: Re: [core] draft-bormann-core-links-json: call for adoption
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 22 May 2013 07:13:43 -0000

On May 22, 2013, at 08:28, Bert Greevenbosch <Bert.Greevenbosch@huawei.com> wrote:

> +1
>  
> Not sure if I agree with the fact that it is only suitable outside the constraint environment though; the JSON variant seems easy enough to parse. How to avoid IOP trouble due to two endpoints using the different formats?

I'd say: stick with RFC 6690 in the constrained environment...

>  Some things for consideration:
> - Change ".well-known/core" to ".well-known/jlink" or something?

Again, I don't argue for moving over the constrained nodes to JSON links.

> - Register new mime type?

Yep:    application/link-format+json
(Section 3; the IANA boilerplate has to filled in, next).

> - Does this allow multivalue attributes, e.g. through arrays? Definitely possible in JSON, but it would break easy conversion to the conventional link format.

Yes, it does (and no, it wouldn't break link-format or RFC 5988):

   If a Link attribute ("parmname") is present more than once in a
   "link-value", its values are then represented as a JSON array of JSON
   string values; this array becomes the value of the JSON name/value
   pair where the attribute name is the JSON name. 

(Section 2).

> - In JCARD, we started with a similar construction. However we later changed to a construction of {"name", "parameter", "type", "value"} to allow more flexibility and signalling, especially concerning the type (e.g. string or integer) of the value.

I think the jcardcal format is constrained by the need to do round-tripping into the legacy format, so you want to make the type information explicit.
I'm not sure we have the same considerations here.
(Also, since link-format attributes are RFC 5988 attributes and thus always string values, we follow this by even handling "ct" as a string:

   [{"href":"/sensors","ct":"40","title":"Sensor Index"},{"href":"/
   sensors/temp","rt":"temperature-c","if":"sensor"},{"href":"/sensors/
   light","rt":"light-lux","if":"sensor"},{"href":"http://
   www.example.com/sensors/t123","anchor":"/sensors/
   temp","rel":"describedby"},{"href":"/t","anchor":"/sensors/
   temp","rel":"alternate"}]
)

Grüße, Carsten