[core] Review comments on draft-ietf-core-coap-pubsub-05

Jim Schaad <ietf@augustcellars.com> Sun, 22 July 2018 20:12 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 92663120049; Sun, 22 Jul 2018 13:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jxYCIzKdPD5d; Sun, 22 Jul 2018 13:12:04 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EABD130EC6; Sun, 22 Jul 2018 13:12:04 -0700 (PDT)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sun, 22 Jul 2018 13:08:27 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-ietf-core-coap-pubsub@ietf.org>
CC: 'Core' <core@ietf.org>
Date: Sun, 22 Jul 2018 13:11:57 -0700
Message-ID: <00f901d421f8$3f6310d0$be293270$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdQh01bZVq4NgnJpThmQICdlENWX5w==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/s8ws2k6QoLoggHBzcwES9fHeB0M>
Subject: [core] Review comments on draft-ietf-core-coap-pubsub-05
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
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: Sun, 22 Jul 2018 20:12:07 -0000

1.  Welcome to the world of how CoAP defined resolving of URIs.   RFC 6690
either did not do a good job of explaining things or got them wrong.  There
is a special case for /.well-known/core in terms of how the resolution of
links are done.  As I understand things if you do this

GET /ps?rt="temperature"

And get back in the content


When you ask for the resource you will look in the following address

GET /ps/ps/currentTemp

This is because the URI is resolved against the origin of the target URI and
not against just the authority part of the target URI.  Note that this is
the case for /.well-known/core.  

I don't know how you want to address this.  I am not sure that anybody has
actually implemented what the RFC says, but I also don't know if anything
other than /.well-known/core and the RD have used this feature.  RD "gave
up" and said that everything returned is going be resolved by the RD before
sending it back.

2.  It is well defined that one can not create a multiple level new topic
using POST to a topic.  It is not clear if one is allowed to have more than
one item in the link format description for a CREATE operation.

POST /ps/ "<topic1>;ct=50,<topic2>;ct=40"

3.  In section 4.3 in the discussion of garbage collection.  If the broker
does not retain the most recently published value, what is the correct
response to return in a subscribe/read request?  Is this to be treated as if
the Max-Age had been exceeded?

These are just from reading the document.  I have not yet gotten to the
point of trying to update my implementation.