diff --git a/index.bs b/index.bs index 82f90e58..3a073d98 100644 --- a/index.bs +++ b/index.bs @@ -3708,6 +3708,137 @@ and makes it clear when the state described by the flags is reset. +

Use registries to allow constrained extensions outside the original standards track

+ +When you expect a feature to need to be extended over time, +and it would be inappropriate to +manage that change through the same standards process that defined the original feature, +then a registry is usually the right design. + +[[spec-variability#variability|"Variability complicates interoperability."]] +When a feature needs optional components, +it is easiest to manage the complication if +a single group is in charge of the whole design. +This implies that most optional features should be defined +in the same specification that defined the original feature. + +Sometimes new extensions are expected to be needed in the future. +It is often most appropriate +to have to revise the specification to define an extension. +This can reduce or avoid any need to precisely define requirements for extensions. + +However, if extensions need to be defined through +a different process than updating the full specification, +a registry is usually the right way to manage the known extensions. +Default to defining either +an IANA registry governed by [[RFC8126]] or a [[w3c-process#registries|W3C Registry]]. + +The place in a specification that dispatches to an extension's implementation +is known as an extension point. +To maximize the chance that a specification with extension points is interoperably implemented, +each extension point should + +* define how implementations can negotiate which extensions are acceptable, +* define what to do with unrecognized extensions + (see [[RFC6709#section-4|section 4 of RFC6709]]), +* define what interface extensions are supposed to implement, and +* link to a specification of each extension that is + detailed enough to support interoperable implementations of the extension, + as is required by + the IETF's [[RFC8126#section-4.6|Specification Required]] registration policy. + +Registries help because they + +* give each extension a unique name to use + in negotiation and + in recognizing what extension is in use, +* provide a place to link to extension specifications + (if the registry requires this), and +* help readers find the name for a desired purpose. + +It is tempting to additionally require that registry entries be +"good" in some way beyond what is needed to achieve interoperability. +Whether this can succeed depends on the ecosystem and the expected implementers. +Implementers are most likely to be willing to +navigate a demanding registration process and +constrain their implementations to match strict registration requirements +when they are a small set, wealthy, and generally-aligned, +as in the case of web browser engines. +The more diverse or constrained implementers become, +the less you can expect them to consistently work to register extensions. + +At the limit, implementers might not even be willing to specify their extensions. +If the specification authors consider this likely, it may be worth allowing +[[rfc8126#section-4.4|first-come-first-served registrations without a specification]] +just to reduce the risk of name collisions, +although the registry should still encourage full specifications. + +In the case of a registry that doesn't require specifications, +it can be tempting to identify extensions with URLs or URIs instead of registered strings. +This has the effect of defining a [[rfc8126#section-4.3|hierarchical registration policy]] +and making it very easy to extend the feature, +by just picking a URL from a domain that the extender controls. +This clearly loses the interoperability benefits of requiring a specification, +and in the case of DNS-based URLs, +it also risks that the entity that defined the extension may lose control of its domain. +URIs are appropriate for a few kinds of very-low-coordination extension, +but most of the time a WG-managed permissive registry table will work better. + +Because an [=extension point=] defines an interface, +and it's difficult to be confident in an interface definition +before that interface has several implementations, +any new registry should start with at least 2-3 entries defined. +Each of these initial registry entries +can be either required or optional for implementations to recognize. +For extension points that can't just be ignored when their extension isn't recognized, +the registry should include at least 1 required entry. + + + +See [[qaframe-spec#extensions]] and [[RFC6709]] for +more guidance on how to design extensibility. +

Resolving tension between interoperability and implementability