path: root/doc/rfc/rfc4848.txt

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]
^L
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]
^L
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
   populated (and, consequently, the REPLACEMENT field is empty).  The
   regular expression in the REGEXP field must be of the limited form
   described below, and the result of the regular expression evaluation
   will be a URI that is the result of the DDDS resolution.







Daigle                      Standards Track                     [Page 3]
^L
RFC 4848                   URI-Enabled NAPTR                  April 2007


2.2.  Permitted Regular Expressions

   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.  This is essentially a dodge around the fact that the
   REPLACEMENT field in NAPTR is required to produce only a fully
   qualified domain name (and, therefore, cannot be used for a URI).

   The specific allowed syntax for U-NAPTR regular expressions is:

        u-naptr-regexp = "!.*!"<URI>"!"

   where <URI> is as defined in STD 66 [8], the URI syntax
   specification.

   With this limited form of regular expression, applications using
   U-NAPTR need not implement full regular expression parsers.

3.  Sample U-NAPTR DNS Records

   In the sample NAPTR RRs for example.com shown below, "WP" is the
   imagined application service tag for "white pages", and "EM" is the
   application service tag for an imagined "Extensible Messaging"
   application service.

   example.com.
   ;;       order pref flags
   IN NAPTR 100   10   ""    "WP:whois++"      ( ; service
                             ""                  ; regexp
                             bunyip.example.com. ; replacement
                                               )
   IN NAPTR 100   20   "s"   "WP:ldap"         ( ; service
                             ""                  ; regexp
                            _ldap._tcp.myldap.example.com. ; replacement
                                               )
   IN NAPTR 200   10   "u"    "EM:protA"        ( ; service
                             "!.*!prota://someisp.example.com!" ; regexp
                             ""                  ; replacement
                                               )
   IN NAPTR 200   30   "a"   "EM:protB"          ; service
                             ""                  ; regexp
                             myprotB.example.com.; replacement
                                               )








Daigle                      Standards Track                     [Page 4]
^L
RFC 4848                   URI-Enabled NAPTR                  April 2007


4.  Formal Definition of U-NAPTR Application of DDDS

   This section formally defines the DDDS Application, as described in
   [7].

4.1.  Application Unique String

   The Application Unique String is a fully qualified domain name (FQDN)
   for which an authoritative server for a particular service is sought.

4.2.  First Well Known Rule

   The "First Well Known Rule" is identity -- that is, the output of the
   rule is the Application Unique String, the FQDN for which the
   authoritative server for a particular service is sought.

4.3.  Expected Output

   The expected output of this Application is the information necessary
   to connect to authoritative server(s) (host, port, protocol, or URI)
   for an application service within a given domain.

4.4.  Flags

   This DDDS Application uses only 3 of the Flags defined for the URI/
   URN Resolution Application [5]: "S", "A", and "U".  No other Flags
   are valid.  If a client obtains a NAPTR RR for a U-NAPTR-using
   application that contains any other flag, that NAPTR RR should be
   ignored and processing continues with the next record (if any).

   These flags are for terminal lookups.  This means that the Rule is
   the last one and that the flag determines what the next stage should
   be.  The "S" flag means that the output of this Rule is a FQDN for
   which one or more SRV [3] records exist.  "A" means that the output
   of the Rule is a domain name and should be used to lookup address
   records for that domain.  "U" means that the output of the Rule is a
   URI that should be resolved in order to obtain access to the
   described service.

   Consistent with the DDDS algorithm, if the Flag string is empty the
   next lookup is for another NAPTR record (for the replacement target).

4.5.  Service Parameters

   Service Parameters for this Application take the form of a string of
   characters that follow this ABNF [1]:





Daigle                      Standards Track                     [Page 5]
^L
RFC 4848                   URI-Enabled NAPTR                  April 2007


      service-parms = [ [app-service] *(":" app-protocol)]
      app-service   = experimental-service  / iana-registered-service
      app-protocol  = experimental-protocol / iana-registered-protocol
      experimental-service      = "x-" 1*30ALPHANUMSYM
      experimental-protocol     = "x-" 1*30ALPHANUMSYM
      iana-registered-service   = ALPHA *31ALPHANUMSYM
      iana-registered-protocol  = ALPHA *31ALPHANUMSYM
      ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
      DIGIT         =  %x30-39 ; 0-9
      SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
      ALPHANUMSYM   =  ALPHA / DIGIT / SYM
      ; The app-service and app-protocol tags are limited to 32
      ; characters and must start with an alphabetic character.
      ; The service-parms are considered case-insensitive.

   Thus, the Service Parameters may consist of an empty string, just an
   app-service, or an app-service with one or more app-protocol
   specifications separated by the ":" symbol.

   Note that this is similar to, but not the same as the syntax used in
   the URI DDDS application [5].  The DDDS DNS database requires each
   DDDS application to define the syntax of allowable service strings.
   The syntax here is expanded to allow the characters that are valid in
   any URI scheme name (see [8]).  Since "+" (the separator used in the
   RFC3404 service parameter string) is an allowed character for URI
   scheme names, ":" is chosen as the separator here.

