Internet-Draft Structured Value Model August 2026
Le Expires 23 February 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-le-structured-value-model-00
Published:
Intended Status:
Informational
Expires:
Author:
T. Le

A Structured Value Model for Derived Identifiers

Abstract

This document defines a structured value model independent of serialization for use by derived identifier constructions and profiles. A Value consists of exact context octets, exact content octets, and a finite set of scoped opaque identifiers. The model defines structural admission, exact equivalence, placement of distinctions that affect comparison, and rules for importing identifiers from independently governed systems.

The model does not define a wire representation, canonicalization procedure, cryptographic hash, identifier syntax, application profile, resolver, registry, or trust model. Source mappings and concrete derived identifier profiles are defined by surrounding specifications.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 23 February 2027.

▲

Table of Contents

1. Introduction

This specification defines a structured value model independent of serialization for use by derived identifier constructions and profiles. It defines the comparison domain, the distinctions that participate in value equivalence, and how identifiers imported from independently governed schemes participate in comparison.

This model is intended for profiles in which the complete membership of imported identifiers participates jointly in comparison. It is not a generic container for every protocol that carries multiple identifiers. Scoped identifiers, composite values, exact octet comparison, and finite-set membership are established techniques; the specification choice here is their combination into one representation-independent comparison domain with exact conjunctive membership semantics for imported identifiers. Other Internet and Web specifications use multiple identifiers with materially different combination semantics, including aliases that identify the same subject [RFC9493], lists in which any acceptable reference identifier can match a presented identifier [RFC9525], alias and verification relationships in Controlled Identifiers [W3C-CID-1.0], and controller relationships in DIDs [W3C-DID-1.1]. A surrounding specification that needs alias, alternative, capability, controller, succession, authorization, graph-edge, or other relationship semantics resolves those semantics before admission or represents every comparison-relevant distinction explicitly in the admitted Value. Bare co-membership in identifiers does not preserve such a relationship; placing alternatives or relationship-bearing identifiers there without representing the relationship would instead make only the distinct members, not the relation between them, part of this model's exact comparison state.

Requirements in this document apply to mappings, profiles, and implementations that adopt this model. This document does not define a concrete serialization or wire representation, canonical byte encoding, binding or framing construction, cryptographic derivation mechanism, identifier syntax, application profile, transparency service, resolver, registry, or trust model. It also does not define a generic semantic projection across source formats. A companion profile can map concrete representations into this model and can define a deterministic identifier derivation from admitted values.

A surrounding mapping can project richer or heterogeneous source objects into this model. Any equivalence introduced by that projection is part of the mapping before model admission, not of this model. For a fixed mapping from source material to Value, accepted source material and every explicit input that can change the result MUST determine one admitted Value. Inputs that can change the result MUST NOT be left to implementation discretion or ambient mutable state.

The comparison principles in [I-D.le-comparing-derived-identifiers] provide architectural guidance for the semantics defined here.

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

An octet string is a finite sequence of octets. This document defines ScopedIdentifier in Section 3 and Value in Section 4.

3. Scoped Identifiers

A scoped identifier is the pair:

ScopedIdentifier := {
  scope      : finite octet string,
  identifier : finite octet string
}

Both components are opaque octet strings at this model boundary. Either component can be empty. An empty scope or identifier is still an exact value and is distinct from absence of the ScopedIdentifier from the set. A surrounding profile may impose a non-empty requirement when required by the imported identifier system; this model does not impose that restriction on every future system. This specification does not impose a namespace syntax on imported identifier systems, require a registry lookup, require resolution, or interpret the semantics associated with an imported scope.

Imported scope semantics are interpreted relative to the context of the containing value. A specification or interoperability profile that imports an identifier system MUST define, for each context value it uses, the exact mapping from scope octets to imported identifier semantics and the exact identifier octets carried for that system. Within one context value, incompatible imported semantics MUST NOT use the same scope octets. The same scope octets can be reused under different context values because context itself affects comparison.

