Brad Peabody

> This change causes a certain amount of cognitive dissonance RFC4122 causes it's own cognitive dissonance. The fact that one of the backward compatibility issues that comes up is implementations...

If we merge variant and version fields into one byte and combine it with using a common time format, we get things like this: https://play.golang.org/p/yWjgCNy_GQq ```go var v [16]byte binary.BigEndian.PutUint64(v[:8],...

Fair points. You're correct, it does add some more logic to these situations. However, variable length will break the "find a UUID in text" anyway. So will Crockford Base32 encoding....

To follow up from earlier discussion and from #58, my current stance on this is that the simplicity combining the variant and version fields introduces is worth the downsides. So...

> This is a classic "worst of two worlds" solution, IMHO. Pick one or the other... but let's please not be wishy-washy about how implementors indicate and detect versions. It...

@sergeyprokhorenko Unfortunately DBMSs and OSs do not contain any values that I'm aware of that have global uniqueness properties. The closest thing I can think of is an IPv6 address,...

I'll also just add here as another important factor: One should consider what the cost/penalty of getting a duplicate UUID is. This can be vastly different in different scenarios. Some...

@edo1 Agreed on IP addresses, it's not practical in many cases. > This clearly shows that a registry is a bad idea for a uniqueness guarantee. How so? I mean...

The reasons for not using MAC address are: - possible security issues with intentionally leaking data about which machine produced the value and machine manufacturer - uniqueness guarantees from MAC...

The general ideas that the draft is intended to communicate are: * For UUID6, it is valid and okay to just shift the bits around and use the rest of...