Recommend registries, and give some guidance on how to define them. #596
Conversation
| In this case, the right plan is often to | ||
| have the original standards body continue or restart | ||
| a working group to produce an update to the feature's full specification. |
There was a problem hiding this comment.
| In this case, the right plan is often to | |
| have the original standards body continue or restart | |
| a working group to produce an update to the feature's full specification. | |
| It is often most appropriate | |
| to have revise the specification to define an extension. | |
| This can reduce or avoid any need to precisely define requirements for extensions. |
| See [[qaframe-spec#extensions]] for | ||
| more guidance on how to design extensibility. |
There was a problem hiding this comment.
| See [[qaframe-spec#extensions]] for | |
| more guidance on how to design extensibility. | |
| See [[qaframe-spec#extensions]] and [[RFC6709]] for | |
| more guidance on how to design extensibility. |
| Default to defining either | ||
| an IANA registry governed by [[RFC8126]] or a [[w3c-process#registries|W3C Registry]], | ||
| but another similar mechanism is also acceptable. |
There was a problem hiding this comment.
What other mechanism do you think might be appropriate? What criteria do you think apply to the selection of process?
|
|
||
| Registries are helpful because they | ||
|
|
||
| 1. Reduce name collisions. |
There was a problem hiding this comment.
I think that you have a bullet list with commas, not periods...
| 1. Reduce name collisions. | |
| * reduce name collisions, |
| The definition of the registry must be clear about this interface, | ||
| and it should require new entries to include a specification that follows it. |
There was a problem hiding this comment.
The extension point that is governed by a registry needs to be fully-specified. That includes a definition of what to do if an item is not understood (is there a negotiation mechanism? is there feature detection? is the extension ignored when it is not understood? or, does it cause a failure of some sort?)
RFC 6709 goes into some detail about some of the extension models that might apply. Those are for protocols, but the same principles broadly apply to APIs as well.
Then, the requirements for what it takes to define the extension need to be clearly defined, as you say here.
| so any new registry should start with at least 2-3 entries defined. | ||
|
|
||
| It is tempting to additionally require that registry entries be | ||
| "good" in some way beyond simply being specified. |
There was a problem hiding this comment.
| "good" in some way beyond simply being specified. | |
| "good" in some way beyond what is needed to achieve interoperability. |
| Use a permissive registration policy instead of doing this | ||
| unless the feature includes | ||
| some way to enforce that no implementation can use an unregistered name. | ||
| The IETF has found that | ||
| when it's too hard to add entries to a registry, | ||
| implementers will often simply use names without registering them. |
There was a problem hiding this comment.
This isn't quite the angle I'd use here. The extent to which you can add tighter constraints varies based on the ecosystem you are deploying into. If your implementers are browsers, then you might imagine that a tighter set of restrictions might be respected and therefore it would be more reasonable to at least try it on.
If you are looking at websites implementing, then you can almost guarantee that registrations won't happen, even if the constraints are very lightweight.
Getting that nuance in might be a good idea.
| When a feature's main specification defines some initial registry entries, | ||
| each one can be either required or optional for implementations to recognize. | ||
| If implementations need to pick an understood registry entry to send to their recipients, | ||
| then the registry should include at least 1 required entry. |
There was a problem hiding this comment.
Extensions for optional features - ones that are simply ignored if not understood - don't need this.
You should say that where the functioning of a specification depends on choosing and using an registered value, then you have three choices:
- One party implements all the options.
- You mandate a baseline that all parties implement.
- Risk interoperability failure if the intersection of options between entities is empty.
And that's for a two-party negotiation. There are many things that the W3C documents where there are more than two potential actors involved.
| It can be tempting to use URLs instead of registered strings to identify extensions. | ||
| This has the benefit of making it very easy to extend the feature, | ||
| by just picking a URL from a domain that the extender controls. | ||
| However, there's no way to ensure that | ||
| these URLs point to a specification for the extension they name, | ||
| or even that the domain stays under the control of the entity that defined the extension. | ||
| URLs are appropriate for a few kinds of completely-permissionless extension, | ||
| but most of the time a WG-managed permissive registry table will work better. |
There was a problem hiding this comment.
XML namespaces use URIs (not URLs). They are not using URIs for their ability to resolve to something; most XML namespace URIs, if they are resolved, point to nothing useful. You seem to imply that they could point to something; some do, but that's never been the goal.
They use URIs because the domain into which they are being deployed does not benefit from centralized coordination. They need identifiers and a way to generate them without coordination or - save us all - namecoin-style consensus. Indeed, it would be a mistake to require centralized coordination for those (doubly so for a wasteful distributed consensus). XML is a file format that is used by many people for many reasons. There is no value in asking people to coordinate identifier allocation. The same applies to JSON-LD, for similar reasons 1.
But the question we need to answer here is different. If you are specifying an extension to a protocol, why would you use a registry rather than letting the proverbial thousand flowers bloom? That all comes down to how you conceive of the interoperability goals of the extension point.
An optional, ignorable extension might benefit from a registry if there is a greater need to have different implementations agree on what the meaning of the extension is. In TLS, we have a registry for extensions, not just because there is a limited space available, but because the goal of defining an extension is to enable a shared understanding of the space.
In comparison, the IPTC metadata format uses URLs, because they don't see a need to constrain the space of options. There, the risk that people define multiple identifiers that are close, or even identical, in meaning is something that is tolerated so that there is a low-coordination way of adding metadata for limited or proprietary uses.
An extension point that determines everything that follows, like TLS ciphersuites or digital credential protocols, benefits more from coordination than something that can be readily ignored. Those are places where mandating implementation of a core by all (or a subset by browsers) is necessary.
Footnotes
-
Even if you don't think that JSON-LD is solving a problem that matters, this choice is not one that is really in contention, to my mind. ↩
There was a problem hiding this comment.
XML namespaces use strings that by convention often look like URLs and might parse as one, if we're going to quibble about details.
| If implementations can be | ||
| divided into distinct [[spec-variability#subdivision-profile|profiles]] | ||
| that tend not to need to communicate with other profiles, | ||
| it can be sufficient for each profile to require a registry entry | ||
| even if the main specification leaves them all optional. |
There was a problem hiding this comment.
That's not interoperability in the sense that we should care about here.
This is a rough draft of a "define registries" principle, based on the discussion in Hong Kong last week. It will fix #583 once it's polished and merged. I expect it'll need a lot of polishing.
Preview | Diff