w3c-ccg / multibase

An IETF Internet Draft for the Multibase data format

The Multibase Data Format

This specification describes a forward-compatible data model for expressing raw binary data in a variety of base-encoding formats such as base32, base58. and base64.

Raw binary data is often encoded using a mechanism that enables the data to be included in human-readable text-based formats. This mechanism is often referred to as "base-encoding the data". Base-encoding is often used when expressing binary data in hyperlinks, cryptographic keys in web pages, or security tokens in application software. There are a variety of base-encodings, such as base32, base58, and base64. It is not always possible to differentiate one base-encoding from another. The purpose of this specification is to provide a mechanism to be able to deterministically identify the base-encoding for a particular string of data.

You can view an HTML version of the specification here:

https://datatracker.ietf.org/doc/html/draft-multiformats-multibase

We encourage contributions meeting the Contribution Guidelines. While we prefer the creation of issues and Pull Requests in the GitHub repository, discussions often occur on the public-credentials mailing list as well.

Other useful links

• Multiformats Website
• Multibase Website
• Public group email archive

multibase's Issues

Multibase (and multihash and others) could be replaced with tagged CBOR format

It seems, that this standard submission is just redundant in RFC.
All its serialization formats could be added into CBOR tag registry and the serialization itself is not very different from tagged CBOR itself (it provides type and tag by itself).

Review by Peng Shuping

@shupingpeng provided the following review:

I read through your drafts on multibase and multhash. I got a few questions and comments.

1. Both drafts are Informational. Do you intend to put them as in the Informational track? Since it requires the IANA registries, should it be in the Standards track?

2. “Given data 'd' encoded into text 's', what base is it encoded with?”. You are talking about encoding bytes into text, but here you use ‘d’, what are the bytes ‘d’ is corresponding to? The example would be better to show using different base-encodings the same bytes could result in the same text, right? That could give your work much stronger motivation.

3. In the multihash draft, the “avoiding” part of this sentence could be removed. :p “This vastly simplifies the upgrade process, avoiding the waste of hundreds or thousands of software engineering hours, deep frustrations, and high blood pressure.”

Best Regards,

Shuping

Follow the guidelines for creating an IANA registry

https://www.iana.org/help/protocol-registration and https://www.rfc-editor.org/rfc/rfc8126.html say how to create IANA registries, and the current draft is missing some important parts, like the registration policy.

Link in README bad to html version of spec

https://w3c-dvcg.github.io/multibase/ should be https://w3c-ccg.github.io/multibase/

Not all identifiers fit in a single byte

https://datatracker.ietf.org/doc/html/draft-multiformats-multibase-07#name-the-multibase-format says

The encoding algorithm is a single character value that is always the first byte of the data.

However, the Multibase Algorithms Registry includes two entries where that's either not true or not obviously true.

• The "identity" algorithm's identifier is "0x00", which appears to be a string, but might be a confusing attempt to indicate the 0 byte. (As opposed to the base2 identifier which is the "0" character and the 0x30 byte.)
• The "base256emoji" algorithm's identifier is "🚀", which definitely doesn't fit in a byte, and might be an attempt to indicate that the identifier is the U+1F680 (Rocket, 🚀) character, in some unspecified encoding.

This should all be consistent and clearly identify the initial byte values that identify the various algorithms.