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

From: "Jim Schaad" <[email-masked]>
Date: Thu, 28 Jan 2016 16:30:59 -0800

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