I know defining UUIDv10 isn't a thing yet, but I wanted to ask if we can take into account a special form within UUIDv10. I don't see a need to register this special form already in the upcoming RFC, it is also possible to do this in a later RFC, but I hope people will not forget this special form when the time is there to define UUIDv10.
I'm talking about AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA. In binary, this will be 10101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010, a alternating sequence of bits. I would propose Alternating UUID as name. This UUID begins with 10xxxxxx in the variant/family field, making it the OSF/DCE variant. In the version field, it has the bits 1010, making it UUIDv10.
There is no need to do something now. It is possible to already add the special form in the upcoming RFC, but I don't see a reason to force that, because we also can do this later. I only ask to keep this in mind for the future.
I know defining UUIDv10 isn't a thing yet, but I wanted to ask if we can take into account a special form within UUIDv10. I don't see a need to register this special form already in the upcoming RFC, it is also possible to do this in a later RFC, but I hope people will not forget this special form when the time is there to define UUIDv10.
I'm talking about
AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA
. In binary, this will be10101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010
, a alternating sequence of bits. I would proposeAlternating UUID
as name. This UUID begins with10xxxxxx
in the variant/family field, making it the OSF/DCE variant. In the version field, it has the bits1010
, making it UUIDv10.There is no need to do something now. It is possible to already add the special form in the upcoming RFC, but I don't see a reason to force that, because we also can do this later. I only ask to keep this in mind for the future.
Thanks