Esko Dijk <[email protected]> wrote:
    > Indeed, and the ace-coap-est examples use port 61616 mostly. The
    > discovery Link Format is quite inefficient when returning results on
    > *different* endpoints. Example:

    > REQ: GET coap://[2001:db8::2:1]/.well-known/core?rt=ace.est

    > RES: 2.05 Content

    > <coaps://hostcanhavealongname.example.com:61616/est>;rt="ace.est"

I understand.

    > Although in above case the server could shorten the response payload by
    > returning its IP address ( <coaps://
    > [2001:db8::2:1]:61616/est>;rt="ace.est"). But still it’s a waste of
    > bytes.

It could have multiple addresses!!!
I've seen it just return </est>, but I guess if you want to return the
port number, you have to return the hostname... <:61616/est> won't do?

    > The current example in Section 5 of ace-coap-est is problematic,
    > because discovery is on port 5683 and the hosted EST endpoint is on the
    > secure port 5684. So the following won’t work according to RFC 7252 /

So I've assumed that discovery happens on 5684, under DTLS.
You are suggesting that we need to run an unencrypted CoAP to offer the
discovery option as well.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace

Reply via email to