Re: [core] Sketch of "Keep it simple" / "Never reified union types"

Christian Amsüss <christian@amsuess.com> Thu, 21 March 2019 07:47 UTC

Return-Path: <christian@amsuess.com>
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 5C6F1130F3E for <core@ietfa.amsl.com>; Thu, 21 Mar 2019 00:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HtbaufJiubuF for <core@ietfa.amsl.com>; Thu, 21 Mar 2019 00:47:16 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5028130F39 for <core@ietf.org>; Thu, 21 Mar 2019 00:47:15 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 54BA941923; Thu, 21 Mar 2019 08:47:13 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1C28336; Thu, 21 Mar 2019 08:47:11 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:9568:5ff3:9971:c700]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 5207B17B; Thu, 21 Mar 2019 08:47:11 +0100 (CET)
Received: (nullmailer pid 8381 invoked by uid 1000); Thu, 21 Mar 2019 07:47:10 -0000
Date: Thu, 21 Mar 2019 08:47:10 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Michael Koster <michaeljohnkoster@gmail.com>
Cc: core WG <core@ietf.org>
Message-ID: <20190321074710.GB28481@hephaistos.amsuess.com>
References: <20190308134459.GA7720@hephaistos.amsuess.com> <162F3D30-6DF8-4A73-A018-94CD511EB2F1@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB"
Content-Disposition: inline
In-Reply-To: <162F3D30-6DF8-4A73-A018-94CD511EB2F1@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ebyK9Q1Gb-InlFg9LJm9h4v4vMw>
Subject: Re: [core] Sketch of "Keep it simple" / "Never reified union types"
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: Thu, 21 Mar 2019 07:47:19 -0000

Hello Michael and CoRE,

On Mon, Mar 11, 2019 at 08:23:23AM -0700, Michael Koster wrote:
> In the spirit of handling "empty topic" case in the application layer,
> as we discussed, I propose to have the publisher be responsible to
> publish "nothing-here-to-see" as a topic's initial value if it has no
> initial value in the more meaningful content format. 
> 
> (Keeping in mind that, as defined, CoAP pub/sub only handles
> representations, and is not strictly a proxy for resource state,
> therefore should not be responsible for generating default
> representations in any particular content format, except the required
> link-format in the case of create-on-publish).
> 
> The pub-sub behavior would be to reply to READ/SUBSCRIBE only when
> something has been published. The topic creator is thus responsible to
> "promptly" publish nothing-here-to-see upon topic creation. Otherwise
> the broker simply acks any READ/SUBSCRIBE request and waits to send a
> response until something is published. 

That would mean that any faulty (or malicious) topic creator could force
the broker into (costly-to-maintain in terms of memory) long-poll
situations, I'd prefer not to do that. (An alternative would be that the
broker answers 5.03 "I'm not in a state to process this request, retry
later please" with some Max-Age).


My gut feeling is that the broker can be argued to be the authority on
the topic (at least formally it is) and would thus be justified to say
that "empty" is its current representation, but I'll need to read the
latest version of pubsub to argue that well (or be taught better).

> This way, the Accept-Any option and the nothing-here-to-see content
> formats may be defined in separate independent drafts, and the
> multipart format may be used with its potential accept-subformat
> options.

I agree that Accept-Any can (and probably should) be separate.

Kind regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom