RE: DID Core Proposed Recommendation draft ready for review

This email is most likely stating the obvious on “allow new features”. Nevertheless, I’d like to make sure that we achieve consensus about the following.

  *   There shall be unequivocal version control
     *   Implementors shall be able to unequivocally reference to a specific version, and to a specific feature set
     *   There shall be a unequivocal distinction between corrections and new features
     *   Implementations should unequivocally announce/describe their own version and supported features
     *   There should be unequivocal rules when implementations of different versions and/or different supported feature sets interact

Specifying forward and backward compatibility is a best practice in standardisation, see also https://docs.confluent.io/platform/current/schema-registry/avro.html


  *   One well-known solution is to introduce a “compatibility field” with every new feature codepoint. This field specifies what the recipient should when receiving an unknown feature codepoint.
     *   Ignore and proceed as if the unknow feature were not there
     *   Pass on the unknown feature to processes further downstream
     *   Abort and return an error message
     *   Abort silently
     *   ...
     *   The field may also be “role-based”: “pass on if you are a proxy, abort if you are an end point”

Specifying negotiation is a best practice in standardisation

  *   Learning about the version and feature set at the other side, and revert to a mutually compatible version and feature set
  *   Performing an offer-answer negotiation (cf IETF Session Description Protocol)
  *   Return “deprecated” warning messages

3GPP has the most advanced version control that I am aware of. It is a cumbersome system from the maintenance perspective. However, it is has also been very effective in the introducing compatible new feature sets into smartphone and mobile networks worldwide.

  *   3GPP has annual releases: release 15, 16, 17, 18, ...
  *   Each release has a new feature set, each release also manages deprecations
  *   The releases have a 3-stage waterfall pattern
     *   Stage-1: Use cases and requirements are specified in release N documents
     *   Stage-2: Associated architecture is specified in release N+1 documents
     *   Stage-3: Protocols and data models are specified in release N+2 documents
     *   If the specification of a new feature misses any of he stage deadlines, it can go into a next release for that stage
  *   Corrections are kept synchronised between release
     *   If an error is found and corrected in release X-2, then it will be identically corrected in releases X-1 and X.
  *   There is the classic three-level version numbering: https://www.3gpp.org/specifications/specification-numbering/81-version-numbering-scheme


Oskar


From: Drummond Reed <drummond.reed@evernym.com>
Sent: 18 July 2021 23:14
To: Mike Prorock <mprorock@mesur.io>
Cc: Manu Sporny <msporny@digitalbazaar.com>; W3C DID Working Group <public-did-wg@w3.org>
Subject: Re: DID Core Proposed Recommendation draft ready for review

Evernym is also a +1 to this "allow new features" option for all the reasons Manu states. I personally believe this is going to become the new normal now that the W3C has formally recognized this option.

=Drummond

On Sun, Jul 18, 2021 at 10:43 AM Mike Prorock <mprorock@mesur.io<mailto:mprorock@mesur.io>> wrote:
Good summary, thanks.

+1 to "allow new features" from mesur.io<http://mesur.io> as well in case I am not able to be on the call
Michael Prorock
CTO, Founder
mesur.io<http://mesur.io>

On Sun, Jul 18, 2021, 13:40 Manu Sporny <msporny@digitalbazaar.com<mailto: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/


This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.