idnits 2.17.1 draft-hausenblas-csv-fragment-08.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 abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4180, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4180, updated by this document, for RFC5378 checks: 2005-02-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2, 2013) is 3790 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Hausenblas 3 Internet-Draft DERI, NUI Galway 4 Updates: 4180 (if approved) E. Wilde 5 Intended status: Informational EMC Corporation 6 Expires: June 5, 2014 J. Tennison 7 Open Data Institute 8 December 2, 2013 10 URI Fragment Identifiers for the text/csv Media Type 11 draft-hausenblas-csv-fragment-08 13 Abstract 15 This memo defines URI fragment identifiers for text/csv MIME 16 entities. These fragment identifiers make it possible to refer to 17 parts of a text/csv MIME entity, identified by row, column, or cell. 18 Fragment identification can use single items, or ranges. 20 Note to Readers 22 This draft should be discussed on the apps-discuss mailing list [1]. 24 Online access to all versions and files is available on github [2]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 5, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. What is text/csv? . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Why text/csv Fragment Identifiers? . . . . . . . . . . . . 3 63 1.2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 65 1.3. Incremental Deployment . . . . . . . . . . . . . . . . . . 4 66 1.4. Notation Used in this Memo . . . . . . . . . . . . . . . . 4 67 2. Fragment Identification Methods . . . . . . . . . . . . . . . 5 68 2.1. Row-based selection . . . . . . . . . . . . . . . . . . . 5 69 2.2. Column-based selection . . . . . . . . . . . . . . . . . . 5 70 2.3. Cell-based selection . . . . . . . . . . . . . . . . . . . 6 71 2.4. Multi-Selections . . . . . . . . . . . . . . . . . . . . . 7 72 3. Fragment Identification Syntax . . . . . . . . . . . . . . . . 7 73 4. Fragment Identifier Processing . . . . . . . . . . . . . . . . 7 74 4.1. Syntax Errors in Fragment Identifiers . . . . . . . . . . 7 75 4.2. Semantics of Fragment Identifiers . . . . . . . . . . . . 8 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. The text/csv media type . . . . . . . . . . . . . . . . . 9 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. From -07 to -08 . . . . . . . . . . . . . . . . . . . . . 11 81 7.2. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 11 82 7.3. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 11 83 7.4. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 12 84 7.5. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 12 85 7.6. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 12 86 7.7. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 12 87 7.8. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 12 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 90 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 13 91 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 This memo updates the text/csv media type defined in RFC 4180 97 [RFC4180] by defining URI fragment identifiers for text/csv MIME 98 entities. 100 The change to the text/csv media type registration required IESG 101 approval, as the IESG is the change controller for that registration. 102 The IESG has, after consultation with the IETF community, approved 103 the change, which is specified in Section 5 of this document. 105 This section gives an introduction to the general concepts of text/ 106 csv MIME entities and URI fragment identifiers, and discusses the 107 need for fragment identifiers for text/csv and deployment issues. 108 Section 2 discusses the principles and methods on which this memo is 109 based. Section 3 defines the syntax, and Section 4 discusses 110 processing of text/csv fragment identifiers. 112 1.1. What is text/csv? 114 Internet Media Types (often referred to as "MIME types") as defined 115 in RFC 2045 [RFC2045] and RFC 2046 [RFC2046] are used to identify 116 different types and sub-types of media. The text/csv media type is 117 defined in RFC 4180 [RFC4180], using US-ASCII [ASCII] as the default 118 character encoding (other character encodings can be used as well). 119 Apart from a media type parameter for specifying the character 120 encoding ("charset"), there is a second media type parameter 121 ("header") that indicates whether there is a header row in the CSV 122 document or not. 124 1.2. Why text/csv Fragment Identifiers? 126 URIs are the identification mechanism for resources on the Web. The 127 URI syntax specified in RFC 3986 [RFC3986] optionally includes a so- 128 called "fragment identifier", separated by a number sign ("#"). The 129 fragment identifier consists of additional reference information to 130 be interpreted by the client after the retrieval action has been 131 successfully completed. The semantics of a fragment identifier is a 132 property of the media type resulting from a retrieval action, 133 regardless of the URI scheme used in the URI reference. Therefore, 134 the format and interpretation of fragment identifiers is dependent on 135 the media type of the retrieval result. 137 1.2.1. Motivation 139 Similar to the motivation in RFC 5147 [RFC5147], which defines 140 fragment identifiers for plain text files, referring to specific 141 parts of a resource can be very useful, because it enables users and 142 applications to create more specific references. Users can create 143 references to the part they really are interested in or want to talk 144 about, rather than always pointing to a complete resource. Even 145 though it is suggested that fragment identification methods are 146 specified in a media type's registration (see [RFC6838]), many media 147 types do not have fragment identification methods associated with 148 them. 150 Fragment identifiers are only useful if supported by the client, 151 because they are only interpreted by the client. Therefore, a new 152 fragment identification method will require some time to be adopted 153 by clients, and older clients will not support it. However, because 154 the URI still works even if the fragment identifier is not supported 155 (the resource is retrieved, but the fragment identifier is not 156 interpreted), rapid adoption is not highly critical to ensure the 157 success of a new fragment identification method. 159 1.2.2. Use Cases 161 Fragment identifiers for text/csv as defined in this memo make it 162 possible to refer to specific parts of a text/csv MIME entity. Use 163 cases include, but are not limited to, selecting a part for visual 164 rendering, stream processing, making assertions about a certain value 165 (provenance, confidence, comments, etc.), or data integration. 167 1.3. Incremental Deployment 169 As long as text/csv fragment identifiers are not supported 170 universally, it is important to consider the implications of 171 incremental deployment. Clients (for example, Web browsers) not 172 supporting the text/csv fragment identifier described in this memo 173 will work with URI references to text/csv MIME entities, but they 174 will fail to understand the identification of the sub-resource 175 specified by the fragment identifier, and thus will behave as if the 176 complete resource was referenced. This is a reasonable fallback 177 behavior, and in general users should take into account the 178 possibility that a program interpreting a given URI will fail to 179 interpret the fragment identifier part. Since fragment identifier 180 evaluation is local to the client (and happens after retrieving the 181 MIME entity), there is no reliable way for a server to determine 182 whether a requesting client is using a URI containing a fragment 183 identifier. 185 1.4. Notation Used in this Memo 187 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 188 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in RFC 190 2119 [RFC2119]. 192 2. Fragment Identification Methods 194 This memo specifies fragment identification using following methods: 195 "row" for row selections, "col" for columns selections, and "cell" 196 for cell selections. 198 Throughout the sections below, the following example table in CSV 199 (having 7 rows, including one header row, and 3 columns) is used: 200 date,temperature,place 201 2011-01-01,1,Galway 202 2011-01-02,-1,Galway 203 2011-01-03,0,Galway 204 2011-01-01,6,Berkeley 205 2011-01-02,8,Berkeley 206 2011-01-03,5,Berkeley 208 2.1. Row-based selection 210 To select a specific record, the "row" scheme followed by a single 211 number is used (the first row is at position 1). 212 http://example.com/data.csv#row=4 214 The above CSV fragment identifies the fourth row: 215 2011-01-03,0,Galway 217 Fragments can also select ranges of rows: 218 http://example.com/data.csv#row=5-7 220 The above CSV fragment identifies three consecutive rows: 221 2011-01-01,6,Berkeley 222 2011-01-02,8,Berkeley 223 2011-01-03,5,Berkeley 225 The value "*" can be used to indicate the last row, so the previous 226 URI is equivalent to: 227 http://example.com/data.csv#row=5-* 229 2.2. Column-based selection 231 To select values from a certain column, the "col" scheme is used, 232 followed by a position (the first column is at position 1): 233 http://example.com/data.csv#col=2 235 The above CSV fragment addresses the second column, identifying the 236 column: 238 temperature 239 1 240 -1 241 0 242 6 243 8 244 5 246 The "col" scheme can also be used to identify ranges of columns: 247 http://example.com/data.csv#col=1-2 249 The above CSV fragment addresses the first and second column: 250 date,temperature 251 2011-01-01,1 252 2011-01-02,-1 253 2011-01-03,0 254 2011-01-01,6 255 2011-01-02,8 256 2011-01-03,5 258 As for rows, the value "*" can be used to indicate the last column. 260 2.3. Cell-based selection 262 To select particular fields, the "cell" scheme is used, followed by a 263 row number, a comma, and a column number. 264 http://example.com/data.csv#cell=4,1 266 The above CSV fragment addresses the field in the first column within 267 the fourth row, yielding: 268 2011-01-03 270 It is also possible to select cell-based fragments that have more 271 than just one cell, in which case the cell selection uses the same 272 range syntax as for row and column range selections. For these 273 selections, the syntax uses the upper-lefthand cell as the starting 274 point of the selection, followed by a minus sign, and then the lower- 275 righthand cell as the end point of the selection. 276 http://example.com/data.csv#cell=4,1-6,2 278 The above CSV fragment selects a region that starts at the fourth row 279 and the first column, and ends at the sixth row and the second 280 column: 281 2011-01-03,0 282 2011-01-01,6 283 2011-01-02,8 285 2.4. Multi-Selections 287 Row, column, and cell selections can make more than one selection, in 288 which case the individual selections are separated by semicolons. In 289 these cases, the resulting fragment may be a disjoint fragment, such 290 as the selection "#row=3;6" for the example CSV, which would select 291 the third and the sixth row. It is up to the user agent to decide 292 how to handle disjoint fragments, but since they are allowed, user 293 agents should be prepared to handle disjoint fragments. 295 3. Fragment Identification Syntax 297 The syntax for the text/csv fragment identifiers is as follows. 299 The following syntax definition uses ABNF as defined in RFC 4234 300 [RFC4234], including the rule DIGIT. 302 NOTE: In the descriptions that follow, specified text values MUST be 303 used exactly as given, using exactly the indicated lower-case 304 letters. In this respect, the ABNF usage differs from [RFC4234]. 306 csv-fragment = rowsel / colsel / cellsel 307 rowsel = "row=" singlespec 0*( ";" singlespec) 308 colsel = "col=" singlespec 0*( ";" singlespec) 309 cellsel = "cell=" cellspec 0*( ";" cellspec) 310 singlespec = position [ "-" position ] 311 cellspec = cellrow "," cellcol [ "-" cellrow "," cellcol ] 312 cellrow = position 313 cellcol = position 314 position = number / "*" 315 number = 1*( DIGIT ) 317 4. Fragment Identifier Processing 319 Applications implementing support for the mechanism described in this 320 memo MUST behave as described in the following sections. 322 4.1. Syntax Errors in Fragment Identifiers 324 If a fragment identifier contains a syntax error (i.e., does not 325 conform to the syntax specified in Section 3), then it MUST be 326 ignored by clients. Clients MUST NOT make any attempt to correct or 327 guess fragment identifiers. Syntax errors MAY be reported by 328 clients. 330 4.2. Semantics of Fragment Identifiers 332 Rows and columns in CSV are counted from one. Positions thus refer 333 to the rows and columns starting from position 1, which identifies 334 the first row or column of a CSV. The special character "*" can be 335 used to refer to the last row or column of a CSV, thus allowing 336 fragment identifiers to easily identify ranges that extend to the 337 last row or column. 339 If single selections refer to non-existing rows or columns (i.e., 340 beyond the size of of the CSV), they MUST be ignored. 342 If ranges extend beyond the size of the CSV (by extending to rows or 343 columns beyond the size of the CSV), they MUST be interpreted to only 344 extend to the actual size of the CSV. 346 If selections of ranges of rows or columns or selections of cell 347 ranges are specified in a way so that they select "inversely" (i.e., 348 "#row=10-5" or "#cell=10,10-5,5"), they MUST be ignored. 350 Each specification of an identified region is processed 351 independently, and ignored specifications (because of reason listed 352 in the previous paragraphs) do not cause the whole fragment 353 identifier to fail, they just mean that this single specification is 354 ignored. For the example file, the fragment identifier "#row=1-2;5- 355 4;13-16" does identify the first two rows: the second specification 356 is an "inverse" specification and thus is ignored, and the third 357 specification targets rows beyond the actual size of the CSV and thus 358 is also ignored. 360 The complete fragment identifier identifies all the successfully 361 evaluated identified parts as a single identified fragment. This 362 fragment can be disjoint because of multiple selections. Multiple 363 selections also can result in overlapping individual parts, and it is 364 up to the user agent how to process such a fragment, and whether the 365 individual parts are still made accessible (i.e., visualized in 366 visual user agents), or are presented as one unit. For example, the 367 fragment identifier "#row=3-6;4-5" contains a second identified part 368 that is completely contained in the first identified part. Whether a 369 user agent maintains this selection as two parts, or simply signals 370 that the identified fragment spans from the third to the sixth row, 371 is up for the user agent to decide. 373 5. IANA Considerations 375 Note to RFC Editor: Please change this section to read as follows 376 after the IANA action has been completed: "IANA has added a reference 377 to this specification in the text/csv Media Type registration." 379 IANA is requested to update the registration of the MIME Media type 380 text/csv at http://www.iana.org/assignments/media-types/text/ with 381 the fragment identifier defined in this memo by adding a reference to 382 this memo (with the appropriate RFC number once it is known). 384 5.1. The text/csv media type 386 The Internet media type [RFC6838] for a CSV document is text/csv. 387 The following registration has been copied from the original 388 registration of text/csv [RFC4180], with the exception of the added 389 fragment identification considerations, and added security 390 considerations for fragment identifiers. 392 Type name: text 394 Subtype name: csv 396 Required parameters: none 398 Optional parameters: charset, header 400 The "charset" parameter specifies the charset employed by the 401 CSV content. In accordance with RFC 6657 [RFC6657], the 402 charset parameter SHOULD be used, and if it is not present, 403 UTF-8 SHOULD be assumed as the default (this implies that US- 404 ASCII CSV will work, even when not specifying the "charset" 405 parameter). Any charset defined by IANA for the "text" tree 406 may be used in conjunction with the "charset" parameter. 408 The "header" parameter indicates the presence or absence of the 409 header line. Valid values are "present" or "absent". 410 Implementors choosing not to use this parameter must make their 411 own decisions as to whether the header line is present or 412 absent. 414 Encoding considerations: CSV MIME entities consist of binary data 415 [RFC6838]. As per section 4.1.1. of RFC 2046 [RFC2046], this 416 media type uses CRLF to denote line breaks. However, implementers 417 should be aware that some implementations may use other values. 419 Security considerations: 421 Text/csv consists of nothing but passive text data that should 422 not pose any direct risks. However, it is possible that 423 malicious data may be included in order to exploit buffer 424 overruns or other bugs in the program processing the text/csv 425 data. 427 The text/csv format provides no confidentiality or integrity 428 protection, so if such protections are needed they must be 429 supplied externally. 431 The fact that software implementing fragment identifiers for 432 CSV and software not implementing them differs in behavior, and 433 the fact that different software may show documents or 434 fragments to users in different ways, can lead to 435 misunderstandings on the part of users. Such misunderstandings 436 might be exploited in a way similar to spoofing or phishing. 438 Implementers and users of fragment identifiers for CSV text 439 should also be aware of the security considerations in RFC 3986 440 [RFC3986] and RFC 3987 [RFC3987]. 442 Interoperability considerations: Due to lack of a single 443 specification, there are considerable differences among 444 implementations. Implementers should "be conservative in what you 445 do, be liberal in what you accept from others" (RFC 793 [RFC0793]) 446 when processing CSV files. An attempt at a common definition can 447 be found in Section 2. Implementations deciding not to use the 448 optional "header" parameter must make their own decision as to 449 whether the header is absent or present. 451 Published specification: While numerous private specifications exist 452 for various programs and systems, there is no single "master" 453 specification for this format. An attempt at a common definition 454 can be found in Section 2 of RFC 4180 [RFC4180]. 456 Applications that use this media type: Spreadsheet programs and 457 various data conversion utilities. 459 Fragment identifier considerations: Fragment identification for 460 text/csv is supported by using fragment identifiers as specified 461 by RFC XXXX (Note to RFC Editor: Please update with RFC number 462 once it is known). 464 Additional information: 466 Magic number(s): none 468 File extension(s): CSV 469 Macintosh file type code(s): TEXT 471 Person & email address to contact for further information: Yakov 472 Shafranovich and Erik Wilde 474 Intended usage: COMMON 476 Restrictions on usage: none 478 Author: Yakov Shafranovich and Erik Wilde 479 481 Change controller: IESG 483 6. Security Considerations 485 The security considerations for text/csv fragment identifiers are 486 listed in the respective section of the media type registration 487 Section 5.1. 489 7. Change Log 491 Note to RFC Editor: Please remove this section before publication. 493 7.1. From -07 to -08 495 o Added IESG approval note. 497 o Removed "Implementation Status" section. 499 7.2. From -06 to -07 501 o Changing "charset" parameter to "SHOULD be used" and UTF-8 as 502 default value. 504 o Changing encoding to be binary. 506 7.3. From -05 to -06 508 o Adding complete media type registration by copying and editing the 509 registration from RFC 4180. 511 o Moving "Security Considerations" text to media type registration. 513 7.4. From -04 to -05 515 o Updating "Implementation Status" section to refer to RFC 6982 516 [RFC6982]. 518 o Switching to 520 7.5. From -03 to -04 522 o Switched category from "std" to "info". 524 o Changed the definition of positions to start counting from 1 525 instead of 0. 527 7.6. From -02 to -03 529 o Added "Implementation Status" section. 531 o Added examples of ranges of rows and columns. 533 o Corrected errors in examples. 535 7.7. From -01 to -02 537 o Removed slices ("#where:") as fragment identification method. 539 o Removed any special support for headers, which means that they are 540 now treated as a regular (the first) row (if a header row is 541 present). 543 o Changed semantics and syntax to allow multiple selection of rows, 544 columns, and cells, and to allow ranges of rows and columns. 546 7.8. From -00 to -01 548 o Added cell-based selections. 550 o Added Jeni Tennison as author; updated Erik Wilde's affiliation to 551 EMC. 553 8. References 555 8.1. Normative References 557 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 558 Extensions (MIME) Part One: Format of Internet Message 559 Bodies", RFC 2045, November 1996. 561 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 562 Extensions (MIME) Part Two: Media Types", RFC 2046, 563 November 1996. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", RFC 2119, March 1997. 568 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 569 Resource Identifier (URI): Generic Syntax", RFC 3986, 570 January 2005. 572 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 573 Identifiers (IRI)", RFC 3987, January 2005. 575 [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- 576 Separated Values (CSV) Files", RFC 4180, October 2005. 578 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 579 Specifications: ABNF", RFC 4234, October 2005. 581 [RFC6657] Melnikov, A. and J. Reschke, "Update to MIME regarding 582 "charset" Parameter Handling in Textual Media Types", 583 RFC 6657, July 2012. 585 8.2. Non-Normative References 587 [ASCII] ANSI X3.4-1986, "Coded Character Set - 7-Bit American 588 National Standard Code for Information Interchange", 589 STD 63, RFC 3629, 1992. 591 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 592 RFC 793, September 1981. 594 [RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the 595 text/plain Media Type", RFC 5147, April 2008. 597 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 598 Specifications and Registration Procedures", BCP 13, 599 RFC 6838, January 2013. 601 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 602 Code: The Implementation Status Section", RFC 6982, 603 July 2013. 605 URIs 607 [1] 609 [2] 611 Appendix A. Acknowledgements 613 Thanks for comments and suggestions provided by Nevil Brownlee, 614 Richard Cyganiak, Ian Davis, Gannon Dick, Leigh Dodds, and Barry 615 Leiba. 617 Authors' Addresses 619 Michael Hausenblas 620 DERI, NUI Galway 621 IDA Business Park 622 Galway 623 Ireland 625 Phone: +353-91-495730 626 Email: michael.hausenblas@deri.org 627 URI: http://sw-app.org/about.html 629 Erik Wilde 630 EMC Corporation 631 6801 Koll Center Parkway 632 Pleasanton, CA 94566 633 U.S.A. 635 Phone: +1-925-6006244 636 Email: erik.wilde@emc.com 637 URI: http://dret.net/netdret/ 639 Jeni Tennison 640 Open Data Institute 641 65 Clifton Street 642 London EC2A 4JE 643 U.K. 645 Phone: +44-797-4420482 646 Email: jeni@jenitennison.com 647 URI: http://www.jenitennison.com/blog/