Given that the spec also includes

I feel limits on these options should be more strict in general because it is a dereliction of duty for MF2 to allow a message that is supported in one implementation but rejected in another (without using implementation-specific namespaced options), but I'll leave it up to the WG to decide if this text, permitting engines to differ in the limits they impose, is acceptable to MF2.

@sffc What change would you propose here? The goal would be to restrict the upper size of a digit size option's value without restricting numeric types supported by implementations. Note that we have limited the size to 99, while BigDecimal/BigInteger types existing in various languages that can exceed this (the practicality, of course, of formatting that many digits might be questioned).

Note that the ABNF is a syntactic limit. We would probably change that syntax if we agree on a practical upper limit < 99.

it is a dereliction of duty for MF2 to allow a message that is supported in one implementation but rejected in another (without using implementation-specific namespaced options)

This would not happen because the message will not be rejected. Exceeding 99 or an implementation-defined limit can only result in a Bad Option error. These are never fatal (i.e. message-rejecting):

The result of option resolution MUST be a (possibly empty) mapping of string identifiers to values; that is, errors MAY be emitted, but such errors MUST NOT be fatal.

@aphillips explained to me that what this means is:

• Error handling for this option is to emit a non-fatal error and drop the option
• All implementations must error if the value exceeds 99
• ECMAScript could error if the value exceeds 21

Since the error is non-fatal, you get GIGO-like behavior, so nothing actually breaks; you don't get data-driven exceptions, which is what I'm concerned about.

2024-04-14 call: Need to allow clamping.