My one suggestion would be in sections 5 and 8 to tell IANA to remove the non-normative tables since you'll persuade people that not all IANA content is non-normative about the same time that you persuade people that not all RFCs are standards. Instead perhaps say that you hope to find workable ways to publish tools to create the tables that people can use as Unicode comes out with version 12.<n+1>. Then hand that over to the ongoing Github flame war since Github is the obvious place to put them. ...
Thanks for the background. It was a suggestion, and if it would involve reopening old arguments I agree it's probably better to let sleeping dogs lie.
This isn't the only situation where we have stuff that is authoritative but not normative and I certainly don't want to wait until that particular ocean is boiled.
R's, John
This was discussed during the period in which draft-faltstrom-unicode11 was being developed and refined and again when we were putting together this I-D, more or less as a summary of those discussions. My personal position on it is out toward the radical end of the spectrum of opinions, that is, I'd rather see the IANA tables gone. Patrik can speak for himself (copying him in case he is not following the IETF list these days), but he has been more inclined to leave the IANA tables there an attach disclaimers. Possibly some of his reasons align with mine below. Despite my belief that the IANA tables have created confusion and done more harm than good, I'm convinced that we should transition out of them rather than dropping them abruptly. First, while your analogy is interesting, I'm not sure that the set of people who believe that all RFCs are standards and who have not been deliberately misled is large enough to worry about. If you want to include the group that has been deliberately misled, then the evidence of people who have been convinced that I-Ds are standards (or other authoritative IETF documents) suggests that we could have the same problem with a repository somewhere else. Second, the thing that propelled draft-faltstrom-unicode11 and then draft-faltstrom-unicode12 and the associated version was the IAB's conclusion that the tables were important enough to give instructions to the Designated Expert to get those tables out and essentially that they were important enough to ignoring some outstanding issues. I think we are better off moving forward than reopening those questions, and the way forward probably involves keeping the current versions of the tables and improving the descriptions of what they are rather than having the IETF repudiate those IAB decisions. A different way to say almost the same thing is that the actions associated with draft-faltstrom-unicode11/12 involve an assumption of IETF consensus the publish the tables with IANA. Reversing that decision is likely to be controversial enough that it would be better to just keep moving forward rather than revising the recommendations in a new version of this document, trying to resolve that controversy, and presumably going through a second Last Call. To me, I think there would need to be a rather strong case for immediately removing those registries to justify that amount of delay and level of effort. I don't believe your suggestion above makes that case. As to github repositories with the tables, I have to admit having given up on trying to follow what you describe as a flame war, but I'd think that having the IETF start putting things into github that are formally considered authoritative, even if not normative, would put an entirely different spin on that set of arguments. best, john
Regards, John Levine, johnl@xxxxxxxxx, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly