Subject: [core] Fwd: New Version Notification for draft-silverajan-core-coap-protocol-negotiation-04.txt

From: Bill Silverajan <[email-masked]>
Date: Fri, 11 Nov 2016 12:10:58 +0200

Dear All,

We submitted a new version of our draft, "CoAP Protocol Negotiation" 
recently.

After the Berlin meeting, we took onboard several suggestions and 
recommendations and as a consequence, the draft has been reshaped quite 
significantly. So in this version, we introduce the CoRE Resource 
Directory as a central component in an architecture to which CoAP origin 
servers can register multiple available transports. This then allows 
clients to perform lookups in order to discover these transports on the 
endpoints.

Several sections of draft-ietf-core-coap-tcp-tls discuss client-server 
exchange and/or negotiation of reliable transport features in-band, such 
as TLS ALPN, WebSocket subprotocol selection or Capability and Settings 
Messages. The mechanisms in this draft for allowing clients and servers 
to use various CoAP transports do not affect or interfere with those.

We're working on a strawman proposal allowing CoAP origin servers and 
clients to directly interact and discover available alternative 
transports, in situations where using a CoRE Resource Directory may seem 
unfeasible. That'll be addressed in future versions of our draft.

Looking forward to your comments,
Bill

-------- Forwarded Message --------
Subject: New Version Notification for 
draft-silverajan-core-coap-protocol-negotiation-04.txt
Date: Mon, 31 Oct 2016 14:03:11 -0700
From: [email-masked]
To: Bill Silverajan <[email-masked]>, Mert Ocak 
<[email-masked]>

A new version of I-D, draft-silverajan-core-coap-protocol-negotiation-04.txt
has been successfully submitted by Bilhanan Silverajan and posted to the
IETF repository.

Name:		draft-silverajan-core-coap-protocol-negotiation
Revision:	04
Title:		CoAP Protocol Negotiation
Document date:	2016-10-31
Group:		Individual Submission
Pages:		11
URL: 
https://www.ietf.org/internet-drafts/draft-silverajan-core-coap-protocol-negotiation-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-silverajan-core-coap-protocol-negotiation/
Htmlized: 
https://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiation-04
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-silverajan-core-coap-protocol-negotiation-04

Abstract:
    CoAP has been standardised as an application-level REST-based
    protocol.  When multiple transport protocols exist for exchanging
    CoAP resource representations, this document introduces a way forward
    for CoAP endpoints as well as intermediaries to agree upon alternate
    transport and protocol configurations as well as URIs for CoAP
    messaging, using the CoRE Resource Directory.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 14 Nov 2016 16:50:34 +0100

Hello Bill,

On Fri, Nov 11, 2016 at 12:10:58PM +0200, Bill Silverajan wrote:
> significantly.

I had started writing a review back on the -03 version and the notes for
-04 from the slides, but most of the points have been obsoleted in -04.

> clients to directly interact and discover available alternative transports,
> in situations where using a CoRE Resource Directory may seem unfeasible.
> That'll be addressed in future versions of our draft.

I'm looking forward to seeing that.

My notes / questions to -04:

