doc: Add RFC documents

1 files changed, 907 insertions, 0 deletions

diff --git a/doc/rfc/rfc9517.txt b/doc/rfc/rfc9517.txt
new file mode 100644
index 0000000..84bb72b
--- /dev/null
+++ b/doc/rfc/rfc9517.txt
@@ -0,0 +1,907 @@
+
+
+
+
+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