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 joachim.wackerow@posteo.de secretariat@ddialliance.org ddialliance.org

URN resolution This document describes the Namespace Identifier (NID) "ddi" for Uniform Resource Names (URNs) used to identify resources that conform to the standards published by the Data Documentation Initiative (DDI) Alliance. The DDI Alliance is not affiliated with the Internet Engineering Task Force (IETF) or Internet Society (ISOC). This Independent Submission is not a standard nor does it have IETF community consensus.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice 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 () 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.

Table of Contents

• .  Introduction
• .  Conventions Used in This Document
• .  Specification
  • .  Declaration of Syntactic Structure
    • .  Description
    • .  ABNF Grammar
    • .  Regular Expression
    • .  Examples of DDI URNs
  • .  Relevant Ancillary Documentation
  • .  Identifier Uniqueness Considerations
  • .  Identifier Persistence Considerations
  • .  Process of Identifier Assignment
  • .  Process for Identifier Resolution
  • .  Rules for Lexical Equivalence
  • .  Conformance with URN Syntax
  • .  Validation Mechanism
  • . Scope
• .  Namespace Considerations
  • .  URN Assignment Procedures
  • .  URN Resolution/Delegation
  • .  Type of Resources To Be Identified
  • .  Type of Services
• .  Community Considerations
  • .  Open Assignment and Use of Identifiers
  • .  Open Operation of Resolution Servers
  • .  Creation of Software for Service Discovery
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Example DNS Records
  • .  Delegation of the URN Namespace "ddi"
  • .  Delegation of DDI Agencies
  • .  DDI Services
• .  Algorithm for DDI Service Discovery
  • .  Application Unique String
  • .  First Well Known Rule
  • .  Valid Databases
  • .  Expected Output
• Acknowledgments
• Author's Address

Introduction This document registers a formal Namespace Identifier (NID) for URNs associated with DDI resources in accordance with the process defined in . The DDI Alliance is an international collaboration dedicated to establishing metadata standards and semantic products for describing social science data, data covering human activity, and other data based on observational methods. DDI specifications are free standards that document and manage different stages in the research data lifecycle, such as conceptualization, collection, processing, distribution, discovery, and archiving. Documenting data with DDI facilitates understanding, interpretation, and use -- by people, software systems, and computer networks. The specifications DDI Codebook and DDI Lifecycle are expressed in XML Schema; DDI Extended Knowledge Organization System (XKOS) in OWL/RDF; Structured Data Transformation Language (SDTL) in JSON Schema; and the upcoming DDI Cross Domain Integration (DDI-CDI) in UML. DDI is aligned with other metadata standards like Dublin Core Metadata Initiative ; Statistical Data and Metadata Exchange for exchanging aggregate data; ISO/IEC 11179 for building metadata registries, such as question, variable, and concept banks; and ISO 19115 for supporting geographic information systems. DDI URNs support reusability of DDI resources inside a single DDI instance and in a distributed network of DDI instances. The DDI specification is developed and maintained by the DDI Alliance . The DDI Alliance is a self-sustaining membership organization whose over 40-member institutions have a voice in the development of the DDI specifications. This memo describing the ddi URN is an informational specification. It is not a standard and is not the product of the IETF.

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 when, and only when, they appear in all capitals, as shown here. In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying significance.

DDI:

Data Documentation Initiative. The single term is often used as a synonym for the DDI specification.

DDI agency:

An organization that maintains DDI resources.

Specification This section provides the information required to register a formal namespace according to the registration procedure defined in . The URNs conform to the syntax defined in .

Declaration of Syntactic Structure

