idnits 2.17.1 draft-newton-link-rr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 139: '...le, therefore applications MUST ignore...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 11, 2014) is 3453 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-14) exists of draft-faltstrom-uri-09 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft ARIN 4 Intended status: Standards Track November 11, 2014 5 Expires: May 15, 2015 7 The LINK DNS Resource Record 8 draft-newton-link-rr-00 10 Abstract 12 This document describes a DNS resource record for holding a URI and 13 meta-data about the URI useful in constructing web links (as 14 described in RFC 5988). The name of this resource record is LINK. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 15, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 6. Internationalization Considerations . . . . . . . . . . . . . 4 56 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 8.2. Informational References . . . . . . . . . . . . . . . . 5 60 Appendix A. Design Considerations . . . . . . . . . . . . . . . 5 61 Appendix B. Relevance to U-NAPTR and the URI Record Type . . . . 6 62 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 [RFC5988] describes a typed link framework for relating resources on 68 the Web (and more generally on the Internet). It does this by 69 specifying a formal syntax for a Link header to be used in HTTP 70 [RFC7230] and by establishing an IANA registry for link 71 relationships. 73 The LINK resource record described in this document re-uses the tags 74 and values of the HTTP Link header described in [RFC5988] but with a 75 simplified syntax for compactness and use of multiple records in a 76 DNS resource record set (RRSET). By making link information 77 available in the DNS, applications may perform link mapping outside 78 of HTTP. Additionally, since the Link data uses other common 79 application building blocks such as URIs [RFC3986] and media types, 80 the use of this link information can be much broader than HTTP with 81 other application protocols. 83 The following is a simple LINK example which links "icon.png" as the 84 icon for example.com. 86 example.com. IN LINK "http://example.com/icon.png r=icon" 88 Figure 1 90 The following is a LINK example instructing search engines not to 91 follow a specific link. 93 example.com. IN LINK "http://example.com/ r=nofollow" 95 Figure 2 97 In the following example, links are given for example.com based on a 98 natural language preference. 100 example.com. 101 IN LINK "http://en.example.com/ hl=en" 102 IN LINK "http://es.example.com/ hl=es" 103 IN LINK "http://fr.example.com/ hl=fr" 105 Figure 3 107 In the following example, links are given for a RESTful service in 108 both an XML and JSON format. 110 restful.example.com. 111 IN LINK "http://example.com/rest-xml t=application/foo+xml" 112 IN LINK "http://example.com/rest-json t=application/foo+json" 114 2. Format 116 The format of the LINK resource record is the same as the TXT 117 resource record, except the resource record name is LINK. The 118 resource record data consists of character-strings. When these 119 character-strings are concatenated they take the form of: 121 URI tag1=value1 tag2=value2 ... 123 The ABNF for the final character string concatenation is: 125 tagchar = ( DIGIT / ALPHA ) 126 tag = *tagchar 127 quotedvalue = %x27 *(VCHAR / WSP ) %x27 128 tagvalue = tag "=" VCHAR / quotedvalue 129 linkdata = URI 1*SP tagvalue *( 1*SP tagvalue ) 130 ; URI is defined in RFC 3986 132 Each tag value pair is separated by space, and the values do not need 133 to be quoted unless they contain space characters. Tags are defined 134 in Section 3. 136 3. Tags 138 This document defines the following tags for the LINK RR. Future 139 specification of tags is possible, therefore applications MUST ignore 140 unknown tags. All of the tags below reference a tag from [RFC5988]. 142 1. r - matches "rel" 144 2. v - matches "rev" 145 3. hl - matches "hreflang" 147 4. m - matches "media" 149 5. t - matches "type" 151 6. tt - matches "title", only one may appear per LINK record 153 7. tl - refers the language of the title, only one may appear per 154 LINK record and must be accompanied by a tl tag in the same LINK 155 record 157 Becaue multiple LINK records may be specified, the restrictions upon 158 the tt and tl tags gives the same functionality as the title and 159 title* tags from [RFC5988]. 161 4. IANA Considerations 163 The IANA will need to assign a value for the LINK record type. 165 5. Security Considerations 167 TBD 169 6. Internationalization Considerations 171 The LINK record allows referenced links and titles to links to be 172 given language tags with the tl and hl record tags, respectively. 174 7. Privacy Considerations 176 Information in the DNS is publicly visible to all parties on the 177 Internet. While visibility of the HTTP Link header can be 178 constrained via HTTP access methods, visibility of the LINK record 179 cannot. Care should be taken that information available in an HTTP 180 Link header is appropriate for public visibility once translated into 181 a LINK record. 183 8. References 185 8.1. Normative References 187 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 188 Resource Identifier (URI): Generic Syntax", STD 66, RFC 189 3986, January 2005. 191 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 193 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 194 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 195 2014. 197 8.2. Informational References 199 [I-D.faltstrom-uri] 200 Faeltstroem, P. and O. Kolkman, "The Uniform Resource 201 Identifier (URI) DNS Resource Record", draft-faltstrom- 202 uri-09 (work in progress), August 2014. 204 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 205 Service Location Using SRV RRs and the Dynamic Delegation 206 Discovery Service (DDDS)", RFC 3958, January 2005. 208 [RFC4848] Daigle, L., "Domain-Based Application Service Location 209 Using URIs and the Dynamic Delegation Discovery Service 210 (DDDS)", RFC 4848, April 2007. 212 Appendix A. Design Considerations 214 In designing the format for the LINK record, the author considered a 215 record specific RDATA format and presentation format using a simple 216 tag-length-value (TLV) construction. Such a design has the advantage 217 of mapping the same [RFC5988] tags to numeric codes and potentially 218 avoids escaping issues with quoted strings. 220 The decision to use space separated key-value pairs inside character 221 strings was instead chosen to better aid adoption. With this method, 222 libraries need only re-use the TXT record construct at the bare 223 minimum, and in more complete cases couuld offer a richer interface 224 while using simple space delimited token parsing of the character 225 strings. 227 In the event that this design is found to be problematic or lacking 228 the ease-of-adoption desired, the author believe moving to a TLV 229 design is semantically compatible and easily achieved. 231 Re-use of the exact syntax of the Link header was also considered. 232 However, that syntax is not as simple as desired because of the 233 nature of how headers are embedded in HTTP and the need for backwards 234 compatibility with a previously deprecated version of the Link 235 header. Therefore a simplified, space delimited syntax is used. 237 Appendix B. Relevance to U-NAPTR and the URI Record Type 239 Placement of URIs in the DNS is not a new idea, but it has yet to 240 have found significant usage. 242 U-NAPTR [RFC4848] is a method for using NAPTR records to resolve URIs 243 in the DNS using application service keywords and application 244 protocol or transport protocol keywords. 246 [I-D.faltstrom-uri] defines the URI resource record which can be used 247 without further domain name qualification or with NAPTR records as 248 described by [RFC3958] to achieve the same service/protocol keyword 249 resolution as U-NAPTR [RFC4848]. 251 In practice, the need for service/protocol keyword resolution by 252 applications is usually irrelevant and can be redundant or conflict 253 with the scheme of the target URI. Additionally, both U-NAPTR 254 [RFC4848] and [I-D.faltstrom-uri] offer a weight and order sorting 255 mechanism which is seldom ever needed but adds confusion to the 256 administration of these DNS resource records. 258 The approach used by this document is to offer applications the 259 ability to reference information about a URI and the target of the 260 URI as is commonly used on the Internet, especially in web-based 261 protocols. 263 Appendix C. Changelog 265 Initial -00 Booyah! 267 Author's Address 269 Andrew Lee Newton 270 American Registry for Internet Numbers 271 3635 Concorde Parkway 272 Chantilly, VA 20151 273 US 275 Email: andy@arin.net 276 URI: http://www.arin.net