This draft's premise is interesting, but the implementation leaves to be desired. That is, I like the idea of fragment identifiers for CSV, but row/column/cell-based selection doesn't address my need. My need is based on the CSV files generated from IANA registries. Here's one: https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.csv Here's an excerpt: 2001:0200::/23,APNIC,1999-07-01,whois.apnic.net,ALLOCATED, 2001:0400::/23,ARIN,1999-07-01,whois.arin.net,ALLOCATED, 2001:0600::/23,RIPE NCC,1999-07-01,whois.ripe.net,ALLOCATED, In general, for IANA registries, what would be useful would be fragments pointing to a particular record or a set of records. It seems like row-based selection would accomplish that purpose, right? Well, yes, but not in a useful way, because the row *index* is used in the fragment. The problem is that when IANA inserts new records, all records that come after the new one are moved one row down, and the URL containing the fragment is no longer valid and needs to be updated. That's not cool. What we need is a fragment that points to the record without needing to be updated when new records are added. That is, I want to be able to say something like this: .../ipv6-unicast-address-assignments.csv#2001:0200::/23 I think this is an important use case, and I would like the draft to be updated to address it. Thanks, Simon