Description The Namespace Specific String (NSS) of all URNs using the "ddi" NID is a globally unique identifier consisting of the DDI agency-identifier (registration authority identifier), the identifier of the DDI resource (data identifier), and the version of the resource (version-identifier) . This structure is according to the International Registration Data Identifier (IRDI) defined in "Information technology - Metadata registries (MDR) - Part 6: Registration", Annex A . A description of the DDI resource identification is available in the Identification section of the "DDI Lifecycle 3.3 Technical Guide" . The DDI NSS has the following structure: <agency-identifier>:<resource-identifier>:<version-identifier> agency-identifier is the identifier of a DDI agency that maintains DDI resources. This identifier basically follows the rules of reversed domain names and is case insensitive. This way, the DNS resolution of DDI agency-identifiers is supported. The hierarchy of domains descends from the left to the right label in the name; each label to the right specifies a subdivision, or subdomain, of the domain to the left. The left-most label of agency-identifier conveys the top-level domain. It SHALL be a country code corresponding to ISO 3166 alpa-2 codes or another top-level domain maintained by IANA . All two-letter top-level domains are reserved for current and future ISO 3166 codes. Assignment of identifiers for DDI agencies in the requested namespace is managed by the DDI Alliance (see on ""). The next subdomain identifies the agency within that top-level domain. Further optional subdomains can follow. The top-level domain and possible subdomains are separated by the full stop character. The full stop character is not allowed within top-level domain names or subdomain names. The top-level domain and subdomains are composed from the limited set of characters for the preferred form of a DNS label (). The length of the label and the full name are restricted by DNS rules (). The agency identifier is case insensitive (). resource-identifier is the identifier of a DDI resource of a DDI agency. The value MUST be unique in the scope of this DDI agency. The resource-identifier is case sensitive. version-identifier is the version of a DDI resource of a DDI agency. The value MUST be unique in the scope of this resource. The resource version is case sensitive.

ABNF Grammar The following syntax specification for the complete URN uses the Augmented Backus-Naur form (ABNF) as described in .

ABNF Grammar ; 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

Regular Expression The used syntax is the XML Schema flavor, which can be easily used in other flavors. These regular expressions implicitly anchor at the head and tail. The following regular expression syntax uses components (component names indicated by angle brackets, i.e. <component>) and is written in free-spacing mode for easier reading (the XML Schema flavor does not support that). Please note that use of multiple quantifiers in regular expressions can result in false outcomes due to so-called greediness. Therefore, there are separate regular expressions for the length restriction and other purposes 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-._~!$&'()*+,;=@]+

Examples of DDI URNs The examples are taken from the DDI Lifecycle 3.3 documentation . Please note that the resource-identifiers are simplified. In real applications, they are much longer for unique identification purposes. They don't relate to DDI types like the examples might suggest.

URN of a Represented Variable urn:ddi:us.ddia1:R-V1:1

The DDI represented variable identified by "R-V1" with the version "1" of the DDI agency "ddia1" located in the domain "us" .

URN of a Question Item urn:ddi:us.ddia1:PISA-QS.QI-2:1

The DDI question item identified by "PISA-QS.QI-2" with the version "1" of the DDI agency "ddia1" located in the domain "us" .

URN as Reference to a Controlled Vocabulary urn:ddi:int.ddi.cv:AggregationMethod:1.0

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" .

Relevant Ancillary Documentation An introductory article on DDI can be found at . Information on the DDI specifications (DDI-C, DDI-L, XKOS, Controlled Vocabularies, and SDTL) can be found in the standards section of the DDI Alliance website . Information on domain names can be found in the relevant RFCs.

• For an overview, see .
• Regarding case insensitivity, see .
• Regarding syntax, see the "Lexical grammar" in the "Grammatical Host Table Specification" section of and .
• Regarding size limits, see and .

Identifier Uniqueness Considerations Assignment of identifiers for DDI agencies in the requested namespace will be managed by the DDI Alliance, which will ensure that the assigned DDI agency-identifiers are consistent with the directives for unique identification of DDI agencies. Assignment of URNs for resources of a DDI agency in the requested namespace will be managed by the respective DDI agency, which ensures that the assigned URNs are unique for the scope of the agency.

