Aspect
Section: 3.4 Obligation levels & conformance semantics
Orientation relevance: both
For each fact a profile asks for, it has to say how strongly it is expected: you must provide this, you should, or this is optional. This issue agrees the exact words we use for those levels and precisely what each one means, so that every profile is read the same way by everyone.
Example
A tax form marks some boxes mandatory and others optional. A cryptography profile does the same: a procurement profile might make the algorithm name required but the internal software-library version merely optional. We need one agreed vocabulary so that "required" always means the same thing, no matter who wrote the profile
Objective
Decide the vocabulary by which a profile states that an attribute is required, recommended, or
optional, and how that vocabulary is interpreted consistently across all profiles.
Background & links
Scoping document §3.4, and the floor/ceiling argument in §2.2. Reference: BCP 14 (RFC 2119 +
RFC 8174) keyword semantics. Attaches obligations to the attributes defined in 3.3.
Options under consideration
- BCP 14 keywords — MUST / SHOULD / MAY, with profile-level interpretation notes.
(Trade-off: familiar, widely tooled.)
- Explicit obligation scheme — required / recommended / optional / conditional as named
levels. (Trade-off: unambiguous for non-RFC audiences.)
- Conditional obligations — predicate-based rules ("required when X present") versus
per-asset-type attribute tables.
Open questions
Dependencies
Depends on the attribute model (3.3 #1). Closely related to conformance (3.5 #7); may
be informed by orientation (3.1 #4).
Decision
Not yet decided.
Impact on the specification
Spec section "Attribute selection, obligations, and conformance semantics."
Aspect
Section: 3.4 Obligation levels & conformance semantics
Orientation relevance: both
For each fact a profile asks for, it has to say how strongly it is expected: you must provide this, you should, or this is optional. This issue agrees the exact words we use for those levels and precisely what each one means, so that every profile is read the same way by everyone.
Example
A tax form marks some boxes mandatory and others optional. A cryptography profile does the same: a procurement profile might make the algorithm name required but the internal software-library version merely optional. We need one agreed vocabulary so that "required" always means the same thing, no matter who wrote the profile
Objective
Decide the vocabulary by which a profile states that an attribute is required, recommended, or
optional, and how that vocabulary is interpreted consistently across all profiles.
Background & links
Scoping document §3.4, and the floor/ceiling argument in §2.2. Reference: BCP 14 (RFC 2119 +
RFC 8174) keyword semantics. Attaches obligations to the attributes defined in 3.3.
Options under consideration
(Trade-off: familiar, widely tooled.)
levels. (Trade-off: unambiguous for non-RFC audiences.)
per-asset-type attribute tables.
Open questions
Dependencies
Depends on the attribute model (3.3 #1). Closely related to conformance (3.5 #7); may
be informed by orientation (3.1 #4).
Decision
Not yet decided.
Impact on the specification
Spec section "Attribute selection, obligations, and conformance semantics."