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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| 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
Show full document text