External-Registry DNS Resource Record Types: UNECE and ISO

Introduction Many protocols need to convey data whose controlled vocabularies are defined and maintained outside the IETF, including but not limited to quantities, countries, languages, locations, and units of measure. The authoritative registries of these vocabularies are external standards organizations. The two referenced in this document are the United Nations Economic Commission for Europe (UNECE) and the International Organization for Standardization (ISO). The DNS has historically accommodated such data in one of two ways. Either the external registry is duplicated into an IANA registry, creating a synchronization burden and a second claimant to authority over the code space, as the IANA Language Subtag Registry replicates ISO and UN code lists, and as IANA's IEEE 802 Numbers registry partially mirrors IEEE Registration Authority assignments; or the data is carried in TXT records under private convention, forfeiting type-distinct queries, field structure, and single-RRset signing. This document defines two resource record types which take a different path: the RDATA carries a discriminator identifying the registry, an optional numeric value, the registry code point, and an optional free-text descriptor. Semantics of the code remain entirely with the external maintainer; unrecognized codes are carried and displayed rather than rejected, so that the RRTYPEs track the external registries without protocol changes or IANA registry actions. The approach has precedent in e164.arpa , whose ENUM delegations are keyed to ITU-T E.164 country-code assignments without maintaining a local copy, leaving authority with the external registry. The immediate motivation for these RRTYPEs is the work currently being done in the DIEM working group on Digital Emblems, which convey cryptographically signed record-bundles identifying assets marked under international law. The proposed RRTYPEs are, however, general-purpose and intended for use by other applications which need to represent standardized data formats maintained by external registries.

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The External Registry Pattern

Roles

External Maintainer:: The standards organization which defines and revises external registries. The code space belongs to the External Maintainer; nothing in this document, and no issuer of records, creates, modifies, or retires codes.
Issuer:: The party publishing records in a DNS zone.
Receiver:: Any party retrieving or interpreting the resource records.

Design Principles RRTYPEs following this pattern conform to all of the following. The UNECE () and ISO () types are initial instantiations.

One type per maintainer organization:: A single RRTYPE covers all of an External Maintainer's registries; a Discriminator field in the RDATA specifies the particular registry. Per-registry RRTYPEs are not defined.
Codes verbatim:: The Code field carries the code exactly as published by the External Maintainer, and is compared octet-for-octet, with no case folding. Issuers MUST NOT coin codes. Codes contain no whitespace: where a maintainer's published rendering separates a code's components with whitespace, the separator is presentation rather than part of the code, and the code is the concatenation.
Unknown values carried:: A Receiver encountering an unrecognized Discriminator MUST carry and display the record without interpretation. A Receiver encountering an unrecognized code within a recognized list MUST display it uninterpreted and MUST NOT treat the record as invalid. These rules allow the type to track the external registry without IANA registry action or protocol changes.
Registries must be at a valid stage:: An Issuer MUST NOT publish a DNS Resource Record referencing a registry whose code list is not currently active and publicly available at no cost and citable at the time of RR publication. This precludes code lists which have not yet been published as official work-products of their respective External Maintainer organizations, code lists which require subscriptions to access or which carry prohibitive use restrictions, and those which have been withdrawn or superseded.
No mirror registries:: IANA action is limited to the RRTYPE code point. No IANA subregistry duplicating the external registries is created; specifications instead cite each external registry as its current revision or its successor.
Common value grammar:: The optional numeric Value field uses the shared grammar and semantics of , including its distinction between an inapplicable quantity and an unknown one.
Descriptor as hint:: The optional Descriptor field is free text identifying what the datum describes relative to the subject. It is a display and matching hint for human receivers, and MUST NOT be interpreted as machine semantics.
RFC 3597 cleanliness:: RDATA contains no domain names, and requires no compression, rewriting, or additional-section processing, so the RRTYPEs are fully compatible with unknown-type handling .
Temporal anchoring:: Where records appear in DNSSEC-signed zones and historical accuracy matters, Receivers SHOULD interpret codes against the registry revision in force at the inception time of the covering RRSIG . Where an External Maintainer retains deleted codes in its published lists, as UNECE Recommendation 20 does , locally cached code tables remain safe.

