Section 3.3. - on random least significant bits

[fabiolimace]

In the current draft the section 2.3 says that the random component of 64 bits may be:

(a) filled with random bits; or (b) filled with application defined values for uniqueness.

I have some considerations about it:

(0) I would like to remember that to be consistent with the other RFC-4122 versions, the first 2 bits of the random component should be set to ONE and ZERO, respectively.

(1) For the item (a) I propose that, in the case that more than one UUID v6 is generated within the same timestamp, the random component is incremented by 1. This is the approach adopted by the ULID specification*.

(2) For the item (b) I also propose to recommend that the 14 bits (2^14 = 16384) that are used for clock sequence in the version 1 could be used to embed an application defined value for uniqueness. The name continues the same, but the purpose changes, and the application decides what to put in these bits. I think that it could be easier to the existing libraries that already implement clock sequence. But in this case the clock sequence should not be incremented.

So the structure could be one of these two:

(1) In the LSB, 2 bits are fixed, and the remaining 62 are random

|-------MSB--------|-------LSB-------|
 00000000-0000-6000-8000-000000000000
|------------------|-----------------|
     timestamp           random

(2) In the LSB 2, bits are fixed, 14 bits are uniquifier, the remaining 48 are random

|-------MSB--------|-------LSB-------|
 00000000-0000-6000-8000-000000000000
|------------------|----|------------|
     timestamp    clockseq random

0: any value
6: fixed version
8: fixed variant (2 first bits are ONE and ZERO)

(3) As a consequence of the item (1), the multicast bit is not required anymore as in the version 1. Is it necessary to mention that in the draft?

Footnote:

• ULID Specification: https://github.com/ulid/spec

[bradleypeabody]

(0) I would like to remember that to be consistent with the other RFC-4122 versions, the first 2 bits of the random component should be set to ONE and ZERO, respectively.

Yes I see this in the spec but honestly have no idea why it is there.

Also, to be clear, version 6 UUID is are closer to Version 1 than anything else. The idea is that instead of a MAC address it could just be a random value.

I agree with your statement about incrementing in case of collision, but I feel like this is an implementation detail.

My general view of the existing specification is that it is over-specified. If you are writing code that has some locking mechanism to synchronize values that are being generated simultaneous, then really it does not matter how you change which fields to ensure uniqueness - nobody reads these fields after the value is generated. So all of this stuff about in which exact cases which fields are incremented, while not wrong or incorrect, I think is really an implementation suggestion. The only guarantee should be that unique values are produced. Again, nothing parses these values after generation (with the exception of the time stamp - that can be useful - but the rest not).

Factually you could ignore clock sequence and node - the entire last 64 bits, and fill it with random data, and if there's a duplicate just try again. That's a workable strategy too.

So I do get where you are coming from, but I want to simplify and boil it down to the core issues, not add more specification that may or may not be useful in all cases. Many UUID implementations already take liberties with the details of how the values are generated, and it is for this same reason.

[fabiolimace]

I read the draft again after you responded to my comment. It couldn't be clearer than that.

I agree with you on most things. I think it is a very good idea to only require the order of bytes of the timestamp in the first 64 bits. It helps to come up with many implementation options for different specific needs.

The increment suggested in item (1) may be an implementation detail that need not be mentioned in the document. And forget item (2), now I see that it is a bad idea. I just wanted to contribute some suggestions. You can close this issue.

I really like your initiative. You are doing an excellent job!

[bradleypeabody]

Cool and thanks @fabiolimace, makes sense.

I will keep these points in mind though for the implementation suggestion aspect as the draft progresses.