[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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

Abstract

   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.

Status of This Memo

   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 Notice

   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.





Newton                    Expires May 15, 2015                  [Page 1]


Internet-Draft                   LINK RR                   November 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Format  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Tags  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Internationalization Considerations . . . . . . . . . . . . .   4
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informational References  . . . . . . . . . . . . . . . .   5
   Appendix A.  Design Considerations  . . . . . . . . . . . . . . .   5
   Appendix B.  Relevance to U-NAPTR and the URI Record Type . . . .   6
   Appendix C.  Changelog  . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   [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



Newton                    Expires May 15, 2015                  [Page 2]


Internet-Draft                   LINK RR                   November 2014


   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"

2.  Format

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

3.  Tags

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

   1.  r - matches "rel"

   2.  v - matches "rev"



Newton                    Expires May 15, 2015                  [Page 3]


Internet-Draft                   LINK RR                   November 2014


   3.  hl - matches "hreflang"

   4.  m - matches "media"

   5.  t - matches "type"

   6.  tt - matches "title", only one may appear per LINK record

   7.  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 [RFC5988].

4.  IANA Considerations

   The IANA will need to assign a value for the LINK record type.

5.  Security Considerations

   TBD

6.  Internationalization Considerations

   The LINK record allows referenced links and titles to links to be
   given language tags with the tl and hl record tags, respectively.

7.  Privacy Considerations

   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.

8.  References

8.1.  Normative References

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




Newton                    Expires May 15, 2015                  [Page 4]


Internet-Draft                   LINK RR                   November 2014


   [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
              2014.

8.2.  Informational References

   [I-D.faltstrom-uri]
              Faeltstroem, P. and O. Kolkman, "The Uniform Resource
              Identifier (URI) DNS Resource Record", draft-faltstrom-
              uri-09 (work in progress), 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.

Appendix A.  Design Considerations

   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.








Newton                    Expires May 15, 2015                  [Page 5]


Internet-Draft                   LINK RR                   November 2014


Appendix B.  Relevance to U-NAPTR and the URI Record Type

   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.

Appendix C.  Changelog

   Initial -00  Booyah!

Author's Address

   Andrew Lee Newton
   American Registry for Internet Numbers
   3635 Concorde Parkway
   Chantilly, VA  20151
   US

   Email: andy@arin.net
   URI:   http://www.arin.net











Newton                    Expires May 15, 2015                  [Page 6]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/