RFC 9517

A URN Namespace for the Data Documentation Initiative (DDI)

📅 published January 2024, from ietf

RFC 9517: A URN Namespace for the Data Documentation Initiative (DDI) 🎀

  • Number: 9517
  • Title: A URN Namespace for the Data Documentation Initiative (DDI)
  • Author: J. Wackerow, DDI Alliance
  • Category: Informational
  • Stream: Independent Submission
  • Date: January 2024
  • ISSN: 2070-1721
  • Obsoletes / Updates: Nothing. The title block doesn't list any RFCs this one obsoletes or updates.

Abstract ✨

Okay bestie, the big idea here is a namespace! This doc sets up the Namespace Identifier (NID) ddi for Uniform Resource Names (URNs). Those URNs are used to identify resources that follow the standards published by the Data Documentation Initiative (DDI) Alliance. 💖

Heads up: The DDI Alliance is not affiliated with the Internet Engineering Task Force (IETF) or the Internet Society (ISOC). This Independent Submission is not a standard, and it doesn't have IETF community consensus. Just so we're clear! 🙈

Status of This Memo

This doc is not an Internet Standards Track specification. It's published for informational purposes, so no pressure, it's just here to inform 🌸

This is a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. For the details, check Section 2 of RFC 7841. 💅

Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc9517 ✨

Copyright (c) 2024 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) as they're in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. 🧚

Table of Contents

   1.  Introduction
   2.  Conventions Used in This Document
   3.  Specification
     3.1.  Declaration of Syntactic Structure
       3.1.1.  Description
       3.1.2.  ABNF Grammar
       3.1.3.  Regular Expression
       3.1.4.  Examples of DDI URNs
     3.2.  Relevant Ancillary Documentation
     3.3.  Identifier Uniqueness Considerations
     3.4.  Identifier Persistence Considerations
     3.5.  Process of Identifier Assignment
     3.6.  Process for Identifier Resolution
     3.7.  Rules for Lexical Equivalence
     3.8.  Conformance with URN Syntax
     3.9.  Validation Mechanism
     3.10. Scope
   4.  Namespace Considerations
     4.1.  URN Assignment Procedures
     4.2.  URN Resolution/Delegation
     4.3.  Type of Resources To Be Identified
     4.4.  Type of Services
   5.  Community Considerations
     5.1.  Open Assignment and Use of Identifiers
     5.2.  Open Operation of Resolution Servers
     5.3.  Creation of Software for Service Discovery
   6.  IANA Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  Example DNS Records
     A.1.  Delegation of the URN Namespace "ddi"
     A.2.  Delegation of DDI Agencies
     A.3.  DDI Services
   Appendix B.  Algorithm for DDI Service Discovery
     B.1.  Application Unique String
     B.2.  First Well Known Rule
     B.3.  Valid Databases
     B.4.  Expected Output
   Acknowledgments
   Author's Address

1. Introduction ✨

This doc registers a formal Namespace Identifier (NID) for URNs linked to DDI resources, following the process defined in [RFC8141]. 🦋

The DDI Alliance is an international collab that's all about metadata standards and semantic products for describing social science data, data covering human activity, and other data built on observational methods. 🌈 DDI specs are free standards that document and manage the different stages of the research data lifecycle, like conceptualization, collection, processing, distribution, discovery, and archiving. Documenting data with DDI makes it easier to understand, interpret, and use. That goes for people, software systems, and computer networks alike 💜

Here's where the formats live. The DDI Codebook [DDI-C] and DDI Lifecycle [DDI-L] specs are written in XML Schema. DDI Extended Knowledge Organization System (XKOS) [DDI-XKOS] is in OWL/RDF. Structured Data Transformation Language (SDTL) [DDI-SDTL] is in JSON Schema. And the upcoming DDI Cross Domain Integration (DDI-CDI) is in UML. 👑

DDI also plays nicely with other metadata standards: the Dublin Core Metadata Initiative [DUBLINC], Statistical Data and Metadata Exchange [SDMX] for exchanging aggregate data, ISO/IEC 11179 [IS11179] for building metadata registries (like question, variable, and concept banks), and ISO 19115 [ISO.19115.2003] for supporting geographic information systems. It's giving collaboration 🫶

DDI URNs are all about reusability. They help DDI resources get reused inside a single DDI instance and across a distributed network of DDI instances. 🍓

