IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Mon, 24 April 2017 12:56 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF137128959; Mon, 24 Apr 2017 05:56:50 -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 7vQKb_6jzFps; Mon, 24 Apr 2017 05:56:49 -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 7B40E131448; Mon, 24 Apr 2017 05:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v3OCtv8U024072; Mon, 24 Apr 2017 14:55:57 +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 3wBRCx27SHzDHKw; Mon, 24 Apr 2017 14:55:57 +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: <4cd01462-2a0f-803e-df10-e68b3eed0226@dret.net>
Date: Mon, 24 Apr 2017 14:55:56 +0200
Cc: Herbert Van de Sompel <hvdsomp@gmail.com>, art@ietf.org, Mark Nottingham <mnot@mnot.net>, ietf@ietf.org, "core@ietf.org WG" <core@ietf.org>, draft-ietf-core-links-json.all@ietf.org
X-Mao-Original-Outgoing-Id: 514731356.639242-36f7ee4bca0d5a83208bda5fa5f40929
Content-Transfer-Encoding: quoted-printable
Message-Id: <B04F33DD-51C1-4545-AD59-2F1A3AF14FF6@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>
To: Erik Wilde <erik.wilde@dret.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/Hj0kP6gNN-ZpCvOSSJkuwNmSv3w>
Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2017 12:56:51 -0000

On Apr 24, 2017, at 14:48, Erik Wilde <erik.wilde@dret.net> wrote:
> 
> On 2017-04-24 13:52, Carsten Bormann wrote:
>> On Apr 24, 2017, at 10:49, Erik Wilde <erik.wilde@dret.net> wrote:
>>> - consider adding a serialization of web links to RFC 5988bis. this would address the problem of how to serialize web links outside of the HTTP link header field.
>> Sounds good to me.
>> What needs to be done to make sure links-json is a proper subset of this?
> 
> hard to tell as "this" is just speculation at this point. generally speaking, i don't think it's such a great idea to piggyback on standards and then reduce their expressiveness. imho that's one of the well-known anti-patterns of interop: (extended) subsets.
> 
> but if you're shooting for a subset i think that's where you are right now.
> 
> 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?

Grüße, Carsten

v2.23.0 | Report a Bug | By Email