The Value Field If a record utilizes a code which does not require a quantity, the Value is not applicable (na): empty, zero-length on the wire, the solitary token "-" in presentation. This is the same representation used for an empty Salt field in NSEC3 and NSEC3PARAM . A Value field MUST NOT consist solely of the octet "-"; the zero-length field is na's only wire encoding. Values are represented in US-ASCII in this grammar, using ABNF and its core rule DIGIT:

"?" (unknown):: A quantity attaches to this record, but is unknown to the Issuer at the time of RR creation or signing.
quantity:: The number, in the units or terms of the code. The parenthetical precision is plus-or-minus that amount in the same units; "(?)" marks the precision unknown. A precision attached to an unknown value ("?(n)") is not permitted.

The grammar admits exactly one representation of each number: leading zeros, trailing zeros in a fractional part, all-zero fractional parts, and negative zero cannot be represented. Non-zero negative values are permitted. A Receiver encountering a nonempty Value which does not match the grammar MUST display it uninterpreted without deriving a quantity, and MUST NOT treat the record as invalid. The distinction between "-" and "?" is semantic and deliberate: the former states that no quantity exists to be reported, the latter that one exists and is unreported.

The UNECE RRTYPE The UNECE RRTYPE conveys a value coded according to a registry published in the UNECE Recommendations series.

Wire Format The wire format of the RDATA field is as follows: Fields marked "/" are variable length.

Recommendation Length:: an 8-bit unsigned integer, which MUST be nonzero.
Recommendation:: <Recommendation Length> octets, US-ASCII: a token identifying the Recommendation from whose code list the Code field is drawn. The token is the Recommendation's identifier with the words "Recommendation No." omitted: "20" for Recommendation No. 20. Tokens are not necessarily numeric: a future "Recommendation No. 3bis" would yield the token "3bis". "UNECE" is omitted because the RRTYPE itself names the organization; edition years, amendments, and corrigenda are omitted to preserve forward compatibility under the temporal-anchoring principle of . Tokens contain no whitespace and are compared octet-for-octet with no case folding. Issuers MUST use tokens exactly as the rule yields them, neither coining nor reformatting.
Value Length:: an 8-bit unsigned integer.
Value:: <Value Length> octets, US-ASCII, matching the value grammar of . A length of zero encodes na, and is its only wire encoding.
Code Length:: an 8-bit unsigned integer, which MUST be nonzero.
Code:: <Code Length> octets, US-ASCII, verbatim from the cited Recommendation's registry.
Descriptor:: all remaining octets of the RDATA, UTF-8 , possibly empty, but at most 255 octets in total. A Receiver encountering a longer Descriptor MUST NOT treat the record as invalid.

Presentation Format The presentation format is:

 [""]
]]>


        where <rec> is the Recommendation token per ; <value>
is the Value token per , with the zero-length wire
value presented as "-"; <code> is the Code, unquoted; and the
Descriptor, if present, is a single quoted <character-string> per
, its embedded quotes, backslashes, and
non-ASCII octets escaped by that section's "\X" and "\DDD"
conventions.


      
        Applicable Recommendations
        The applicable Recommendations are those whose registries UNECE
itself publishes .  At the time of
writing, these include:
        
        A Recommendation 16 code is the five-character concatenation of the
ISO 3166-1 country code and the location code; the space separating
them in UNECE's published tables is not part of the code: "JPTYO",
not "JP TYO".
        UNECE, through its United Nations Centre for Trade Facilitation and
Electronic Business (UN/CEFACT), maintains and publishes these code
lists free of charge .  The code-list Recommendations are
maintained on UN/CEFACT's behalf by its Information Content
Management Group, and the Recommendation 16 code list, UN/LOCODE, is
updated by the UNECE secretariat twice a year.  Deleted and
deprecated code values are marked as such in the published lists
rather than removed, so that a code value, once assigned, remains
permanently attached to its original meaning .
        Recommendations which adopt externally maintained standards are out