4.5.1.  Application Services

   The "app-service" must be an IANA-registered service; see Section 5
   for instructions on registering new application service tags.

4.5.2.  Application Protocols

   The protocol identifiers that are valid for the "app-protocol"
   production are standard, registered protocols; see Section 5 for
   instructions on registering new application protocol tags.

4.6.  Valid Rules

   Permitted rules are substitution rules and regular expressions of the
   following syntax (i.e., a regular expression to replace the domain
   name with a URI):

           u-naptr-regexp = "!.*!"<URI>"!"

   where <URI> is as defined in STD 66 [8], the URI syntax
   specification.



Daigle                      Standards Track                     [Page 6]
^L
RFC 4848                   URI-Enabled NAPTR                  April 2007


4.7.  Valid Databases

   At present, only one DDDS Database is specified for this Application.
   [4] specifies a DDDS Database that uses the NAPTR DNS resource record
   to contain the rewrite rules.  The Keys for this database are encoded
   as domain names.

   The First Well Known Rule produces a domain name, and this is the Key
   that is used for the first lookup -- the NAPTR records for that
   domain are requested.

   DNS servers MAY interpret Flag values and use that information to
   include appropriate NAPTR, SRV, or A records in the Additional
   Information portion of the DNS packet.  Clients are encouraged to
   check for additional information but are not required to do so.  See
   the Additional Information Processing section of [4] for more
   information on NAPTR records and the Additional Information section
   of a DNS response packet.

5.  IANA Considerations

   This document does not itself place any requirements on IANA, but
   provides the basis upon which U-NAPTR-using services can make use of
   the existing IANA registries for application service tags and
   application protocol tags (defined in RFC 3958 [2]).

   As is the case for S-NAPTR, all application service and protocol tags
   that start with "x-" are considered experimental, and no provision is
   made to prevent duplicate use of the same string.  Use them at your
   own risk.

   All other application service and protocol tags are registered based
   on the "specification required" option defined in [6], with the
   further stipulation that the "specification" is an RFC (of any
   category).

   There are no further restrictions placed on the tags other than that
   they must conform with the syntax defined above (Section 4.5).

   The defining RFC must clearly identify and describe, for each tag
   being registered:

   o  Application protocol or service tag

   o  Intended usage

   o  Interoperability considerations




Daigle                      Standards Track                     [Page 7]
^L
RFC 4848                   URI-Enabled NAPTR                  April 2007


   o  Security considerations (see Section 6 of this document for
      further discussion of the types of considerations that are
      applicable)

   o  Any relevant related publications

   The defining RFC may also include further application-specific
   restrictions, such as limitations on the types of URIs that may be
   returned for the application service.

6.  Security Considerations

   U-NAPTR has the same considerations for security as S-NAPTR; see
   Section 8 of [2].  U-NAPTR has the additional consideration that
   resolving URIs (from the result of the DDDS resolution) has its own
   set of security implications, covered in the URI specification (in
   particular, Section 7 of [8]).  In essence, using DNSSEC, client
   software can be confident that the URI obtained using U-NAPTR is
   indeed the one specified by the administrator of the domain from
   which it was retrieved; but the validity of the service reached by
   resolving that URI is a matter of URI resolution security practices.

7.  Acknowledgements

   Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes,
   Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier
   versions and catching errors!

8.  References

8.1.  Normative References

   [1]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [2]  Daigle, L. and A. Newton, "Domain-Based Application Service
        Location Using SRV RRs and the Dynamic Delegation Discovery
        Service (DDDS)", RFC 3958, January 2005.

   [3]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.

   [4]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Three: The Domain Name System (DNS) Database", RFC 3403,
        October 2002.





Daigle                      Standards Track                     [Page 8]
^L
RFC 4848                   URI-Enabled NAPTR                  April 2007


   [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        Four: The Uniform Resource Identifiers (URI)", RFC 3404,
        October 2002.

   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8.2.  Informative References

   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
        One: The Comprehensive DDDS", RFC 3401, October 2002.

   [8]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66,
        January 2005.

   [9]  Malamud, C., "Attaching Meaning to Solicitation Class Keywords",
        RFC 4095, May 2005.

Author's Address

   Leslie L. Daigle
   Cisco Systems
   13615 Dulles Technology Drive
   Herndon, VA  20171
   US

   EMail: ledaigle@cisco.com; leslie@thinkingcat.com























Daigle                      Standards Track                     [Page 9]
^L
RFC 4848                   URI-Enabled NAPTR                  April 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Daigle                      Standards Track                    [Page 10]
^L