Identifier Persistence Considerations Persistence of identifiers is dependent upon the suitable delegation of resolution at the level of the DDI agencies and the persistence of DDI agency assignment. The persistence of the referenced resource is also the responsibility of the DDI agency.

Process of Identifier Assignment Assignment of identifiers for DDI agencies in the requested namespace is managed by the DDI Alliance. A registry for DDI agency identifiers ensures through an approval process that the syntax of agency-identifiers complies with the associated rules . Assignment of URNs for resources of a DDI agency and sub-agencies of a DDI agency in the requested namespace will be managed by the respective DDI agency.

Process for Identifier Resolution The DDI Alliance promotes a service discovery system for identifying 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 is delegated by the DNS servers of the DDI Alliance 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 has assigned URNs. The approach is based on the Dynamic Delegation Discovery System (DDDS) and especially the straightforward URI-enabled NAPTR (U-NAPTR) . The DDI Alliance is responsible for operating or 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 have assigned URNs.

Sample Sequence Diagram for Receiving a List of DDI Services from the Example DDI agency "ddia1" Client NS for NS for NS for DDI services urn.arpa ddialliance.org example1.edu for us.ddia1 | | | | | 1 |------>| | | | 2 | |----------->| | | 3 | |-------------->| | 4 |<-----------------------------------| | 5 |-------------------------------------------------->| 6 |<--------------------------------------------------|

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

See for examples of name server records.

Rules for Lexical Equivalence The DDI agency-identifier basically follows the rules of domain names. Domain names are case insensitive. Thus, the following portion of the URN is case insensitive for matches: urn:ddi:<agency-id>: The remainder of the identifier MUST be considered case sensitive.

Conformance with URN Syntax The NSS conforms to the related section in . It is composed from the limited set of characters for a URN NSS . Percent-encoding is not used.

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

Scope The scope is global.

Namespace Considerations There is no available namespace that will allow one to uniquely identify and access DDI resources.

URN Assignment Procedures See , "".

URN Resolution/Delegation See , "". It is RECOMMENDED that sub-agencies for flexible administration be used. For example, delegation of URNs of a sub-agency to different servers would be easily possible.

Type of Resources To Be Identified The DDI specifications define resources at a granular level, many of which can be identified by a DDI URN.

Type of Services Examples of potential services are listed below. The services and appropriate service tags need to be defined in the future. The mentioned service tags are from .

• 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.

Community Considerations

Open Assignment and Use of Identifiers DDI agency-identifiers can be registered at the DDI Alliance. The DDI Alliance maintains a registry of the assigned values for the DDI agency-identifier used in the NSS. Information may be obtained from the following address: secretariat@ddialliance.org. DDI agencies assign URNs and potential sub-agencies within the scope of the assigned DDI agency-identifiers. See also on "".

Open Operation of Resolution Servers The DDI Alliance operates publicly accessible name servers for the delegation of DNS requests within the domain ddi.urn.arpa to DNS servers of DDI agencies.

Creation of Software for Service Discovery The DDI Alliance promotes software for service discovery for identifying available services connected to DDI agencies using the Domain Name System (DNS). See also on "". A basic resolver library is available .

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.

Security Considerations URN:DDI identifiers are assigned to resources that are public information; therefore, resolving these identifiers has low security profile. Registration of DDI agencies is approved by the DDI Alliance. Assignment and resolution of URN:DDI identifiers are controlled by the DDI Alliance and approved DDI agencies. The DDI Alliance SHALL have in place control mechanisms in order to make sure that DDI Agency applications from malicious third parties will not be accepted. URN:DDI resolvers will be protected against eavesdropping and attacks with appropriate tools. This document introduces no additional technical security considerations beyond those associated with the use and resolution of URNs in general. The security of the DNS-based resolution of DDI agency-identifiers is only as good as the security of DNS queries in general. A full discussion of the security threats pertaining to DNS and possible solutions can be found in . Further information on security considerations regarding U-NAPTR can be found in . "DNS Queries over HTTPS (DoH)" could be used to increase security by preventing eavesdropping and manipulation of DNS data by machine-in-the-middle attacks. The HTTPS protocol encrypts the data between the DoH client and the DoH-based DNS resolver.

