Subject: [core] draft-core-coap-09 Uri-Port

From: Thomas Fossati <[email-masked]>
Date: Fri, 13 Apr 2012 10:29:56 +0200

Section 5.10.2 says:

"The default Uri-Host and Uri-Port options are sufficient for requests to most
servers, and are typically used when an endpoint hosts multiple virtual
servers."

which is quite confusing since "and ... typically" seems to refer to the default values while the opposite is meant.  I would rephrase that with something like:

"The default values of Uri-Host and Uri-Port options are sufficient for requests to most servers.  Explicit Uri-Host and Uri-Port are typically used when an endpoint hosts multiple virtual servers."

I have also a minor concern about a zero-length Uri-Port: it would default to UDP port 0, which is reserved.  In principle an explicit Uri-Port should have no strict relation to the underlying protocol port, thus a 0 value should be fine anyway.
[So, this is just a note to check if everyone agrees on this interpretation.]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Apr 2012 10:53:04 +0200

On Apr 13, 2012, at 10:29, Thomas Fossati wrote:

> Section 5.10.2 says: [...]

Yes, this is wrong and clearly needs to be fixed.  Now #208.

> [So, this is just a note to check if everyone agrees on this interpretation.]

Right.  As another data point, RFC 3986 does not go to the trouble of restricting port numbers either.

A more general point (also supporting staying with the current status): I would prefer to refrain from attempting to express range constraints on uints by setting up a minimum number of bytes used.  You can still send a 0 value as a 1-byte or 2-byte uint, so taking out the 0-byte form does not accomplish anything.  It just creates the need to add code for checking the length.  No other uint in CoAP needs a minimum length check at this point, and I would like to keep it that way.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 13 Apr 2012 15:27:09 +0200

> Right.  As another data point, RFC 3986 does not go to the trouble of restricting port numbers either.

Exactly, they are just DIGITs.  And, more importantly, it does not bind in any way an explicit port value in the URI to the port actually used by the transport protocol to access the service that hosts the resource.  

> A more general point (also supporting staying with the current status): I would prefer to refrain from attempting to express range constraints on uints by setting up a minimum number of bytes used.…

Sounds perfectly reasonable to me.  I also agree that requiring minimal length checks is a non-sense unless we decide to force an "use always the minimum number of bytes" constraint on CoAP uint encoders.

Anyway, my point was fairly limited in scope :-) just trying to remove any ambiguity WRT the "0" value as a valid value for the Uri-Port option.