Subject: [core] Multicast in resource identification (was: Re: What is an end-point)

From: Peter Bigot <[email-masked]>
Date: Sun, 25 Jul 2010 13:58:29 -0500

I like using the term "service access point" instead of "end-point".  That
allows us to assess requirements and behavior by deferring to a (reasonably)
well-understood concept.

It makes sense that a service access point is in one-to-one correspondence
with scheme and authority from a URI, where authority for coap incorporates
the host and port, but not the userinfo.

My fundamental problem with end-points/SAPs is how to correlate URIs,
unicast addresses, and multicast addresses with a SAP.  At this point, I get
wrapped around the axle by a fundamental issue:

I can find no existing practice where multicast addresses are used as the
host part of a URI authority to name a resource in a REST-style interaction.

What, exactly, does it mean when the resource is an aggregate of
independent, individually addressable resources that are not guaranteed to
be identical?  For example, when I send a non-confirmable "on" command to
blue-lights.bu036.floor1, I get no response, which seems unhelpful.  If I
send it confirmable, I get back acks from the ones that turned on.  By
limiting responses for CON multicasts to those that produce a 2xx response
code, the protocol itself is preventing me from getting the most useful
information: which ones heard me but did *not* turn on.  Unless tricks are
performed, even inverting the response state wouldn't help because how do I
get the (unicast) resource names for the ones that didn't turn on?

This is not the problem domain REST and URIs were designed to support.  REST
can be made to work for CoAP when dealing with unicast resources.  I have no
mental model that tells me how to deal with resources identified by
multicast.

A quick read of the CoRE charter failed to reveal anything that requires
naming groups of resources in the way that multicast works.  If we eliminate
the use of multicast in addressing resources, I understand what an end-point
is, and can easily answer all those other questions.  Service discovery and
resource discovery are easy too.  I suspect, though, that there are a lot of
people who anticipate using CoAP in the way suggested in
draft-vanderstok-coap-bc.

I just don't see how it can work.

Peter

On Fri, Jul 23, 2010 at 9:31 AM, Kerry Lynn <[email-masked]> wrote:

> A few corrections...
>
> On Fri, Jul 23, 2010 at 10:20 AM, Kerry Lynn <[email-masked]> wrote:
> > Hi Peter,
> >
> > I'll rush in where angels fear to tread...
> > <snip>
>
> I meant "any multicast *request* to [IANA_TBD_PORT] arrives
> at the end-point."
>
> > By the proposal above, any multicast response to [IANA_TBD_PORT] arrives
> > at the end-point.  Any unicast to [IANA_TBD_PORT]  or the server's
> (optional)
> > dynamic port in the compressed UDP range arrives at the end-point.
> >
> >
> >> In an asynchronous response, is the server obliged to transmit the
> response
> >> message from the same end-point as received the original request?  Or
> could
> >> it use the asynchronous response specifically to change the end-point (a
> >> sort of implicit redirect)?
> >>
>
> And here it could be that a unicast request arrives via the [IANA_TDB_PORT]
> but the async response is sent from the dyamic port, if there is one...
>
> > By the proposal above, the server MUST accept a unicast request to
> > [IANA_TBD_PORT] and SHOULD accept a unicast request on its dynamic
> > port, if one is bound.  If the latter, then it would respond via the
> > dynamic port.
>
> >
> > Regards, -K-
> >
>