IETF Logo Mail Archive

Re: [art] Artart last call review of draft-ietf-core-links-json-07

Carsten Bormann <cabo@tzi.org> Tue, 25 April 2017 13:07 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342441200FC; Tue, 25 Apr 2017 06:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 JjSJrpLvIKPH; Tue, 25 Apr 2017 06:07:44 -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 89573127B57; Tue, 25 Apr 2017 06:07:43 -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 v3PD6pKS026446; Tue, 25 Apr 2017 15:06:51 +0200 (CEST)
Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (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 3wC3Q304RBzDHsc; Tue, 25 Apr 2017 15:06:50 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAOywMHfJpYB6u7BFVf10Gf=Nxk0E1h5iEvyVX5VeAW0UKQOSzQ@mail.gmail.com>
Date: Tue, 25 Apr 2017 15:06:48 +0200
Cc: Erik Wilde <erik.wilde@dret.net>, art@ietf.org, Mark Nottingham <mnot@mnot.net>, IETF <ietf@ietf.org>, "core@ietf.org WG" <core@ietf.org>, draft-ietf-core-links-json.all@ietf.org
X-Mao-Original-Outgoing-Id: 514818407.59117-b4ffb0b6498cf5f580cda089da02173a
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EB045F7-09FA-4EE8-844A-5AC0E3BF5C1E@tzi.org>
References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <A12A8CB3-F756-4790-806A-A67AA8CE1D78@tzi.org> <CAOywMHdqitw-uN09p11j2xkBK6TO8y3wjAWipK7vhqbTWp0T1w@mail.gmail.com> <a2350664-05a7-8909-4cf4-5b765e09f9e7@dret.net> <027F2C41-E498-4801-86E2-047771E10545@tzi.org> <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net> <B04F33DD-51C1-4545-AD59-2F1A3AF14FF6@tzi.org> <feee7d84-263a-49e4-d95e-09ab8526b703@dret.net> <CAOywMHfJpYB6u7BFVf10Gf=Nxk0E1h5iEvyVX5VeAW0UKQOSzQ@mail.gmail.com>
To: Herbert Van de Sompel <hvdsomp@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/SlbN5_o1QMIAG3MVwF2H66N33Cw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Apr 2017 13:07:51 -0000

> On Apr 25, 2017, at 14:50, Herbert Van de Sompel <hvdsomp@gmail.com> wrote:
> 
> On Tue, Apr 25, 2017 at 2:35 PM, Erik Wilde <erik.wilde@dret.net> wrote:
> hello carsten.
> 
> On 2017-04-24 14:55, Carsten Bormann wrote:
> it would be better to make sure that serializations of web links actually can represent web links and not just some of the information that they convey. that train may have left the station with RFC 6690, but maybe for the JSON and CBOR serializations that can be changed.
> Right.  Can you be more specific what you would want to see here?
> 
> two possibilities:
> 
> - to do things well it would be better to have web link serializations that cover *all* of RFC 5988 (bis). that's a hard thing to do and will take a while.
> 
> 
> As Erik previously indicated, it would be great if this could be done as part of RFC5988bis.

Yes.

But covering all of RFC 5988 is mainly hard because of the vagaries of HTTP header field encoding.
We don’t have that problem in RFC 6690, so it is easy to have RFC 6690 and links-json as a proper subset if we want to.

>  - for the RFC 6690-based variants under consideration right now, it would be helpful to very explicitly point out that they are *not* general-purpose serializations of web links, but instead inherit the limitations of the underlying spec.
> 
> 
> That would, indeed, be good. But, in case RFC5988bis would spec a (JSON) serialization, it seems to me that it would be rather helpful for the CORE community if the RFC 6690 JSON serialization would be based on it. 

I would hope so, but remember that links-json is already out there.

The RFC 6690 JSON serialization is pretty much a no-brainer, and there are no obvious ways to do things very different (well, you could choose a different name for “href”, but that would not be very bright).   CBOR adds a few bike sheds, but these can be painted in the same color with little effort.

If a superset RFC 5988 JSON serialization deviates from this (i.e., is not a proper superset), I think this would require some willful effort.
(I’m happy to be proven wrong; that’s why I was asking if any specifics are known here already.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email