--On Tuesday, October 15, 2013 09:31 -0400 Barry Leiba <barryleiba@xxxxxxxxxxxx> 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