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

[Bill Silverajan <[e-mail]>]

Hi Christian,

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

Christian Amsüss wrote:

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

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)


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

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,

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

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.


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

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.

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

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.

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

"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
>   repeated to indicate a set of supported transports? Does it have a
>   default value? (I'd assume '*').
>

"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



> Best regards
> Christian
>