Because this model compares each complete ScopedIdentifier exactly, a mapping also has to adapt any native comparison semantics of an imported identifier system to that exact boundary. Exact equality represents an equivalence relation. A profile that claims to preserve an imported identifier comparison unchanged therefore MUST identify an equivalence relation to be represented. If, after the applicable imported interpretation is fixed, that matching behavior is not an equivalence relation, the surrounding mapping MUST first define the equivalence being projected into this model; any additional collapse introduced by that projection occurs before model admission.

Under one context and applicable mapping, accepted imported instances equivalent under the fixed interpretation MUST produce the same (scope, identifier) pair before admission. A profile claiming to import that comparison unchanged MUST also reflect equivalence: with that interpretation fixed, accepted instances produce the same exact pair if and only if they are equivalent under the imported relation. Direct copying is sufficient only when the relevant equality is already exact octet equality and the selected scope is stable for that comparison. For aliases, the mapping MUST deterministically select or derive the exact pair for the equivalence class under the imported relation under the fixed interpretation. Under the same mapping and interpretation, that pair MUST NOT vary with implementation preference, time, or ambient mutable state; changing representative selection changes the import mapping. Merging imported identifiers that the imported comparison considers different is upstream loss and cannot be reversed by preserving the resulting pair.

At this model boundary, scope participates in fixing the interpretation of that imported identifier within the containing Value, not necessarily only the public name of the imported identifier scheme. A distinction that changes the imported identifier interpretation or imported comparison relation MUST be fixed by the imported identifier octets, the containing context, or the scope octets; it MUST NOT exist only in content or ambient mapping state if that would let the same (context, scope, identifier) tuple carry incompatible imported meanings. A separate application-specific distinction, such as a role, relationship class, position, or occurrence label that changes only how the imported identifier participates in this Value, MUST be made observable under the placement rule in Section 4.3 and can be carried in scope or content. A context mapping can define a whole family of scope encodings; this model still treats every resulting scope as opaque octets and defines no scope grammar.

Conceptually, an imported identifier is qualified by:

(context, scope, identifier)

The context is represented once at the level of the containing Value. A ScopedIdentifier copied out of a Value does not carry that context. A consumer MUST NOT assume that the same (scope, identifier) pair has the same imported meaning under another context unless a surrounding specification defines it.

A profile may use an allocated name, self-certifying value, Uniform Resource Identifier (URI), including a Uniform Resource Name (URN), an identifier defined by another standard, or another stable octet string as a scope. This specification does not prefer or require one such mechanism.

Equality of scoped identifiers is exact equality of both scope octets and identifier octets. This is the model-level equality relation for the pair. The pair is not self-interpreting: its imported meaning is determined by the containing context and the applicable mapping described above.

4. Structured Value

The comparison domain consists of records of the following form:

Value := {
  context      : finite octet string,
  content      : finite octet string,
  identifiers  : finite set of ScopedIdentifier
}

Emptiness is typed. The empty octet string is a valid value of context, content, scope, or identifier, and the empty mathematical set is a valid value of identifiers. Absence and source representation sentinel or exceptional values are not additional model values and MUST NOT be silently treated as those empty values. A surrounding source mapping can intentionally define how such source states map into this model, but the result MUST be an explicit admitted Value before model comparison.

The record is deliberately small. It provides exact local material and a set of identifiers imported from this or other identifier systems. It does not define an application grammar, resolver, graph language, provenance model, serialization, or trust model.

A profile is not required to admit a non-empty identifiers set. When no imported identifiers participate in comparison, identifiers is the empty mathematical set and context and content carry the remaining comparison-relevant material. The empty-set case remains the same Value type and equivalence relation; it does not define a second core model or an extension variant.

4.1. Context

context carries exact octets that select the interpretation used for comparison. A surrounding specification or interoperability profile defines the exact context octets and their interpretation.

The context can distinguish identical content and identifiers when their application or protocol meaning is intentionally different. When identifier systems are imported, context also provides the interpretation domain under which identifier scope octets are understood.

