Re: [dispatch] Demonstration of W3C Implementer Support for Multibase at IETF (was: Re: Finding a home for Multibase and Multihash)

John C Klensin <john-ietf@jck.com> Sun, 26 March 2023 19:56 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0FDC15153E for <dispatch@ietfa.amsl.com>; Sun, 26 Mar 2023 12:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vHTZC1zUMVM for <dispatch@ietfa.amsl.com>; Sun, 26 Mar 2023 12:56:21 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BDEC14CF0D for <dispatch@ietf.org>; Sun, 26 Mar 2023 12:56:20 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1pgWTS-0009LH-NZ; Sun, 26 Mar 2023 15:56:18 -0400
Date: Sun, 26 Mar 2023 15:56:12 -0400
From: John C Klensin <john-ietf@jck.com>
To: Manu Sporny <msporny@digitalbazaar.com>, dispatch@ietf.org
Message-ID: <FA71DB2D93B4DB5EBECA3F8C@PSB>
In-Reply-To: <CAMBN2CScMLz9UzB-Fzp2NKPhZ-t4D0rZ72DnDPLPiVYAJ0Wt8A@mail.gmail.com>
References: <c9e0219c-0bca-32ab-56b4-ead9427e7578@gmail.com> <CAMBN2CScMLz9UzB-Fzp2NKPhZ-t4D0rZ72DnDPLPiVYAJ0Wt8A@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/eN_lCFjEU5aK_YyIBX3_tqwMck4>
Subject: Re: [dispatch] Demonstration of W3C Implementer Support for Multibase at IETF (was: Re: Finding a home for Multibase and Multihash)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Mar 2023 19:56:22 -0000


--On Sunday, March 26, 2023 14:33 -0400 Manu Sporny
<msporny@digitalbazaar.com> wrote:

> Similar to the recent email documenting support from the
> Multiformats implementer community, a number of implementers
> in the W3C Community wrote a similar letter to the W3C
> Verifiable Credentials Working Group in support of the use of
> Multiformats (specifically, Multibase and Multikey). To be
> clear, Multikey is NOT being requested for dispatch at this
> time... only Multibase and Multihash are. The full text of
> that letter of support[1] is included below:
> 
> To the Verifiable Credentials Working Group, Chairs, and Staff,
> 
> We, the undersigned, support the adoption of the EdDSA
> Cryptosuite[1] as a standards-track deliverable of the W3C
> Verifiable Credentials Working Group. We note that this
> cryptography suite is listed as in scope in the W3C VCWG
> Charter[2]. We are already using, or plan to use, this
> cryptography suite in our software and desire a ratified W3C
> global standard for the cryptography suite.
>...

With the understanding that what I am about to write are
questions, not a position on whether or not the IETF should be
involved with this...

(1) If  this work is being actively pursued in W3C, why is it
also being pursued in the IETF?  Or, if one prefers, if it is
being brought to the IETF, why is it also being pursued in W3C?

(2) In general, developing standards for the same thing in two
different bodies, especially ones with even slightly different
procedural rules, constituencies, and success criteria, leads to
subtle inconsistencies.  Those inconsistencies often lead to
confusion and may cause interoperability problems.  If the
intent is to bring the work to both IETF and W3C, what is the
plan to prevent such problems?   If the work being brought to
each body is sufficiently distinct that such problems would be
avoided (note the HTTP / HTML distinction as an example), can
you clearly explain the distinction and the boundary between the
two? 

(3) There are two other, fairly common, way to try to avoid the
inconsistencies suggested above.  One is to wait until the work
is complete (through to having a specification approved and
published or ready to publish as a standard) in one body and
then ask the other to endorse it by either republication or
reference.  The other, fairly common among many pairs of SDOs,
is to work out what is often called a Joint Development
Agreement where the work progresses in both bodies in parallel,
issues are resolved jointly, and approval and publication occurs
together (or not at all).  Noting that the IETF has almost never
been the endorser under the first type of arrangement or been
part of a task-specific Joint Development Agreement, would you
suggest one or the other in this case?

(4) As I read them, some of the endorsements imply that
organizations are either deploying, or ready to deploy, these
specifications already.  For example, I read "currently
implement, use, or foresee" in one of the messages you posted.
At least the first two would imply that the specs are finished
and not expected to change.  If so, what value would you expect
work in the IETF to add?  Conversely, if the IETF were to go to
work on the specs, find issues, and make changes, are those who
have already deployed committed (presumably without
foreknowledge of what the changes might be) to quickly retrofit
them into their implementations or would we end up with
inconsistent implementations, all claiming to be the
authoritative one?  And, for those who "foresee a need", does
their endorsement constitute a commitment to eventually deploy
implementations consistent with whatever the IETF reaches rough
consensus about?   In general, few organizations are willing to
make that level of commitment rather than saying something that
they interpret as "when there is a standardized spec, we will
examine it and, while we expect to move forward, an actual
decision depends on what it specifies".  The latter is a
statement of interest and intent and may be very helpful as such
but falls well short of endorsing the work itself. 

I trust these questions/issues will be addressed during the
DISPATCH discussion.

   john