A Structured Value Model for Derived Identifiers
draft-le-structured-value-model-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Thanh Le | ||
| Last updated | 2026-09-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-le-structured-value-model-01
Network Working Group T. Le
Internet-Draft 10 September 2026
Intended status: Informational
Expires: 14 March 2027
A Structured Value Model for Derived Identifiers
draft-le-structured-value-model-01
Abstract
Derived identifier constructions that combine local material with
identifiers from other systems need a defined comparison domain.
This document defines a structured value model for such constructions
and their profiles. A Value contains exact context octets, exact
content octets, and a finite set of scoped opaque identifiers.
Structural admission and equivalence are independent of
serialization. Equality includes context, content, and complete
identifier-set membership.
The specification gives source mappings and profiles common
obligations for fixed inputs, imported comparison adaptation, and
preservation of participation distinctions. Surrounding
specifications define concrete mappings, representations, identifier
derivations, and the shared interpretation needed for
interoperability. The model defines no global semantic namespace,
wire format, cryptographic construction, or trust mechanism.
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 14 March 2027.
Le Expires 14 March 2027 [Page 1]
Internet-Draft Structured Value Model September 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Conformance Scope . . . . . . . . . . . . . . 4
3. Value Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Value Types . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Structural Admission and Empty Values . . . . . . . . . . 5
3.3. Equivalence . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. A Value in Use . . . . . . . . . . . . . . . . . . . . . 6
4. Source Mappings and Imported Identifiers . . . . . . . . . . 7
4.1. Fixed Inputs and Mapping Semantics . . . . . . . . . . . 7
4.2. Context and Content . . . . . . . . . . . . . . . . . . . 8
4.3. Imported Interpretation . . . . . . . . . . . . . . . . . 9
4.4. Adapting Imported Comparison . . . . . . . . . . . . . . 9
4.5. Participation and Member Associations . . . . . . . . . . 10
4.6. Complete Membership and Source Changes . . . . . . . . . 11
5. Derived Identifier Profiles . . . . . . . . . . . . . . . . . 12
5.1. Profile Domains and Representations . . . . . . . . . . . 12
5.2. Derivation and Comparison Claims . . . . . . . . . . . . 13
5.3. Changes to Applicable Semantics . . . . . . . . . . . . . 14
6. Worked Trade-Document Mapping Examples . . . . . . . . . . . 14
6.1. Source Comparison and Mapping . . . . . . . . . . . . . . 14
6.2. Comparison Cases . . . . . . . . . . . . . . . . . . . . 15
6.3. Carrying Participation in Content . . . . . . . . . . . . 16
6.4. Combining Independently Governed Systems . . . . . . . . 18
6.5. Adapting Native Spellings . . . . . . . . . . . . . . . . 19
6.6. Preserving Associations Between Parties . . . . . . . . . 20
7. Relationship to Existing Work . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 24
Le Expires 14 March 2027 [Page 2]
Internet-Draft Structured Value Model September 2026
Appendix A. Model Test Considerations . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
Derived identifier constructions can combine local data with
identifiers produced by other systems. A trade-document description,
for example, can include a document reference and identifiers for a
buyer, seller, and carrier. Independent implementations need to
agree on which material enters comparison, how identifiers from
different namespaces are qualified, and which participant
associations distinguish the value being identified.
This specification provides a common structural comparison domain. A
Value groups context, content, and a finite set of scoped opaque
identifiers. Context selects interpretation, content carries local
material, and the identifier field provides reusable qualification
and complete-set comparison rules for imported results. Equality
compares exact octets and complete membership. Profiles can reuse
these qualification and set-comparison rules across concrete
encodings and derivations. Independent implementations can compare
their mapped Values before testing any profile-specific encoding or
cryptographic operation.
The comparison-contract framework in
[I-D.le-comparing-derived-identifiers] describes the source-to-result
obligations surrounding derived identifiers. This document fixes one
admitted value domain and its exact equivalence relation. A source
mapping defines which source distinctions enter that domain; a
derived identifier profile defines how Values produce identifiers and
what output comparison supports. Complete membership suits
descriptions and configuration snapshots; continuity across changed
descriptions is addressed in Section 4.6.
Figure 1 distinguishes the three comparison boundaries. P denotes
one fixed source mapping and F one fixed profile derivation. Each
application of F requires a Value in that profile's derivation
domain. Dotted lines mark comparisons; the arrows alone assert no
preservation or reflection property.
Le Expires 14 March 2027 [Page 3]
Internet-Draft Structured Value Model September 2026
Sources Values Identifiers
+-----------+ +-----------+ +-----------+
| s1 | -- P --> | V1 | -- F --> | i1 |
+-----------+ +-----------+ +-----------+
: : :
source model output
comparison equality comparison
: : :
+-----------+ +-----------+ +-----------+
| s2 | -- P --> | V2 | -- F --> | i2 |
+-----------+ +-----------+ +-----------+
Figure 1: Mapping and Derivation Comparison Boundaries
Shared interpretation depends on the applicable surrounding
definitions; this model establishes no global semantic namespace.
Concrete representations, cryptographic constructions, and trust
mechanisms belong to surrounding specifications. Section 3 defines
the model and gives a short example; Section 4 specifies mapping
obligations; Section 5 specifies profile obligations; and Section 6
develops the trade-document mappings.
2. Conventions and Conformance Scope
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. A source mapping
converts accepted source material into a Value. A derived identifier
profile defines how admitted Values in its domain produce
identifiers. A single specification can define both.
The definitions in Sections 3.1 through 3.3 and the applicable
requirements in Sections 4, 5, and 8 govern mappings, profiles, and
implementations that adopt this model. A conformance claim
identifies whether it concerns model comparison, a source mapping, a
derived identifier profile, or a combination, together with the
applicable definitions and comparison claims. Correct Value
comparison alone does not establish conformance to a mapping or
profile. Mapping and profile implementations apply their selected
definitions.
Le Expires 14 March 2027 [Page 4]
Internet-Draft Structured Value Model September 2026
Sections 1, 3.4, 6, and 7, together with Appendix A, provide
explanation and examples. These conceptual boundaries do not require
separate implementation stages or exposed intermediate objects.
3. Value Model
3.1. Value Types
A scoped identifier is a pair of octet strings:
ScopedIdentifier := {
scope : finite octet string,
identifier : finite octet string
}
Two ScopedIdentifier values are equal if and only if their scope
octets are equal and their identifier octets are equal. Both
components are opaque to the model. Imported interpretation is
specified under Section 4.3.
The comparison domain consists of records of the following type:
Value := {
context : finite octet string,
content : finite octet string,
identifiers : finite set of ScopedIdentifier
}
context selects an interpretation within the applicable surrounding
definitions. content carries exact local material. identifiers
carries the complete set of imported identifier members participating
in comparison. Sections 4.2 through 4.5 specify how mappings
populate these fields.
3.2. Structural Admission and Empty Values
A candidate is structurally admitted if and only if it is a Value of
the type in Section 3.1: context and content are finite octet
strings, and identifiers is a finite mathematical set whose members
each contain finite scope and identifier octet strings.
Each octet string can be empty, and identifiers can be the empty set.
An empty scope or identifier is part of an exact member value. In
particular, the empty set and a set containing the pair of two empty
strings are different. A Value with no imported identifiers still
has the same type; context and content supply its other comparison
material.
Le Expires 14 March 2027 [Page 5]
Internet-Draft Structured Value Model September 2026
Structural admission does not validate arbitrary identifier octets
against an imported system. A mapping defines any imported-system
validation and restrictions, including non-empty requirements, before
producing the Value. Profile domain restrictions do not redefine
this mathematical domain. Conformance to a claimed source mapping is
addressed in Section 5.2.
These admission conditions are independent of local memory, time,
storage, or other resource availability. An inability to process an
admitted Value is an operational refusal, not evidence that the Value
lies outside the model domain.
3.3. Equivalence
Two admitted Values are equivalent if and only if all of the
following hold:
* Their context octet strings are equal.
* Their content octet strings are equal.
* Their identifiers are the same mathematical set under the
ScopedIdentifier equality of Section 3.1.
This relation, denoted by ~, is reflexive, symmetric, and transitive.
It is equality of abstract Values. Order of set presentation and
repeated presentations of the same member do not distinguish Values.
Multiplicity or occurrence identity requires explicit representation
under Section 4.5.
With context and content unchanged, adding, removing, or substituting
members so that the mathematical set changes produces a non-
equivalent Value. Whether a source change is permitted by an
application does not alter this equality rule.
Implementations comparing admitted Values MUST apply this relation.
Implementation strategies and resource limits MUST NOT change the
logical Value, its exact member equality, or its set membership.
Imported meaning is specified separately under Section 4.3.
3.4. A Value in Use
This informative example uses the mapping specified in Section 6.1.
A trade document references party-a as seller and party-b as buyer.
The mapping records the document reference in content and each
party's role in its scope:
Le Expires 14 March 2027 [Page 6]
Internet-Draft Structured Value Model September 2026
context = "example.org/trade-document/participants/v1"
content = "commercial-invoice:1234"
identifiers = {
("trade-party/v1/role/buyer", "party-b"),
("trade-party/v1/role/seller", "party-a")
}
The strings denote exact ASCII octets and the braces denote a
mathematical set. Changing the order in which the two members are
displayed leaves the Value unchanged. Swapping the parties between
buyer and seller changes the scoped members and therefore the Value.
Section 6.3 shows an alternative mapping that carries these
associations in content.
4. Source Mappings and Imported Identifiers
4.1. Fixed Inputs and Mapping Semantics
A source mapping specifies accepted source material, explicit inputs,
and source comparison claims. The requirements below cover
reproducible Values, intentional projection, and preservation and
reflection of the declared comparison.
For fixed mapping semantics, the same accepted source and explicit
inputs MUST determine one admitted Value, including its complete
identifier set. Result-affecting choices MUST NOT be left to
implementation discretion or ambient mutable state.
A dependency that can change the Value or its interpretation MUST be
an explicit input or fixed unambiguously by the applicable rules.
This includes any relevant version of a schema, normalization rule,
imported definition, resolver result, clock value, or registry state.
Fixing a locator without fixing its relevant interpretation is
insufficient. Acquisition can require a service; model comparison
does not itself require that service to remain reachable.
A mapping can project a richer source object. It MUST make every
source distinction that its comparison claims require observable in
the admitted Value. Intentional exclusions are part of the defined
source comparison. If an omitted distinction is later required by a
consumer, that consumer cannot recover it from the resulting Value
alone.
Source absence, null, sentinels, or exceptional values are not
additional model values. A source mapping MUST NOT silently coerce
them to empty model values. It can explicitly define such a
projection, but its result MUST be an admitted Value. Representation
admission and decoding are addressed in Section 5.1.
Le Expires 14 March 2027 [Page 7]
Internet-Draft Structured Value Model September 2026
A mapping claiming to represent a source equivalence relation by
model equality MUST define that relation and preserve it: under fixed
mapping semantics and explicit inputs, equivalent accepted sources
produce equal Values. It MUST also reflect that relation: non-
equivalent accepted sources produce different Values. These
obligations concern the declared comparison, not every distinction in
a richer source object.
The obligations apply to the complete Value. A source comparison can
retain distinctions ignored by an imported comparison, but those
distinctions then belong to the declared source relation. Adapting
imported members alone does not establish whole-source preservation
or reflection. A comparison property established directly for the
complete source-to-output construction does not by itself establish
preservation by the mapping.
4.2. Context and Content
A surrounding specification defines the exact context octets and
their interpretation. Within one fixed applicable definition, it
MUST NOT assign incompatible interpretations to the same context
octets or silently change an existing imported meaning associated
with a context and scope.
This is a consistency requirement within those definitions, not a
global allocation rule. Independently governed environments can
select equal context octets without agreeing on their meaning. A
consumer drawing conclusions under imported semantics needs agreement
on the applicable definitions. Selection, distribution, and
authentication of those definitions are surrounding protocol
responsibilities; they do not add a field to Value equality.
A new distinct scope meaning can be added without changing context
octets when existing meanings remain unchanged. Any associated
change in profile acceptance or mapping rules remains subject to
Section 5.3.
content is exact local material after the source mapping. The model
performs no normalization, character conversion, decompression,
defaulting, or canonicalization. A mapping starting from richer
content defines any such processing before admission. Context
identifies the interpretation of the Value as a whole; content holds
the local material compared within that interpretation.
Le Expires 14 March 2027 [Page 8]
Internet-Draft Structured Value Model September 2026
4.3. Imported Interpretation
A mapping that imports an identifier system MUST define, for every
context value it uses, how scope octets select imported identifier
semantics and which exact identifier octets are carried. Within that
applicable context definition, incompatible imported semantics MUST
NOT use the same scope octets. Different context values can reuse a
scope because context participates in Value equality.
The imported meaning of a member is qualified by:
(context, scope, identifier)
A distinction that changes the imported identifier interpretation or
comparison relation MUST be fixed by this tuple under the applicable
definitions. It MUST NOT exist only in content or ambient state if
that would give the same tuple incompatible imported meanings.
Participation that does not change the imported interpretation is
addressed separately in Section 4.5.
This requirement makes imported members interpretable from their
qualified tuples under the applicable definitions, without consulting
content. It is additional to whole-source preservation and
reflection: distinguishing complete Values through content does not
establish unambiguous imported meaning for each member.
Context is carried once in the containing Value. A consumer copying
out a ScopedIdentifier MUST NOT assume that its imported meaning is
preserved under another context unless a surrounding specification
establishes that compatibility.
A scope can use an allocated name, a self-certifying value, a URI or
URN, or another stable octet string. The model specifies no scope
grammar or lookup mechanism. Equal identifier octets under different
scopes do not establish a cross-system identity or equivalence
relation.
4.4. Adapting Imported Comparison
A mapping MUST identify the imported equivalence relation represented
at the exact ScopedIdentifier boundary. If the relevant native
matching behavior, under its fixed interpretation, is not an
equivalence relation, the mapping MUST define the equivalence being
projected into the model. Such a projection is a choice of
comparison semantics; this model supplies no default conversion of a
directional or other non-equivalence match into equality.
Le Expires 14 March 2027 [Page 9]
Internet-Draft Structured Value Model September 2026
For example, nonempty overlap between identifier sets is not
transitive: {a} overlaps {a, b}, and {a, b} overlaps {b}, but {a}
does not overlap {b}. Equality of one independently computed
identifier per set cannot represent this relation unchanged.
Selecting complete-set equality or an equivalence closure changes the
comparison and requires an explicitly defined source relation.
For a fixed imported interpretation and fixed participation
qualification, equivalent accepted native instances MUST produce
equal ScopedIdentifier values. A mapping claiming to preserve the
imported comparison unchanged MUST also reflect that relation:
accepted native instances produce an equal pair only if they are
equivalent under the imported relation. A deliberate merge of native
classes is upstream projection and cannot support an unchanged-
comparison claim.
Native adaptation and participation qualification are distinct
responsibilities. The requirement above governs the resulting pair
under a fixed qualification; it does not require a separately
materialized native class representative. Alias representative
selection MUST be deterministic under the fixed interpretation.
Direct copying suffices when native equality is already exact octet
equality and the applicable interpretation and qualification are
fixed.
An imported identifier can remain opaque when those octets already
represent its relevant comparison. The model need not parse or
reproduce the imported construction. Any source distinction already
lost within that construction remains lost at this boundary.
Retaining its output exactly does not establish uniqueness of its
preimages or repair its own false matches.
Section 6.5 illustrates adaptation of imported members together with
the content that records their associations.
4.5. Participation and Member Associations
A source can use an imported identifier in a particular role,
relationship, position, or occurrence. A mapping MUST preserve every
such distinction required by its source comparison in the complete
Value. It can qualify the member's scope or encode the participation
and its association with the member in content.
When qualification is carried in scope, two roles can produce
different ScopedIdentifier members for the same native identifier
class. When it is carried in content, the same member can
participate in both roles; content then preserves their associations.
The imported interpretation itself remains governed by Section 4.3.
Le Expires 14 March 2027 [Page 10]
Internet-Draft Structured Value Model September 2026
scope is not a general metadata channel. Material placed there
qualifies that member; it does not replace context for the
interpretation of the whole Value. A profile can define a family of
scope encodings, while the model continues to treat each resulting
scope as opaque octets.
A qualification MAY be carried in scope when it is specific to one
imported member's participation at this comparison boundary. When a
comparison-relevant relationship depends on two or more participants,
content provides a direct place to encode the participants together.
If a mapping instead uses member scopes, those scopes MUST encode
enough association material to preserve the relationship;
independently qualifying each endpoint is insufficient.
A mapping preserving a relationship MUST retain the association
between its participants and their roles, not just the endpoint
identifiers or separate collections of labels. Order, multiplicity,
and occurrence distinctions likewise require explicit material, such
as position-qualified scopes or a defined structure in content. They
cannot reside only in an external relationship table while the same
Value is supplied to derivation.
These rules specify comparison material without imposing a graph
topology or requiring traversal or resolution. Section 6.6
illustrates grouping between imported members, with the different
pairings shown in Figure 3. Application relationship semantics are
discussed in Section 7.
4.6. Complete Membership and Source Changes
Fixed mapping inputs determine the entire identifier set under
Section 4.1. An implementation cannot substitute a locally
discovered or supported subset for that set. A mapping can use a
selected snapshot or other explicit source input, but changing that
input can change the Value.
For example, let A and B be distinct ScopedIdentifier values. With
equal context and content, Values containing {A} and {A, B} are
different even if an application describes B as a newly learned
alias. The application determines whether B belongs in the identity-
bearing input, is adapted by a fixed import rule to an existing
member, or remains descriptive information outside this Value.
Le Expires 14 March 2027 [Page 11]
Internet-Draft Structured Value Model September 2026
Complete membership can therefore describe a configuration or
inventory snapshot whose changes are intended to affect comparison.
It does not by itself provide continuity of an entity across changed
descriptions. An application needing that continuity selects stable
identity-bearing inputs or defines a relation between successive
Values. Calling two members aliases or alternatives does not change
the model's set equality.
5. Derived Identifier Profiles
A source mapping determines a Value. A derived identifier profile
takes Values in its domain and specifies their representations,
derivation, and output comparison. The requirements below apply
after the source distinctions have been represented in the Value.
5.1. Profile Domains and Representations
A profile MAY restrict its derivation domain to a subset of
structurally admitted Values when required by its encoding or
downstream operation. Domain membership MUST be determined from the
Value under fixed profile rules, independent of its accepted
representation and of local resource availability. Because model
equivalence is equality of abstract Values, a domain defined solely
from the Value is automatically closed under that equivalence.
A profile defines the admission and decoding of its concrete
representations. Representation rejection, exclusion from a profile
domain, and operational inability to process an admitted Value are
different conditions. None redefines the model's structural
admission or equality. Capability minima and operational limits are
not additional Value fields.
The set model does not require every decoder to accept duplicate or
reordered presentations. A profile specifies which presentations it
accepts and how they map into a Value. Accepted presentations of the
same Value MUST NOT change model equality or split a model
equivalence class in derivation. In particular, an accepted
duplicate presentation does not create a second occurrence in a
mathematical set.
Representation rules specify any transformations and treatment of
unsupported source forms; they do not infer model membership merely
from what a host parser can store.
Le Expires 14 March 2027 [Page 12]
Internet-Draft Structured Value Model September 2026
5.2. Derivation and Comparison Claims
A profile specifies how Values in its derivation domain produce
identifiers. Under the same fixed applicable derivation semantics,
equivalent Values in that domain MUST produce equal identifier values
at the profile's defined output comparison boundary. A profile
claiming independent recomputation MUST fix enough input material,
rules, and dependencies for separate implementations to reproduce
that result without hidden result-affecting state.
The profile defines its encoding or other pre-processing, any
cryptographic compression, and the construction and comparison of the
output. It distinguishes comparison of a carrier representation from
comparison of a decoded identifier value. Different profile
semantics need not produce equal identifiers for the same Value.
Source mapping and derivation have separate comparison
responsibilities. A mapping can merge source distinctions before
admission; an encoding can merge non-equivalent Values before a later
primitive receives its input. When a deterministic remaining
computation receives the same complete input, its equal outputs are
not a collision of that later primitive. Such loss is considered
separately from the primitive's false match properties.
Exact model equality does not establish that a profile's derivation
is free of false matches. The profile characterizes the comparison
conclusions its construction supports. Consumers also establish any
binding they rely on between a received identifier and its claimed
Value or source.
Structural admission and profile-domain admission alone do not
establish conformance to a claimed source mapping. If a consumer
relies on that claim, the mapping or surrounding protocol defines the
required consistency checks or evidence, including any relationship
between content associations and identifier-set membership. If
reliance depends on validation before mapping, the surrounding
protocol specifies how completion of that validation is established.
For example, the content octets "00:" are structurally valid, but no
accepted source under the mapping in Section 6.3 produces them. An
empty document reference and empty pair set instead produce "0:".
Checking this mapping rule is distinct from checking the Value's
type.
For further background on comparison contracts and the limits of
supporting evidence, see [I-D.le-comparing-derived-identifiers].
Le Expires 14 March 2027 [Page 13]
Internet-Draft Structured Value Model September 2026
5.3. Changes to Applicable Semantics
A change only in representation leaves a Value unchanged when the
accepted representation still denotes that Value. A change affecting
mapping results, profile-domain membership, source or imported
comparison rules, imported interpretation, or derivation and output
comparison rules changes the applicable comparison semantics. Such
changes do not redefine the model equality specified in Section 3.3.
Existing Values and identifiers MUST NOT be silently reinterpreted
under incompatible changed semantics.
A surrounding specification identifies the applicable definitions and
any compatibility, migration, or continuity rules it provides. A
semantic change does not automatically require a new model field or
globally allocated context. The relevant mapping, context
definition, or profile specifies how the change is distinguished.
6. Worked Trade-Document Mapping Examples
Each example fixes an accepted source domain and its mapping rules.
An input outside that domain has no mapped result under those rules;
additional preprocessing requires an explicitly defined mapping.
These examples define no API or error format.
6.1. Source Comparison and Mapping
This informative example uses a simplified trade-document participant
model. It is shaped after multi-party commercial-invoice, packing-
list, and transport-document workflows. UN Verifiable Trade
Documents (UNVTD) [UNVTD] provides application context for these
document families. This example defines its own source domain and
comparison relation; it does not adopt an external document schema or
assert document, shipment, legal, or party identity outside that
relation.
A source contains an exact ASCII document reference and a finite
sequence of role and party-identifier pairs. Roles are the exact
ASCII strings buyer, seller, and carrier. Party identifiers are
nonempty ASCII tokens using lowercase letters, digits, and hyphen.
Source equivalence requires equal document references and equal sets
of role and party-identifier pairs. Entry order and duplicate
presentations of a pair are irrelevant. No resolver, mutable alias
state, or additional relationship semantics participates.
The mapping uses the ASCII context example.org/trade-
document/participants/v1. It places the exact document reference in
content. For each source entry, it imports the party identifier and
qualifies its scope by the participation role:
Le Expires 14 March 2027 [Page 14]
Internet-Draft Structured Value Model September 2026
scope = "trade-party/v1/role/" followed by the role
identifier = exact party identifier
identifiers is the set of the resulting pairs. These displayed
strings denote exact ASCII octets; the notation is illustrative, not
a wire format.
Source A has document reference commercial-invoice:1234 and entries:
[(seller, party-a), (buyer, party-b)]
Its complete mapped Value is shown in Section 3.4.
The mapping retains exactly the document reference and pair set
defining source equivalence. The fixed scope prefix and restricted
role alphabet distinguish participation, and exact identifier octets
distinguish the party identifiers. This gives a general preservation
and reflection argument for this example's source relation.
6.2. Comparison Cases
Each case uses the same mapping and document reference commercial-
invoice:1234 unless stated otherwise:
A: [(seller, party-a), (buyer, party-b)]
B: [(buyer, party-b), (seller, party-a), (seller, party-a)]
C: [(seller, party-b), (buyer, party-a)]
D: [(seller, party-a), (buyer, party-a)]
E: document commercial-invoice:1235 with A's entries
F: A's entries plus (carrier, party-c)
A and B yield equivalent Values. Entry order and repeated
presentation of an existing role/party pair do not change the
mathematical set.
A and C yield non-equivalent Values because the party/role
associations are reversed. Retaining {buyer, seller} separately from
{party-a, party-b} would erase that distinction.
D contains two different scoped members even though both identifier
components are party-a. It differs from A and from a source
containing only one of D's roles. Repetition of one exact member
would not express the other role.
E differs from A in content while preserving the identifier set. F
differs from A by an additional distinct set member while preserving
context and content. These are model inequalities regardless of
whether a trade workflow permits the source changes.
Le Expires 14 March 2027 [Page 15]
Internet-Draft Structured Value Model September 2026
An empty participant sequence maps to the empty identifier set and
retains the exact document reference in content. Model admission
permits that Value. Any application requirement for particular trade
roles belongs to its source or profile rules.
6.3. Carrying Participation in Content
An alternative mapping uses context example.org/trade-document/
participants-content/v2 and unqualified scope trade-party/v1. Its
identifier set contains each distinct party identifier once. Content
carries the document reference and the complete association
structure.
Figure 2 illustrates this mapping for Source A. C abbreviates the
context above, and S abbreviates the scope trade-party/v1. Adjacent
quoted content fragments concatenate without added octets; their line
breaks are only for display. In this mapping, the identifiers field
retains the distinct scoped party identifiers, while content retains
the document reference and role/party associations.
Source A Mapped Value
+-------------------------+ +-------------------------------+
| document reference: | | context = C |
| commercial-invoice:1234 | | |
| | +-------------------------------+
| | | content (concatenated): |
| seller --> party-a | P | "23:commercial-invoice:1234" |
| | -----> | ";buyer=party-b" |
| buyer --> party-b | | ";seller=party-a" |
| | | |
| | +-------------------------------+
+-------------------------+ | identifiers = { |
| (S, "party-a"), |
| (S, "party-b") |
| } |
+-------------------------------+
Figure 2: Source A Mapped into Content Associations
Le Expires 14 March 2027 [Page 16]
Internet-Draft Structured Value Model September 2026
Start content with the length of the document reference in octets,
encoded as ASCII decimal digits with no leading zeros except "0" for
an empty reference. Append ":" and the exact reference octets. Then
sort the distinct role/party pairs lexicographically by ASCII role
and then ASCII party identifier, with a proper prefix ordered before
the longer string. Append each pair as ";" followed by the role, "="
and the party identifier. An empty pair set adds no suffix. The
length prefix delimits the reference even when it contains ":", ";",
"=", or text resembling a role/party suffix. The restricted role and
party alphabets make the remaining suffix unambiguous.
A and B then produce:
context = "example.org/trade-document/participants-content/v2"
content = "23:commercial-invoice:1234;buyer=party-b;seller=party-a"
identifiers = {
("trade-party/v1", "party-a"),
("trade-party/v1", "party-b")
}
C has the same identifier set but different content:
"23:commercial-invoice:1234;buyer=party-a;seller=party-b"
D produces one identifier member and content retaining both roles:
identifiers = {("trade-party/v1", "party-a")}
content = "23:commercial-invoice:1234;buyer=party-a;seller=party-a"
Thus the complete Value retains participation even when the member
itself does not distinguish roles. Equal source references and pair
sets produce identical framed content and identifier sets.
Conversely, the length prefix recovers the exact reference; the
remaining suffix recovers the complete role/party pair set. Equal
Values therefore imply source equivalence. This establishes
preservation and reflection for this mapping.
The context version identifies these framing rules under Section 5.3.
This mapping and the scope-qualified mapping in Section 6.1 produce
different Values. They are distinct mappings, so the model requires
no convergence between their derived identifiers. These examples
instantiate no derivation; their arguments establish mapping and
model-equality properties only.
Table 1 gives additional cases for this mapping, including proper-
prefix ordering and empty inputs.
Le Expires 14 March 2027 [Page 17]
Internet-Draft Structured Value Model September 2026
6.4. Combining Independently Governed Systems
This further example combines two fictional, independently governed
party-identifier systems used by one trade application. The global
system compares identifiers exactly. The local system also compares
identifiers exactly but only within an exact jurisdiction namespace.
Their interpretation rules are fixed here; no registry, resolver, or
mutable alias information participates.
A source contains an exact ASCII document reference and a finite
sequence of entries, each in exactly one of these forms:
(global, role, identifier)
(local, jurisdiction, role, identifier)
global and local are literal system tags. Roles are buyer, seller,
or carrier. Jurisdiction and identifier values are nonempty ASCII
tokens using lowercase letters, digits, and hyphen. Source
equivalence requires equal document references and equal sets of
entries. System tags, jurisdictions, roles, and identifiers remain
exact. Order and repeated presentations of the same entry are
irrelevant. These rules assert no identity relation between the two
systems.
The mapping uses context example.org/trade-document/two-systems/v1
and the exact document reference as content. For each entry, it
constructs a member as follows; identifiers is the set of those
members:
global entry:
scope = "trade-registry/v1/role/" followed by role
identifier = exact identifier
local entry:
scope = "local-party/v1/jurisdiction/" followed by jurisdiction,
then "/role/" followed by role
identifier = exact identifier
These strings denote exact ASCII octets. The disjoint system
prefixes and restricted jurisdiction alphabet make the scope encoding
unambiguous.
A source with document reference bill-of-lading:5678 and these
entries:
[(global, seller, party-a), (local, east, buyer, party-a), (local,
west, buyer, party-a)]
Le Expires 14 March 2027 [Page 18]
Internet-Draft Structured Value Model September 2026
maps to:
context = "example.org/trade-document/two-systems/v1"
content = "bill-of-lading:5678"
identifiers = {
("trade-registry/v1/role/seller", "party-a"),
("local-party/v1/jurisdiction/east/role/buyer", "party-a"),
("local-party/v1/jurisdiction/west/role/buyer", "party-a")
}
All three identifier components have equal octets, but the scoped
members are distinct. Reordering or repeating entries leaves the
Value unchanged. Changing a role changes participation without
changing the underlying identifier octets. Changing jurisdiction
east to north instead changes the imported namespace.
Encoding jurisdiction only in content while reusing one scope for all
local namespaces would violate Section 4.3, even if complete Values
remained distinguishable. Participation can instead be carried with
its associations in content by a separately specified mapping, as in
Section 6.3.
The document reference is retained exactly. Each member uniquely
retains its system, role, identifier, and jurisdiction where
applicable. Sources with equal document references and equal entry
sets yield equal Values; equal Values recover those same source
components. This establishes preservation and reflection for the
declared source relation without selecting an identifier derivation.
6.5. Adapting Native Spellings
This separate example uses a fictional party-identifier system with
ASCII case-insensitive comparison. Sources have the form defined in
Section 6.1, except that party identifiers can also contain uppercase
ASCII letters. Roles and document references remain exact. No
resolver or mutable alias state participates.
Define lower(p) by replacing each ASCII letter A through Z with its
corresponding letter a through z and leaving every other accepted
octet unchanged. Native identifiers are equivalent exactly when
their lower(p) octets are equal. Source equivalence requires equal
document references and equal sets of (role, lower(p)) pairs. Entry
order and repetitions of a normalized pair are irrelevant.
Le Expires 14 March 2027 [Page 19]
Internet-Draft Structured Value Model September 2026
The mapping uses context example.org/trade-document/ascii-ci/v1 and
scope trade-party-ascii-ci/v1. It replaces each party identifier p
with lower(p), then applies the content framing, distinct-pair
sorting, and identifier-set construction from Section 6.3 to those
normalized entries. The reference octets are unchanged. All
displayed strings denote exact ASCII octets.
With document reference invoice:1, these sources are equivalent:
S1: [(seller, Party-A), (buyer, party-b)]
S2: [(buyer, PARTY-B), (seller, party-a), (seller, PARTY-A)]
Both produce:
context = "example.org/trade-document/ascii-ci/v1"
content = "9:invoice:1;buyer=party-b;seller=party-a"
identifiers = {
("trade-party-ascii-ci/v1", "party-a"),
("trade-party-ascii-ci/v1", "party-b")
}
Equal source classes produce identical content and identifier sets.
Conversely, the framed content recovers the exact reference and
normalized role/party pair set that define source equivalence. The
mapping therefore preserves and reflects that relation. Different
normalized role/party pair sets remain distinguishable.
If only imported members were adapted while content retained native
party spellings, S1 and S2 would have equal identifier sets but
different Values. That would violate whole-source preservation for
this declared source relation, despite successful member adaptation.
The model performs no further normalization to repair such a mapping.
6.6. Preserving Associations Between Parties
This example records directed document-exchange links between
parties. A source contains an exact ASCII document reference and a
finite sequence of ordered (sender, recipient) pairs. Each endpoint
is a nonempty ASCII party identifier using lowercase letters, digits,
and hyphen, compared exactly under the fictional trade-party/v1
system. Source equivalence requires equal document references and
equal sets of ordered pairs. Sequence order and repeated
presentations of a pair are irrelevant. The links describe
associations; they do not prove delivery or authorization.
The mapping uses context example.org/trade-document/links/v1 and
scope trade-party/v1. The identifier set contains each distinct
endpoint identifier once, regardless of which position it occupies.
Le Expires 14 March 2027 [Page 20]
Internet-Draft Structured Value Model September 2026
Start content with the length-prefixed document reference defined in
Section 6.3. Sort the distinct ordered pairs lexicographically by
ASCII sender and then recipient, with a proper prefix before the
longer string. Append each pair as ";", the sender, ">", and the
recipient. An empty pair set adds no suffix. The restricted
endpoint alphabet excludes both separators.
With document reference invoice:1, compare:
X: [(party-a, party-b), (party-c, party-d)]
Y: [(party-a, party-d), (party-c, party-b)]
Figure 3 shows the same endpoint sets with different ordered pairs.
In graphical renderings, the Y links may cross; such a crossing does
not join the links or introduce another party.
X: Y:
party-a ----> party-b party-a ----> party-d
party-c ----> party-d party-c ----> party-b
Figure 3: Same Endpoints with Different Pairings
Both Values have:
context = "example.org/trade-document/links/v1"
identifiers = {
("trade-party/v1", "party-a"),
("trade-party/v1", "party-b"),
("trade-party/v1", "party-c"),
("trade-party/v1", "party-d")
}
Their content differs:
X: "9:invoice:1;party-a>party-b;party-c>party-d"
Y: "9:invoice:1;party-a>party-d;party-c>party-b"
The sources have the same sender set and the same recipient set.
Separate collections of sender-qualified and recipient-qualified
identifiers would therefore erase their different pairings. The
mapped content preserves those pairings, so X and Y yield non-
equivalent Values. Reordering or repeating a source's existing pairs
leaves its Value unchanged.
Equal document references and ordered-pair sets produce identical
content and identifier sets. Conversely, the length prefix recovers
the exact reference, and the delimited suffix recovers every ordered
Le Expires 14 March 2027 [Page 21]
Internet-Draft Structured Value Model September 2026
pair. Equal Values therefore imply source equivalence. This
establishes preservation and reflection for the mapping, including
empty references, empty pair sets, and links whose sender and
recipient identifiers are equal.
7. Relationship to Existing Work
Scoped identifiers, composite records, exact octet comparison, and
finite sets are established techniques. This specification combines
them into a reusable comparison domain with obligations for mappings
and profiles. The same information could be expressed in another
structure or entirely within content; the dedicated identifier field
provides reuse of qualification and set comparison rules, not
additional expressive power.
[RFC6943] discusses canonicalization and other identifier comparison
methods. [RFC3444] distinguishes information models from data
models; that distinction is an architectural analogy. [RFC8949]
separates an abstract data model from serialization choices. This
document defines values independently of representation, leaving
concrete encodings to profiles.
[I-D.le-comparing-derived-identifiers] provides the broader
comparison-contract framework.
Other specifications give collections of identifiers and
relationships different meanings. [RFC9493] describes aliases
identifying the same subject. [RFC9525] uses reference identifiers
when matching service identities; its Section 6.5 preserves the
association between an application service type and its domain name
rather than recombining components from different reference
identifiers. This is a concrete precedent for the association-
preservation concern in Section 4.5.
UNVTD [UNVTD] provides schemas and semantic resources for trade
documents, including commercial invoices, packing lists, and bills of
lading. These document families provide application context for
Section 6, whose source comparison relations and mappings are
specified independently here.
The UN Transparency Protocol Identity Resolver [UNTP-IDR] supports
discovery and verification across identifier schemes and specifies
conventions for consistent identifier representation. Its
"Identifier Representation" section illustrates failed matching
across credentials when one product is named using different URL and
URN forms. In this model, any adaptation of such forms is fixed by
the surrounding mapping under Section 4.3 and Section 4.4; model
equality compares the resulting exact octets. Resolution and
verification remain operations of the surrounding system.
Le Expires 14 March 2027 [Page 22]
Internet-Draft Structured Value Model September 2026
Controlled Identifiers [W3C-CID-1.0] and DIDs [W3C-DID-1.1] define
application-specific alias, verification, and control relationships.
The version of Recognized Entities cited here
[W3C-RECOGNIZED-ENTITIES-1.0] defines recognition and action
relationships among entities and recognition systems.
Those application relationships require their own interpretation.
Recognition, authorization, control, succession, validity, and trust
semantics remain properties of the surrounding system. When a source
comparison requires a relationship among imported members, a source
mapping can represent the comparison-relevant association under
Section 4.5; bare co-membership alone does not encode it. The model
does not absorb the imported systems' internal derivation,
resolution, lifecycle, or trust mechanisms.
8. Security Considerations
A mapping can erase a required distinction or make equivalent sources
yield non-equivalent Values through ambiguous parsing, unadapted
native spellings, omitted associations, or inconsistent source
processing. A consumer assesses these properties against the
intended source relation. Loss within imported identifiers and loss
in a later derivation are separate boundaries, as described in
Sections 4.4 and 5.2.
Changing the admitted identifier set changes Value equality even when
the application authorizes that change. An unauthorized omission,
insertion, or substitution is an integrity failure when it violates
the applicable mapping or the binding required by the consuming
protocol. Duplicate presentations that leave the mathematical set
unchanged do not by themselves change model equality. These effects
are determined before attributing any equality to a downstream
cryptographic collision.
A surrounding protocol MUST protect the definitions that affect
comparison and any attacker-controlled selection of those definitions
according to its threat model. Protection can concern both acquiring
authentic material and selecting the applicable mapping, context,
imported interpretation, or profile. A stable name or authenticated
locator alone does not fix mutable interpretation.
Model equality authenticates neither a source nor its claimed
identifier binding. Authority, freshness, revocation, provenance,
and trust require separate evidence. Local resource limits remain
necessary where appropriate for denial-of-service protection; refusal
is not evidence of non-equivalence.
Le Expires 14 March 2027 [Page 23]
Internet-Draft Structured Value Model September 2026
9. Privacy Considerations
Stable or low-entropy material in a Value can permit correlation or
offline guessing when used in a deterministic derived identifier.
Hashing alone does not make that material confidential.
Combining identifiers from independently governed systems can create
linkage even when model co-membership asserts no cross-system
identity. A particular combination can identify a smaller set of
possible sources than any member alone. Exposing only a stable
opaque result for that combination can retain correlation or guessing
risks without exposing the individual member octets.
Applications assess which identifying inputs are necessary, how
widely derived identifiers are exposed, and whether their comparison
purpose permits excluding unnecessary material. Persistent
identifiers and linkability are discussed more generally in
[RFC6973]. Model opacity is a comparison boundary, not a
confidentiality guarantee.
10. IANA Considerations
This document has no IANA actions.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[I-D.le-comparing-derived-identifiers]
Le, T., "A Framework for Comparing Independently Derived
Identifiers", Work in Progress, Internet-Draft, draft-le-
comparing-derived-identifiers-01, 7 September 2026,
<https://datatracker.ietf.org/doc/html/draft-le-comparing-
derived-identifiers-01>.
Le Expires 14 March 2027 [Page 24]
Internet-Draft Structured Value Model September 2026
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for
Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
2013, <https://www.rfc-editor.org/info/rfc6943>.
[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, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9493] Backman, A., Scurtescu, M., and P. Jain, "Subject
Identifiers for Security Event Tokens", RFC 9493,
DOI 10.17487/RFC9493, December 2023,
<https://www.rfc-editor.org/info/rfc9493>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[UNVTD] UN/CEFACT, "UN/CEFACT Verifiable Trade Documents", 28 July
2026, <https://unvtd.unece.org/overview/>. Project
overview, last updated 28 July 2026. Accessed 11
September 2026.
[UNTP-IDR] UN/CEFACT, "UN Transparency Protocol: Identity Resolver",
Version 0.7.0,
<https://untp.unece.org/docs/0.7.0/specification/
IdentityResolver/>. Versioned specification for pre-
production pilot implementations. Accessed 11 September
2026.
[W3C-CID-1.0]
Sporny, M., Ed. and M. B. Jones, Ed., "Controlled
Identifiers v1.0", W3C Recommendation, 15 May 2025,
<https://www.w3.org/TR/2025/REC-cid-1.0-20250515/>.
Latest version available at
https://www.w3.org/TR/cid-1.0/.
Le Expires 14 March 2027 [Page 25]
Internet-Draft Structured Value Model September 2026
[W3C-DID-1.1]
Sporny, M., Ed. and D. Zagidulin, Ed., "Decentralized
Identifiers (DIDs) v1.1", W3C Candidate Recommendation
Snapshot, 5 March 2026,
<https://www.w3.org/TR/2026/CR-did-1.1-20260305/>. Latest
version available at https://www.w3.org/TR/did-1.1/.
[W3C-RECOGNIZED-ENTITIES-1.0]
Jeyakumar, I. H. J., Ed. and M. Sporny, Ed., "Recognized
Entities v1.0", W3C Working Draft, 6 September 2026,
<https://www.w3.org/TR/2026/WD-vc-recognized-entities-
1.0-20260906/>. Latest version available at
https://www.w3.org/TR/vc-recognized-entities-1.0/.
Appendix A. Model Test Considerations
These informative cases test model semantics without choosing a wire
format, hash, API, or minimum resource capacity.
* Distinguish an empty set from a set containing an empty scope and
identifier pair. Accept finite empty octet strings at the model
boundary; apply any imported-system restrictions in the mapping or
profile.
* Preserve arbitrary octets, including zero octets and values
outside ASCII. Changing a scope or identifier octet changes the
pair; a leading zero octet is not discarded by model comparison.
* For presentations accepted by a profile, verify that order and
repeated members do not change the represented set. Test
representation rejection separately; model set equality does not
prescribe decoder acceptance.
* Hold imported interpretation and participation fixed when testing
equivalent native spellings. Exercise reflection as well as
preservation when an import mapping claims to retain native
comparison unchanged.
* Test declared source equivalence against the complete Value.
Equal imported members do not compensate for content that retains
a spelling distinction excluded by the source relation. Exercise
the equivalent sources and the incomplete-adaptation case in
Section 6.5.
* Test role swaps, the same native identifier in different roles,
and distinctions in position or occurrence. Check the association
structure when participation is carried in content.
Le Expires 14 March 2027 [Page 26]
Internet-Draft Structured Value Model September 2026
* In Section 6.3, compare "invoice:1" with pairs {(buyer, party-a),
(seller, party-a)} against "invoice:1;buyer=party-a" with only
{(seller, party-a)}. The identifier sets are equal; the framed
content differs. Cover delimiter characters, suffix-like
reference text, and empty references and pair sets, separately and
together.
* Preserve grouping across multiple relationships when the source
relation requires it. The edge sets {(a, b), (c, d)} and {(a, d),
(c, b)} differ even though their input and output endpoint sets
are identical. Role-qualified endpoints alone lose grouping.
Section 6.6 supplies a complete mapping and mapped Values for this
case.
* Keep equal identifier octets under different systems or tenants
distinct when their imported meanings differ. Vary participation
separately from imported interpretation, as in Section 6.4.
* Check the intended native relation before adapting it to equality.
Non-transitive overlap, as in Section 4.4, cannot be preserved
unchanged by one independently computed identifier per source.
* Change context, content, or a distinct set member independently
and check the resulting model inequality. Equal context octets
from unrelated definitions do not establish imported semantic
compatibility.
* Test fixed-input mapping reproducibility and explicit dependency
selection. Keep structural rejection, profile-domain exclusion,
and resource refusal distinct. A structurally admitted Value with
inconsistent content associations and identifier-set membership is
not evidence of conformance to the mapping in Section 6.3.
* In a concrete derivation profile, test tuple framing, complete set
encoding, and equivalent accepted representations. Evidence about
these profile properties is additional to evidence about model
equality.
The additional cases in Table 1 use the mapping in Section 6.3.
Every Value has context example.org/trade-document/participants-
content/v2. The following input sequences P0, P1, and P2 produce
identifier sets I0, I1, and I2, respectively:
Le Expires 14 March 2027 [Page 27]
Internet-Draft Structured Value Model September 2026
P0 = []
P1 = [(buyer, party-a)]
P2 = [(seller, party-ab), (seller, party-a)]
I0 = {}
I1 = {("trade-party/v1", "party-a")}
I2 = {("trade-party/v1", "party-a"),
("trade-party/v1", "party-ab")}
+======+=============+=======+=====================================+
| Case | Reference | Pairs | Content |
+======+=============+=======+=====================================+
| T1 | "" | P0 | "0:" |
+------+-------------+-------+-------------------------------------+
| T2 | "invoice:1" | P0 | "9:invoice:1" |
+------+-------------+-------+-------------------------------------+
| T3 | "" | P1 | "0:;buyer=party-a" |
+------+-------------+-------+-------------------------------------+
| T4 | "" | P2 | "0:;seller=party-a;seller=party-ab" |
+------+-------------+-------+-------------------------------------+
| T5 | hex 00 | P0 | hex 31 3a 00 |
+------+-------------+-------+-------------------------------------+
Table 1: Additional Content-Framing Cases
Quoted strings denote exact ASCII octets without the quotation marks.
In T5, hex notation denotes octets directly: the reference is one NUL
octet, and content is ASCII "1:" followed by that octet. The ASCII
reference domain does not exclude control octets. T4 exercises
proper-prefix ordering of party-a before party-ab under the same
role. These cases do not extend the example's source domain to non-
ASCII octets.
Selected cases can refute a universal claim but do not establish it
over an unbounded domain. Mapping arguments in Section 6 rely on the
declared source relation and complete mapping rules, not solely on
the displayed cases.
Author's Address
Thanh Le
Viet Nam
Email: vnlemanhthanh@gmail.com
Le Expires 14 March 2027 [Page 28]