Summary

  • RFC 4180 in October 2005 documented a common CSV format and registered text/csv. It was an Informational RFC, acknowledged differences among implementations and left the presence of a header row to an optional media-type parameter.
  • RFC 7111 in January 2014 added fragment identifiers for a text/csv resource: #row=4, #col=2 or #cell=4,1 select by one-based position. A client without support still retrieves the complete file. The server cannot reliably tell whether the request used a fragment.
  • Position is not record identity. Insert a row above the fourth row and the same #row=4 selects whatever now occupies that position. A valid link can therefore point to a different fact without changing its URL.

A dataset gets a precise-looking address

Imagine a public CSV file listing a sequence of decisions. An analyst wants to cite the entry in its fourth row. A link to the whole file forces every reader to open it, count rows and find the claim. A link ending in #row=4 promises to do that work. It looks like an address for the fact, as tidy as a footnote and easier to copy.

The promise became expressible in RFC 7111, published in January 2014. It defined URI fragments for CSV resources: row for rows, col for columns and cell for fields at the intersection. Its example data.csv#row=4 identifies the fourth row of the CSV. The example includes a header, so row one is the header and row four is the third data record. That detail is small enough to miss and large enough to send a citation to the wrong record.

There is an older story beneath that neat syntax. RFC 4180, published in October 2005, documented a common CSV format and registered the text/csv media type. Its introduction says CSV was already widely used and had never had a single formal description. The RFC gave conventions for records, commas, quotes and optional headers, while acknowledging differences among programs. It was Informational, a description of a working format rather than a decree that all spreadsheet software had suddenly agreed.

The optional header matters to a positional link. RFC 4180's registration offers a header parameter with present and absent values. If the publisher omits it, a reader's program must decide whether the first record names columns or contains data. RFC 7111 still counts physical rows from one. An assertion about “the fourth data entry” is therefore not automatically the same as #row=4. The publisher's file structure and media-type information help determine which record a human thinks the pointer names.

The number points to a place, not a person

RFC 7111 gave the pointer more range than a single row. #col=2 selects the second column. #cell=4,1 selects the first field in the fourth row. A dash can select a span, an asterisk can mean the final row or column, and a semicolon can name separate selections. A reader of a CSV table could now link to a line, a field or a patch of cells using the same file address.

The convenience has a strict limit. These selectors describe positions in the representation the client receives. They do not contain a record key, a field name, a hash of the expected value or a date of the version that made the citation true. The RFC's syntax tells a client where to look within a table. It does not tell the client whether the row it found is the row the author intended months earlier.

Take a file whose fourth row says a decision was approved. A publisher later inserts a new record above it, perhaps to correct the chronology. The old fourth row becomes the fifth. The URL ending in #row=4 has not broken: it still names a row that exists, and a conforming client can highlight it. But the highlighted row now says something else. This is the nastiest kind of reference drift. The link can be syntactically healthy and factually wrong.

Removing a row above the target has the same structure in reverse. Reordering a file can move many records while leaving every positional selector well-formed. Even a column edit can shift a cell reference away from its original field. A citation tied to order inherits the publisher's future editing choices. The URL's permanence says little about the record's permanence.

This follows directly from RFC 7111's one-based counting rule. It is a mechanism, not a claim that a named publisher caused a particular incident. A dated file version and its later revision would show an actual moved citation. The standard itself supplies the reason such a move can happen.

The server hands over the whole sheet

Who is responsible for interpreting #row=4? RFC 3986's URI syntax, published in January 2005, treats a fragment as a client-side indirect reference. The fragment is separated before the underlying resource is retrieved. Its meaning depends on the media type returned, and the user's program resolves the selected part. RFC 7111 applies that general design to text/csv.

In the 2014 document, the consequence is explicit. A server has no reliable way to know whether the requesting client arrived with a CSV fragment. It serves the CSV resource. The client then decides whether it understands row, col or cell and what to display. The same file can arrive at two readers who clicked the same visible link; one sees a selected row, while a client without RFC 7111 support treats the reference as the whole file.

That division gives authors a useful power. A publisher need not create a separate server route for every line in a dataset. A reader can identify a portion of a file the publisher made available, and the choice travels in the link itself. The server cannot simply inspect a log of file requests and learn which row each reader meant to cite. The selector sits on the reader's side of the exchange.

It also limits what the link can prove. A server's successful response proves that it delivered a file, not that a particular row was shown, read or verified. A client that ignores the fragment can show the whole table without reporting a failed request. RFC 7111 itself warns that different presentation of a selected fragment and a whole CSV can create misunderstandings. A footnote that looks exquisitely specific in one viewer may be an ordinary file download in another.

The document's processing rules sharpen this point. A malformed fragment is ignored rather than guessed at. A selection beyond the last row is ignored; a range that runs past the end is cut back to the actual size. A client has rules for handling bad positions, but none of these rules verifies the historical identity of a good position. The fourth row can be present, legal and wrong for the claim attached to it.

A link that survives its own evidence

CSV made a strong candidate for web data exchange because it was plain, portable and already in widespread use. RFC 4180 put a recognizable media type around an unruly working format. RFC 7111 later let the web address a part of that format without asking every file publisher to build a database application. The two documents describe a very practical bargain: low ceremony for publication, convenient selection for readers.

The bill arrives when the file changes. For a casual reference, pointing to today's fourth row may be enough. For a claim that must remain auditable, position alone is a weak anchor. The publisher can preserve a dated version of the file, expose a durable record identifier through another surface, or make the record's key part of the citation. Those measures carry extra work. They also tell a future reader which fact was intended after the table is edited.

The standard's status should stay in view. RFC 7111 was an Informational Independent Submission, and the change to the text/csv registration received the required IESG approval. Its text defines how a supporting client can select a CSV fragment; it does not provide a census of supporting browsers or prove that public datasets adopted the syntax. Dated client implementation records would establish that deployment history.

The enduring lesson sits in a tiny symbol. The # after a CSV URL can turn an entire dataset into a reference to one place. It cannot freeze the content at that place. A citation to a row number gives the spreadsheet a street address; it does not give the resident a name.