GUARDAID Extension registry, version 2

GUARDAID reserves fields 1000 to 65535 of its packages for extensions, and leaves to a registry — never to whoever produces a package — whether each extension field may be ignored or must be understood. This is version 2 of that registry (registry-kind 3). It sets the entry and exit policy for extension fields. A field enters with a public defining document that has a permanent identifier, a free number, and a must-understand mark decided by a single test: could a reader that ignores the field admit something it would not otherwise have admitted. Numbers are never reassigned. An extension is never withdrawn, only marked as historical, so that what was signed with it stays readable. Whoever publishes a version executes the policy and does not decide it; anyone may publish the next version. Version 2 contains everything in version 1 — the five fields defined by GUARDAID Annex 1: interaction (1000), additional-data (1001), derived-mandate (1002), encounter-envelopes (1101) and retention-windows (1102) — and adds the two defined by the Annex 1 technical specification: presence (1003) and distress (1004), both must-understand. Number 1100 is unassigned and will not be reassigned. The set of test packages that version 1 declared missing now exists: the Annex 1 technical specification carries 52 cases with their bytes and the generator that produces them. This is the registry of extensions. It is not the signed registry of algorithms (registry-kind 1) announced in §4.4 of the GUARDAID core. The signed file of this registry will be added as a new version of this record. Open, free of charge, with nothing to sign. Files. The registry in English, which is the normative language, and a Spanish translation as an informative version; where the two differ, the English governs. Feedback. Corrections, implementation reports and findings of an error are welcome at [email protected]. A difference between two of these documents is a defect in one of them, and reporting it is the fastest way it gets fixed.

Authors

Institutions

Publication Details

Journal
Zenodo (CERN European Organization for Nuclear Research)
Published
2026-10-12
DOI
https://doi.org/10.5281/zenodo.23307388
Primary Topic
Access Control and Trust
Type
preprint
Controls
|||
ALL TIME
JAN
FEB
MAR
APR
MAY
JUN
JUL
AUG
SEP
OCT
preprint

GUARDAID Extension registry, version 2

Fabiana Andrea Gómez Martínez
Zenodo (CERN European Organization for Nuclear Research)
Access Control and Trust
preprint

GUARDAID Extension registry, version 2

Fabiana Andrea Gómez Martínez
preprint en

Abstract

GUARDAID reserves fields 1000 to 65535 of its packages for extensions, and leaves to a registry — never to whoever produces a package — whether each extension field may be ignored or must be understood. This is version 2 of that registry (registry-kind 3). It sets the entry and exit policy for extension fields. A field enters with a public defining document that has a permanent identifier, a free number, and a must-understand mark decided by a single test: could a reader that ignores the field admit something it would not otherwise have admitted. Numbers are never reassigned. An extension is never withdrawn, only marked as historical, so that what was signed with it stays readable. Whoever publishes a version executes the policy and does not decide it; anyone may publish the next version. Version 2 contains everything in version 1 — the five fields defined by GUARDAID Annex 1: interaction (1000), additional-data (1001), derived-mandate (1002), encounter-envelopes (1101) and retention-windows (1102) — and adds the two defined by the Annex 1 technical specification: presence (1003) and distress (1004), both must-understand. Number 1100 is unassigned and will not be reassigned. The set of test packages that version 1 declared missing now exists: the Annex 1 technical specification carries 52 cases with their bytes and the generator that produces them. This is the registry of extensions. It is not the signed registry of algorithms (registry-kind 1) announced in §4.4 of the GUARDAID core. The signed file of this registry will be added as a new version of this record. Open, free of charge, with nothing to sign. Files. The registry in English, which is the normative language, and a Spanish translation as an informative version; where the two differ, the English governs. Feedback. Corrections, implementation reports and findings of an error are welcome at [email protected]. A difference between two of these documents is a defect in one of them, and reporting it is the fastest way it gets fixed.

Zenodo (CERN European Organization for Nuclear Research)
Estonian Association for Applied Linguistics (EE)
Access Control and Trust
AI Navigator

Ask Laika to Summarize, Analyze, and Connect papers live on the map.

Summarize Papers & Methodologies

Extract key findings, datasets, and comparative methods across publications.

Benchmark Rankings & Visual Analytics

Rank top research institutions, authors, funders, topics, and journals by Field-Weighted Citation Impact (FWCI) and paper volume with instant charts.

Connect Distant Disciplines

Bridge topological clusters on the map to find hidden collaborative intersections.

GUARDAID Extension registry, version 2 — Fabiana Andrea Gómez Martínez · Zenodo (CERN European Organization for Nuclear Research) (2026) | TGRS Research Map | TGRS