References Normative References DDI Alliance DDI Alliance DDI Lifecycle (3.3) Technical Guide: General Structures DDI Alliance DDI Alliance DDI Alliance This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date. This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IANA Informative References IETF DDI Alliance DDI Alliance DDI Alliance DDI Lifecycle 3.3 Technical Guide: Examples DDI Alliance DDI Lifecycle 3.3 Technical Guide: Examples The International Journal of Digital Curation, Issue 1, Volume 3 DDI Alliance DDI Alliance Dublin Core Metadata Initiative ISO ISO ISO Retrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. This memo defines an Experimental Protocol for the Internet community. This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community. This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK] This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK] Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community. This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK] The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK] This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. Statistical Data and Metadata eXchange

Example DNS Records The examples use NAPTR and SRV records. The values for the services and flags fields of the NAPTR records will be determined by the DDI application (). For a description of the packet format of NAPTR, see .

Delegation of the URN Namespace "ddi" Example records below are defined at a.iana-servers.net and other authoritative name servers for the domain urn.arpa. The empty flag indicates that the lookup is not terminal and the next probe to DNS is for more NAPTR records where the new domain is "dns.ddialliance.org". ; Delegation to name servers of ddialliance.org ; order pref flag service regexp replacement ddi.urn.arpa. IN NAPTR 100 10 "" "" "" dns.ddialliance.org.

Delegation of DDI Agencies Example records below are defined at dns.ddialliance.org for ddi.urn.arpa. The empty flag indicates that the lookup is not terminal and the next probe to DNS is for more NAPTR records where the new domain is the DNS server of the relevant DDI agency. ; 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.

DDI Services Example records below are defined at dns.example2.org for ddi.urn.arpa. The "u" flag states that the rule is terminal and that the output is a URI that contains the information needed to contact that DDI service. The "s" flag states that the rule is terminal and that the output of the rewrite will be a domain name for which an SRV record SHOULD be queried. See also . The service I2R returns one instance of the resource identified by the given URN. That service is a repository of DDI resources available at ; possibly a REST-based service. The service I2C returns a description of the resource identified by the given URN. That service is a registry of DDI resources available at registry-udp.example2.org port 10060. U-NAPTR permits regular expressions of a form that does a complete replacement of the matched string with a URI, expressed as a constant string. With this limited form of regular expression (), applications using NAPTR need not implement full regular expression parsers. 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.

Algorithm for DDI Service Discovery The description is based on the Dynamic Delegation Discovery System (DDDS) algorithm . The application selects the appropriate service from the output described below and contacts the service for the given URN. The process can be optimized by an application cache for the NAPTR records of already requested DDI agencies.

Application Unique String The Application Unique String is a DDI URN.

First Well Known Rule

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

Valid Databases The DNS is specified as a DDDS Database for this application, which uses the NAPTR DNS resource records to contain the rewrite rules for service discovery. The DNS is queried for NAPTR records for the domain name, which is the output of the First Well Known Rule.

Expected Output The expected output is the information necessary 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 pointing to services available for the relevant DDI agency.

Acknowledgments Many thanks to , , and from the DDI Alliance Technical Committee and from DENIC (German Network Information Center) for the discussion and input that led to this document. The following software tools have been helpful in evaluating the ABNF grammar and the regular expressions: an ABNF parser , a tool that creates regular expressions from an ABNF grammar , and a tool that generates random strings that match an ABNF grammar .

Author's Address 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 joachim.wackerow@posteo.de secretariat@ddialliance.org ddialliance.org