Re: [Multiformats] Multiformats Considered Harmful
"Murray S. Kucherawy" <superuser@gmail.com> Wed, 06 September 2023 04:22 UTC
Return-Path: <superuser@gmail.com>
X-Original-To: multiformats@ietfa.amsl.com
Delivered-To: multiformats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E47FC14CE5E for <multiformats@ietfa.amsl.com>; Tue, 5 Sep 2023 21:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.844
X-Spam-Level:
X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 roKmv6w05q3r for <multiformats@ietfa.amsl.com>; Tue, 5 Sep 2023 21:22:17 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF81C14CE52 for <Multiformats@ietf.org>; Tue, 5 Sep 2023 21:22:17 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2be4d132654so6251821fa.0 for <Multiformats@ietf.org>; Tue, 05 Sep 2023 21:22:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693974135; x=1694578935; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qywVW92c/sFmAME9F0R1y0veiKfNtM1vyj8VusZRVmA=; b=aSjADo7lZxSMvInG/+JpEfSHn2wpmxZC9UwaCArTTxyvBjR+6XO+fi/Hrejk8JVgrQ +K3tqikamfCWrAjRGFMD6JaaNYNgCTZgyU8qE3szL9zXpzB8bRk8DtqvJBWrQzQ7bej+ OFcP50LOwo9jMHWNlTC3K/EnYwqUg42vVvU93jsrl4meL+Q/3crIHssZoUku9Uh1IFiP Vphzxy4Zv1siBSzeDzfAjq1bDceIcWKJKX2uuGxrXg/0qXf91O0f/BDsXTjjKHpr2z4u YBz5l2mKs7ew365i2X0ZAkdbaKurdxjCiyAw/2q9+ynjMVIMxaETCqMdRZuKu8xAR3OJ JDGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693974135; x=1694578935; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qywVW92c/sFmAME9F0R1y0veiKfNtM1vyj8VusZRVmA=; b=MS8ez6LsiUKthE1ZDAGP+FtNEHp9N4eP5ASz5GWJdhAgQBNWfXDbX5TPfPrB5qHeiW tuTE2mkGzpsNuOPwF22jNDEWukjIcCw6UFSPzghKKaF85b7kysSlfrIqjM7XkGMJT95i ohoU0nwJUYktucLnzogTvsEmvMNevjylpy7YAjVuy2LN8uTnHjLNkk8rET8gGLjD/Gvn Iy8iz/GF/+w3DziH0mFhEtCTz8ttwwczO/Srm+GFvJ1laC5j/MsxLUyGkZoZFwYdvpUK e8nvJZN13dx2VyFAlVZcI3FSSdI01qk6L7f16EFJ//QBopZ4U1beEkmlsTO6TmfWBlcm LJGQ==
X-Gm-Message-State: AOJu0YyrUMc8CAH2aZnGPWHiiV90NTbb/wkDA2LffzhykHp4UXUNAsNS jtMjr49X7Q8vY8lW3pCF18DzzWscroK1l0quljA=
X-Google-Smtp-Source: AGHT+IExWScF3JjYS6YkKaJ0nRoBaih7pUc/ew++1W0EkN2JMeH47B072CWU9kHD0+9q760VHR/K7Oygiq95VCVzVNI=
X-Received: by 2002:a19:c215:0:b0:500:d6ca:b3e5 with SMTP id l21-20020a19c215000000b00500d6cab3e5mr8914460lfc.4.1693974135005; Tue, 05 Sep 2023 21:22:15 -0700 (PDT)
MIME-Version: 1.0
References: <MW4PR02MB74285C15BBD628DD5F637C2EB7EFA@MW4PR02MB7428.namprd02.prod.outlook.com>
In-Reply-To: <MW4PR02MB74285C15BBD628DD5F637C2EB7EFA@MW4PR02MB7428.namprd02.prod.outlook.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Tue, 05 Sep 2023 21:22:02 -0700
Message-ID: <CAL0qLwa2unFCt3JrsGGHAbKjJ376krgpZjO81wDLBgzgsM4NAg@mail.gmail.com>
To: Michael Jones <michael_b_jones@hotmail.com>
Cc: "Multiformats@ietf.org" <Multiformats@ietf.org>, Barry Leiba <barryleiba@computer.org>, Francesca Palombini <francesca.palombini@ericsson.com>, Roman Danyliw <rdd@cert.org>, Paul Wouters <paul.wouters@aiven.io>
Content-Type: multipart/alternative; boundary="0000000000009364a80604a91647"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multiformats/A4umoNCeMd6tq4VZJ6uUSzf66mc>
Subject: Re: [Multiformats] Multiformats Considered Harmful
X-BeenThere: multiformats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion related to the various Multiformats data formats <multiformats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multiformats>, <mailto:multiformats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multiformats/>
List-Post: <mailto:multiformats@ietf.org>
List-Help: <mailto:multiformats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multiformats>, <mailto:multiformats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Sep 2023 04:22:21 -0000
Hi, Thanks for this feedback. I'm not taking a position on this at this point, but I want to mention that the DISPATCH discussion about this work took place at IETF 116, and the proceedings can be found here, in case reviewing that discussion might be helpful: https://datatracker.ietf.org/meeting/116/materials/minutes-116-dispatch-202303270030-00 -MSK, ART AD On Tue, Sep 5, 2023 at 7:03 PM Michael Jones <michael_b_jones@hotmail.com> wrote: > While I usually reserve my time and energy for advancing good ideas, I’m > making an exception to publicly state the reasons why I believe “ > multiformats <https://github.com/msporny/charter-ietf-multiformats/>” > should not be considered for standardization by the IETF. > > 1. Multiformats institutionalize the failure to make a choice, which is > the opposite of what good standards do. Good standards make choices about > representations of data structures resulting in interoperability, since > every conforming implementation uses the same representation. In contrast, > multiformats enable different implementations to use a multiplicity of > different representations for the same data, harming interoperability. > https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-03#appendix-D.1 defines > 23 equivalent and non-interoperable representations for the same data! > > 2. The stated purpose of “multibase > <https://www.ietf.org/archive/id/draft-multiformats-multibase-08.html>” > is “*Unfortunately, it’s not always clear what base encoding is used; > that’s where this specification comes in. It answers the question: Given > data ‘d’ encoded into text ‘s’, what base is it encoded with?*”, which is > wholly unnecessary. Successful standards DEFINE what encoding is used > where. For instance, > https://www.rfc-editor.org/rfc/rfc7518.html#section-6.2.1.2 defines that > “x” is base64url encoded. No guesswork or prefixing is necessary or useful. > > 3. Standardization of multiformats would result in unnecessary and > unhelpful duplication of functionality – especially of key representations. > The primary use of multiformats is for “publicKeyMultibase” – a > representation of public keys that are byte arrays. For instance, the only > use of multiformats by the W3C DID spec <https://www.w3.org/TR/did-core/> is > for publicKeyMultibase. The IETF already has several perfectly good key > representations, including X.509, JSON Web Key (JWK), and COSE_Key. There’s > not a compelling case for another one. > > 4. publicKeyMultibase can only represent a subset of the key types used in > practice. Representing many kinds of keys requires multiple values – for > instance, RSA keys require both an exponent and a modulus. By comparison, > the X.509, JWK, and COSE_Key formats are flexible enough to represent all > kinds of keys. It makes little to no sense to standardize a key format that > limits implementations to only certain kinds of keys. > > 5. The “multihash > <https://www.ietf.org/archive/id/draft-multiformats-multihash-07.html>” > specification relies on a non-standard representation of integers called > “Dwarf”. Indeed, the referenced Dwarf document lists itself as being at > http://dwarf.freestandards.org/ – a URL that no longer exists! > > 6. The “Multihash Identifier Registry” at > https://www.ietf.org/archive/id/draft-multiformats-multihash-07.html#mh-registry duplicates > the functionality of the IANA “Named Information Hash Algorithm Registry” > at > https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg, > in that both assign (different) numeric identifiers for hash functions. If > multihash goes forward, it should use the existing registry. > > 7. It’s concerning that the draft charter > <https://msporny.github.io/charter-ietf-multiformats/> states that “*Changing > current Multiformat header assignments in a way that breaks backward > compatibility with production deployments*” is out of scope. Normally > IETF working groups are given free reign to make improvements during the > standardization process. > > 8. Finally, as a member of the W3C DID and W3C Verifiable Credentials > working groups, I will state that it is misleading for the draft charter to > say that “*The outputs from this Working Group are currently being used > by … the W3C Verifiable Credentials Working Group, W3C Decentralized > Identifiers Working Group…*”. The documents produced by these working > groups intentionally contain no normative references to multiformats or any > data structures derived from them. Where they are referenced, it is > explicitly stated that the references are non-normative. > > > > -- Mike > > > > P.S. This was also posted at https://self-issued.info/?p=2408 and > https://www.linkedin.com/posts/selfissued_github-mspornycharter-ietf-multiformats-activity-7105001423574077441-6tcS, > referenced from https://twitter.com/selfissued/status/1699234431293370376, > and filed as an issue at > https://github.com/msporny/charter-ietf-multiformats/issues/2. > > >
- [Multiformats] Multiformats Considered Harmful Michael Jones
- Re: [Multiformats] Multiformats Considered Harmful Murray S. Kucherawy
- Re: [Multiformats] Multiformats Considered Harmful Michael Jones
- Re: [Multiformats] Multiformats Considered Harmful Carsten Bormann
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho
- Re: [Multiformats] Multiformats Considered Harmful Carsten Bormann
- Re: [Multiformats] Multiformats Considered Harmful bumblefudge von CASA
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho
- Re: [Multiformats] Multiformats Considered Harmful Orie Steele
- Re: [Multiformats] Multiformats Considered Harmful Orie Steele
- Re: [Multiformats] Multiformats Considered Harmful Michael Jones
- Re: [Multiformats] Multiformats Considered Harmful Richard Barnes
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho
- Re: [Multiformats] Multiformats Considered Harmful Robin Berjon
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho
- Re: [Multiformats] Multiformats Considered Harmful Robin Berjon
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho
- Re: [Multiformats] Multiformats Considered Harmful bumblefudge von CASA
- Re: [Multiformats] Multiformats Considered Harmful Robin Berjon
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho
- Re: [Multiformats] Multiformats Considered Harmful Robin Berjon
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho
- Re: [Multiformats] Multiformats Considered Harmful Robin Berjon
- Re: [Multiformats] Multiformats Considered Harmful Orie Steele
- Re: [Multiformats] Multiformats Considered Harmful Martin J. Dürst
- Re: [Multiformats] Multiformats Considered Harmful Martin J. Dürst
- Re: [Multiformats] Multiformats Considered Harmful Aaron Goldman
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho
- Re: [Multiformats] Multiformats Considered Harmful Manu Sporny
- Re: [Multiformats] Multiformats Considered Harmful Melvin Carvalho