[core] draft-koster-core-coap-pubsub

"Jim Schaad" <ietf@augustcellars.com> Fri, 29 January 2016 00:33 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9D91B2DDF for <core@ietfa.amsl.com>; Thu, 28 Jan 2016 16:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.907
X-Spam-Level: *
X-Spam-Status: No, score=1.907 tagged_above=-999 required=5 tests=[BAYES_50=0.8, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 Ld5tdGZQaDlQ for <core@ietfa.amsl.com>; Thu, 28 Jan 2016 16:33:35 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094361B2DC1 for <core@ietf.org>; Thu, 28 Jan 2016 16:33:34 -0800 (PST)
Received: from hebrews (unknown [12.40.199.14]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 665C638EA5; Thu, 28 Jan 2016 16:33:34 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: draft-koster-core-coap-pubsub@tools.ietf.org
Date: Thu, 28 Jan 2016 16:30:59 -0800
Message-ID: <064601d15a2c$53b55a70$fb200f50$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AdFaKo5GkgS+N5BaRh2j2/IE/FPReA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/oWvrY6-Hy7BMYQmTtwIbbZRtG3E>
Cc: core@ietf.org
Subject: [core] draft-koster-core-coap-pubsub
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 29 Jan 2016 00:33:36 -0000

This draft came to my attention at the last F2F meeting.  In thinking about
it at the time and since then I have come up with a desire to have some
additional functionality applied to it.  I am unsure what is the best way to
proceed on this.

Consider the case of having two different types of messages coming on a
stream.  The simple case would be a rebase message and a delta value
message.  One cannot understand the delta value message without having
received and processed the rebase message.  If the sense emits <rebase>,
series of deltas, <rebase> series of deltas.  The series of deltas does
necessarily need to be delivered to the client.  But the last rebase message
must be delivered to the client.

The actual case that I am looking at is a message security scenario.  Two
types of messages are sent over the data stream.  The first are going to be
regular encrypted messages that have the least possible amount of overhead.
The second type of messages are going to send some additional context
information when any of a number of changes are made to the security state.
These would include a re-key event, an ACL change event (requiring going
back to an access server for a new base key), or events relating to dealing
with multicast responses back to the resource server.

I have come up with two easy ways to look at this:

1.  There is a single stream with multiple messages.  Some of which are
marked as confirmable (and thus must be delivered) and some of which are
not.  This involves logic on the subscription server to keep all of the
confirmable messages for all of the active subscriptions until they have
been confirmed back but only the last non-confirmed message.  They are then
delivered in order.

2.  We create multiple related streams each of which only has the last
message of each type in it.  When one subscribes to the main feed, one is
automatically subscribed to the related feeds.  The problem with this
solution is that synchronization is not present between the two streams so
that some type of sync state in messages might be required as well.

Does this ring any bells in people's heads as something that needs to be
done or am I in limbo.

Jim