This specification assigns no global meaning to context values and requires no registry, resolver, network lookup, global authority, or distribution mechanism. Exact context equality is required for model equivalence but does not prove that independently governed environments use compatible definitions; such interpretation depends on agreement about applicable context and scope semantics outside this model.

context octets participate directly in Value equivalence and select the interpretation domain used for comparison. The same context octets MUST NOT be reused for an incompatible interpretation of the Value as a whole. Within a fixed context, the same (context, scope) combination MUST NOT acquire an incompatible imported-identifier meaning. Adding a new distinct scope meaning under an existing context does not by itself require new context octets when existing (context, scope) meanings remain unchanged. Selection, distribution, authentication, or agreement on surrounding definitions is outside this model and is not an additional Value field or input to model equality.

4.2. Content

content is exact local material that participates in comparison. This model does not perform Unicode normalization, character set conversion, media type processing, decompression, canonicalization, or any other transformation.

An application starting from a richer source object is responsible for defining any mapping from source material to content before admission to this model. Different native representations are not considered equivalent merely because an application believes they describe the same thing; a surrounding specification has to define that mapping explicitly before the resulting exact octets enter content. If that mapping collapses a distinction the application later expects identifier comparison to preserve, no later encoding or cryptographic operation can restore the distinction.

Accordingly, content is exact local material after any semantic projection defined by the application. It is not a universal canonical form and this model is not a substitute for canonicalization or mapping rules specific to a source format.

4.3. Placement of Comparison Distinctions

This model does not define separate occurrence, nonce, revision, timestamp, sequence, role, relationship, or position fields. A surrounding specification that needs such a distinction to affect comparison MUST make the distinction observable in the admitted Value rather than leave it as ambient state that can change the result.

The intended placement rule is:

  1. a distinction that changes interpretation of the Value as a whole belongs in context;

  2. exact local comparison material that is not represented by an independently governed identifier belongs in content; and

  3. a distinction that qualifies the application-specific participation of one imported identifier belongs in that identifier's scope, unless the application deliberately represents the distinction as exact local material in content. A distinction that changes the imported identifier interpretation or imported comparison relation is governed by Section 3 and is not moved only into content.

scope is therefore not a generic metadata channel for each member. Material belongs in scope only when its comparison meaning is specific to that imported identifier's membership in the Value. Semantics of the whole Value remain in context, and independently meaningful local structure remains in content.

For example, if the same imported identifier can participate once as a "subject" and once as an "input", and that role changes Value equality, a profile can define two distinct scope octet strings that encode the role. If ordered occurrences or multiplicity matter, a profile can similarly bind an occurrence or position label into the applicable scope, or encode the relevant application structure exactly in content.

A surrounding mapping specifies how source distinctions become these octets; it is not an alternative storage location for a distinction that varies between Values and is intended to affect comparison. If such a distinction is omitted from the admitted Value, this model necessarily treats source values differing only in that omitted distinction as the same Value. No later profile encoding or cryptographic operation can recover it.

4.4. Identifiers

identifiers is a mathematical finite set of ScopedIdentifier values. Membership is relevant to comparison. For each admitted Value, the entire finite membership of this set is part of the comparison state: adding, removing, or substituting a distinct member changes the Value when context and content are unchanged. The set is not an alternatives list, capability advertisement, inventory, discovery result, history, or version-negotiation mechanism. A surrounding source mapping that constructs identifiers remains subject to the mapping-determinism requirement in Section 1; fixed explicit inputs and fixed mapping semantics determine the complete admitted set rather than an implementation-selected subset. Order of presentation and duplicate occurrences are not semantic distinctions. Duplicate presentation is not a way to express multiplicity. If multiplicity or occurrence identity is relevant to comparison, the surrounding profile MUST represent that distinction explicitly under the placement rule in Section 4.3.

Set membership means only that the complete scoped identifier participates in the structured value for model comparison. Membership or co-membership does not by itself assign an application-specific role or relationship between a member and the Value or another member. Co-membership is not an implicit join between identifier systems; cross-system identity or equivalence is outside this model as described in Section 7. A source relation such as alias-of, equivalent-to, controls, authorized-for, supersedes, component-of, or alternative-to is not preserved merely by admitting both endpoint identifiers as members. If that relation is relevant to comparison, the surrounding mapping resolves it before admission or materializes the required distinction under Section 4.3; otherwise flattening the relation to bare co-membership is upstream semantic loss.

