IETF Logo Mail Archive

Re: [core] Report on first Resource Directory plugtest

Carsten Bormann <cabo@tzi.org> Fri, 13 April 2018 07:14 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 85BD7127337 for <core@ietfa.amsl.com>; Fri, 13 Apr 2018 00:14:35 -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 GmlCgLnKCEPu for <core@ietfa.amsl.com>; Fri, 13 Apr 2018 00:14:32 -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 12EC212711A for <core@ietf.org>; Fri, 13 Apr 2018 00:14:31 -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 w3D7ESvv008505; Fri, 13 Apr 2018 09:14:28 +0200 (CEST)
Received: from [192.168.217.102] (p5DC7FA72.dip0.t-ipconnect.de [93.199.250.114]) (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 40MptX3n9mzDXCs; Fri, 13 Apr 2018 09:14:28 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20180412211159.GB20765@hephaistos.amsuess.com>
Date: Fri, 13 Apr 2018 09:14:27 +0200
Cc: Core WG mailing list <core@ietf.org>
X-Mao-Original-Outgoing-Id: 545296465.678485-ac7f197246017cc4be57bb369d0c4de1
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D3CBCEA-C563-4B55-B018-C134B3F023B4@tzi.org>
References: <20180322144452.GA13008@hephaistos.amsuess.com> <20180322150452.GA17015@hephaistos.amsuess.com> <20180403082122.GA30478@hephaistos.amsuess.com> <20180411103951.GC14388@hephaistos.amsuess.com> <20180412211159.GB20765@hephaistos.amsuess.com>
To: Christian Amsüss <christian@amsuess.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/eWdnXqd2jWb2LxtVS136xrqSjfM>
Subject: Re: [core] Report on first Resource Directory plugtest
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: Fri, 13 Apr 2018 07:14:36 -0000

Hi Christian,

this is great input.  Let me pick out two items here:

>  * Can there be a Location-Query option in a registration response?
>    (Probably not, we just didn’t say that.)

Why not?
(Sorry, I missed out on responding to Jim’s earlier message on this.
I’m trying to find out why we need to restrict the server’s flexibility in choosing the URI here.
Maybe there is a good reason, I’d just like it to be more explicitly stated.)

> Ceterum censeo RFC6690 esse revidendam.

Well, the general feeling was that instead of going for a 6690bis, we maybe want to let the link-format just fade out (In favor of links-json/-cbor).

>  * Production and parsing of invalid RFC6690 (which link attributes
>    need to be quoted, 

Right.  I think we really should be following RFC 8288 here and asking implementations to be robust to the misguided “this attribute needs to be quoted” decisions we made in RFC 6690.

Maybe we can put a few updates to 6690 in links-json?

Grüße, Carsten

v2.23.0 | Report a Bug | By Email