]> American Registry for Internet Numbers

3635 Concorde Parkway Chantilly VA US 20151 andy@arin.net http://www.arin.net

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.

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

The following is a LINK example instructing search engines not to follow a specific link. example.com. IN LINK "http://example.com/ r=nofollow"

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"

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: URI tag1=value1 tag2=value2 ... 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 .

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 . r - matches "rel" v - matches "rev" hl - matches "hreflang" m - matches "media" t - matches "type" tt - matches "title", only one may appear per LINK record tl - refers the language of the title, only one may appear per LINK record and must be accompanied by a tl tag in the same LINK record 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 .

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; &RFC5988; &RFC7230; &I-D.faltstrom-uri; &RFC3958; &RFC4848;

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 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 is a method for using NAPTR records to resolve URIs in the DNS using application service keywords and application protocol or transport protocol keywords. defines the URI resource record which can be used without further domain name qualification or with NAPTR records as described by to achieve the same service/protocol keyword resolution as U-NAPTR. 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 and 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.

Booyah!