Any loss relevant to comparison already embodied in an imported identifier is inherited by the Value. If the imported construction or its applicable comparison deliberately or accidentally maps two source values to the same imported identifier result, preserving that result as opaque octets cannot recover the discarded source distinction. This inherited upstream loss is distinct from a collision or loss introduced by a later derived identifier profile.

If an application needs role, order, position, multiplicity, edge type, or another relationship distinction, it MUST apply the placement rule in Section 4.3. In particular, a distinction for one identifier that changes comparison cannot exist only in an external relationship table while the same Value octets are supplied to the derivation.

This specification does not require the resulting relationships to form a directed acyclic graph (DAG), tree, line, or other global topology and does not traverse or resolve identifiers.

4.5. Separation of Comparison Responsibilities

The three fields expose separate comparison responsibilities; this document does not claim that they are the only representation able to carry the same information. Projecting away any field can erase a distinction this model exposes:

  • removing context loses the explicit boundary that distinguishes otherwise identical Values interpreted under different semantics of the Value as a whole or of imported scopes;

  • removing content removes the dedicated location for exact local material that affects comparison, which then has to be carried elsewhere; and

  • removing identifiers removes the dedicated model-level boundary for opaque results imported from independently governed identifier systems. A surrounding specification can still encode equivalent information in content, but then has to define the per-system qualification, complete-membership, order and duplicate treatment, and imported-comparison adaptation needed for that application rather than reusing the ScopedIdentifier and mathematical-set semantics defined here.

The value of the identifiers field is therefore semantic factoring and reuse, not expressive completeness: it standardizes how opaque imported identifier results participate in comparison while leaving the internal identifier schemes, resolution, trust, and relationships outside the model. context, content, and identifiers expose interpretation context, exact local material, and opaque imported identifier results. Additional roles or relationships need no new primitive field, but every distinction that affects comparison MUST be represented in the admitted Value under Section 4.3.

5. Admission

A candidate value is structurally admitted to the model only when:

  1. context and content are finite octet strings;

  2. every identifier is a ScopedIdentifier whose scope and identifier are finite octet strings; and

  3. identifiers is finite.

Structural admission determines the mathematical domain and is independent of external discovery or interpretation. It does not assert that arbitrary identifier octets are valid according to an imported identifier system. A surrounding profile that imports such a system defines any validation required by that identifier system as part of its mapping from source material to Value.

These are conditions of the model domain, not capability limits. Local memory, time, storage, or denial-of-service limits do not redefine admission or equivalence; resource refusal does not place an otherwise admitted Value outside the mathematical domain.

Model semantics are independent of implementation scale. Streaming, bounded storage, resource refusal, profile subsets, sharding, replication, or long-delay operation MUST NOT change an admitted Value, ScopedIdentifier equality, identifier set membership, or the equivalence relation in Section 6.

The model requires no continuously reachable authority, synchronized clock, current ledger head, mutable global registry, network lookup, or object traversal. A surrounding profile can use such facilities, but state that changes a Value or its comparison semantics MUST be explicit rather than ambient.

Implementations processing the same admitted Values MUST apply the same model equivalence semantics. Profile capability minima do not become Value fields, change equality, or turn local resource refusal into model domain rejection.

6. Equivalence

Two admitted values are equivalent if and only if all of the following hold:

  1. their context octet strings are equal;

  2. their content octet strings are equal; and

  3. their identifiers are the same mathematical set under exact ScopedIdentifier equality.

This relation is reflexive, symmetric, and transitive. Under any fixed applicable derivation semantics, a derived identifier profile using this model MUST treat Values equivalent under this model as equivalent derivation inputs; accepted source or wire representations MUST NOT split one model equivalence class. This requirement does not require different surrounding derivation semantics to produce equal outputs from the same Value. Any merge of non-equivalent Values belongs to the surrounding mapping or construction and its loss boundaries, not to model equality.

