Network Working Group Joachim
Independent Submission J. Wackerow
Internet Draft
Request for Comments: 9517 DDI Alliance
Intended status:
Category: Informational August 13, 2023
Expires: February January 2024
ISSN: 2070-1721
A Uniform Resource Name (URN) URN Namespace for the Data Documentation Initiative (DDI)
draft-urn-ddi-06.txt
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 (https://ddialliance.org/).
Alliance.
The DDI Alliance is not affiliated with the Internet Engineering Task
Force (IETF) or Internet Society (ISOC); and as an
independent submission, it does (ISOC). This Independent Submission
is not a standard nor does it have IETF community consensus.
Status of this This Memo
This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the not an Internet Engineering Task Force (IETF). Note that
other groups may also distribute working documents as Internet-
Drafts. The list of current Internet-Drafts Standards Track specification; it is at
http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid
published for informational purposes.
This is a maximum contribution to the RFC Series, independently of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
This
RFC stream. The RFC Editor has chosen to publish this document is published at
its discretion and makes no statement about its value for informational purposes. It is an
independent submission. It is
implementation or deployment. Documents approved for publication by
the RFC Editor are not an candidates for any level of Internet Standard and does
not have rough consensus Standard;
see Section 2 of RFC 7841.
Information about the IETF community.
This Internet-Draft will expire in February 2024. 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) 2023 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
(http://trustee.ietf.org/license-info)
(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.
Code Components extracted from this document must include
Simplified BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3 Introduction
2. Conventions used Used in this document..............................4 This Document
3. Specification..................................................5 Specification
3.1. Declaration of Syntactic Structure...........................5 Structure
3.1.1. Description................................................5 Description
3.1.2. ABNF Grammar...............................................6 Grammar
3.1.3. Regular Expression.........................................8 Expression
3.1.4. Examples of DDI URNs.......................................9 URNs
3.2. Relevant Ancillary Documentation.............................9 Documentation
3.3. Identifier Uniqueness Considerations........................10 Considerations
3.4. Identifier Persistence Considerations.......................10 Considerations
3.5. Process of Identifier Assignment............................10 Assignment
3.6. Process for Identifier Resolution...........................10 Resolution
3.7. Rules for Lexical Equivalence...............................11 Equivalence
3.8. Conformance with URN Syntax.................................12 Syntax
3.9. Validation Mechanism........................................12 Mechanism
3.10. Scope......................................................12 Scope
4. Namespace Considerations......................................12 Considerations
4.1. URN Assignment Procedures...................................12 Procedures
4.2. URN Resolution/Delegation...................................12 Resolution/Delegation
4.3. Type of Resources to be Identified..........................12 To Be Identified
4.4. Type of Services............................................12 Services
5. Community Considerations......................................13 Considerations
5.1. Open Assignment and Use of Identifiers......................13 Identifiers
5.2. Open Operation of Resolution Servers........................13 Servers
5.3. Creation of Software for Service Discovery..................13 Discovery
6. IANA Considerations...........................................14 Considerations
7. Security Considerations.......................................14 Considerations
8. References....................................................14 References
8.1. Normative References........................................14 References
8.2. Informative References......................................16
9. Acknowledgments...............................................19 References
Appendix A. Example DNS Records..................................20 Records
A.1. Delegation of the URN Namespace "ddi".......................20 "ddi"
A.2. Delegation of DDI Agencies..................................20 Agencies
A.3. DDI Services................................................20 Services
Appendix B. Algorithm for DDI Service Discovery..................22 Discovery
B.1. Application Unique String...................................22 String
B.2. First Well Known Rule.......................................22 Rule
B.3. Valid Databases.............................................22 Databases
B.4. Expected Output.............................................22 Output
Acknowledgments
Author's Address
1. Introduction
This document registers a formal namespace identifier Namespace Identifier (NID) for
Uniform Resource Names [RFC8141] 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 can 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 [DDIC] [DDI-C] and DDI Lifecycle [DDIL] [DDI-L] are
expressed in XML Schema, Schema; DDI XKOS - Extended Knowledge Organization System [DDIXKOS]
(XKOS) [DDI-XKOS] in OWL/RDF, SDTL - OWL/RDF; Structured Data Transformation Language [SDTL]
(SDTL) [DDI-SDTL] in JSON Schema, 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], [DUBLINC]; Statistical
Data and Metadata Exchange [SDMX] for exchanging aggregate data, ISO/IEC data; ISO/
IEC 11179 [IS11179] for building metadata registries registries, such as
question, variable, and concept banks, banks; and ISO 19115 [IS19115] [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 [DDIALL].
[DDI-ALL]. The DDI Alliance is a self-sustaining membership
organization whose over 40 member 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 Used in this document 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. Lower case Lowercase uses of these words are not to be
interpreted as carrying RFC 2119 [RFC2119] significance.
"DDI":
DDI: Data Documentation Initiative. The single term is often used
as a synonym for the DDI specification.
"DDI agency":
DDI agency: An organization which that maintains DDI resources.
"DDI Alliance": Alliance for the Data Documentation Initiative
(DDI).
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 agency-
identifier (registration authority identifier), the identifier of the
DDI resource (data identifier), and the version of the resource (version identifier) [DDIID].
(version-identifier) [DDI-ID]. This structure is according to the
International Registration Data Identifier (IRDI) defined in ISO/IEC 11179 Information
"Information technology - Metadata registries (MDR) - Part 6: Registration,
Registration", Annex A [IS11179].
A description of the DDI resource identification is available in the DDI
Identification section of the "DDI Lifecycle (3.3) 3.3 Technical Guide, section Identification
[DDIID]. 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. case insensitive. This way, the DNS
resolution of DDI agency identifiers 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 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 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.8. 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 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 ([RFC1035], Section 2.3.1). The length of the
label and the full name are restricted by DNS rules ([RFC2181] section ([RFC2181],
Section 11). The agency identifier is case insensitive ([RFC4343] section ([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 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
Augmented Backus-Naur Form form (ABNF) as described in [RFC5234].
ABNF Grammar
; Rules are case-sensitive, case sensitive, if not stated otherwise.
ddi-urn = urn separator ddi separator ddi-irdi
; urn is case-insensitive, case insensitive, see [RFC8141].
urn = "urn"
; ddi is the URN namespace identifier.
; ddi is case-insensitive, case insensitive, see [RFC8141] section [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 case insensitive, see [RFC4343], Section 2.
; For allowed characters characters, see [RFC1035] section [RFC1035], Section 2.3.1.
; For length restrictions restrictions, see [RFC2181] section [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 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 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]
; [RFC3986], Section 2.2.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" /
"*" / "+" / "," / ";" / "="
separator = ":"
sub-separator = "."
; ALPHA and DIGIT are actually defined in the ABNF
specification.
; 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 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. 3.3 documentation
[DDI-ID]. Please note that the resource identifiers 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
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"
[DDIEXRV]. [DDI-EXRV].
urn:ddi:us.ddia1:PISA-QS.QI-2:1
Figure 3: 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"
[DDIEXQU]. [DDI-EXQU].
urn:ddi:int.ddi.cv:AggregationMethod:1.0
Figure 4: 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" [DDICVAG]. [DDI-CVAG].
3.2. Relevant Ancillary Documentation
An introductory article on DDI can be found at [DDIINTR]. [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 [DDIALL]. [DDI-ALL].
Information on domain names can be found in the relevant RFCs.
o
* For an overview, see [RFC1034].
o
* Regarding case insensitivity, see [RFC1035] section 2.3.3.
o Section 2.3.3 of [RFC1035].
* Regarding syntax, see [RFC952] section the "Lexical grammar" in the "Grammatical
Host Table Specification" B. and [RFC1123] section 2.1.
o of [RFC0952] and Section 2.1 of
[RFC1123].
* Regarding size limits, see [RFC1123] section Section 2.1 of [RFC1123] and [RFC1035]
section 2.3.4.
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 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, 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
namespaceis namespace
is managed by the DDI Alliance. A registry for DDI agency
identifiers ensures through an approval process that the syntax of
agency identifiers
agency-identifiers complies with the associated rules [DDIREGI]. [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 will promote 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) (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 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 |<--------------------------------------| |
7 |------------------------------------------------------>|
8 |<------------------------------------------------------| |<--------------------------------------------------|
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./3.
2. The request is delegated to the name server for
"ddialliance.org".
4./5.
3. The request is delegated to the name server for "example1.edu"
(domain of the DDI agency "us.ddia1").
6.
4. The server responds with a list of NAPTR records [RFC3403]
pointing to available DDI services for the DDI agency "us.ddia1".
7.
5. The client selects an appropriate DDI service and sends a request
for a DDI URN to this service.
8.
6. The DDI service responds responds, for example 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 agency-identifier basically follows the rules of domain
names. Domain names are case-insensitive. case insensitive. Thus, the following
portion of the URN
urn:ddi:<agency-id>: is case-insensitive case insensitive for matches. matches:
urn:ddi:<agency-id>:
The remainder of the identifier MUST be considered case-sensitive. case sensitive.
3.8. Conformance with URN Syntax
The Namespace Specific String NSS conforms to the related section in [RFC8141]. It is composed
from the limited set of characters for
an a URN NSS [RFC8141]. Percent 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 Section 3.5, 'Process "Process of Identifier Assignment'. Assignment".
4.2. URN Resolution/Delegation
See section Section 3.6, 'Process "Process for Identifier Resolution'. Resolution".
It is RECOMMENDED to use that sub-agencies for flexible administration. 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 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].
o
* DDI repository
o
I2R (URI to Resource): given a DDI URN return return, one instance of
the resource identified by that URN.
o
* DDI registry
o
I2C (URI to URC, Uniform Resource Characteristics are
descriptions of resources): given a DDI URN return return, a description
or a summary of that resource.
o
* DDI URN resolution
o
I2L (URI to URL): given a DDI URN return return, one URL that identifies
a location where the identified DDI resource can be found.
o
I2Ls (URI to URLs): given a DDI URN return 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 agency-identifiers can be registered at the DDI Alliance. The
DDI Alliance will maintain maintains a registry of the assigned values for the DDI agency identifier
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. agency-identifiers.
See also above section Section 3.3 on Identifier "Identifier Uniqueness Considerations. 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 will promote promotes software for the resolution of DDI
agency identifiers and service discovery. discovery for
identifying available services connected to DDI agencies using the
Domain Name System (DNS). See also Appendix B Section 3.6 on "Process for
the resolution algorithm.
Identifier Resolution". A basic resolver library is available
[DDIRESO].
[DDI-RESO].
6. IANA Considerations
IANA is requested to update has updated the "ddi" entry in the Universal
Resource Names "Formal URN Namespaces"
registry to reference this specification.
The registration following NAPTR record for the key "ddi" has been registered in
the "URN.ARPA" zone is approved. urn.arpa zone:
ddi IN NAPTR 100 10 "" "" "" registry.ddialliance.org.
Requests for the domain ddi.urn.arpa will be are delegated to the name
servers of the DDI Alliance.
7. Security Considerations
URN:DDI identifiers are assigned to resources that are public
information, and therefore
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 3rd 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 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 [RFC4848],
Section 6. DNS "DNS Queries over HTTPS (DoH) (DoH)" [RFC8484] could be used to
increase security by preventing eavesdropping and manipulation of DNS
data by man-in-the-middle 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
[DDIC]
[DDI-C] DDI Codebook, Alliance, "DDI-Codebook 2.5", 2014,
<https://ddialliance.org/Specification/DDI-Codebook/2.5/>.
[DDI-ID] DDI Alliance 2000-2014,
<https://ddialliance.org/Specification/DDI-Codebook/>.
[DDIL] Alliance, "Identification", DDI Lifecycle, Lifecycle (3.3)
Technical Guide: General Structures, <https://ddi-
lifecycle-technical-
guide.readthedocs.io/en/latest/General%20Structures/
Identification.html>.
[DDI-L] DDI Alliance 2009-2020, Alliance, "DDI-Lifecycle",
<https://ddialliance.org/Specification/DDI-Lifecycle/>.
[DDIXKOS]
[DDI-SDTL] DDI XKOS 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, DDI
Alliance 2020,
System", <https://ddialliance.org/Specification/RDF/XKOS>.
[DDIID] DDI Lifecycle (3.3) Technical Guide, Identification,
<https://ddi-lifecycle-technical-
guide.readthedocs.io/en/latest/General%20Structures/Iden
tification.html>.
[RFC952]
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler Feinler, "DoD Internet
Host Table Specification",
host table specification", RFC 952, DOI 10.17487/RFC0952,
October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC1034] Mockapetris, P., "Domain Names names - Concepts concepts and
Facilities", facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain Names names - Implementation implementation and
Specification",
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed. 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>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
[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, D. 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., 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>.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors
Provide to the IETF Trust", BCP 78, RFC 5378, November
2008, <https://www.rfc-editor.org/info/rfc5378>.
[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", RFC 8174, May 2017, <https://www.rfc-
editor.org/info/rfc8174>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, 14, RFC 8179, 8174, DOI 10.17487/RFC8174,
May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[SDTL] SDTL - Structured Data Transformation Language - Version
1.0, <https://ddialliance.org/products/sdtl/1.0/>. <https://www.rfc-editor.org/info/rfc8174>.
[TLD] IANA Database of Top Level Domains, IANA, "Root Zone Database",
<https://www.iana.org/domains/root/db>.
8.2. Informative References
[ABNF2RS] ABNF "ABNF to REGEX REGEX: Regular Expression Generator, Michael R.
Sweet, Generator", October
2019, <https://www.msweet.org/abnf/>.
[ABNFGEN] abnfgen, Jutta Degener, J., "abnfgen", <http://www.quut.com/abnfgen/>.
[ABNFPFE] IETF, "IETF Author Tools - ABNF Parser, Bill Fenner,
<http://tools.ietf.org/tools/bap/abnf.cgi>.
[DDIALL] Tools",
<https://author-tools.ietf.org/abnf>.
[DDI-ALL] DDI Alliance, "Document, Discover and Interoperate",
<https://ddialliance.org/>.
[DDICVAG]
[DDI-CVAG] DDI Alliance, "DDI Controlled Vocabulary for Aggregation Method,
<https://ddialliance.org/Specification/DDI-
CV/AggregationMethod_1.0.html>.
[DDIEXQU]
Method", <https://ddialliance.org/Specification/DDI-CV/
AggregationMethod_1.0.html>.
[DDI-EXQU] DDI Alliance, "Questions", DDI Lifecycle 3.3 Technical Guide,
Guide: Examples, Questions, <https://ddi-lifecycle-technical-
guide.readthedocs.io/en/latest/Examples/Questions.html>.
[DDIEXRV]
[DDI-EXRV] DDI Alliance, "Represented Variable", DDI Lifecycle 3.3
Technical Guide, Guide: Examples, Represented
Variable, <https://ddi-lifecycle-technical-
guide.readthedocs.io/en/latest/Examples/RepresentedVaria
ble.html>.
[DDIINTR] <https://ddi-lifecycle-
technical-guide.readthedocs.io/en/latest/Examples/
RepresentedVariable.html>.
[DDI-INTR] Vardigan, M., Heus, P., and W. Thomas. Thomas, "Data Documentation
Initiative: Toward a Standard for the Social Sciences." Sciences",
The International Journal of Digital
Curation Curation, Issue 1,
Volume 3, 1 (2008), DOI 10.2218/ijdc.v3i1.45, December 2008,
<http://www.ijdc.net/article/view/66>.
[DDIREGI]
[DDI-REGI] DDI Agency Registry, Alliance, "Welcome to the DDI Registry",
<https://registry.ddialliance.org/>.
[DDIRESO]
[DDI-RESO] DDI Agency Registry Tools, Alliance, "Tools",
<https://registry.ddialliance.org/Home/Tools>.
[DUBLINC] Dublin Core Metadata Initiative, "Dublin Core",
<https://www.dublincore.org/>.
[ISO3166] ISO 3166 Country Codes,
<https://www.iso.org/iso-3166-country-codes.html>.
[IS11179] ISO/IEC 11179 Information ISO, "Information technology - Metadata registries (MDR) -
Part 6: Registration,
<http://metadata-standards.org/11179/>.
[IS19115] ISO 19115, Geographic Registration", ISO/IEC 11179-6:2023, January 2023,
<https://www.iso.org/standard/78916.html>.
[ISO.19115.2003]
ISO, "Geographic information -- Metadata, - 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>.
[RFC2843] Mealling, M., Daniel, R., "URI Resolution Services
Necessary for URN Resolution", RFC 2483, January 1999,
<https://www.rfc-editor.org/info/rfc2483>.
<https://www.rfc-editor.org/info/rfc2782>.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) -
Part Two: One: The Algorithm", 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 of the Domain
Name System", System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
2004, <https://www.rfc-editor.org/info/rfc3833>.
[RFC3958] Daigle, L., L. and A. Newton, A., "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>.
[RFC5385] Touch, J, "Version 2.0 Microsoft Word Template for
Creating Internet Drafts and RFCs", RFC 5385, February
2010, <https://www.rfc-editor.org/info/rfc5385>.
[RFC8484] Hoffman, P., P. and P. McManus, P., "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-
editor.org/rfc/rfc8484>.
<https://www.rfc-editor.org/info/rfc8484>.
[SDMX] SDMX -- Statistical Data and Metadata Exchange, eXchange, "SDMX",
<https://sdmx.org/>.
9. 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 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].
This document was prepared using the Word template
2-Word-v2.0.template.dot [RFC5385].
Appendix A. Example DNS Records
The examples use NAPTR [RFC3403] and SRV [RFC2782][RFC3958] [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.). ([RFC3403], Section 9).
For a description of the packet format of NAPTR, see [RFC3403]
section [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 which 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 domain name for which an SRV record
SHOULD be queried. See also [RFC4848] section [RFC4848], Section 4.4.
The service N2R 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/N2R/; http://repos.example2.org/I2R/; possibly a REST-based
service. The service N2C 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.), ([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" "N2R+http" "I2R+http" ( ; service
"!.*!http://repos.example2.org/N2R/!";
"!.*!http://repos.example2.org/I2R/!"; regex
. ; replacement
)
IN NAPTR 100 10 "s" "N2C+udp" "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" "N2R+http" "I2R+http" ( ; service
"!.*!http://repos.example2.org/N2R/!";
"!.*!http://repos.example2.org/I2R/!"; regex
. ; replacement
)
IN NAPTR 100 10 "s" "N2C+udp" "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).
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 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 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 server(s) 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
USA
United States of America
Email: joachim.wackerow@posteo.de, secretariat@ddialliance.org
Website:
URI: ddialliance.org