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

[Christian Amsüss <[e-mail]>]

Hello Bill,

On Fri, Nov 11, 2016 at 12:10:58PM +0200, Bill Silverajan wrote:
> After the Berlin meeting, we took onboard several suggestions and
> recommendations and as a consequence, the draft has been reshaped quite
> 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.

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

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)