Subject: [core] What is an end-point (was: URI splitting (was: Re: explicit option for URI query part))

From: Peter Bigot <[email-masked]>
Date: Tue, 20 Jul 2010 13:37:43 -0500

OK, we've moved to a question I'd avoided, so I've changed the subject for
this thread.  To wit, what is an end-point?  And, once we figure that out,
how does end-point relate to a URI-reference that identifies a resource at
that end-point?

Section 2.1 of coap-01 states:

   ...Machine-to-machine interactions typically result in a CoAP
   implementation acting in both client and server roles (called an
   end-point).

The plural "roles" and singular particle "an" make this text imprecise.  Are
the two roles considered distinct end-points?  Or is the single
implementation one end-point with both roles?

If an implementation accepts messages on multiple interfaces or ports, is
each a separate end-point?  For example, when monitoring multiple UDP
sockets, one bound to the (TBD) IANA registered COAP port and another bound
to a port in the RFC4944-specified (private) compressed UDP port space.
Text in section 4.4 implies these are distinct end-points.

What about multicast?  A received multicast message has to be delivered to
an end-point, right?  For the end-point to send ACKs over UDP, it has to be
bound to a non-multicast address (unless it's supposed to multicast the
ACKs, which seems wrong).  Is that end-point required to accept messages
addressed to its non-multicast address?  Or is it that ACKs and RSTs should
not be considered as coming from an end-point, even though they're generated
in response to a message received by an 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)?

My conclusion had been:

- Each end-point is bound to exactly one non-multicast (i.e., unicast or
link-local) IP address and port.

- Each end-point can additionally receive messages on zero or more multicast
addresses and ports.

- A transaction response message must be sent from the unicast or link-local
IP address and port associated with the end-point that received the
transaction request.

 > Then the reconstructed URI is different on each recipient.  That would
> introduce an issue with recognizing an asynchronous response.
>
> Not so sure about that.  If f::0:0 tells me their /bar is 14, that may be
> exactly what I want to know.
>

>From your comment, it appears that a resource identified by a multicast
address continues to be identified by multicast.  I can see that use, though
it wasn't the first that came to mind.

I had assumed that I would send a GET request for a URI with an unspecified
authority to a multicast address in order to identify the end-points to
which I could subsequently send direct requests.  For that use, I would
either have to be able to examine the envelope information (the address
provided via recvfrom(2)), or assume I could reconstruct the resource URI at
the responding end-point from option headers.

For example, I think this is how I would have to do resource discovery with
a URI like "/.well-known/r?name=temperature": multicast it to all-hosts,
then somehow extract from the responses the addresses of the end-points that
can provide temperatures.  How do I do that extraction?

All this is assuming end-points are defined by one or more UDP
"end-point"s.  Angelo Castellani suggested on 31 May that end-point in REST
referred to something that retained state, so a resource to which a
subscription existed necessitated creation of a new end-point that held the
knowledge of that subscription.

> I propose making Uri-Authority have no default, rather than an empty
> string default: an empty string doesn't conform to the ABNF for authority in
> section 3.2 of RFC3986.
>
> Really?  Page 18:
>

Hah.  Once, just once, I decide to wing it and get work done instead of
tracing the references all the way back to Genesis, and I get bit.  You're
absolutely right; I was mis-generalizing from the http scheme.

I still think it's worth being able to distinguish a missing authority from
an empty one, though, so we can precisely recreate the text of the original
URI without assuming the specific scheme treats them as equivalent.

Peter

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 23 Jul 2010 10:20:02 -0400

Hi Peter,

I'll rush in where angels fear to tread...

> implementation one end-point with both roles?
My interpretation (in the absence of greater specificity) is that an "end-point"
is what might be termed a "service access point" in other context.  That is,
an end-point is a triple consisting of: a host (in the RFC 3986 sense), plus a
(possibly default) port, plus a protocol (CoAP).  I imagine there is a single
CoAP instance per host, which can (and does) operate in peer-to-peer mode.
This view is supported by the following text in section 6 of the CoAP draft:

   CoAP makes the assumption that all CoAP servers host an end-point
   on the default CoAP port (see Section 4.4) hosting a well-known
   discovery resource, or otherwise have been configured or discovered
   using some general service discovery mechanism such as
   [I-D.cheshire-dnsext-dns-sd].

