Explicitly allow implementations to support additional option values

[eemeli]

We should more explicitly allow implementations to support option values for default functions that are not listed in registry.md. This is currently only implicit, as we preface the lists of options with

The following options and their values are required in the default registry to be available on the function ...

which does not say anything about behaviour with unlisted values.

There's also a tech preview request for feedback here that ought to be dropped.

[aphillips]

I agree with this change in spirit, but the "last remaining task" is a refactor of this file to fit with the design for function set management. I promised to do that after we land the remaining open PRs for currency, number, etc.

I think if we do this we should provide complete guidance, hence the massive suggestion......

[aphillips]

Suggested change

	This section describes the functions for which each implementation MUST provide
	a _function handler_ to be conformant with this specification.
	Implementations MAY implement additional _functions_ or additional _options_.
	In particular, implementations are encouraged to provide feedback on proposed
	_options_ and their values.
	Implementations MAY implement additional _functions_,
	additional _options_, and additional _option_ values.
	This section defines the _functions_ which are REQUIRED for conformance with this specification,
	along with **optional** _functions_ that SHOULD be implemented to support
	additional functionality.
	Each **standard** _function_ MUST be defined and
	MUST accept all standard _options_ and _option_ values listed in this specification.
	When provided by an implementation, each **optional** _function_
	MUST accept all standard _options_ and _option_ values listed in this specification.
	Implementations SHOULD implement _options_ and _option_ values that are marked as **optional**.
	Implementations MAY implement _functions_ not defined in this specification.
	Such functions MUST use an implementation-defined _namespace_.
	In addition, implementations are encouraged to provide mechanisms for users to
	register and use user-defined _functions_ and their associated _functional handlers_.
	Implementations MAY implement additional _options_ not defined here.
	Such _options_ MUST use an implementation-specific _namespace_ .
	Implementations MAY implement additional _option_ values for _options_ defined here,
	although care needs to be exercised to ensure interoperability
	and to avoid collisions with future standardization.
	There is no namespace mechanism for _option_ values,
	however, the [stability policy](#stability-policy) for this specification
	permits only the ranges a-z, A-Z, and 0-9 in _option_ values.
	Implementation-defined values SHOULD use a distinguishing character
	or character sequence, such as by prefixing an underscore,
	to ensure that they don't collide with future standardization.

[macchiati]

Such functions SHOULD use an implementation-defined namespace.
...
Such options SHOULD use an implementation-specific namespace .

Shouldn't that be a MUST, to avoid collisions with later additional standard functions / options?

although care needs to be exercised to ensure interoperability

Even though we don't have namespaces for option values, I suggest we consider recommending that when an additional option values is added to a standard or optional option, that it start with "_" to avoid collision with future standard or optional options.

That is not as powerful as namespaces, since it doesn't help to prevent collisions with other implementations, but at least is future-proofing against Unicode's future option values.

[aphillips]

Probably should be MUST.

Our stability policy (soon to be effective) says:

Updates to this specification will only reserve, define, or require function names or function option names consisting of characters in the ranges a-z, A-Z, and 0-9. All other names in these categories are reserved for the use of implementations or users.

So we can recommend something like what you mention or just call out the stability guarantee explicitly here. I'll make an edit to that effect. I edited my suggestion above.

[eemeli]

I'd much rather consider my small clarification and the proposed refactor separately as they are rather different changes, but fine, let's do the feature-creep thing again. I'll merge @aphillips's suggestion, and then review it.

For clarity, I no longer consider this "my" PR.

Edit: Merging the suggestion is apparently not allowed as it touches deleted lines. So I'm going to close this PR instead, and @aphillips can file a separate one.

[aphillips]

I understand the reluctance to do this all in one go, but we're very nearly out of time. PR to follow.