It is probably enough to add to the text of est-coaps:
(see section 5.10.1 of RFC7252)

Peter
Carsten Bormann schreef op 2019-12-20 08:06:

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
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to