The DDI specification is developed and maintained by the DDI Alliance [DDI-ALL], a self-sustaining membership organization. Over 40 member institutions have a voice in how the DDI specs get developed. This memo about the ddi URN is an informational specification. It's not a standard, and it isn't a product of the IETF. 🎀

2. Conventions Used in This Document ✨

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💅

Only the ALL CAPS versions carry that meaning. Lowercase uses of these words aren't interpreted as carrying [RFC2119] significance. 🙈

Quick glossary, because we love a definition:

  • DDI: Data Documentation Initiative. Often used as a synonym for the DDI specification. 📚
  • DDI agency: An organization that maintains DDI resources. 🏛️

3. Specification 🌸

This section gives you the information required to register a formal namespace under the registration procedure defined in [RFC8141]. The URNs conform to the syntax defined in [RFC8141]. ✨

3.1. Declaration of Syntactic Structure 💖

3.1.1. Description

The Namespace Specific String (NSS) of every URN using the ddi NID is a globally unique identifier. It's made up of three parts: the DDI agency-identifier (registration authority identifier), the identifier of the DDI resource (data identifier), and the version of the resource (version-identifier) [DDI-ID]. This structure follows the International Registration Data Identifier (IRDI) defined in "Information technology - Metadata registries (MDR) - Part 6: Registration", Annex A [IS11179]. 🧩

If you want more on DDI resource identification, check the Identification section of the "DDI Lifecycle 3.3 Technical Guide" [DDI-ID]. 📖

The DDI NSS has this structure:

<agency-identifier>:<resource-identifier>:<version-identifier>

Let's break down the agency-identifier, because it's giving DNS vibes. 🌐 It identifies a DDI agency that maintains DDI resources. It basically follows the rules of reversed domain names, and it's case insensitive. That's what makes DNS resolution of DDI agency-identifiers possible. The hierarchy of domains goes from left to right: each label to the right is a subdivision (a subdomain) of the domain to its left. The left-most label is the top-level domain, and it SHALL be a country code corresponding to ISO 3166 alpa-2 codes [ISO3166] or another top-level domain maintained by IANA [TLD]. All two-letter top-level domains are reserved for current and future ISO 3166 codes. ✨

Assigning identifiers for DDI agencies in the requested namespace is handled by the DDI Alliance (see Section 3.5 on "Process of Identifier Assignment"). The next subdomain identifies the agency within that top-level domain, and more optional subdomains can follow. The top-level domain and any subdomains are separated by the full stop character. That full stop character is not allowed inside top-level domain names or subdomain names. 🦋

The top-level domain and subdomains are built from the limited character set for the preferred form of a DNS label ([RFC1035], Section 2.3.1). DNS rules restrict the length of the label and of the full name ([RFC2181], Section 11). The agency identifier is case insensitive ([RFC4343], Section 2). 🎀

The resource-identifier is the identifier of a DDI resource from a DDI agency. Its value MUST be unique within the scope of that DDI agency. Heads up: the resource-identifier is case sensitive. 🔥

The version-identifier is the version of a DDI resource from a DDI agency. Its value MUST be unique within the scope of that resource. The resource version is case sensitive too. 💜

3.1.2. ABNF Grammar

The full syntax for the complete URN is written in Augmented Backus-Naur Form (ABNF), as described in [RFC5234]. Here's the grammar, serving literal ABNF realness 🤓

; Rules are case sensitive, if not stated otherwise.
ddi-urn              = urn separator ddi separator ddi-irdi
; urn is case insensitive, see [RFC8141].
urn                  = "urn"
; ddi is the URN namespace identifier.
; ddi is case insensitive, see [RFC8141], Section 2.1.
ddi                  = "ddi"
; ddi-irdi is the namespace specific string (NSS).
; ddi-irdi - international registration data identifier,
; see [IS11179] Annex A.2.
ddi-irdi             = agency-identifier separator
                       resource-identifier separator
                       version-identifier
; agency-identifier is case insensitive, see [RFC4343], Section 2.
; For allowed characters, see [RFC1035], Section 2.3.1.
; For length restrictions, see [RFC2181], Section 11.
agency-identifier    = top-level-domain
                         sub-separator ddi-authority-id
                         *(sub-separator ddi-sub-authority-id)
                       ; length limit is 255 characters
                       ; see Section 11 of [RFC2181]
top-level-domain     = dns-label
ddi-authority-id     = dns-label
ddi-sub-authority-id = dns-label
dns-label            = (ALPHA / DIGIT)
                         [ *(ALPHA / DIGIT / "-")
                           (ALPHA / DIGIT) ]
                       ; length limit is 63 characters
                       ; see Section 11 of [RFC2181]
