Zero values for some properties are invalid or unspecified

[dhobsd]

This is a super nit, but the definitions in Interface for Numeric and Integer specify that they take "positive or negative ... values". Although IEEE754 has the concept of positive and negative zero, this idea is not relevant to any of the TAPS specification. Maybe useful to "fix" these definitions to be inclusive of zero.

In working on #1428, I had to do a double-take to see whether we discuss zero anywhere. In doing so, I noticed that zero is implicitly valid for all of our Numeric and Integer options (as they all specify "non-negative"), but only some of them specify what a zero value means for that property.

In some cases, a value of zero is nonsensical. For example, the only logical (to me) behavior for a zero value for connTimeout and keepAliveTimeout would be for those fields to be Disabled. However, Disabled is implicitly an option for an implicitly enumerated type, and is distinct from the zero value. These two properties ought to say "Integer (positive)" or explicitly define a zero value as erroneous.

Further cases:

• What does zero mean for Bounds on Send or Receive Rate?
• Zero seems nonsensical for Group Connection Limit
• Maximum Message Size Before Fragmentation or Segmentation should be above zero or have the zero value specified.
• Maximum Message Size on Send should be above zero or have the zero value specified.
• Maximum Message Size on Receive should be above zero or have the zero value specified.
• Advertised User Timeout should be at least 1 per RFC5482 ("Thus, the UTO option allows hosts to exchange user timeout values from 1 second to over 9 hours at a granularity of seconds, and from 1 minute to over 22 days at a granularity of minutes.") (Sadly, this RFC neither defines nor precludes zero.)
• Lifetime seems to have a valid use-case for zero that should be explained.

I have attempted to be comprehensive, but I am not sure this is every case.

[mwelzl]

Many thanks for this, great catch!

[mwelzl]

I created #1443 to address this. I think it was easy not to miss anything, I just did a search for "Integer" and "Numeric"... so I think this is complete now. A few answers (and I agree with everything else, as the PR should reflect):

• About timeouts: yep, positive only.
• What does zero mean for Bounds on Send or Receive Rate? Theoretically, zero may seem to be a good allowed value for minima only, but this is inconsistent: we have Unlimited as a special value for all four bounds, and clearly an Unlimited minimum means "as small as zero".
• UTO: yep, I had to dig, too. Since this is an Integer, "Positive" should do the trick ( >= 1 :-) )
• Lifetime: you got me thinking a bit with this one... semantically, 0 seems to convey "don't delay this, send it immediately!". I checked SCTP, where this originally comes from: 0 doesn't seem to be specified there. However, the functionality that this represents is: "throw away a message if the lifetime has expired". It's not really a means to declare urgency - and so I felt that defining 0 seems out of place here (that's like inventing new functionality, and if I want stuff to be sent right away, I should probably control the send buffer instead using the "Receive queuing" system).