On 8 Aug 2019, at 4:52, John C Klensin wrote: > 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. The tables are also a bit confusing for even "insiders". People do not understand what "non-normative" means. I am though as John said of the view that the IANA tables help, as I have seen people doing everything from copying them (and ask why not new ones exists) to diff the output from their tools with what IANA has. Now with the new view that the derived property values should be fixed, and the algorithm change, I think the tables will be somewhere (the non-normative ones) and why not at IANA. > 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. Agree as you know. > 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. This is one of my evidence that people do not get what non-normative means. Even IAB members felt the IANA tables where extremely important. I do think I misunderstood what the real issue was and....ultimately it did get the ball rolling again :-) So if there was a misunderstanding, it was a good one :-D > 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. Agree. > 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. As long as we have the excellent staff at IANA we have, I do not see any difference between a pull request and IANA doing the updates when needed. I do not want a wikipedia war. To conclude, as long as we do not really know what the non-normative tables are used for, I rather have control over them than letting them completely loose, as I have no idea what could happen with them. Patrik
Attachment:
signature.asc
Description: OpenPGP digital signature
