Re: [Multiformats] Multiformats Considered Harmful

["Martin J. Dürst" <[e-mail]>]

On 2023-09-07 21:09, bumblefudge von CASA wrote:
> Dear Prof Bormann and Melvin Carvalho:
> 
> Thank you very much for your bibliographic erratum and expression of interest, respectively. They're incorporated below in the longer response.
> 
> Dear Mike Jones:
> 
> Thank you for taking the time to spell out your feedback. I believe that clarifying the spec in a few places can address most of your concerns.

[snip]

>> 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.
> 
> Successful standards for self-describing encodings have also been adopted by communities rather than relying on fixed registries and protocols that define encodings in advance and universally. While it could be argued that interoperability with those kinds of protocol could be difficult, inefficient, or, in some cases, even zero-sum, I do not feel a universal claim to harmfulness is warranted, particularly without defining the criterion and context of interoperability.

There are examples both of where a single encoding is best, and when 
allowing some variety is best. And there are examples where the best 
choice varied over time. The difficulty may be to figure out which case 
one is looking at. Just because different people prefer different things 
isn't a reason to invent some "multi"thing; it may just be a sign that 
the consensus process isn't going too well (yet).

[longish example, sorry; you may skip to the end]
As an example, character encodings (usually designated using the 
"charset" parameter) for the Web evolved from a start with a single, 
undeclared character encoding (iso-8859-1, covering most of Western 
Europe). The reason for this was that it was simplest to start this way, 
and the choice of encoding resulted from the time and place the Web was 
created (1989 in Geneva).

Later, the charset parameter on the Content-Type header field was 
introduced. This allowed a wide variety of character encodings covering 
wide swaths of the world's scripts and languages. This was necessary at 
a time when a uniform, global encoding was "in the making", but not yet 
widely available. Browsers were supporting some subsets of character 
encodings, and people may have chosen their browsers (among else) based 
on what character encodings it supported.

In RFC 2070 (https://www.rfc-editor.org/rfc/rfc2070), we managed to at 
least nail down numeric character references (e.g. &#xABCD;) in HTML to 
Unicode. Later, Unicode, in the form of UTF-8, became more and more 
popular, to the extent that the WhatWG spec simply calls it "The 
encoding" (see https://encoding.spec.whatwg.org/#the-encoding).

Nowadays, use of UTF-8 is given at 98% of the Web (see 
https://w3techs.com/technologies/overview/character_encoding). Other 
encodings are still in use, and browsers support them because it's not 
too much work to keep old code. But they have mostly made it invisible 
for the user (see e.g. 
https://support.mozilla.org/en-US/kb/text-encoding-no-longer-available-firefox-menu).

As for registration of new "charset"s, effectively nothing is going on, 
because there's no need for anything new. UTF-8 covers everything there 
is, and if it's not in Unicode, it's easier to deploy by adding it to 
Unicode than be defining a new "charset". And many if not all new 
protocols/formats restrict themselves to UTF-8 only these days, for 
obvious reasons.
[end of longish example]

Multibase deals with something much simpler than characters, namely 
bytes. The different bases were mostly introduced because the different 
contexts where the data would be carried had different restrictions on 
the set of usable characters. Putting various bases together with 
multibase means that such restrictions can't be made. So the question 
remains: Why multiple bases? The conclusion should be that multiple 
bases are not needed. In context, it should always be clear what base is 
used. And there should be no "out of context". If you are out of 
context, then you might not even know that you deal with a multibase 
"thingy". If you have to specify that you're dealing with multibase, you 
can as well specify that you are dealing with baseX (where X is a single 
choice).

Interest in decentralization shouldn't mean that each and every element 
of a protocol is decentralized with many more options than necessary. 
Ideally, the options are available only at those points where they 
matter, but at all points where they matter. For base encodings, they 
don't matter; a single option (which is the same as no option) in each 
specific place is enough.

Regards,    Martin.