Getting Multibase ready for IETF review (align with IANA terminology and registry governance style)

[bumblefudge]

For pre-PR context, see original issue on W3C-CCG discussion repo here and multiformats#65

[rvagg]

Could you try and column-align both forms of the table please? Removing the word "Unicode" in the second column would help compact it a bit if that's not unreasonable to remove it.

You're also welcome to note in there that the practical bases only have a single-byte prefix indicator, and that implementations may choose to only concern themselves with the single-byte case. The emoji one just pushes the boundaries a bit but it's not expected that it gets much practical use and most people wouldn't be upset if an implementation didn't use it.

[bumblefudge]

(Dear merger - please squash these before merging, lots of little commits)

[vmx]

I'm unsure if "code" is the right word here. It's more like the "ASCII representation", so perhaps just "ASCII"? I would then move it into the second (column) as the Unicode is really the canonical thing.

[AaronGoldman]

The goal is to communicate that the first column is the display name for the encoding and the second column is the machine readable prefix.

code => display name for humans
Unicode => machine readable prefix (runes)
utf-8 => machine readable prefix (bytes)

I don't know if these name communicate the conesepts well or not.

[vmx]

In the newest version the columns are called:

Unicode => The thing that implementations should care about
Character => Display name what users see

Is that better?

[vmx]

I don't get the ToC reformatting, but it's not a blocker for me.

[vmx]

There is one little comment left from me, but I don't consider it a blocker.

Before this is merged, I'd like to see an approval from @rvagg and @Stebalien as well (or at least a "it's OK to be merged").

[vmx]

Just for everyone's information: one big change here is the 0x00 is no longer considered a Multibase. Though we keep it as "reserved" for now (perhaps we should remove it completely). This aligns with the comments at #85 (comment) and also what we talked about the IPLD community/sync call.

[Stebalien]

Cursory LGTM (I didn't read it in-depth, just looked at the high-level changes).

I was initially a bit concerned about specifying this in terms of unicode code-points, but that shouldn't tie us to any specific encodings, it just adds some clarity. In theory, any encoding can (and likely is) mapped to unicode code-points.

Deprecating NUL is definitely the right thing to do.

[rvagg]

Minor change on README and major concerns with the issue templates; can you tell I'm not a fan of issue templates? If we must have issue templates, can we make them less prickly for the user and more actionable for maintainers? In general I'm happy to answer people's free-form questions in issues and would prefer people self-serve when it comes to submitting stuff, that's what PRs are for.

[rvagg]

From the README:

If you'd like to switch a project over to multibase, whether by creating a new multibase implementation or building on one of those listed above, please file an issue in this repository using the "Interested in implementing" issue template.

This isn't really actionable and I'm unsure what we're supposed to do with these issues. Just a nod and and ignore? I'd like these to be actionable and not leading to cruft in the issue tracker since we already have a tendency toward cruft-buildup.

I think the purpose here might be to get a new implementation/library/system onto a list somewhere, can we just shunt people to open a pull request to add their thing? The "express interest" only really tells me that the issue opener is going to open a new issue telling us what they have in their head, which may be awesome, or may be terrible, but it's not really actionable without a thing or an explicit question--which is fine, but this isn't a template for a question.

[bumblefudge]

Would this be better handled by a GH "Discussion"? TBH I wanted an "expressed interest" tracker somewhere for IETF purposes, because the perennial question of standardization is "for whom is this actually useful outside of the PLN/IPFS community that spawned it?"...

[bumblefudge]

In the interest of not holding up this PR, I have just cut that template for now and will open a new PR adding it as a Discussion template.

I only realized just now that discussion templates are also a thing! Separate PR incoming.

[rvagg]

If would also like to reserve a prefix for compatibility, please file a separate issue in this repository using the "New Registration" issue template.

This one's a little better, but I'd still prefer this in PR form rather than this asking us to do the PR for them; I'm not really a user of github issue templates (nor particularly a fan! I did my time in JIRA hell already so I can do without the extreme structure), do we have the tools to shunt people toward a PR with all of these things filled out there?

[bumblefudge]

Will rework the semantics so that it's more of a placeholder. Maybe something like "open this issue so we can give you timely feedback before you start, but please open a draft PR soon and work there until you can close the issue you just opened" would work?

[bumblefudge]

Does the insertion of this checkbox make it explicit enough?

[rvagg]

Yeah, I guess -- what I'd like to avoid here is a collection of poorly maintained opened issues with no clear path to getting them closed. If we permission people opening unactionable issues, then we can't take action and have no clear path to closing them.

I think it's fine to have issues opened flagging intent to register, but we have to acknowledge that there's a limit to how long those will be held.

[rvagg]

I guess we've tinkered enough, thanks for your patience and persistence @bumblefudge
anything else @vmx?

[vmx]

I think it's good to be merged. Thanks @bumblefudge for the hard work and @rvagg for being so thorough about the issue templates, I totally agree that it's good to reduce non-actionable issues.

[rvagg]

I hope a squash merge is OK @bumblefudge, lots of info in these commits but there's too many. If you'd prefer to keep more context when we can force push it out and put some new chain in, but 33 commits is a bit too many!

[ben221199]

I see a extra column with codepoint information. That is nice. The status reserved is exactly what I had in mind, but maybe the column name could be state instead of status. Also I don't know if having none as encoding name is the right way to do. I think I prefer it being empty. Also I think that a relevant description is more useful than (No base encoding).

[ben221199]

Also, identity is removed for 0x00. Is something planned to add it back with another codepoint?

[rvagg]

See discussion above re NUL, we've all agreed it was a historical accident and the only place it's really used is in dag-cbor where it's recorded in the spec as something of a historical accident. It's still there if people really want to use it, but there's not really a good justification for it.