path: root/doc/rfc/rfc9517.txt

Independent Submission                                       J. Wackerow
Request for Comments: 9517                                  DDI Alliance
Category: Informational                                     January 2024
ISSN: 2070-1721


      A URN Namespace for the Data Documentation Initiative (DDI)

Abstract

   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
   https://www.rfc-editor.org/info/rfc9517.

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

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 document registers a formal Namespace Identifier (NID) for URNs
   associated with DDI resources in accordance with the process defined
   in [RFC8141].

   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 [DDI-C] and DDI Lifecycle [DDI-L] are
   expressed in XML Schema; DDI Extended Knowledge Organization System
   (XKOS) [DDI-XKOS] in OWL/RDF; Structured Data Transformation Language
   (SDTL) [DDI-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 [DUBLINC]; Statistical
   Data and Metadata Exchange [SDMX] for exchanging aggregate data; ISO/
   IEC 11179 [IS11179] for building metadata registries, such as
   question, variable, and concept banks; and ISO 19115 [ISO.19115.2003]
   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
   [DDI-ALL].  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.

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.

   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 [RFC2119] 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.

3.  Specification

   This section provides the information required to register a formal
   namespace according to 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 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) [DDI-ID].  This structure is according to the
   International Registration Data Identifier (IRDI) defined in
   "Information technology - Metadata registries (MDR) - Part 6:
   Registration", Annex A [IS11179].

   A description of the DDI resource identification is available in the
   Identification section of the "DDI Lifecycle 3.3 Technical Guide"
   [DDI-ID].

   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 [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.  Assignment of
   identifiers for DDI agencies in the requested namespace is managed by
   the DDI Alliance (see Section 3.5 on "Process of Identifier
   Assignment").  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 ([RFC1035], Section 2.3.1).  The length of the
   label and the full name are restricted by DNS rules ([RFC2181],
   Section 11).  The agency identifier is case insensitive ([RFC4343],
   Section 2).

   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.

3.1.2.  ABNF Grammar

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

   ; 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

   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-._~!$&'()*+,;=@]+

3.1.4.  Examples of DDI URNs

   The examples are taken from the DDI Lifecycle 3.3 documentation
   [DDI-ID].  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:ddi:us.ddia1:R-V1:1

                  Figure 2: URN of a Represented Variable

   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

   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

   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

   An introductory article on DDI can be found at [DDI-INTR].

   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 [DDI-ALL].

   Information on domain names can be found in the relevant RFCs.

   *  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

   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.

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

3.5.  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 [DDI-REGI].

   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.

3.6.  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) [RFC3401] and especially the
   straightforward URI-enabled NAPTR (U-NAPTR) [RFC4848].

   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.

   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." 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 [RFC3403]
       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 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.  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.

3.8.  Conformance with URN Syntax

   The NSS conforms to the related section in [RFC8141].  It is composed
   from the limited set of characters 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 is no available namespace that will allow one to 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, delegation of URNs of a sub-agency to different
   servers would be easily possible.

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

4.4.  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 [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 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 Section 3.3 on "Identifier Uniqueness Considerations".

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

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

7.  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 [RFC3833].  Further information on security
   considerations regarding U-NAPTR can be found in [RFC4848],
   Section 6.  "DNS Queries over HTTPS (DoH)" [RFC8484] 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.

8.  References

8.1.  Normative References

   [DDI-C]    DDI Alliance, "DDI-Codebook 2.5", 2014,
              <https://ddialliance.org/Specification/DDI-Codebook/2.5/>.

   [DDI-ID]   DDI Alliance, "Identification", DDI Lifecycle (3.3)
              Technical Guide: General Structures, <https://ddi-
              lifecycle-technical-
              guide.readthedocs.io/en/latest/General%20Structures/
              Identification.html>.

   [DDI-L]    DDI Alliance, "DDI-Lifecycle",
              <https://ddialliance.org/Specification/DDI-Lifecycle/>.

   [DDI-SDTL] DDI Alliance, "SDTL - Structured Data Transformation
              Language - Version 1.0", December 2020,
              <https://ddialliance.org/products/sdtl/1.0/>.

   [DDI-XKOS] DDI Alliance, "XKOS - Extended Knowledge Organization
              System", <https://ddialliance.org/Specification/RDF/XKOS>.

   [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
              host table specification", RFC 952, DOI 10.17487/RFC0952,
              October 1985, <https://www.rfc-editor.org/info/rfc952>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,
              <https://www.rfc-editor.org/info/rfc1123>.

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

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <https://www.rfc-editor.org/info/rfc2181>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4343]  Eastlake 3rd, D., "Domain Name System (DNS) Case
              Insensitivity Clarification", RFC 4343,
              DOI 10.17487/RFC4343, January 2006,
              <https://www.rfc-editor.org/info/rfc4343>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <https://www.rfc-editor.org/info/rfc8141>.

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

   [TLD]      IANA, "Root Zone Database",
              <https://www.iana.org/domains/root/db>.

8.2.  Informative References

   [ABNF2RS]  "ABNF to REGEX: Regular Expression Generator", October
              2019, <https://www.msweet.org/abnf/>.

   [ABNFGEN]  Degener, J., "abnfgen", <http://www.quut.com/abnfgen/>.

   [ABNFPFE]  IETF, "IETF Author Tools - ABNF Tools",
              <https://author-tools.ietf.org/abnf>.

   [DDI-ALL]  DDI Alliance, "Document, Discover and Interoperate",
              <https://ddialliance.org/>.

   [DDI-CVAG] DDI Alliance, "DDI Controlled Vocabulary for Aggregation
              Method", <https://ddialliance.org/Specification/DDI-CV/
              AggregationMethod_1.0.html>.

   [DDI-EXQU] DDI Alliance, "Questions", DDI Lifecycle 3.3 Technical
              Guide: Examples, <https://ddi-lifecycle-technical-
              guide.readthedocs.io/en/latest/Examples/Questions.html>.

   [DDI-EXRV] DDI Alliance, "Represented Variable", DDI Lifecycle 3.3
              Technical Guide: Examples, <https://ddi-lifecycle-
              technical-guide.readthedocs.io/en/latest/Examples/
              RepresentedVariable.html>.

   [DDI-INTR] Vardigan, M., Heus, P., and W. Thomas, "Data Documentation
              Initiative: Toward a Standard for the Social Sciences",
              The International Journal of Digital Curation, Issue 1,
              Volume 3, DOI 10.2218/ijdc.v3i1.45, December 2008,
              <http://www.ijdc.net/article/view/66>.

   [DDI-REGI] DDI Alliance, "Welcome to the DDI Registry",
              <https://registry.ddialliance.org/>.

   [DDI-RESO] DDI Alliance, "Tools",
              <https://registry.ddialliance.org/Home/Tools>.

   [DUBLINC]  Dublin Core Metadata Initiative, "Dublin Core",
              <https://www.dublincore.org/>.

   [IS11179]  ISO, "Information technology - Metadata registries (MDR) -
              Part 6: Registration", ISO/IEC 11179-6:2023, January 2023,
              <https://www.iso.org/standard/78916.html>.

   [ISO.19115.2003]
              ISO, "Geographic information - Metadata", ISO 19115:2003,
              <https://www.iso.org/standard/26020.html>.

   [ISO3166]  ISO, "ISO 3166 Country Codes",
              <https://www.iso.org/iso-3166-country-codes.html>.

   [RFC2483]  Mealling, M. and R. Daniel, "URI Resolution Services
              Necessary for URN Resolution", RFC 2483,
              DOI 10.17487/RFC2483, January 1999,
              <https://www.rfc-editor.org/info/rfc2483>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/info/rfc2782>.

   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part One: The Comprehensive DDDS", RFC 3401,
              DOI 10.17487/RFC3401, October 2002,
              <https://www.rfc-editor.org/info/rfc3401>.

   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Two: The Algorithm", RFC 3402, DOI 10.17487/RFC3402,
              October 2002, <https://www.rfc-editor.org/info/rfc3402>.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, DOI 10.17487/RFC3403, October 2002,
              <https://www.rfc-editor.org/info/rfc3403>.

   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
              Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
              2004, <https://www.rfc-editor.org/info/rfc3833>.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958,
              January 2005, <https://www.rfc-editor.org/info/rfc3958>.

   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
              Using URIs and the Dynamic Delegation Discovery Service
              (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007,
              <https://www.rfc-editor.org/info/rfc4848>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [SDMX]     Statistical Data and Metadata eXchange, "SDMX",
              <https://sdmx.org/>.

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"

   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.

A.2.  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.

A.3.  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 [RFC4848], Section 4.4.

   The service I2R returns one instance of the resource identified by
   the given URN.  That service is a repository of DDI resources
   available at http://repos.example2.org/I2R/; 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 ([RFC4848],
   Section 2.2), 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.

Appendix B.  Algorithm for DDI Service Discovery

   The description is based on the Dynamic Delegation Discovery System
   (DDDS) algorithm [RFC3402].

   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.

B.1.  Application Unique String

   The Application Unique String is a DDI URN.

B.2.  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.

B.3.  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.

B.4.  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 Arofan Gregory, Dan Smith, and Wendy Thomas from the
   DDI Alliance Technical Committee and Peter Koch 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 [ABNFPFE], a tool
   that creates regular expressions from an ABNF grammar [ABNF2RS], and
   a tool that generates random strings that match 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