| Network Working Group | A. Newton |
| Internet-Draft | ARIN |
| Intended status: Standards Track | November 11, 2014 |
| Expires: May 15, 2015 |
The LINK DNS Resource Record
draft-newton-link-rr-00
This document describes a DNS resource record for holding a URI and meta-data about the URI useful in constructing web links (as described in RFC 5988). The name of this resource record is LINK.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 15, 2015.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[RFC5988] describes a typed link framework for relating resources on the Web (and more generally on the Internet). It does this by specifying a formal syntax for a Link header to be used in HTTP [RFC7230] and by establishing an IANA registry for link relationships.
The LINK resource record described in this document re-uses the tags and values of the HTTP Link header described in [RFC5988] but with a simplified syntax for compactness and use of multiple records in a DNS resource record set (RRSET). By making link information available in the DNS, applications may perform link mapping outside of HTTP. Additionally, since the Link data uses other common application building blocks such as URIs [RFC3986] and media types, the use of this link information can be much broader than HTTP with other application protocols.
The following is a simple LINK example which links "icon.png" as the icon for example.com.
example.com. IN LINK "http://example.com/icon.png r=icon"
Figure 1
The following is a LINK example instructing search engines not to follow a specific link.
example.com. IN LINK "http://example.com/ r=nofollow"
Figure 2
In the following example, links are given for example.com based on a natural language preference.
example.com.
IN LINK "http://en.example.com/ hl=en"
IN LINK "http://es.example.com/ hl=es"
IN LINK "http://fr.example.com/ hl=fr"
Figure 3
In the following example, links are given for a RESTful service in both an XML and JSON format.
restful.example.com.
IN LINK "http://example.com/rest-xml t=application/foo+xml"
IN LINK "http://example.com/rest-json t=application/foo+json"
The format of the LINK resource record is the same as the TXT resource record, except the resource record name is LINK. The resource record data consists of character-strings. When these character-strings are concatenated they take the form of:
The ABNF for the final character string concatenation is:
tagchar = ( DIGIT / ALPHA )
tag = *tagchar
quotedvalue = %x27 *(VCHAR / WSP ) %x27
tagvalue = tag "=" VCHAR / quotedvalue
linkdata = URI 1*SP tagvalue *( 1*SP tagvalue )
; URI is defined in RFC 3986
Each tag value pair is separated by space, and the values do not need to be quoted unless they contain space characters. Tags are defined in Section 3.
This document defines the following tags for the LINK RR. Future specification of tags is possible, therefore applications MUST ignore unknown tags. All of the tags below reference a tag from [RFC5988].
Becaue multiple LINK records may be specified, the restrictions upon the tt and tl tags gives the same functionality as the title and title* tags from [RFC5988].
The IANA will need to assign a value for the LINK record type.
TBD
The LINK record allows referenced links and titles to links to be given language tags with the tl and hl record tags, respectively.
Information in the DNS is publicly visible to all parties on the Internet. While visibility of the HTTP Link header can be constrained via HTTP access methods, visibility of the LINK record cannot. Care should be taken that information available in an HTTP Link header is appropriate for public visibility once translated into a LINK record.
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. |
| [RFC5988] | Nottingham, M., "Web Linking", RFC 5988, October 2010. |
| [RFC7230] | Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. |
| [I-D.faltstrom-uri] | Fältström, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", Internet-Draft draft-faltstrom-uri-09, August 2014. |
| [RFC3958] | Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. |
| [RFC4848] | Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007. |
In designing the format for the LINK record, the author considered a record specific RDATA format and presentation format using a simple tag-length-value (TLV) construction. Such a design has the advantage of mapping the same [RFC5988] tags to numeric codes and potentially avoids escaping issues with quoted strings.
The decision to use space separated key-value pairs inside character strings was instead chosen to better aid adoption. With this method, libraries need only re-use the TXT record construct at the bare minimum, and in more complete cases couuld offer a richer interface while using simple space delimited token parsing of the character strings.
In the event that this design is found to be problematic or lacking the ease-of-adoption desired, the author believe moving to a TLV design is semantically compatible and easily achieved.
Re-use of the exact syntax of the Link header was also considered. However, that syntax is not as simple as desired because of the nature of how headers are embedded in HTTP and the need for backwards compatibility with a previously deprecated version of the Link header. Therefore a simplified, space delimited syntax is used.
Placement of URIs in the DNS is not a new idea, but it has yet to have found significant usage.
U-NAPTR [RFC4848] is a method for using NAPTR records to resolve URIs in the DNS using application service keywords and application protocol or transport protocol keywords.
[I-D.faltstrom-uri] defines the URI resource record which can be used without further domain name qualification or with NAPTR records as described by [RFC3958] to achieve the same service/protocol keyword resolution as U-NAPTR [RFC4848].
In practice, the need for service/protocol keyword resolution by applications is usually irrelevant and can be redundant or conflict with the scheme of the target URI. Additionally, both U-NAPTR [RFC4848] and [I-D.faltstrom-uri] offer a weight and order sorting mechanism which is seldom ever needed but adds confusion to the administration of these DNS resource records.
The approach used by this document is to offer applications the ability to reference information about a URI and the target of the URI as is commonly used on the Internet, especially in web-based protocols.