resource-identifier  = restricted-string
                       *("/" restricted-string)
version-identifier   = restricted-string
                       *("/" restricted-string)
restricted-string    = 1*(unreserved / sub-delims / "@")
; Definitions for unreserved and sub-delims from
; [RFC3986], Section 2.2.
unreserved           = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims           = "!" / "$" / "&" / "'" / "(" / ")" /
                       "*" / "+" / "," / ";" / "="
separator            = ":"
sub-separator        = "."
; ALPHA and DIGIT are actually defined in the ABNF
; specification. They are declared here for convenience
; purposes.
ALPHA                = %x41-5A /  ; uppercase letters
                       %x61-7A    ; lowercase letters
DIGIT                = %x30-39    ; digits

Figure 1: ABNF Grammar 💖

3.1.3. Regular Expression 🎀

okay so the syntax here is the XML Schema flavor 💅, and it's super easy to port to other flavors ✨. These regexes implicitly anchor at the head and tail, so you don't need to add ^ or $ yourself. The grammar uses components (named in angle brackets, like <component>) and is written in free-spacing mode so it's easier to read 🦋. The XML Schema flavor doesn't support free-spacing, though, so keep that in mind if you copy it over. Heads up, bestie: stacking multiple quantifiers can give you false outcomes because of greediness 🙈. That's why the length restriction and the other purposes get separate regular expressions for the components agency-identifier and dns-label.

ddi-urn              := [Uu][Rr][Nn] : [Dd][Dd][Ii] :
                          <agency-identifier> :
                          <resource-identifier> :
                          <version-identifier>
agency-identifier    := <top-level-domain> \.
                          <ddi-authority-id>
                          (\. <ddi-sub-authority-id>)*
agency-identifier    := .{1,255}

top-level-domain     := <dns-label>
ddi-authority-id     := <dns-label>

ddi-sub-authority-id := <dns-label>
dns-label            := [A-Za-z0-9]([-A-Za-z0-9]*[A-Za-z0-9])?

dns-label            := .{1,63}

resource-identifier  := <restricted-string>
                        (/ <restricted-string>)*

version-identifier   := <restricted-string>
                        (/ <restricted-string>)*

