Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)
RFC 4848

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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 be