--On Tuesday, October 15, 2013 09:31 -0400 Barry Leiba
<barryleiba(_at_)computer(_dot_)org> wrote:
In a slightly broader interpretation of that question, I
believe that having Independent (or even IAB) stream
documents modify registrations that are required, either by
the registration procedure or the registration itself, to be
under IETF change control is a bad idea. If we don't like
that constrain, we should modify the registration, not
conduct odd Last Calls. I would strongly support processing
this document in the IETF Stream as an individual submission
(and, while that slips over into the substantive part,
approving it for publication and modification of the
registration on that basis).
I understand your comment about precedent. To that, I'll note
that RFC 6838 says this in Section 3.1, related to Standards
Tree registrations:
Registrations published in non-IETF RFC streams are also
allowed and require IESG approval.
That is, it explicitly allows Independent stream documents to
register in the Standards Tree. It would seem odd to at the
same time forbid them from modifying registrations (with, of
course, the same IESG approval).
Yeah, I know. I am somewhat acquainted with the authors.
We probably need to agree to disagree on this, but I don't see
the distinction as odd at all. The text/* namespace is
essentially unlimited. If someone wants to create a new one,
the key issue is whether it is fundamentally harmful in some
way, even if it is ignored in the marketplace. "Standards Tree"
implies some level of endorsement, but not very much, and the
ISE process is (we hope) pretty good at determining whether a
document is competent as a document. The bar for such new
registrations should be reasonably low and, a snit or two about
parameter relationships (like "charset=") generally has been.
But a parameter-adding modification is different. It should be
evaluated for whether or not it could have bad effects on
existing uses of the registration or in combination with other
parameters. As an example for this particular case and drawing
on my long-ago experience with data format conversion systems,
some systems that convert CSV files to matrix (or ER)form use
named columns, either inventing names or taking them from the
first line of the CSV file (for this case, "text/csv;
header=present"). For some of those systems, the separation
occurs right after the data are received or as they are
streaming in, so processing of a fragment with row selection
using this approach requires that one preserve the information
needed to decrement row numbers in the fragment specification.
That example is actually about two things: a comment to the ISE
that the draft needs to have an explicit discussion about
interactions between row numbers and headers (or at least a
Security Considerations warning) and a comment to the IESG about
the dangers of this type of registration modification.
Other interactions with other registration extensions could be
much more serious. I note, without recommending it, that a new
registration for text/csv-with-fragments that recommended the
gradual retirement of text/csv would have none of these problems
and, if successful, would have the potential to eliminate many
of the issues with different CSV interpretations that are noted
in both this spec and RFC 4180 itself. I don't know that would
be an especially good idea, but it would eliminate the multiple
issues raised by modifying an existing spec.
Also, this document was offered to the IETF community, and the
community was not interested in taking it up. But there's a
need for it in some circles, and we've seen no expression of
objection. That's why I sent the authors to the ISE back in
May. I think this document is a good example of what the
Independent stream is for, and I think that RFC 6838 allows us
to approve these sorts of things case by case.
At the risk of hair-splitting, Section 3.1 of RFC 6838 is
entirely about new registrations. Section 5.5 is applicable in
this case. First, if the IESG, as the representative of the
relevant standards body, is assumed to be the "owner" of RFC
4180 and the existing registration, then the IESG needs to take
responsibility for the evaluation discussed above. If Yakov
Shafranovich is the owner as author of 4180, then he has a
significant voice in any decision here. More important,
Section 5.5 says
"Significant changes to a media type's definition should
be requested only when there are serious omissions or
errors in the published specification."
Presumably this is a "significant change". Whether the absence
of fragments is a "serious omission" or not is debatable and we
have heard little debate on the subject. Again, this would be
a much more comfortable situation if the document were handed as
an individual submission in the IETF Stream (on which the
community could give advice during Last Call that had to be
considered) rather than as an independent submission (on which
the community could give advice and hope the authors are
interested).
As to precedent, if another document should come along and do a
similar thing, we would do a similar analysis and have a
similar discussion. If that one should garner significant
objections, its path would be different.
Again, I agree with your analysis for new registrations. What
is giving me pause is the notion of modifying an existing one to
add features.
p.s. W3C is circulating a draft charter for a WG that might
affect CSV on the web. Because having a hard-to-change
Informational RFC and IANA registration that was inconsistent
with W3C recommendations would be a generally bad idea, some
coordination may be in order, especially to verify that the
current draft is not an end run around W3C efforts.
Thanks for bringing that up. I'll be sure to send this to the
liaisons, and make sure we're not interfering with their plans
for text/csv.
If the IETF is uninterested in text/csv (as you imply above) and
W3C is interested (the media type is apparently intertwined
with their "web data" and "semantic web" efforts), another
possibility would be for the IESG to take the action described
in the last paragraph of Section 5.4 of RFC 6838, reassign
responsibility for text/csv to W3C (which I assume is a
"recognized standards-related organization") and let them sort
it out. That would presumably even allow replacement of RFC
4180 with a reference to a stable W3C spec.
That solution would, of course, not automatically generalize to
other cases.
best,
john