* at parameter / con parameter: It seems that the at= list arguments are
  roughly equivalent to the con= context parameter that defaults to the
  protocol and address of the originating submission.

  Does that mean that the endpoint registers using TCP instead of UDP,
  the equivalent to the 4.1 example would be

  POST coap+tcp://rd.example.com/rd?ep=node1&1&at=\
          coap://server.example.com,\
          coap+ws://server.example.com:5683/ws/

  ? This means that registration is only possible using a protocol where
  no path component is used in the at parameter, but that's probably
  fine because those protocols are rather not used to start a
  connection. (Aren't the? It'd be something like a server accessed via
  websockets registering itself as an endpoint at an RD runnign inside
  the browser. If you don't want to rule out registration over those,
  updating allowing a path into con= might be an option.)

  If at is intended to be a list of more con= parameters, I suggest this
  be made more explicit (eg. "The list does not need to contain the
  location that is implied by the source address of the registering
  connection or explicitly set in the con= parameter." after 4.1 par1).

* at= parameter list: The comma-separation precludes all URIs that
  contain the comma character. This is unlikely to occur (maybe
  `coap+ws://.../ws,v=1.1/` like in RFC3986) but legal in a URI.

* tt= parameter: To which of the four defined lookup types is this
  applicable? (My assumption would be ep and res, where the res would
  return the composed ). Can the parameter
  repeated to indicate a set of supported transports? Does it have a
  default value? (I'd assume '*').

Best regards
Christian

-- 
The detailed semantics of CoAP methods are "almost, but not entirely
unlike" [HHGTTG] those of HTTP methods.
[HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979.
  -- Shelby, et al., Internet-Draft Constrained Application Protocol (CoAP)

---

From: Bill Silverajan <[email-masked]>
Date: Tue, 15 Nov 2016 18:26:54 +0200

Hi Christian,

Thanks for the interesting comments and suggestions. I'll reply inline 
to them:

>   protocol and address of the originating submission.

After looking at "con", we took an active decision to introduce "at", 
for a couple of reasons. The first is to avoid overloading the semantics 
of "con" when the EP registers with the RD:

When using "con": This is my *one and only* context URI to describe the 
endpoint location. *Always* use it instead of the endpoint address (and 
protocol configurations) I'm registering my links with.

When using "at": You can reach me at the endpoint address (and protocol 
configuration) I registered my link with. Optionally, I'm also available 
to serve my CoAP resources at these other locations over alternative 
transports.

The second reason is that you may need to use "con" together with "at" 
for a reason you mention below (if you do a goto alt+con a little way down)

>           coap+ws://server.example.com:5683/ws/

To me this makes complete sense, if the primary endpoint transport is 
seen to be TCP, and the server also wishes to indicate it's available 
over UDP and WebSockets. But, to see my next point on using alt and con,

>   updating allowing a path into con= might be an option.)

alt+con:

I think this is a very interesting point when it comes to using CoAP 
over reliable transports such as TCP and WebSockets with the RD. While 
UDP sockets allow reuse and peer-to-peer communication, the same cannot 
be said for the others. i.e. if you're registering with a reliable 
transport protocol, I assume you must use "con", since the endpoint 
would use a different location (or a system generated client random port 
number in userspace) than the CoAP server endpoint.

I'm not sure whether our draft, coap-tcp-tls or core-resource-directory 
is a better place to highlight this, but we'll capture this into our 
draft if it isn't mentioned in the others.

>   connection or explicitly set in the con= parameter." after 4.1 par1).

Thanks for the suggestion. It's good to explicitly clarify the 
relationship to "con" as well as the endpoint location during the 
registration, so we'll add that text in.

>   `coap+ws://.../ws,v=1.1/` like in RFC3986) but legal in a URI.

The comma is a valid (default) separator for query expansion (see 
section 3.2 in RFC 6570) but as you say, it's also legal in a URI. 
However, section 2.2 of RFCC 3986 describes the comma as a reserved 
character and has this to say about its use:

"If data for a URI component would conflict with a reserved character's 
purpose as a delimiter, then the conflicting data must be 
percent-encoded before the URI is formed."

We could mention this in the draft text too.

One thing: The CoAP URI for (secure) WebSockets as defined in 
core-tcp-tls does not specify a path component for the Websocket 
endpoint. It was too tricky to do location/identification by separating 
the path components for the websoocket endpoint away from the CoAP 
resource. However, this problem is addressed in this draft.

>   return the composed ).

"tt" extends the URI Template in the RD Lookup Function Set as follows:

URI Template:  /{+rd-lookup-base}/{lookup-
       type}{?d,ep,gp,et,rt,page,count,resource-param,tt}

So technically all four lookup types (including d and gp)

>Can the parameter

"tt" can be used to look up a specific transport type (or * for all). 
I'm not sure if it needs a default value? The use cases we had here were 
a client querying the RD for endpoints supporting a specific tranport, 
or a client querying the RD for an endpoint's currently available and 
active transports. This would also return the secure URIs if registered.

There's a tradeoff between making several queries to check for specific 
kinds of transports (so you get success or notfound responses), or 
extending "tt" to support a query list that can be returned in one 
operation (but may or may not contain all the transports you asked for).

Regards,
Bill

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 16 Nov 2016 08:33:56 +0100

Hi Bill,

thanks for your response.

On Tue, Nov 15, 2016 at 06:26:54PM +0200, Bill Silverajan wrote:
> I think this is a very interesting point when it comes to using CoAP over
> reliable transports such as TCP and WebSockets with the RD. While UDP
> sockets allow reuse and peer-to-peer communication, the same cannot be said
> for the others. i.e. if you're registering with a reliable transport
> protocol, I assume you must use "con", since the endpoint would use a
> different location (or a system generated client random port number in
> userspace) than the CoAP server endpoint.

You are right about the port number, I didn't think of that. I'll go
through the RD and TCP drafts again to check whether this needs further
notes.

> One thing: The CoAP URI for (secure) WebSockets as defined in core-tcp-tls
> does not specify a path component for the Websocket endpoint. It was too
> tricky to do location/identification by separating the path components for
> the websoocket endpoint away from the CoAP resource. However, this problem
> is addressed in this draft.

Indeed; then the example in 4.2 needs updating to drop the /ws/, doesn't
it? (I suppose that it is neither to mean that clients should connect
their web-sockets to ws://.../ws/ instead of .well-known/core, nor that
they should prefix /sensors/temp into /ws/sensors/temp when sending a
request to the WS).

> So technically all four lookup types (including d and gp)

I'm looking forward to seeing the gp applications you mentioned in the
presentations.

> "tt" can be used to look up a specific transport type (or * for all). I'm
> not sure if it needs a default value?

The default value would describe what protocol-negotiation-unaware
clients would receive, I think this does deserve mention.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom