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