Discussion: Alternate Text Encoding Methods (Crockford's Base32, etc)

[fabiolimace]

I think the 'base32hex' encoding, decribed in the section 7 of the RFC-4648, should be used instead of creating a new one. I know that the algorithm is the same with a different alphabet, but the 'base32hex' already exists for the same purpose.

[bradleypeabody]

The reason I wanted to change the base32 alphabet is because it makes implementation (particularly as a db primary key) simpler when UUIDs always sort exactly the same when treated as raw bytes. This holds true for the binary format I'm proposing, but I think it would be even better if it was also true for the text format(s). For some applications sequence is critical, and having the text format when sorted return values in one sequence and the binary another has no up side, only down sides. In my opinion this outweighs the benefit of using the same alphabet that has been used in the past.

@douglascrockford 's base32 (https://www.crockford.com/base32.html) actually looks like a better alternative to what I've laid out in the draft and has the same properties. I'm considering updating the draft to use that.

[fabiolimace]

I understand why you wanted to change the alphabet order 'base32' from A-Z2-7 to 2-7A-Z. However, RFC-4648 also describes another alphabet called 'base32hex' that has this char sequence: 0-9A-V. According to section 7 of the document, "a property of this alphabet, which lacks the base64 and base32 alphabets, is that the encoded data maintains its sorting order when the encoded data is compared in bits".

I agree that Crockford base32 is much better than 'base32' and 'base32hex'. In addition to the property of keeping the sort order, it avoids the confusion of similar characters and prevents accidental obscenity. I am not a native English speaker, but I know some obscene words that can be formed with the letter 'U'. There are other extremely obscene words with 'U' in romance languages ​​like Italian, Spanish, French and Portuguese. There is no need to mention them here.

Before opening this issue, I was thinking of suggesting Crockford encoding, but I was afraid it would not be approved, since 'base32hex' already exists for the sort order problem.

I vote for @douglascrockford 's base32 too.

P.S.: another point is that the Crockford's encoding is adopted by other projects like the ULID specification.

[bradleypeabody]

Okay, great. Unless some better idea comes along I'll update the spec with Crockford's base32 version the next time I do a round of changes. (I was not aware of the difference between 'base32' and 'base32hex' - thanks for pointing that out.)

I think the key idea here is to balance and weigh the concept of "don't invent something new if the existing standard solves the problem" against "use the best tool for the job". I'm sure the question of why not use RFC 4648 will come up again during the standardization process, but as it stands now I think the argument in favor of using something that sorts correctly ("best tool for the job") is stronger than the "use the existing standard" argument.

[fabiolimace]

Great! I have no objections. This issue is solved to me.

[fabiolimace]

@bradleypeabody , have you seem this IETF draft that proposes a compact representation for UUIDs?

The draft aims to update the RFC-4122 to include a new textual representation for UUIDs encoded to base64url or base32. The new representation is temporarily called "UUID-NCName".

[bradleypeabody]

Interesting - I will definitely look into it further and see if I can connect up with the author to collaborate.

[bradleypeabody]

I wrote to Dorian Taylor (the draft author) about the possibility of collaborating. We'll see where that discussion goes.

[fabiolimace]

Great!

Should we open this issue again to show that there is work in progress? Or is it better to leave it closed?

[bradleypeabody]

Good point, reopening it.

[daegalus]

I just wanted to add my voice that we should consider base32 encoding for sure, or base58 encoding that just adds both cases of letters. 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz which doesnt include 0s and Os. And it will make UUIDs fairly short.

If we do use base32, we should require it be lowercase, easier to distinguish certain characters in most fonts when they are lowercase.

I do also hope you merge with the NCName draft, the UUID format is a bit verbose and long for most usecases. so a different encoding would be great.

[bradleypeabody]

The current proposal does not include an alternate encoding, but let's see how the discussion goes with the IETF. Personally I am in favor of documenting Crockford's base32 (https://www.crockford.com/base32.html) as a valid alternative encoding.