DTIF

Appearance

Conformance ​

Sections marked as "Note" or "Example" are non-normative. Everything else is normative.

As well as sections marked non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Normative sections use the terms MUST, SHOULD, and MAY as described in RFC 2119.

Conformance classes ​

  • Producer: serialises token documents. Producers MUST output UTF‑8 encoded JSON, SHOULD include a $version member, and MAY include $schema.
  • Consumer: reads token documents. Consumers MUST parse JSON, MUST resolve $ref values, MUST ignore unrecognised members beginning with $, and SHOULD warn on unknown $type values.
  • Validator: evaluates token documents. Validators MUST enforce this specification and MAY offer corrective guidance.

Error handling ​

  • Invalid JSON: Consumers MUST reject the document.
  • Unknown extension identifiers: Consumers MAY ignore but MUST preserve.
  • Unknown $type: Consumers MAY ignore but SHOULD warn.
  • Invalid $ref: Consumers MUST treat the token as invalid.
  • Unsupported units: Consumers MAY warn but MUST NOT reject the token.
  • Major $version mismatch: Consumers SHOULD warn and MAY ignore the document.

See Architecture and model for structural constraints and Format and serialisation together with Token types for token member semantics referenced by these requirements.