standard: erratum — editorial batch (RFC 9562, ld+json media type, aliases.json, tombstone rationale, namespace note)

[maehr]

Affected spec version

v0.1.0-draft

Affected section

Multiple — see per-item references below.

The problem

A small batch of editorial / definitional nits found during the pre-1.0 review. Filing as one issue because each item is trivial; happy to split if maintainers prefer one PR per item.

1. UUID normative reference is RFC 4122 (obsolete). /standard/specification/ § "Normative references" cites RFC 4122 (specification.md:411). RFC 4122 was obsoleted by RFC 9562 (May 2024), which defines the modern UUID format/registry.

2. JSON-LD alternate link uses application/json. /standard/specification/ § 13 currently says:

   The HTML representation SHOULD advertise the JSON-LD sibling via <link rel="alternate" type="application/json" href="…json"> … (specification.md:279)

   JSON-LD's registered media type is application/ld+json (RFC 9727 / IANA registration). Using application/json means JSON-LD-aware clients won't pick the link up via content negotiation.

3. aliases.json is referenced but not schema-defined. /standard/versioning/ line 103 introduces aliases.json as the mechanism for presentational URL aliases, but no section defines its schema, fields, or validation rules. Either define it (location, JSON shape, validation) or remove the reference and describe the mechanism inline.

4. Tombstone rationale fields are referenced but not defined. /standard/versioning/ line 107 says blocked records "remain in exports with status: blocked and tombstone rationale fields." No section defines those rationale fields (names, required/optional, expected values). Define or remove.

5. UUID namespace constants note. /standard/identifier-syntax/ lines 19, 110 derive both reference and mapping namespaces via uuidv5(uuid.NAMESPACE_DNS, "textrefs.org/reference") / "textrefs.org/mapping". The strings contain slashes (not valid DNS labels), which is fine — NAMESPACE_DNS is just a frozen UUID constant used as a salt and the input to UUIDv5 is opaque bytes — but a one-line note avoids reader confusion and pre-empts "this looks wrong" review comments. Add an explanatory sentence near each derivation.

Proposed correction

1. Update the normative references table entry to RFC 9562; replace the link in specification.md:411. UUIDv5 wire format is unchanged between 4122 and 9562, so no implementation impact.
2. Replace type="application/json" with type="application/ld+json" in specification.md:279 (and any duplicated examples in the docs / src/content/docs/get-started/). Verify the generated HTML actually emits this header.
3. Either: (a) add a "URL aliases" subsection defining aliases.json's location, shape, and validation; or (b) drop the filename reference at versioning.md:103 and describe the alias mechanism prose-only. Pick one — current state is half-named.
4. Either: (a) add a "Tombstone rationale fields" subsection listing field names and values; or (b) remove the phrase "tombstone rationale fields" from versioning.md:107 and rely on status: blocked alone. Pick one.
5. Add a sentence at identifier-syntax.md:19 and :110 along the lines of: "NAMESPACE_DNS is used here as a frozen UUIDv5 salt; the second argument is treated as opaque bytes, so the slash in textrefs.org/reference does not require a valid DNS label."

Each item is independent; happy to PR them in one batch or split — maintainer's call.