Add "allow new features" indicator to SotD.

[msporny]

Specify that the specification allows new features to be added after its initial publication as a Recommendation as described by the W3C Process.

---

Preview | Diff

[peacekeeper]

The idea sounds good, i.e. to be able to fix or add things that we forgot.. However, I think there's also the threat that content may get "fixed" in a way that could contradict or overturn previous decisions, or become a problem for existing implementations.

For example..

• Could Orie use this mechanism to add a "feature" that says the JSON and JSON-LD representations must be byte-to-byte equivalents?
• Could I use this to re-introduce matrix parameters?
• etc.

In both cases, some implementers wouldn't be happy with the change, and for various reasons they may not be able to participate in the process that makes the change.

[peacekeeper]

Also, I know it's not quite the same, but to some extent we already have a mechanism for additions.. The DID Spec Registries.

When would we add new features to the actual spec using this process, vs using the DID Spec Registries?

[msporny]

. However, I think there's also the threat that content may get "fixed" in a way that could contradict or overturn previous decisions, or become a problem for existing implementations.

The normal W3C Process still applies, which includes formal objections... and I expect formal objections would be filed for each of your examples above. :)

People will try to sneak their pet feature into the core specification, the CCG will be notified... there will be formal objections, and the new spec will fail to be published. This will almost certainly happen MORE frequently now that we have a stable spec and the threat of having no specification if someone formally objects goes away.

I do think there are appropriate controls for the scenarios you outline.

[peacekeeper]

I do think there are appropriate controls for the scenarios you outline.

I think I agree, just wanted to bring this up :)

[talltree]

I agree that the normal controls would apply. If anything, given that the change would be to a W3C Recommendation, even more scrutiny would apply to any substantial change.

[kdenhartog]

I thought I asked this somewhere, but I'm not able to find it anywhere so I'll re ask here just in case.

First off, I'm +1 on the allowance of Class 4 changes (new features) into the specification. I think in many cases this is going to be useful. Two questions pop in my head though.

1. Do we need to make any similar statements to allow class 1 through 3 erratum as well? I presume the answer to this is no based on my reading of 6.2.11 subsection 1, 2 and 3. As far as I understand we only need to allow this for class 4 because it "enables third parties to depend on Recommendations having a stable feature-set, as they have prior to the 2020 revision of this Process". Is that your reading of it as well?

2. How does the did-spec-registries relate to the ability to add new features? I'm noting the defined process for adding new features is more rigid then our process for the spec registries. Most notably looking at 6.2.11.5 which is referenced in that new process appears to effectively be going through in principle the CR review process. Would we like to set the expectation that we need to follow this process for new registry entries for the did-spec-registries or will this be limited to only "core" features?

[msporny]

This PR failed to achieve consensus during the last WG call. Closing without applying it.