Re: [core] Review of draft-ietf-core-coap-pubsub-06

[Jim Schaad <[e-mail]>]

Hurrah - there is a new draft (actually apparently two since this review)

I have trimmed out items that I am not responding to.  That does not mean
that all of the other items don't need to be responded to, just that I am
not doing it now.


> -----Original Message-----
> From: Michael Koster <[e-mail]>
> Sent: Tuesday, March 12, 2019 7:40 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: Review of draft-ietf-core-coap-pubsub-06
> 
> Hi Jim,
> 
> Thanks for the review! You hit a lot of the squishy bits
> 
> Sorry for the delay in processing.
> 
> We incorporated some items in the current draft, others we will need to
> discussin the WG.
> 
> > On Jan 9, 2019, at 4:21 PM, Jim Schaad <[e-mail]> wrote:
> >
> > Here is a more detailed review of this document:
> >
> 
> > 6. Section 4.1 - The definition of 'ps' implies that topics can be
> > rooted at / rather than at /ps.  While I don't have a problem with
> > this I think that by saying that it 'ps' is optional seems to be
> > slightly odd.  It would make more sense to me to say that '{ps}' is
> > not optional but can be the equivalent of '/.' The assumption in this
> > case is that what would be returned by .w-k/core would be
> > '</>;rt=core.ps;ct=40' rather than '<>' as the refpath.
> >
> Yes, that's what we want. We probably misunderstand URI template syntax. I
> think we confuse "ps" as a template variable vs. "ps" as a path segment
> string.
> Are there any specific suggestions for how we could reorganize this?

I think it was my understanding that was wrong at the time.  This matches
what is done for RD so it seems to be ok.


> > 10.  Section 4.2/3  You should think about what happens if I use a
> > multipart content for publishing.  This would allow for publishing
> > multiple content types at the same time which might be an interesting
> > feature.  This allows for multiple content types w/o the broker having
> > to do the content conversions.
> >
> I think pub/sub will work with multipart content format as long as the
broker
> can treat the published payloads as opaque. What are some potential
issues?

I think that this can be done in some type of extension.  I was thinking in
terms of the publisher using the multipart content format to say:

Here are 5 different representations of the same information.  The PS broker
can say that any of the 5 different representations are available for
retrieval.   This allows for "content conversions" to be done at the
publisher rather than at the broker.  However, yes there are going to be
cases where this breakup of the multipart must not be done by the PS server.

> > 12. Section 5 - I think you need to re-write the text dealing with con
> > as this does not appear to be in the RD any more.
> >
> Con as in CON/NON? We do have a bit where we say that a READ or
> SUBSCRIBE maybe ack'ed and queued waiting for first publish.

A client which
   registers pub/sub Topics with an RD MUST use the context relation
   (con) [I-D.ietf-core-resource-directory] to indicate that the context
   of the registered links is the pub/sub Broker.

This is what I was referring to.

Jim

> 
>