This language might be interpreted to mean that several CoAP servers
could be demux'd through a single end-point (as in the case of a proxy).
OTOH, the meaning might be that EACH server hosts an end-point on
the default CoAP port, which would imply one server per host.

In draft-vanderstok-core-bc we take the position that the CoAP end-point
is fully specified by the scheme and authority parts of the URI, and that
dereferencing these elements is the function of service discovery.  Quoting
from section 6.2:

   Whereas service discovery is used to find the IP address, port and
   protocol of an unknown service, resource discovery is a fine-grained
   discovery of resource URIs within a web service.

and again from section 6:

   This section assumes that... service discovery has already been
   performed a priori, if needed.

So, in general, it would seem that service discovery has occurred upstream
of any path/query processing at the end-point.  For example, in figure 9
of the CoAP draft some form of service discovery must have occurred
before unicast resource discovery can proceed.

>From a practical standpoint the question might also boil down to "what
value goes in the source port" for CONs from an end-point, or in response
to multicast CONs.  My vote would be [IANA_TBD_PORT] for the latter
(and that should also be the destination port used in the multicast), but
MAY be a dynamic port in the 61616-61631 range for the unicast case
(see below).

> Text in section 4.4 implies these are distinct end-points.
You raise several questions here.  First, are constrained devices likely to be
multi-homed?  More generally, can multiple URIs locate the same resource?
If so, this would seem to admit multiple relative URI-references for the same
resource at the same end-point.  For example, a namespace path schema
might coexist with an unstructured schema to access the same resource.  But
I digress...

<flame>
  As a meta-issue, I think one objective of CoRE should be to capture a
  consensus regarding the meaning of constrained.  That is, what degrees
  of freedom are we willing to limit?  Multi-homing might be an example.
</flame>

Regarding multiple ports, I think this is a very important question.  We use
host names as persistent references because they are durable compared to
IP addresses.  If it should be the consensus that coap://host:portX/path
locates a different resource than coap://host:portY/path, then there are some
implications:
- End-points using dynamic ports should always use the same port.  If not,
  then any cached (persistent) URIs might become invalid.
- To the extent that different end-points may use different dynamic ports, this
  makes multicast messages to a group of end-points problematic.

A simple solution might be to stipulate that there is only one CoAP end-point
per host but that it might be reached on multiple ports.  For example, the first
GET that a client makes to a new server might be via the [IANA_TBD_PORT]
but the response might be returned by way of a dynamic port, which would
be used by the client for all subsequent requests to that server.  That would
necessitate changing the text in section 4.4 to "...MUST be supported for
providing access to other resources."  The canonical end-point is thus
defined as the {canonical host IP address, IANA_TBD_PORT, CoAP} triple.

> in response to a message received by an 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.

> sort of implicit redirect)?
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.

> link-local) IP address and port.
Concur, but it seems there may be more than one end-point per host.

> - Each end-point can additionally receive messages on zero or more multicast
I believe this must be "one or more", otherwise how is multicast
resource discovery
accomplished?  Without multicast resource discovery, (and its side
effect of quasi
service discovery) an external service discovery method is required.
If selecting a
default service discovery mechanism is outside the charter, that leads to the
conclusion that groups of CoAP end-points may not be able to find each
other.  My
own personal opinion is that mDNS/DNS-SD should be used for service discovery,
but that's another email.

> the responding end-point from option headers.
Dunno how the latter approach will help unless you have a DNS client and
can resolve the authority.

> can provide temperatures.  How do I do that extraction?
If all you have is UDP and CoAP, then recvfrom().  Note that n=Light, as in
figures 9 & 10 of the draft, is a *resource* name and not a service (end-point)
name.  DNS-SD has little to do with browsing resources (except what might
be derived from examining the service subtype or contents of its TXT record)
and shouldn't be used as a resource registry.  Again, that's another email.

> knowledge of that subscription.
Why not represent that knowledge as a resource at the existing end-point?

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

Regards, -K-

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 23 Jul 2010 10:31:44 -0400

A few corrections...

On Fri, Jul 23, 2010 at 10:20 AM, Kerry Lynn <[email-masked]> wrote:
> <snip>

I meant "any multicast *request* to [IANA_TBD_PORT] arrives
at the end-point."

>> 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...