Subject: [core] zero-length options

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 10 May 2011 18:14:20 +0000

Hi

I guess the purpose of zero-length options is to represent a value of zero with zero bytes. Is that right?

If yes, why is it inconsistent then?

Content-Type and ETag could also be zero, but their lengths must be one at least. Uri-Port on the other hand can have a zero length, although port zero does not make much sense for me.

Regards
Matthias

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 10 May 2011 22:11:21 +0200

Good catch!

> I guess the purpose of zero-length options is to represent a value of zero with zero bytes. Is that right?

It could also be a boolean option, but we don't have any yet.

> Content-Type and ETag could also be zero, but their lengths must be one at least.

Content-Type: Bug.  This was from the time we still had a default of 0: In that case, it didn't make sense to send a zero-length zero.  Now we should enable that again.  (Currently, we don't disallow leading zeros in uints.  Maybe we should fix that.)

ETag is not a uint, but an opaque string.
Here, we do exclude the zero-length string.
(There is no strong reason for that, but it does enable an implementation to represent the absence of an ETag with a zero-length string.)

> Uri-Port on the other hand can have a zero length, although port zero does not make much sense for me.

Right.

Port 0 is somewhat unusual as it is usurped by some APIs.  Probably not a great choice of port number.
Should we explicitly exclude it?  RFC 3986 doesn't.

Gruesse, Carsten