Panos Kampanakis wrote:
> > But can't the client just be configured out-of-band with the URIs directly?
>
> That is right. We could mandate only .well-known URIs. But I think we ought
> to let a deployment use non-default URIs. [...]
I was aiming at something different, but, re-reading my question, my
question wasn't very clear. Let me try again.
In draft-ietf-ace-coap-est-09, a client can do discovery. For that, it
needs to know the host name (or IP address) and port number of a CoAP
server. It then constructs the URI
<coaps://{host}:{port}/.well-known/core> and then gets a list of links
to the EST resources. The host name and port number must come from
somewhere -- e.g., from configuration or from some other discovery
process. I'm quite happy with this.
Then you were saying that, in some cases, this discovery step is
unnecessary/wasteful. A client would instead need to know the host
name (or IP address) and port number of a CoAP server as well as an
ArbitraryLabel. It would then construct the URI
<coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen> and could
immediately start interacting with that resource. Again, the host
name, port number and ArbitraryLabel must come from somewhere. You
were saying that they come from configuration.
My question is: If host name, port number and ArbitraryLabel can come
from configuration, from which the client constructs
<coaps://{host}:{port}/.well-known/est/{ArbitraryLabel}/sen>, wouldn't
it also be possible to configure the client with the whole URI
containing the three parts directly?
> > 5.1 "Discoverable port numbers can be returned in the response payload." --
> > Now I'm wondering if that's actually permitted by RFC 6690...
>
> [...] but I think the example is OK to include the port.
I'm not sure. RFC 6690 is really weird. Let me get back to you on this.
> > 5.4 "All EST-coaps request messages expect an acknowledgement (with a
> > response payload); EST-coaps requests are confirmable CON CoAP messages."
> > -- This seems to be a matter of implementation quality and should not be a
> > requirement for interoperability. I suggest to remove this.
>
> We want to make use of Delayed responses. There are cases where the CA takes
> time to generate the cert/keypair, and in that case it needs to signal the
> delay with a Max-Age or Empty ACK. That is why we use CON. The text
> justification does not explain explicitly, but we didn't want to clutter the
> wording, so we kept it simple.
You're mixing up protocol specification and implementation guidance.
On the protocol specification side, both clients and servers are free
to choose if they want to use confirmable or non-confirmable messages.
And an application should not make any restrictions on that. On the
implementation guidance side, I think it makes a lot of sense to
choose delayed responses here. But implementation guidance should be
clearly marked as such, as not to create the impression that
implementations can only use certain messages types or can rely on
only certain messages types being used.
> > A.1. "The Uri-Host and Uri-Port Options can be omitted" -- But they aren't
> > in this example. Since it's not important for the example, maybe just
> > remove Uri-Host and Uri-Port from the example and also this paragraph?
>
> I wanted to keep it in there. We explain that it can be assumed from DTLS if
> omitted, but I think it is worth to show how the option would be included. I
> had trouble finding a COAP Uri-Host and port example online when I was
> searching and thus this is useful as a reference as well.
Yes, having more examples for reference is really nice. And I really
like that you, the authors, spent quite obviously a lot of time making
sure that EST-coaps is actually implementable and figuring out the
best ways to implement it. But, as I said above, you're mixing up
protocol specification and implementation guidance too much for my
taste. I really don't see why the EST-coaps specification needs to
provide examples for basic CoAP features that don't play a crucial
role in the application.
Specifically on Uri-Host and Uri-Port: RFC 7252 notes that "If the
value of an option is intended to be this default value, the option
SHOULD NOT be included in the message." [1] So your example actually
violates this 'SHOULD NOT'...
Klaus
[1] https://tools.ietf.org/html/rfc7252#section-5.4.4
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
