Re: [core] pubsub short-review

Christian Amsüss <christian@amsuess.com> Tue, 09 April 2019 09:45 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 72F2D1202DB; Tue, 9 Apr 2019 02:45:54 -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 Ed62-3GimJ-O; Tue, 9 Apr 2019 02:45:52 -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 42C0F120099; Tue, 9 Apr 2019 02:45:52 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 98A8B43819; Tue, 9 Apr 2019 11:45:50 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 8A6D326; Tue, 9 Apr 2019 11:45:49 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8877:7422:b795:852a]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 117CC74; Tue, 9 Apr 2019 11:45:49 +0200 (CEST)
Received: (nullmailer pid 804 invoked by uid 1000); Tue, 09 Apr 2019 09:45:40 -0000
Date: Tue, 09 Apr 2019 11:45:40 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: draft-ietf-core-coap-pubsub@ietf.org, core@ietf.org
Message-ID: <20190409094539.GB15632@hephaistos.amsuess.com>
References: <20190401161239.GC28400@hephaistos.amsuess.com> <C30CA800-40FF-4BFF-808C-49C03CA6BC90@tzi.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD"
Content-Disposition: inline
In-Reply-To: <C30CA800-40FF-4BFF-808C-49C03CA6BC90@tzi.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/qLpfKQ4ZlhwZLYw6RO8RGqoB0Eg>
Subject: Re: [core] pubsub short-review
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: Tue, 09 Apr 2019 09:45:55 -0000

Hello Carsten and pubsub authors,

> Indeed.  However, if it is the normal result of an application state
> that results in an error response, it probably is worth to point that
> out in the definition of the application.
> 
> > * The create-on-publish operation is executed using PUT, which MUST be
> >  idempotent according to RFC7252 Section 5.1. Returning 2.01 Created on
> >  first put and 2.04 Changed on the second put is not exactly
> >  idempotent.
> 
> Idempotency in a REST context is with respect to the state on the
> server, not with respect to the response code.  Trivially, doing a
> DELETE will get you a 2.02 only on the first request and a 4.04 on all
> following ones.

You're right, I missed that – implementors might still appreciate a note
that they could receive a 2.04 even if they just created the topic. In
the same vein, the 4.04 one could get on a DELETE is one of the protocol
error codes that would be worth pointing out.

Best regards
Christian

-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables