On Dec 20, 2019, at 01:47, Benjamin Kaduk <ka...@mit.edu> wrote: > >> 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 think that a similar > situation is possible here, though of course you may just know from > out-of-band configuration.
RFC 7252 says: The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. So there is a clear rule: If the URI has the IP address and port number (possibly defaulted), respectively, the options can be omitted. This means you can almost always omit Uri-Port, and can omit Uri-Host if the URI had an IP address literal. The latter is not unlikely if that URI came from a resource directory. If the URI had a DNS name and you omit Uri-Host anyway, you are gambling that the server offers the same resource under the IP address the DNS name resolves to. Not unlikely either, but still gambling, unless you have out-of-band information. Now you might have verified the identity of the server already using a security protocol, in which case you could have more reason to believe you are addressing the right resource. Grüße, Carsten _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
