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

[Manu Sporny <[e-mail]>]

On Sun, Mar 26, 2023 at 3:56 PM John C Klensin <[e-mail]> wrote:
> (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?

The Multiformats work is being used in W3C draft specifications, and
ideally, our specs at W3C would benefit from a stable reference to a
few Multiformats specs and registries instead of what they're doing
now, which is picking and choosing subsets and documenting them
directly in each specification. The Multibase and Multihash I-Ds are
each, a very light spec that establishes a registry. Since IANA does
registries pretty well, and since Multiformats are "lower in the
stack" than most W3C specs, IETF felt like a natural place for the
work.

AFAIK, there are no W3C members that I know of that have plans to
standardize Multiformats at W3C. The preference is to have
Multiformats RFCs at IETF, including IANA registries, that W3C specs
can refer to in a normative way.

> 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?

Yes, the assertion is that the work is sufficiently distinct. The W3C
specifications would normatively refer to some of the Multiformats
RFCs and registries established at IETF.

To provide an example, a W3C specification would say something like:
"The cryptographic hash for the `foo` property is encoded as a
Multibase-encoded Multihash value where the multibase header is 'u'
(base64url-no-pad) and the multihash header is 0x16 (SHA3-256) as
defined in RFCxxxx and RFCyyyy, respectively."

> 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?

As is probably evident from the first two answers, a Joint Development
Agreement would probably be unnecessary as the separation between the
two pieces of work are fairly clean.

> (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?

The IETF would create a stable reference for the specification and a
more stable registry for the work. The multibase and multihash
registry currently exists as a CSV table in a Github repository that
is being maintained by a few individuals. The table largely mirrors an
IANA registry and so having a more permanent home for the table
(rather than a Github repo) would make it possible for us to reference
something from the W3C specifications instead of pulling in parts of
the table into the W3C specifications in an ad-hoc manner.

> 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?

Given the nature of the specifications, which are effectively var-int
encoded headers, there isn't much that could change at this point. I
do expect that if there were severe deficiencies found, that the
implementation community would want to change... but that would
effectively boil down to two general changes:

* We decide to use something other than varint to encode the header values.
* We decide to change the meaning of certain entries that have been
broadly deployed.

I expect the latter to be far more likely than the former, and (like
all things), it would become a discussion between the IETF group and
the implementers during the RFC drafting process.

> 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?

At present, I believe the commitment is to eventually deploy
implementations that are consistent with whatever the IETF reaches
through rough consensus. As I said above, given the type of
specifications we're talking about, the risk of things changing
greatly isn't as high as it is with other specifications.

If things change drastically, like with any specification, we can't
predict how support for a concrete I-D today would translate into
support for a significantly different RFC in the future.

All that said, I believe much of the support extended for the work and
the I-Ds that exist today would also apply for whatever that comes out
of the IETF process.

Did that answer each of your questions, John?

-- 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/