Describe algorithm for randomUUID

[bcoe]

We should, in steps, describe the algorithm for randomUUID(). Some good references for the level of detail we should use, and for the spec markup language are:

• the definition of getRandomValues() in the WebCryptography spec.
• other in process WICG specs, I found myself referencing https://wicg.github.io/contact-api/spec

Open Question?

How detailed should we be?

Is it worth fully defining the v4 algorithm (given its simplicity), with direct reference to getRandomValues(), or

Should we just indicate that we return a DOMString, generated using the RFC4122.

Who'd like to write this part of the spec?

@broofa or @ctavan, either of you interested in writing up this part of the document?

[domenic]

Is it worth fully defining the v4 algorithm (given its simplicity), with direct reference to getRandomValues(),

This is attractive, especially for implementers. However, some caveats:

• You should not directly reference other methods, as those can be overridden with JavaScript. That is, the algorithm should not break just because someone did crypto.getRandomValues = () => {}. Instead, you should just use the same underlying concepts as getRandomValues(). Looking at https://w3c.github.io/webcrypto/#Crypto-method-getRandomValues, this looks to be just "cryptographically random values of the appropriate type". (I guess in this case you could say a specific type, e.g. "8-bit signed integer" or whatever.)

• If the intent is to match RFC4122, this version would make that non-obvious. So, you might want to include a non-normative NOTE saying something about the intent.

Should we just indicate that we return a DOMString, generated using the RFC4122.

This was my initial instinct before reading this issue. However, actually reading https://tools.ietf.org/html/rfc4122 made me reconsider. I can't find any reasonable algorithm in there; https://tools.ietf.org/html/rfc4122#section-4.4 seems almost useless in isolation, and rather non-algorithmic.

Plus, the entire RFC seems to be in terms of bits, not strings, so (unless I'm missing part of it) you'd need an algorithm for converting bit sequences into strings on top of RFC4122.

So, my instinct is now toward the first option.

[bcoe]

Plus, the entire RFC seems to be in terms of bits, not strings, so (unless I'm missing part of it) you'd need an algorithm for converting bit sequences into strings on top of RFC4122.

When I was reading through the spec today, I came across this section, which codifies the string representation.

Edit: added a note to the spec pointing to this section of RFC4122.