One document matched: draft-daigle-unaptr-00.txt

Network Working Group                                          L. Daigle
Internet-Draft                                             Cisco Systems
Expires: December 21, 2006                                 June 19, 2006


  Domain-based Application Service Location Using URIs and the Dynamic
                  Delegation Discovery Service (DDDS)
                       draft-daigle-unaptr-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum 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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The purpose of this memo is to provide a small extension to the
   "Straightforward NAPTR" (S-NAPTR) Dynamic Delegation Discovery System
   (DDDS) Application so that URIs can be offered as the target of the
   DDDS resolution.

   It is not yet clear (in this -00 draft) whether that is best
   achievedby extending the S-NAPTR specification, or by providing a new
   DDDS Application.  This version of the draft focuses on describing



Daigle                  Expires December 21, 2006               [Page 1]

Internet-Draft           draft-daigle-unaptr-00                June 2006


   the extension and pros/cons of either approach.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Straightforward URI-enabled NAPTR (U-NAPTR) Specification . . . 3
     2.1.  Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Permitted Regular Expressions . . . . . . . . . . . . . . . 3
   3.  Sample U-NAPTR DNS records  . . . . . . . . . . . . . . . . . . 4
   4.  Update or Replace S-NAPTR?  . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

































Daigle                  Expires December 21, 2006               [Page 2]

Internet-Draft           draft-daigle-unaptr-00                June 2006


1.  Introduction

   The goal of this document is to provide an extention to the
   Straightforward NAPTR (S-NAPTR) specification found in [13] to allow
   URIs as targets.

   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, and a number of applications, specified ([12]) and
   proposed, find the restriction too limiting, making S-NAPTR a near
   miss to suit their needs.

   This memo proposes 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.  The implications of
   approaching this as an update of S-NAPTR or a new DDDS application
   altogether are discussed.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 ([1]).


2.  Straightforward URI-enabled NAPTR (U-NAPTR) Specification

   This document assumes the reader is familiar with the S-NAPTR
   specification ([13]).  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 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.

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



Daigle                  Expires December 21, 2006               [Page 3]

Internet-Draft           draft-daigle-unaptr-00                June 2006


   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>"!"
           <URI>  =  (as defined in
   [14]
   ,  current URI syntax)

   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   ""    "EM:protA"        ( ; service
                             "!*.!prota://someisp.example.com!"    ; regexp
                             ""                  ; replacement
                                               )
   IN NAPTR 200   30   "a"   "EM:protB"          ; service
                             ""                  ; regexp
                             myprotB.example.com.; replacement
                                               )


4.  Update or Replace S-NAPTR?

   There are 2 obvious ways to implement the functionality described in
   this memo.

   The first approach would be to declare U-NAPTR an extension of
   S-NAPTR, and have this specification formally "update" the S-NAPTR



Daigle                  Expires December 21, 2006               [Page 4]

Internet-Draft           draft-daigle-unaptr-00                June 2006


   RFC.  The implication would be instant access to all S-NAPTR
   registered Application Services and Application Protocols, and no
   question of a new IANA registry.  However, it goes against the
   S-NAPTR specification, which specificallly requires the "REGEXP"
   field of the NAPTR record to be empty.  This would not be a change
   that is backwards compatible with existing S-NAPTR implementations.

   Alternatively, U-NAPTR could be written as a completely separate DDDS
   Application, copying text from the S-NAPTR application and adding the
   2 U-NAPTR specific bits.  This would likely imply the need to create
   a new set of IANA registries, for U-NAPTR aware Application Services
   and Application Protocols.  This would be an unpleasant amount of
   overhead, but would be backwards compatible with existing S-NAPTR
   implementations (because they are completely separate), and would
   allow application protocol designers to choose whether S-NAPTR or
   U-NAPTR fit their requirements.

   Perhaps the best approach is to make U-NAPTR an update of S-NAPTR,
   updating the IANA registry to include an indication of whether an
   Application Service expects S-NAPTR or supports U-NAPTR (i.e., is
   findable with or without "U" flags).  And, existing registrations are
   assumed to be "S-NAPTR" unless otherwise updated.


5.  IANA Considerations

   It's not yet clear whether this memo will incur any IANA actions.


6.  Security Considerations

   U-NAPTR has the same considerations for security as S-NAPTR, and the
   additional consideration that resolving URIs (from the result of the
   DDDS resolution) has its own set of security implications, covered in
   the URI specfication.  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.  References

7.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.




Daigle                  Expires December 21, 2006               [Page 5]

Internet-Draft           draft-daigle-unaptr-00                June 2006


   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

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

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

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

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

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

7.2.  Informative References

   [8]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [9]   Newton, A. and M. Sanz, "IRIS Domain Registry Schema",
         draft-ietf-crisp-iris-dreg-06 (work in progress), April 2004.

   [10]  Newton, A. and M. Sanz, "Using the Internet Registry
         Information Service (IRIS) over the Blocks  Extensible Exchange
         Protocol (BEEP)", draft-ietf-crisp-iris-beep-04 (work in
         progress), April 2004.

   [11]  Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
         System", draft-ietf-dnsext-dns-threats-07 (work in progress),
         April 2004.

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

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

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



Daigle                  Expires December 21, 2006               [Page 6]

Internet-Draft           draft-daigle-unaptr-00                June 2006


         January 2005.

   [15]  Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol
         Modifications for the DNS Security Extensions",
         draft-ietf-dnsext-dnssec-protocol-06 (work in progress),
         May 2004.













































Daigle                  Expires December 21, 2006               [Page 7]

Internet-Draft           draft-daigle-unaptr-00                June 2006


Author's Address

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

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










































Daigle                  Expires December 21, 2006               [Page 8]

Internet-Draft           draft-daigle-unaptr-00                June 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

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




Daigle                  Expires December 21, 2006               [Page 9]