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
- [dispatch] Finding a home for Multibase and Multi… Manu Sporny
- Re: [dispatch] Finding a home for Multibase and M… Ben Schwartz
- Re: [dispatch] Finding a home for Multibase and M… Manu Sporny
- Re: [dispatch] Finding a home for Multibase and M… Tim Bray
- Re: [dispatch] Finding a home for Multibase and M… Benjamin Goering
- Re: [dispatch] Finding a home for Multibase and M… Robin Berjon
- Re: [dispatch] Finding a home for Multibase and M… Eric Rescorla
- Re: [dispatch] Finding a home for Multibase and M… Manu Sporny
- Re: [dispatch] Finding a home for Multibase and M… Carson Farmer
- Re: [dispatch] Finding a home for Multibase and M… Ambrose Chua
- Re: [dispatch] Finding a home for Multibase and M… Volker Mische
- Re: [dispatch] Finding a home for Multibase and M… Eric Rescorla
- [dispatch] Demonstration of Implementer Support f… Manu Sporny
- [dispatch] Demonstration of W3C Implementer Suppo… Manu Sporny
- Re: [dispatch] Demonstration of W3C Implementer S… John C Klensin
- Re: [dispatch] Demonstration of W3C Implementer S… Manu Sporny
- Re: [dispatch] Demonstration of Implementer Suppo… Martin J. Dürst
- Re: [dispatch] Demonstration of Implementer Suppo… Manu Sporny
- Re: [dispatch] Demonstration of Implementer Suppo… worley
- Re: [dispatch] Demonstration of Implementer Suppo… Ross Finlayson