I wanted to close the loop on this discussion before clicking "go" on things. I've heard general support for moving forward with the registration change, adding the fragment identifier to the existing text/csv registration. There have been a few issues raised, primarily these: 1. This might not be the best way to do CSV fragments, and registering this one could get in the way of other, perhaps arguably better, proposals. 2. A better approach might be to create a new media type, such as "text/csv-with-fragments". 3. The "slippery slope" argument: if we allow such a change here, others could try to do similar things with insufficient IETF review and expect similar treatment. ...and, related to that last... 4. This should have been done (and still can be) through the IETF stream. While there wasn't broad support for any of these points, they are all fair concerns to address. Point 4 first: The authors did bring this to the IETF stream, and, as now, there was no objection to the proposal... but no interest in working on it. That was why I sent the authors to the ISE at the time. I see no change in the energy level, and I think the document has received at least as much review in its progress through the Independent stream as it would have had, had we done it in the IETF. On point 3, the IESG operates with due consideration of the technology and the situation, and is generally firm in saying "no" to assumptions that everything be treated equally when the things are not, in fact, equal. There's no reason to believe that a cockamamie idea would get ushered through in some sort of of "fairness" move, just because this one -- which is widely thought to be sane and safe -- was. On point 2, creating a new media type for this would, I think, be a very bad approach, and arguably violates the sense of media subtypes. This proposal is in no way creating a new media subtype, which would be processed in a different way to text/csv. It's only adding a way to point to a portion within a text/csv block. It fits as a fragment identifier within the existing media type, and a processor that understands text/csv and doesn't understand the fragment would treat one of these things as text/csv, which is exactly what we want. A processor that understands text/csv and not text/csv-with-fragments would treat it as text/plain -- not what we want. Finally, to point 1, while it's true that other have other thoughts on how to do fragments in text/csv, the mechanism proposed here is nicely extensible. It uses "row=" and "col=" as tags, allowing other tags to handle other situations as may be proposed in the future. The extensibility mitigates (or eliminates) any harm, by not locking us into any one idea of how CSV fragments should work. I should also note that we have contacted W3C about this, and have received no objection from them. At the moment, the designated expert for media-types still has some comments about the registration particulars, which will be worked out among IANA, the authors, and the ISE. While that proceeds, I am going to proceed with giving the IESG's approval to make the change to the registration. Barry, Applications AD