summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4848.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4848.txt')
-rw-r--r--doc/rfc/rfc4848.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc4848.txt b/doc/rfc/rfc4848.txt
new file mode 100644
index 0000000..24f8b47
--- /dev/null
+++ b/doc/rfc/rfc4848.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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
+ 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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+