restricted-string    := [A-Za-z0-9-._~!$&'()*+,;=@]+

3.1.4. Examples of DDI URNs ✨

These examples come from the DDI Lifecycle 3.3 documentation [DDI-ID]. Quick note: the resource-identifiers are simplified 🌸. In real life they're way longer so they stay unique. They also don't match DDI types, even though the examples might make it look like they do.

urn:ddi:us.ddia1:R-V1:1

Figure 2: URN of a Represented Variable

This is the DDI represented variable identified by "R-V1" with the version "1" of the DDI agency "ddia1" located in the domain "us" [DDI-EXRV].

urn:ddi:us.ddia1:PISA-QS.QI-2:1

Figure 3: URN of a Question Item

This is the DDI question item identified by "PISA-QS.QI-2" with the version "1" of the DDI agency "ddia1" located in the domain "us" [DDI-EXQU].

urn:ddi:int.ddi.cv:AggregationMethod:1.0

Figure 4: URN as Reference to a Controlled Vocabulary

This is the DDI controlled vocabulary identified by "AggregationMethod" with the version "1.0" in the scope of the DDI agency "ddi" and sub-agency "cv" in the domain "int" [DDI-CVAG]. 💜

3.2. Relevant Ancillary Documentation 📚

There's an intro article on DDI at [DDI-INTR] if you want the basics 🍓.

Info on the DDI specifications (DDI-C, DDI-L, XKOS, Controlled Vocabularies, and SDTL) lives in the standards section of the DDI Alliance website [DDI-ALL].

Info on domain names is in the relevant RFCs, so here's the tour:

  • For an overview, see [RFC1034].
  • Regarding case insensitivity, see Section 2.3.3 of [RFC1035].
  • Regarding syntax, see the "Lexical grammar" in the "Grammatical Host Table Specification" section of [RFC0952] and Section 2.1 of [RFC1123].
  • Regarding size limits, see Section 2.1 of [RFC1123] and Section 2.3.4 of [RFC1035].

3.3. Identifier Uniqueness Considerations 🔑

The DDI Alliance manages the assignment of identifiers for DDI agencies in the requested namespace. It makes sure those agency-identifiers follow the directives for uniquely identifying DDI agencies ✨.

Assignment of URNs for resources of a DDI agency in the requested namespace is managed by that agency. The agency makes sure its URNs are unique within its own scope 💖.

3.4. Identifier Persistence Considerations 🧚

Persistence depends on resolution being properly delegated at the DDI agency level, and on the DDI agency assignment sticking around. The DDI agency is also responsible for the persistence of the referenced resource 🫶.

3.5. Process of Identifier Assignment 📝

The DDI Alliance manages assignment of identifiers for DDI agencies in the requested namespace. A registry for DDI agency identifiers uses an approval process to make sure agency-identifiers follow the rules [DDI-REGI].

Assignment of URNs for resources of a DDI agency, and of its sub-agencies, in the requested namespace is managed by the respective DDI agency 🌈.

3.6. Process for Identifier Resolution 🔍

The DDI Alliance promotes a service discovery system that finds the available services connected to DDI agencies, using the Domain Name System (DNS) 🌐. A DNS request for a DDI agency within the domain ddi.urn.arpa gets delegated by the DDI Alliance DNS servers to the DNS servers of the relevant DDI agency. The response is a list of available DDI services for the agency identifier under which the agency assigned its URNs. This is based on the Dynamic Delegation Discovery System (DDDS) [RFC3401], and especially on the straightforward URI-enabled NAPTR (U-NAPTR) [RFC4848] 👑.

The DDI Alliance is responsible for operating resolution servers, or for delegating resolution requests to the resolution servers of the relevant DDI agencies. DDI agencies are responsible for operating or delegating resolution servers for the agency-identifier under which they assigned URNs.

Here's the sequence, bestie 🦋:

Client  NS for    NS for           NS for        DDI services
        urn.arpa  ddialliance.org  example1.edu  for us.ddia1
  |       |            |               |              |
1 |------>|            |               |              |
2 |       |----------->|               |              |
3 |                    |-------------->|              |
4 |<-----------------------------------|              |
5 |-------------------------------------------------->|
6 |<--------------------------------------------------|

Figure 5: Sample Sequence Diagram for Receiving a List of DDI Services from the Example DDI agency "ddia1"

  1. The name server (NS) of IANA for the domain "urn.arpa." gets reached with the request "ddia1.us.ddi.urn.arpa." for the DDI agency "us.ddia1".
  2. The request gets delegated to the name server for "ddialliance.org".
  3. The request gets delegated to the name server for "example1.edu" (the domain of the DDI agency "us.ddia1").
  4. The server responds with a list of NAPTR records [RFC3403] pointing to available DDI services for the DDI agency "us.ddia1".
  5. The client picks an appropriate DDI service and sends a request for a DDI URN to it.
  6. The DDI service responds, for example, with a DDI object identified by the requested DDI URN.

See Appendix A for examples of name server records 📖.

3.7. Rules for Lexical Equivalence ⚖️

The DDI agency-identifier basically follows the rules of domain names, and domain names are case insensitive 🙃. So this part of the URN is case insensitive for matches:

urn:ddi:<agency-id>:

The remainder of the identifier MUST be considered case sensitive. Don't skip this one, bestie 🚨.

3.8. Conformance with URN Syntax 💅

The NSS conforms to the related section in [RFC8141]. It's built from the limited set of characters allowed for a URN NSS [RFC8141]. Percent-encoding is not used 🌸.

3.9. Validation Mechanism 🧪

The DDI Alliance will promote development of software for validation purposes 🎀.

3.10. Scope 🌍

The scope is global ✨.

4. Namespace Considerations 🌟

There's no available namespace that lets you uniquely identify and access DDI resources. 😭

4.1. URN Assignment Procedures 📬

See Section 3.5, "Process of Identifier Assignment".

4.2. URN Resolution/Delegation 🛰️

See Section 3.6, "Process for Identifier Resolution".

It is RECOMMENDED that sub-agencies for flexible administration be used. For example, delegating URNs of a sub-agency to different servers would be super easy 🫶.

4.3. Type of Resources To Be Identified 🧩

The DDI specifications define resources at a granular level, and lots of them can be identified by a DDI URN 💜.

4.4. Type of Services 🛎️

Here are some examples of potential services. The services and their service tags still need to be defined in the future. The service tags mentioned come from [RFC2483].

  • DDI repository
    • I2R (URI to Resource): given a DDI URN, return one instance of the resource identified by that URN.
  • DDI registry
    • I2C (URI to URC, Uniform Resource Characteristics are descriptions of resources): given a DDI URN, return a description or a summary of that resource.
  • DDI URN resolution
    • I2L (URI to URL): given a DDI URN, return one URL that identifies a location where the identified DDI resource can be found.
    • I2Ls (URI to URLs): given a DDI URN, return one or more URLs that identify multiple locations of the identified DDI resource.

5. Community Considerations 🤝

5.1. Open Assignment and Use of Identifiers 🗂️

DDI agency-identifiers can be registered at the DDI Alliance. The DDI Alliance keeps a registry of the assigned values for the DDI agency-identifier used in the NSS. For info, reach out to secretariat@ddialliance.org 💌.

DDI agencies assign URNs, and potential sub-agencies, within the scope of their assigned DDI agency-identifiers.

See also Section 3.3 on "Identifier Uniqueness Considerations".

5.2. Open Operation of Resolution Servers 🌐

The DDI Alliance runs publicly accessible name servers that delegate DNS requests within the domain ddi.urn.arpa to the DNS servers of DDI agencies 🦋.

5.3. Creation of Software for Service Discovery 🛠️

The DDI Alliance promotes software for service discovery, which finds the available services connected to DDI agencies using the Domain Name System (DNS). See also Section 3.6 on "Process for Identifier Resolution". A basic resolver library is available [DDI-RESO] ✨.

6. IANA Considerations 🏛️

IANA has updated the "ddi" entry in the "Formal URN Namespaces" registry to reference this specification 🎀.

The following NAPTR record for the key "ddi" has been registered in the urn.arpa zone:

ddi IN NAPTR 100 10 "" "" "" registry.ddialliance.org.

Requests for the domain ddi.urn.arpa are delegated to the name servers of the DDI Alliance. Iconic work, DDI Alliance 🌈👑

7. Security Considerations 🔐

Okay bestie, security time, and honestly it's a chill vibe 🫶 URN:DDI identifiers point at resources that are public information, so resolving them has a low security profile ✨

Who gets in? Registering DDI agencies is approved by the DDI Alliance 👑 Assigning and resolving URN:DDI identifiers is controlled by the DDI Alliance and the approved DDI agencies. The DDI Alliance SHALL have control mechanisms in place so that DDI Agency applications from malicious third parties will not be accepted 🚫 Also, URN:DDI resolvers will be protected against eavesdropping and attacks with appropriate tools 🛡️

This document adds no extra technical security considerations beyond the ones that come with using and resolving URNs in general. Nothing new here, just the usual URN drama 💅

The security of DNS-based resolution of DDI agency-identifiers is only as good as the security of DNS queries in general. That's a big deal 😭

A full discussion of the security threats for DNS, plus possible solutions, is in [RFC3833]. More on security for U-NAPTR is in [RFC4848], Section 6. "DNS Queries over HTTPS (DoH)" [RFC8484] could be used to boost security by stopping eavesdropping and manipulation of DNS data by machine-in-the-middle attacks. HTTPS encrypts the data between the DoH client and the DoH-based DNS resolver 🔒

8. References 📚

8.1. Normative References

8.2. Informative References

Appendix A. Example DNS Records 🧚

The examples use NAPTR [RFC3403] and SRV [RFC2782] [RFC3958] records. The values for the services and flags fields of the NAPTR records will be determined by the DDI application ([RFC3403], Section 9).

For a description of the packet format of NAPTR, see [RFC3403], Section 4.1. 🍓

A.1. Delegation of the URN Namespace "ddi"

The example records below are defined at a.iana-servers.net and other authoritative name servers for the domain urn.arpa.

The empty flag means the lookup is not terminal, so the next probe to DNS is for more NAPTR records where the new domain is "dns.ddialliance.org". Iconic ✨

; Delegation to name servers of ddialliance.org
;           order pref  flag  service  regexp replacement
ddi.urn.arpa.
   IN NAPTR 100   10    ""    ""       ""     dns.ddialliance.org.

A.2. Delegation of DDI Agencies

The example records below are defined at dns.ddialliance.org for ddi.urn.arpa.

The empty flag means the lookup is not terminal, so the next probe to DNS is for more NAPTR records where the new domain is the DNS server of the relevant DDI agency. Main character energy 💖

; Delegation to name servers of subdomains in ddi.urn.arpa, i.e.
; DDI agencies.
;           order pref  flag  service  regexp replacement
ddia1.us.ddi.urn.arpa.
   IN NAPTR 100   10    ""    ""       ""     dns.example1.edu.
ddia2.de.ddi.urn.arpa.
   IN NAPTR 100   10    ""    ""       ""     dns.example2.org.
ddia3.gb.ddi.urn.arpa.
   IN NAPTR 100   10    ""    ""       ""     dns.example3.ac.uk.

A.3. DDI Services 🧚

Okay, bestie, here are the example records, and they're all defined at dns.example2.org for ddi.urn.arpa 🌸

The "u" flag says the rule is terminal and the output is a URI that has the info you need to contact that DDI service 🦋 The "s" flag also says the rule is terminal, but the output of the rewrite is a domain name, and you SHOULD query an SRV record for it 💅 See also [RFC4848], Section 4.4.

The I2R service returns one instance of the resource identified by the given URN. It's a repository of DDI resources at http://repos.example2.org/I2R/, and it's possibly a REST-based service 📚 The I2C service returns a description of the resource identified by the URN. It's a registry of DDI resources at registry-udp.example2.org, port 10060 💜

U-NAPTR allows regular expressions that completely replace the matched string with a URI, written as a constant string. Because this is a limited form of regex ([RFC4848], Section 2.2), applications using NAPTR don't need full regular expression parsers. Lowkey genius 🧠✨

ddia2.de.ddi.urn.arpa.
;         order pref flag
  IN NAPTR 100  10  "u"  "I2R+http"                   ( ; service
                      "!.*!http://repos.example2.org/I2R/!"; regex
                         .                           ; replacement
                                                      )
  IN NAPTR 100  10  "s"  "I2C+udp"                    ( ; service
                         ""                             ; regex
                         registry._udp.example2.org. ; replacement
                                                      )
; all subdomains in ddia2.de.ddi.urn.arpa.
*.ddia2.de.ddi.urn.arpa.
ddia2.de.ddi.urn.arpa.
;         order pref flag
  IN NAPTR 100  10  "u"  "I2R+http"                   ( ; service
                      "!.*!http://repos.example2.org/I2R/!"; regex
                         .                           ; replacement
                                                      )
  IN NAPTR 100  10  "s"  "I2C+udp"                    ( ; service
                         ""                             ; regex
                         registry._udp.example2.org.; replacement
                                                      )
;_service._protocol.name
; TTL    class  SRV  priority weight port  targetreplac
_registry._udp.example2.org
  14400  IN     SRV  0        0   10060 registry-udp.example2.org.

Appendix B. Algorithm for DDI Service Discovery 🔍

Okay, so this whole thing is based on the Dynamic Delegation Discovery System (DDDS) algorithm [RFC3402] 🎀

The application picks the right service from the output described below, then contacts that service for the given URN 💖

The process can be sped up with an application cache for the NAPTR records of DDI agencies that have already been requested 🚀

B.1. Application Unique String 🍓

The Application Unique String is a DDI URN ✨

B.2. First Well Known Rule 👑

  1. Extract the characters between the second and third colon (the agency-identifier).
  2. Normalize the case of that string.
  3. Reverse the order of the substrings separated by dots.
  4. Append the string ".ddi.urn.arpa" to the end to get a domain name.

B.3. Valid Databases 🌈

The DNS is specified as a DDDS Database for this application. It uses NAPTR DNS resource records to hold the rewrite rules for service discovery 🫶

The DNS gets queried for NAPTR records for the domain name that comes out of the First Well Known Rule 💅

B.4. Expected Output 🦋

The expected output is the info needed to connect to one or more authoritative servers (host, port, protocol, or URL) for an application service within a given DDI agency. The result is a list of terminal NAPTR records that point to the services available for that DDI agency. Main character energy 👑🌸

Acknowledgments 🫶

Many thanks to Arofan Gregory, Dan Smith, and Wendy Thomas from the DDI Alliance Technical Committee, and to Peter Koch from DENIC (German Network Information Center), for the discussion and input that led to this document 💜

The following software tools were super helpful for checking the ABNF grammar and the regular expressions: an ABNF parser [ABNFPFE], a tool that creates regular expressions from an ABNF grammar [ABNF2RS], and a tool that generates random strings matching an ABNF grammar [ABNFGEN] 🧚✨

Author's Address 🎀

Joachim Wackerow
c/o The Data Documentation Initiative Alliance (DDI Alliance)
ICPSR, University of Michigan
PO Box 1248
Ann Arbor, MI 48106-1248
United States of America
Email: joachim.wackerow@posteo.de, secretariat@ddialliance.org
URI:   ddialliance.org
📦 where this page comes from