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" 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. 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 / RFC 6690: REQ: GET coap://[2001:db8::2:1]/.well-known/core?rt=ace.est RES: 2.05 Content </est>;rt="ace.est" Because strictly speaking this tells the client that /est is hosted on port 5683 (no statement about 5684 hosting!) I see this as a design flaw in CoAP discovery; we would like to be able to use the above short syntax of course. @Michael: Since the EST resource is always present on the fixed port 5684 on URI /.well-known/est - if a fixed port is needed e.g. for a join proxy, use 5684 and the well-known URI. No discovery needed. Esko From: Peter van der Stok <[email protected]> Sent: Thursday, September 20, 2018 16:56 To: Michael Richardson <[email protected]> Cc: Esko Dijk <[email protected]>; Panos Kampanakis (pkampana) <[email protected]>; [email protected] Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI Michael Richardson schreef op 2018-09-20 16:51: I didn't think that CoAP resource discovery supports port numbers, does it? It does; at least for the 3rd party registration, but also examples in the RD show return of port
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