The equivalence relation, not a wire representation, states which distinctions matter. Concrete representations do not alter this model unless the profile defines a different mapping from source material to Value.

Model equivalence is an equality relation over admitted Values. Interpreting that equality under imported identifier semantics additionally requires compatible surrounding context and scope definitions. Representation equality does not establish interpretation equality.

7. Imported Identifiers

This model can represent identifiers from multiple independently governed systems in one Value without translating between their internal semantics. For example:

context = profile_X

identifiers = {
  (scope_A, identifier_A),
  (scope_B, identifier_B),
  (scope_C, identifier_C)
}

The surrounding definition for profile_X specifies the imported meaning of each scope. Bare identifier octet equality across scopes or systems is not an implicit join. A bridge asserting identity or equivalence across systems is a separate protocol decision and is outside this model.

A complete identifier produced by another system can be imported as opaque identifier octets without parsing or absorbing that system's internal canonicalization, digest, registry, or derivation semantics when its relevant comparison is already represented by the selected exact octets. Otherwise the surrounding import mapping performs the adaptation of the imported comparison rules described in Section 3 before admission. The surrounding profile defines the imported identifier meaning associated with the exact (context, scope, identifier) tuple; other application-specific distinctions can be carried elsewhere in the Value under Section 4.3. This model preserves those exact materials for comparison without assigning additional semantics to them.

8. Model Boundaries

8.1. Derived Identifier Constructions

This specification defines what is compared; it does not define the bytes that are hashed or the syntax of a resulting identifier.

A derived identifier profile using this model is expected to make the following boundaries explicit:

source representation
    -> profile mapping
    -> admitted Value
    -> deterministic profile encoding
    -> optional cryptographic compression
    -> identifier

A derived identifier profile MAY define a derivation domain that is a proper subset of structurally admitted Values when required by its encoding or downstream operation. Membership in that profile domain MUST be determined from the admitted Value under fixed profile semantics, MUST NOT depend on which accepted source or wire representation produced the Value, and MUST NOT depend on implementation-local resource availability. The profile domain MUST be closed under this model's equivalence relation: if v1 ~ v2, either both Values are in the profile domain or neither is. Restricting a profile derivation domain does not redefine model admission or model equivalence.

Loss introduced by the mapping from source material to Value or by a profile encoding is upstream of any cryptographic collision. A profile claiming independent recomputation MUST define enough information for separate implementations applying the same fixed applicable derivation semantics to produce the same identifier from equivalent admitted values without hidden state that can change the result.

8.2. Mapping and Binding Mechanisms

This document defines a comparison model independent of serialization, not a concrete serialization or wire format and not a universal source canonicalization. The information model/data model distinction in [RFC3444] is an architectural analogy; [RFC8949] likewise separates an abstract data model from encoding choices. Concrete serializations belong to surrounding profiles.

Source mappings determine which distinctions survive into an admitted Value. Imported identifier systems retain their own internal derivation and comparison semantics; the import mapping adapts the relevant comparison to this model's exact (scope, identifier) boundary. Downstream binding, graph, provenance, lifecycle, or relationship protocols can carry derived identifiers without becoming part of model equality.

The model neither repairs distinctions already collapsed upstream nor assigns relationship semantics merely from membership in identifiers. W3C specifications provide contrasting examples: Controlled Identifiers [W3C-CID-1.0] gives explicit semantics to relationships such as alsoKnownAs and verification relationships; DIDs [W3C-DID-1.1] distinguish independent and group controller arrangements; and Recognized Entities [W3C-RECOGNIZED-ENTITIES-1.0] uses sameAs for cross-system references to the same entity. These are relationship-bearing structures, not evidence that bare exact co-membership has those meanings.

Changing a representation, binding construction, or cryptographic mechanism does not by itself change an admitted Value. A change to the value domain, admission rules, ScopedIdentifier semantics, identifier set semantics, or equivalence relation changes the applicable model semantics; existing Values are not silently reinterpreted under changed semantics. A semantic change that affects comparison defines different applicable mapping, context, or model semantics rather than a change only in representation.

