# UUIDv6, UUIDv8 and standard namespaces

## UUIDv6

UUIDv6 is RFC 9562's reordered form of the UUIDv1 field model. It preserves the
60-bit Gregorian 100-ns timestamp, 14-bit clock sequence and 48-bit node fields,
but stores timestamp bits from most significant to least significant so the UUID
sort order has better database locality.

MoonUUID exposes:

```moonbit
@moonuuid.v6_from_parts(timestamp_100ns, clock_seq, node)
@moonuuid.gregorian_ts_100ns(uuid)
@moonuuid.v6_clock_seq(uuid)
@moonuuid.v6_node(uuid)
```

The RFC Appendix A vector is covered by tests:

```text
1ec9414c-232a-6b00-b3c8-9f6bdeced846
```

RFC 9562 recommends UUIDv7 instead for systems that do not need UUIDv1
compatibility.

## UUIDv8

UUIDv8 is explicitly application/vendor-defined. RFC 9562 defines only the
version and variant positions; the remaining 122 bits belong to the application.

MoonUUID therefore exposes only a transparent field constructor:

```moonbit
@moonuuid.v8_from_parts(custom_a, custom_b, custom_c)
```

with widths 48, 12 and 62 bits respectively.

MoonUUID does not claim uniqueness semantics for UUIDv8. Applications define
those semantics themselves.

## Standard namespaces

The RFC namespace UUIDs are exposed as functions:

```moonbit
@moonuuid.namespace_dns()
@moonuuid.namespace_url()
@moonuuid.namespace_oid()
@moonuuid.namespace_x500()
```

These are intended primarily for UUIDv3 / UUIDv5 name-based generation.