Hi Ben, On Fri, Dec 20, 2019, at 12:47 AM, Benjamin Kaduk wrote: > On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker > wrote: > > DISCUSS: > > > > 5.4. Message Bindings > > > > o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- > > Format, Block1, Block2, and Accept. These CoAP Options are used > > to communicate the HTTP fields specified in the EST REST messages. > > The Uri-host and Uri-Port Options can be omitted from the COAP > > message sent on the wire. > > > > The statement above > > > > When omitted, they are logically > > assumed to be the transport protocol destination address and port > > respectively. Explicit Uri-Host and Uri-Port Options are > > typically used when an endpoint hosts multiple virtual servers and > > uses the Options to route the requests accordingly. > > > > and the last quoted statement: How can the sender know whether or not it is > > Ok > > to omit Uri-Host/Uri-Port? > > How do you know when you need to send SNI to a TLS server? "If you try > without and get a strange certificate back."
I don't think this is similar. The answer for SNI is that you always include it, unless you don't care. > I think that a similar > situation is possible here, though of course you may just know from > out-of-band configuration. I don't think this kind of attitude is friendly to implementors ;-). Are you really suggesting that implementations should try not to include these options and then retry if that doesn't work? I am tempted to suggest that the text should be change to "SHOULD include Uri-Host and Uri-Port". Basically, if an implementation knows for sure that it is not needed, the SHOULD can be violated, but the recommended default is safe for all cases. Best Regards, Alexey _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
