Re: DID Core Proposed Recommendation draft ready for review

Good summary, thanks.

+1 to "allow new features" from mesur.io as well in case I am not able to
be on the call

Michael Prorock
CTO, Founder
mesur.io

On Sun, Jul 18, 2021, 13:40 Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 7/18/21 8:53 AM, Mike Prorock wrote:
> > Manu, there is some good flexibility from item 2: "allow features to be
> > added to it after Recommendation." Are there any concerns from your end
> > related to this, process wise, or otherwise, that may cause issues down
> the
> > road with adoption of that clause?
>
> Yes, that's the gambit (unintended consequences), this is new in W3C
> Process
> 2020 (and is thus new to everyone).
>
> It's not really that risky of a position to take, IMHO. Part of it comes
> from
> an attempt to avoid something like this happening again (which was a
> rolling
> decade-long disaster that continues to this day):
>
> https://en.wikipedia.org/wiki/HTML5#W3C_and_WHATWG_conflict
>
> ... but more importantly, I think we're specifically doing it to help the
> spec
> track reality in the market.
>
> Case in point is the Verifiable Credentials Data Model specification...
> while
> we have a Maintenance group for it, we can only fix bugs, not add new
> features
> (we need a recharter for that)... and that's causing the spec to show it's
> age
> in places. Nothing really bad, but it would be nice to have the option of
> adding say "title" and "description" to VCs, for example. :)
>
> If we had flipped the "allow new features" bit on the VC spec (we couldn't
> have done that, btw, Process 2020 wasn't ratified by the time we went to
> REC)... then we wouldn't be in the position we are in with the VC spec.
>
> So, we're learning from our mistakes and trying to take a new option that
> would allow us to add features that the community deems useful.
>
> The downside here is that there may be new REC versions of the
> specification
> within a year or so after first REC, so some large enterprises/governments
> might not like not having the spec stability of 5+ years that they're used
> to.
> To be fair, they can always implement against a single REC and choose to
> not
> upgrade to the latest (and that's valid). That said, the world has sort of
> moved on from the age of stable software to an age of Continuous
> Integration
> and Continuous Deployment... we expect to get rolling upgrades these days
> for
> software. This is the standards version of that.
>
> In any case, it's all new to me (and most everyone else in standards)...
> and
> the benefits far outweigh the downsides IMHO. I'm a +1 to flip the "allow
> new
> features" bit. You can read more about that process here:
>
> https://www.w3.org/2020/Process-20200915/#allow-new-features
>
> https://www.w3.org/2020/Process-20200915/#revised-rec-features
>
> ... and kudos to Brent for catching this; I was clueless that we had to
> explicitly state this in the spec -- I just thought it automatically
> became an
> option if we followed Process 2020.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>