of scope for this type: Recommendation 3 (ISO 3166), Recommendation 9
(ISO 4217; see the ISO RRTYPE, ), and Recommendation 5
(Incoterms, maintained by the International Chamber of Commerce).
Recommendation 10 (ship identification) adopts the IMO Ship
Identification Number Scheme, whose numbers appear as identifiers
rather than as coded values.
      
      
        Examples
        
      
      
        Processing
        Receivers apply the rules of .  In particular, a
Receiver encountering a Recommendation token it does not recognize
carries and displays the record uninterpreted, and a Receiver
encountering a code it does not recognize displays the code
uninterpreted without treating the record as invalid.


    
      The ISO RRTYPE
      The ISO RRTYPE conveys a value coded by a registry defined in a
standard of the International Organization for Standardization.
      
        Wire Format
        The wire format of the RDATA field  is as follows:
        
        Fields marked "/" are variable length.
        
          Standard Length:
          
            an 8-bit unsigned integer, which MUST be nonzero.
          
          Standard:
          
            <Standard Length> octets, US-ASCII: a token identifying the
standard from whose code list the Code field is drawn.  The token
is the standard's identifier, including any hyphen-joined part and
sub-part identifiers: "3166-1" for ISO 3166-1.  Where the
identifier carries a type prefix (such as TR, TS, PAS, IWA, or
Guide), the prefix is joined with an underscore: for example,
"TR_24028" for ISO/IEC TR 24028, or "Guide_2" for ISO/IEC Guide 2.
"ISO" and "ISO/IEC" are omitted because the RRTYPE itself names the
organization; edition years, amendments, and corrigenda are omitted
to preserve forward compatibility under the temporal-anchoring
principle of .  Tokens contain no whitespace and are
compared octet-for-octet with no case folding.  Issuers MUST use
tokens exactly as the rule yields them, neither coining nor
reformatting.
          
          Value Length:
          
            an 8-bit unsigned integer.
          
          Value:
          
            <Value Length> octets, US-ASCII, matching the value grammar of
.  A length of zero encodes na, and is its only wire
encoding.
          
          Code Length:
          
            an 8-bit unsigned integer, which MUST be nonzero.
          
          Code:
          
            <Code Length> octets, US-ASCII, verbatim from the cited standard.
For ISO 3166-1, alpha-2 codes are RECOMMENDED, for consistency with
UNECE Recommendation 3 and general DNS practice.  For ISO 4217, the
alphabetic codes are RECOMMENDED over the numeric, for consistency
with UNECE Recommendation 9.  For ISO 639, two-letter (Set 1)
identifiers are RECOMMENDED where they exist.
          
          Descriptor:
          
            all remaining octets of the RDATA, UTF-8 , possibly
empty, but at most 255 octets in total.  A Receiver encountering a
longer Descriptor MUST NOT treat the record as invalid.
          
        
      
      
        Presentation Format
        The presentation format is:
           [""]
]]>
        where <standard> is the Standard token per ; <value> is
the Value token per , with the zero-length wire value
presented as "-"; <code> is the Code, unquoted; and the Descriptor,
if present, is a single quoted <character-string> per
, its embedded quotes, backslashes, and
non-ASCII octets escaped by that section's "\X" and "\DDD"
conventions.
      

      
        Applicable Standards
        Applicable standards are those defining registries of code lists;
initially:
        
        ISO permits use of its country, currency, and language codes free of
charge , and each code list is maintained by a body
designated for its standard: the ISO 3166 Maintenance Agency for
country and subdivision codes , SIX Financial Information
for currency codes , and the ISO 639 Maintenance Agency
for language codes .  Retirement practices vary by
registry.  A deleted ISO 3166-1 alpha-2 code element is recorded in
ISO 3166-3 and cannot be reused for fifty years under current policy,
but reassignment has occurred.  Withdrawn ISO 4217 codes are
retained, with their withdrawal dates, in that standard's list of
historic currencies.  Retired ISO 639 identifiers are never
reassigned; they remain in the code set permanently.
        Out of scope: ISO 8601, which defines a format rather than a code
list (temporal data uses a separate mechanism); ISO 6346, whose
container owner codes appear within asset identifiers; and ISO 15924,
whose script codes travel within BCP 47  language tags
inside textual elements.
      
      
        Examples
        
      
      
        Processing
        Receivers apply the rules of .  In particular, a
