Re: [core] [T2TRG] CoRE Applications side-meeting @IETF105

Klaus Hartke <hartke@projectcool.de> Mon, 22 July 2019 18:12 UTC

Return-Path: <hartke@projectcool.de>
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 18A4A1200E3 for <core@ietfa.amsl.com>; Mon, 22 Jul 2019 11:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 hXFUFhWD6tpu for <core@ietfa.amsl.com>; Mon, 22 Jul 2019 11:12:40 -0700 (PDT)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E48F120089 for <core@ietf.org>; Mon, 22 Jul 2019 11:12:39 -0700 (PDT)
Received: from mail-qk1-f169.google.com ([209.85.222.169]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hpcnd-0004yk-AW; Mon, 22 Jul 2019 20:12:37 +0200
Received: by mail-qk1-f169.google.com with SMTP id 201so29221353qkm.9 for <core@ietf.org>; Mon, 22 Jul 2019 11:12:37 -0700 (PDT)
X-Gm-Message-State: APjAAAXMXcEuvlRgNG1ikGCUht/0fmyTlEKVM1wE71YyU6pT3ohIf7pk Ln4pqE2cyExIARvqSH/E0EIk7SHwaqPIIFvjUGI=
X-Google-Smtp-Source: APXvYqxG2t8cEYUbtizCKHWMn85Px7ZHqxghmE1qij/SoWw5siVepKxCD1tuoWqtRAidSGmvYdGxnBlMYbexgwRfoMo=
X-Received: by 2002:a37:a346:: with SMTP id m67mr48713033qke.237.1563819156268; Mon, 22 Jul 2019 11:12:36 -0700 (PDT)
MIME-Version: 1.0
References: <HE1PR0701MB21555202129B40E8AAE41F50E6C40@HE1PR0701MB2155.eurprd07.prod.outlook.com> <B672A46D-F18C-49E7-9163-8DBBF289DDE0@tzi.org>
In-Reply-To: <B672A46D-F18C-49E7-9163-8DBBF289DDE0@tzi.org>
From: Klaus Hartke <hartke@projectcool.de>
Date: Mon, 22 Jul 2019 20:11:58 +0200
X-Gmail-Original-Message-ID: <CAAzbHvZaXEKM8ao2Di1C5UD9gKS-dGP6o8C7Wa7XMTQmPgunTQ@mail.gmail.com>
Message-ID: <CAAzbHvZaXEKM8ao2Di1C5UD9gKS-dGP6o8C7Wa7XMTQmPgunTQ@mail.gmail.com>
To: "core@ietf.org" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1563819160; ce220df0;
X-HE-SMSGID: 1hpcnd-0004yk-AW
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/WtjgJVKEBVAPVhVi3uU9SMeCsZc>
Subject: Re: [core] [T2TRG] CoRE Applications side-meeting @IETF105
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 22 Jul 2019 18:12:44 -0000

(trimming the cc list a bit...)

Carsten Bormann wrote:
> Here are a couple of comments I haven’t made yet to the mailing lists:
>
> (1) A subscriber that is waiting for the first Data should observe the info object? An example might help.

>From the point of view of a subscriber, the idea is that setting up a
topic is a two-step process: First, the topic configuration has to be
set up, and then the topic data resource has to be created by
publishing the first item. While only the first step has been
performed, the topic doesn't exist to a subscriber. Topic creators can
expedite the creation of the data resource by publishing the first
item themselves.

> (2) So the data link had to be there from the outset (with a 404) so the publisher can PUT to it? But then it's not a 404, but a 405.

A link can reference a resource that doesn't exist (yet) [1]. I think
it's simpler to say that the topic data resource doesn't exist until
the first item has been published, rather than that the resource
exists but doesn't support GET. But I don't have a strong opinion on
this...

Klaus

[1] " A resource can map to the empty set, which allows references to
be made to a concept before any realization of that concept exists"
<https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>