9. IANA Considerations

This document has no IANA actions.

10. Security Considerations

The primary security requirement of this model is correct preservation of distinctions that affect comparison by surrounding mappings and profiles. Ambiguous parsing, lossy preprocessing, normalization, default insertion, field exclusion, omitted role or occurrence qualification, scope remapping, or copying an unadapted imported alias or spelling into a boundary based on exact octet comparison can make intended equivalence diverge or make non-equivalent source objects enter the same model value. Later cryptography cannot repair either error or recover a distinction that has already been erased.

An identifier does not authenticate or validate an object it denotes. Consumers requiring authenticity, authority, freshness, revocation, provenance, or trust evaluate those properties separately.

Operational resource limits used for denial-of-service protection do not redefine the model domain.

Distribution or selection of the mapping from source material to Value, context definitions, and scope definitions can be security-sensitive. Mutable locators, replaceable aliases, or partially fixed dependencies can make parties apply incompatible semantics to the same source material. When a mapping constructs identifiers, attacker-controlled member injection, omission, or substitution changes model equality unless that membership difference is explicitly part of the applicable mapping semantics. Such a change is a mapping-integrity failure before any downstream binding or cryptographic construction, not a collision in that downstream construction. A surrounding protocol MUST protect each definition that affects comparison and each attacker-controlled selection step according to its threat model.

11. Privacy Considerations

Values can contain stable, identifying, or low-entropy material. A deterministic profile derived from this model can therefore enable correlation or offline guessing. Placing identifiers from independently governed systems in one Value can create linkage across systems even though generic set membership asserts no identity or trust across systems. The conjunction of several members can be more identifying than any member alone because the combination can narrow the set of source objects consistent with the Value. Deriving or exposing a stable opaque identifier for the composite Value does not by itself remove that correlation risk even when the imported member octets are not directly exposed. Persistent identifiers and linkability are discussed more generally in [RFC6973]. Applications need to consider whether unnecessary identifying material should be omitted when resulting identifiers will be broadly observable.

Opaque identifiers do not make denoted or associated values confidential.

12. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

13. Informative References

[RFC3444]
Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, , <https://www.rfc-editor.org/info/rfc3444>.
[I-D.le-comparing-derived-identifiers]
Le, T., "Principles for Comparing Independently Derived Identifiers", Work in Progress, Internet-Draft, draft-le-comparing-derived-identifiers-00, , <https://datatracker.ietf.org/doc/html/draft-le-comparing-derived-identifiers-00>.
[RFC9493]
Backman, A., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, , <https://www.rfc-editor.org/info/rfc9493>.
[RFC9525]
Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, , <https://www.rfc-editor.org/info/rfc9525>.
[W3C-CID-1.0]
World Wide Web Consortium, "Controlled Identifiers v1.0", W3C Recommendation, , <https://www.w3.org/TR/controller-document/>.
[W3C-DID-1.1]
World Wide Web Consortium, "Decentralized Identifiers (DIDs) v1.1", W3C Candidate Recommendation Snapshot, , <https://www.w3.org/TR/did-1.1/>.
[W3C-RECOGNIZED-ENTITIES-1.0]
World Wide Web Consortium, "Recognized Entities v1.0", W3C First Public Working Draft, , <https://www.w3.org/TR/vc-recognized-entities-1.0/>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/info/rfc8949>.
[RFC6973]
Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, , <https://www.rfc-editor.org/info/rfc6973>.

Appendix A. Model Test Considerations

This appendix is informative.

Useful corpus cases include typed emptiness; the distinction between an empty set and an empty member; arbitrary opaque octets; duplicate and reordered presentations; scoped distinctions; leading zeros; ambiguity in tuple framing; deterministic mappings under fixed explicit inputs; stable adaptation of imported equivalence classes; and rejection rather than coercion outside the model domain. Such vectors test model semantics without imposing a wire format, normalization, hash, API shape, or resource floor.

Author's Address

Thanh Le
Viet Nam