mikronova/draupnir

DMTF fixtures — the external anchor for draupnir's Redfish server

These files are not written by this project. They are DMTF's own published schema, message registry and mockup, vendored verbatim so tests/redfish_server_conformance.rs checks src/redfish_server.rs against something outside this repository.

Why they are here at all

draupnir owns both ends of the Redfish protocol: the client (src/redfish.rs) and, behind the redfish-server feature, the server (src/redfish_server.rs). A test that drove one with the other would be a mirror — both ends can be wrong in the same way and every assertion still passes. A loopback green proves self-consistency, not Redfish.

So conformance is asserted against the files below, and only transport uses the client. If a property name, an @odata.type version, an enum token or an error template drifts from DMTF's, the conformance test goes red no matter how happily the two draupnir halves agree with each other.

What was fetched, from where, when

Fetched 2026-08-15 over HTTPS from redfish.dmtf.org and raw.githubusercontent.com. (www.dmtf.org/sites/default/files/standards/documents/DSP2043_*.zip — the packaged mockup bundle — answered HTTP 403 from this box; the same mockup content is published in DMTF's Redfish-Mockup-Server repository and was taken from there instead. See "Walls" below.)

Schemas — https://redfish.dmtf.org/schemas/v1/<file>

Message registry — https://redfish.dmtf.org/registries/Base.1.19.0.json

Mockup — https://raw.githubusercontent.com/DMTF/Redfish-Mockup-Server/main/public-rackmount1/<path>

DMTF's published public-rackmount1 mockup (the rack-mount server example that ships with DMTF's own Redfish Mockup Server). Only the five resources draupnir's client touches were vendored.

Verify with sha256sum from this directory; the conformance test also checks each file's hash at run time, so a fixture edited to make a test pass is itself red.

What the conformance test does with them

1. No invented property. Every key our resources emit must be a property the matching DMTF schema declares (or an OData/Redfish annotation the schema's patternProperties allows).
2. Nothing required is missing. Every name in the schema's required array is present in our resource.
3. The @odata.type is real. #Ns.vX_Y_Z.Type must be a definition the vendored schema file for that version actually declares.
4. The advertised values are DMTF's. ResetType@Redfish.AllowableValues ⊆ Resource.json#/definitions/ResetType; BootSourceOverrideTarget@Redfish.AllowableValues ⊆ ComputerSystem.json#/definitions/BootSource; BootSourceOverrideEnabled ∈ its own enum.
5. The mockup's shape is honoured. Where DMTF's mockup carries structure our server also claims — the Actions block and its target, the collection Members/Members@odata.count pair, the Boot object — the shapes must match.
6. The errors are the registry's. Every message src/redfish_server.rs can emit is compared field-for-field against the Base registry entry of the same Id (Message, MessageSeverity, NumberOfArgs, Resolution), and each live error payload is checked against redfish-error.v1_0_2.

Copyright

The schema, registry and mockup files carry DMTF's copyright notice (Copyright 2014-2024 DMTF) inside them. They are redistributed unmodified as test fixtures under DMTF's published-schema terms. Nothing here is draupnir's work.

Walls hit while assembling this

• https://www.dmtf.org/sites/default/files/standards/documents/DSP2043_2024.3.zip (also _2023.3, _2019.1) → HTTP 403, 5 620-byte block page, measured 2026-08-15. The packaged DSP2043 mockup bundle could not be downloaded from this box; the same mockup content was taken from DMTF's Redfish-Mockup-Server repository instead.
• https://redfish.dmtf.org/redfish/v1 is DMTF's Mockups landing page (HTML), not a live mockup service — there is no public Redfish endpoint on that host to diff against.