Receiver encountering a standard token it does not recognize carries
and displays the record uninterpreted, and a Receiver encountering a
code it does not recognize displays the code uninterpreted without
treating the record as invalid.
      
    

    
      Defining Additional External-Registry RRTYPEs
      This document is intended as the model for future RRTYPEs which make
external registries usable from the DNS without duplicating their
content.  Sections  and
 record the
corresponding information for the two types defined here.  A
specification defining such a type:
      
          identifies the External Maintainer, demonstrates that its
registries are managed with a sufficient level of maturity,
stably published and citable, and states the maintainer's
code-retirement policy (reassignment of retired codes weakens
the temporal-anchoring rule of  and SHOULD be
documented if present);
        
        
          defines a single RRTYPE for the maintainer's whole series,
discriminated by a length-prefixed US-ASCII token
deterministically formed from the External Maintainer's own
identifier for the defining document;
        
        
          reuses the Value field grammar and semantics of 
verbatim, so that implementations share one parser across all
types following this pattern;
        
        
          carries codes verbatim with octet-for-octet comparison, and
prohibits issuers from coining codes;
        
        
          adopts the unknown-value carriage rules of 
unchanged;
        
        
          requests only an RRTYPE code point from IANA, creating no mirror
subregistry; and
        
        
          keeps domain names out of the RDATA, preserving RFC 3597
compatibility.
        
      
      One possible additional instantiation is an RRTYPE for the World
Customs Organization registries, carrying Harmonized System
subheadings for the description of goods; the pattern accommodates it
without modification.
    
    
      Security Considerations
      Records of these types assert data under the containing zone's DNSSEC
signatures; they confer no authorization, and their trustworthiness
is the same as that of the zone's signing chain.
      Issuers should consider anything published in the DNS to be public
unless specific selective-disclosure measures are taken to constrain
distribution.  Such measures are out of scope for this document.
      Because the code travels verbatim in RDATA, a revision of the
external registry cannot alter published signed data.  It can,
however, change what a Receiver understands a code to mean.  Where
the External Maintainer never reassigns retired codes, cached tables
are safe indefinitely; where that policy is absent, Receivers SHOULD
apply the temporal-anchoring rule of , interpreting
codes against the registry revision in force at the inception time of
the covering RRSIG.
      The Descriptor is untrusted free text.  Receivers MUST NOT derive
machine behavior from it, and display implementations SHOULD sanitize
it as they would any untrusted text, removing control and other
hazardous characters.
      The "?" token is an assertion of ignorance made under signature.
Relying parties should treat it as exactly that: evidence that the
Issuer disclaimed knowledge at signing time, not as a zero value nor
as an omission.
    
    
      IANA Considerations
      This document requests the assignment of two new decimal RRTYPE
identifiers, following the guidelines of  (BCP 42).
      
        RRTYPE Assignments
        IANA is requested to add the following entries to the "Resource
Record (RR) TYPEs" registry in the "Domain Name System (DNS)
Parameters" registry group:
        RRTYPE assignments requested
          
          
            
              TYPE
              Value
              Meaning
              Reference
            
          
          
            
              UNECE
              TBD1
              Value coded per a UNECE Recommendation
              [this document]
            
            
              ISO
              TBD2
              Value coded per an ISO standard
              [this document]
            
          
        
        [RFC Editor: replace TBD1 and TBD2 with the decimal values assigned
by IANA, and remove this note.]
      
      
        Expert Review
        RRTYPE identifiers are assigned under the DNS RRTYPE Allocation
Policy of , an Expert Review process
 conducted on the basis of completed application templates
conforming to the template of .  Completed templates for
both types defined here have been submitted separately to
dns-rrtype-applications@ietf.org.  Assignment via Expert Review MAY
complete in advance of the publication of this document, in which
case IANA is requested to update the registry references for both
entries to point to this document upon its publication.

TYPE	Value	Meaning	Reference
UNECE	TBD1	Value coded per a UNECE Recommendation	[this document]
ISO	TBD2	Value coded per an ISO standard	[this document]