Re: [core] Pub/Sub update to use the core multipart content format

Michael Koster <> Sun, 03 March 2019 21:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD22D1200ED for <>; Sun, 3 Mar 2019 13:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E98zPPjMkEgR for <>; Sun, 3 Mar 2019 13:50:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5B1212E04D for <>; Sun, 3 Mar 2019 13:50:24 -0800 (PST)
Received: by with SMTP id j5so1513562pfa.2 for <>; Sun, 03 Mar 2019 13:50:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DE9u9C5/HNmvGEGQdeNG7d2ZNZDCK9MWhItsEEZ2LbU=; b=UJ7CoQbbR/viqvnqzvYhdKgXRNooKrLhlldInDdug4RHqwKoH2c5DOt0IfRUs7DLyo xXbKC6PgS1e75JZ8RhCNTiYIRtqeZ0/uXhYMfdpgLRHvIjREKb6bt8fEvCaUu/yQhxLS WYDQzemFwLtRkfcoTWdb+shVAUACUcxGwAbKowaHWhWOvGRiu5VCox/lHoapL5GYyltf SVwxjKd2w/1v4kpdxFbYeMQDoMSTFnQPrHoA4U4oCQYBWubCxQLj5zWf8OZykUkFkId3 kuFrY/qKzZ18ZpzajQgXnIzaMzjBr4jEFs1KuRqlvH5GSIpV00+I8rPuJA8UI/Eb4IZ3 cRNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DE9u9C5/HNmvGEGQdeNG7d2ZNZDCK9MWhItsEEZ2LbU=; b=F5d64QyQRqBXAWXmWyhpXFoSgGvVpTStifXkTdklkCmTOC1rn/5s1+t1nJyygUusOd PUe++XfUeBmjmgdt4o7v/TIiVGaPAnDe3KALRh5luV+LmIALk3Rrh4H975y66HWOPW0C WDj9A+MseImocjaaJeMDw3VsGVUrs7Um01b86ZCWxoUwnGHsuhRlkzkMMXrV5meL37a4 S21zmMMgtHo9+v3sZA0f6x+9bG+hofypNtQ5VGZaj6tgUQU4vARYDCjViiPDj3MiEk+4 yiSY9GpNan+CR0zTtufzNxPko8uUHZpsK19Cegtuk0MlMCsHAIWmIVdHYBMnxMpe2Y53 luBg==
X-Gm-Message-State: APjAAAUa1dnPDh1eBJ+rjS9XZDdcxSc0YB+WiDvoymqcAPrKkq910uk7 /+VyyTKlRKmB72+p/xIAUjU=
X-Google-Smtp-Source: APXvYqxhkgo/KoqYzsWqSzfFWeEEXJkcXetoBlBOoS69vgOxG7At1/fGMGo1F1Eg1wa+TAZ8YTnF0A==
X-Received: by 2002:a17:902:8b82:: with SMTP id ay2mr16864305plb.64.1551649824129; Sun, 03 Mar 2019 13:50:24 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id b70sm6871507pfm.6.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Mar 2019 13:50:23 -0800 (PST)
From: Michael Koster <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_651AAE21-3DB7-4B01-9809-678D6E779E9E"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 3 Mar 2019 13:50:21 -0800
In-Reply-To: <006e01d4d1f8$c30ed210$492c7630$>
Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= <>, =?utf-8?Q?Jaime_Jim=C3=A9nez?= <>,
To: Jim Schaad <>
References: <> <> <006101d4d173$036f3150$0a4d93f0$> <> <006e01d4d1f8$c30ed210$492c7630$>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [core] Pub/Sub update to use the core multipart content format
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Mar 2019 21:50:27 -0000

The http semantics for 202 Accepted might be another option. It defers processing until later.

We currently propose 2.07 to be added to signal the no-data subscription response. It could be semantically aligned with HTTP or we could have it mean exactly what we want it to mean.

A broker can always offer the multipart format as an alternate way to interact if we want to allow both. If the client sends multipart in the accept header the server could signal no data through the content format.

Could we allow the client to choose content-centric signaling through content negotiation?

Best regards,


PS Sending an empty payload might work for some formats, and in some libraries, e.g. with senml+json [] or cbor x80, but it doesn't seem reliable for all possible formats. 

> On Mar 3, 2019, at 11:39 AM, Jim Schaad <> wrote:
> If I am being honest, I would really rather it be returned as "204 (No Content)".  That is, the server successfully processed the request and there is no content to be returned as this time.