Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)
RFC 4848
Document | Type |
RFC - Proposed Standard
(April 2007; Errata)
Was draft-daigle-unaptr (individual in app area)
|
|
---|---|---|---|
Author | Leslie Daigle | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4848 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
Network Working Group L. Daigle Request for Comments: 4848 Cisco Systems Category: Standards Track April 2007 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. Daigle Standards Track [Page 1] RFC 4848 URI-Enabled NAPTR April 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Straightforward URI-Enabled NAPTR (U-NAPTR) . . . . . . . . . . 3 2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Permitted Regular Expressions . . . . . . . . . . . . . . . 4 3. Sample U-NAPTR DNS Records . . . . . . . . . . . . . . . . . . 4 4. Formal Definition of U-NAPTR Application of DDDS . . . . . . . 5 4.1. Application Unique String . . . . . . . . . . . . . . . . . 5 4.2. First Well Known Rule . . . . . . . . . . . . . . . . . . . 5 4.3. Expected Output . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.5. Service Parameters . . . . . . . . . . . . . . . . . . . . 5 4.5.1. Application Services . . . . . . . . . . . . . . . . . 6 4.5.2. Application Protocols . . . . . . . . . . . . . . . . . 6 4.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 4.7. Valid Databases . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Daigle Standards Track [Page 2] RFC 4848 URI-Enabled NAPTR April 2007 1. Introduction The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) [7] application to allow mapping of domain names to URIs for particular application services and protocols. This allows the "lookup" of particular services available for given domains, for example. Although this is defining a new and separate DDDS Application, dubbed U-NAPTR, it is built from the same principles as the Straightforward NAPTR (S-NAPTR) application, specified in [2]. This specification is not an update of S-NAPTR, but the reader is encouraged to review that document for extensive coverage of motivation and implementation considerations. S-NAPTR provides for application service location that does not rely on rigid domain naming conventions. It is deemed "straightforward" in part because it rules out the use of regular expressions in NAPTR records (for the S-NAPTR DDDS Application). However, that also rules out the possibility of providing a URI as the target of DDDS resolution. A number of applications, specified (e.g., [9]) and proposed, find the restriction too limiting, making S-NAPTR a near miss to suit their needs. This U-NAPTR is effectively a modest extension to S-NAPTR, to accommodate the use of URIs as targets, without allowing the full range of possible regular expressions in NAPTR records. 2. Straightforward URI-Enabled NAPTR (U-NAPTR) This document assumes the reader is familiar with the S-NAPTR specification [2]. The intention of U-NAPTR is to provide everything that S-NAPTR does, except that it allows the use of the "U" flag in the NAPTR record, and a specific form of REGEXP. 2.1. Permitted Flags U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus the "U" Flag. For the U-NAPTR DDDS Application, the presence of the "U" Flag in the NAPTR record indicates the REGEXP field must beShow full document text