Subject: Re: [core] 🔔 Working Group Adoption of draft-koster-core-coap-pubsub

From: Michael Koster <[email-masked]>
Date: Mon, 14 Nov 2016 10:38:59 +0900

Hi Peter,

Sorry I apparently missed this email from months ago. 

Replies in line.

> On Aug 30, 2016, at 7:34 PM, peter van der Stok <[email-masked]> wrote:
> 
> Hi Michael,
> 
> I do support the draft, but have some questions after a first reading.
> 
> section 4 before 4.1; the operations are the functions?

We intended to remove all of the "function set" references. This one will be removed as well. 
> 
> In the discover section 4.1 the base location /ps is nowhere returned, only in the example this becomes clear.
> Is this base /ps compulsory?
> In the resource directory the base location is returned and the value /rd is recommended.
> Would it not be better to recommend the value /ps here as well?

Yes, as per the above statement

> Does the resource type core.ps need to be declared to IANA?
> 
         ps :=   pubsub Function Set path (optional).  The path of the
         pubsub Function Set, as obtained from discovery, used to
         discover topics.
Apparently this is not clear. 

It is meant to work exactly the same as in RD. 

I will rewrite this and make it read like the equivalent section in RD.

Also:
9.  IANA Considerations

   This document registers one attribute value in the Resource Type
   (rt=) registry established with [RFC6690] and appends to the
   definition of one CoAP Response Code in the CoRE Parameters Registry.

9.1.  Resource Type value 'core.ps'

   o  Attribute Value: core.ps

   o  Description: Section 4 of [[This document]]

   o  Reference: [[This document]]

   o  Notes: None
It's there in the draft...

> The concept of "link to it's pubsub function set" is a bit complex for me; why not write /.well-known/core and /ps
> Otherwise I recommend to introduce the "link to the pubsub function set" in section 2.
> 

It's the same as RD. I guess the "function set" thing is whats confusing? we will remove it.

Thanks for pointing this out

> In section 4.2 Create.
> If I understand correctly, "CREATE" <topic> creates a resource at the broker with path name /ps/topic
> Why not describe it like that?
> 
OK, we can be more clear about topics being resources.
 
> I do have problems with understanding what the value of the created resource is.
> Is that a list of messages, or is that a set of named values described in the messages.
> That is important to understand the most recent published value of a topic.
> The content format of a the messages belonging to a topic is specified, but its contents is free.
> 
> Suppose a topic uses content formats application/json and application/merge-patch+json
> 
> Suppose two messages arrive at the broker
> First message: application/json with {"name" : "topic1", "value" : 10}
> Second message: application/merge-patch+json with {"name" : "topic2"}
> 
> 
> The content of the  last message to subscribers is clear; but what does the READ return; Should that be {"name" : "topic2", "value" : 10}
> or {"name" : "topic2"}, or both messages?
> 
> The answer is important with respect to section 6.
> 
> My personal preference is that the value of a pubsub resource is a set of messages.
> 
Thanks for asking this; it's a key clarification point!

The client MUST indicate the
   desired content format for publishes to the topic by using the ct
   (Content Format) link attribute in the link-format payload.

This should be clarified. How about this:

- A topic may support more than one content format. The statement above needs to allow repeating the "ct" link attribute for multiple values.

- The content of a topic resource on a pubsub broker is a list of payloads and their published content formats. 

- The outgoing message is formatted according to the subscription request, which is an CoAP Observe. 

- A client may subscribe using fetch, and may use query parameters to filter notifications by content format.

- The subscription request (CoAP Observe) may indicate which content format it will accept, and the broker (CoAP Server) is expected to comply.

- If a client wishes to receive more than one content format, it must indicate this in the accept header.

- Payloads using a content format not accepted by the client must not be sent to the client.

Thanks for pointing these out, and sorry again for the missed response the first time.

Best regards,

Michael

---

From: peter van der Stok <[email-masked]>
Date: Mon, 14 Nov 2016 05:22:54 +0100

Hi Michael,

I don't have questions any more, and I think we can update the sleepy 
node draft with use of pubsub.

thanks,

Greetings,

Peter
> - A topic may support more than one content format. The statement
> above needs to allow repeating the "ct" link attribute for multiple
> values.
> 
> - The content of a topic resource on a pubsub broker is a list of
> payloads and their published content formats.
> 
> - The subscription request (CoAP Observe) may indicate which content
> format it will accept, and the broker (CoAP Server) is expected to
> comply.
>