(Subject line changed to reflect my belief that this is not about 5892bis. I've also removed the copy to the gen-art list -- if this isn't about 5892bis, it isn't on their agenda, even though Roni's review may have partially stimulated the thread.) --On Tuesday, June 07, 2011 19:45 -0700 Paul Hoffman <paul.hoffman@xxxxxxxx> wrote: >> Anyway, your comments above about "most current version" imply >> to me that IANA should keep derived property tables for the >> most current version only. My expectation when 5982 was >> completed was that IANA was expected to keep derived property >... > While your interpretation could be one thing we might have > meant, it is not what is reflected in the RFC or the registry. > RFC 5892 says: >... > Note that every reference to the registry is singular. Also, > the registry at > <http://www.iana.org/assignments/idnabis-tables/idnabis-tables > .xml> doesn't mention "5.2" at all. > > If the registry definition does not talk about keeping > versions, and the registry itself doesn't look like it tried, > it may be implausible to think that IANA would just start to > do so in some future. To me, "a registry" means a single > registry. Paul, Just to be completely clear about the intent of my comment, while I'm disinclined to split hairs about whether "registry" (singular) could mean a collection of tables, I completely agree that, if such a historically-threaded collection were desired, it should have been crystal-clear in 5892. And it is not crystal-clear. I think this raises three issues: (1) Whether a historical thread is kept or not, having a registry of derived property values that does not identify which version of Unicode it reflects is of poor utility and a possible source of confusion. If I don't know to what version of Unicode the registry has been updated, I cannot comply with the IDNA requirement that, if I use derived property tables (rather than recalculating based on the rule set), those be consistent with the version of Unicode on my system (the level of difficulty associated with that rule has been discussed on this thread already; let's not revisit it). One can, of course, figure it out by comparing the code points listed as UNASSIGNED with changes in successive Unicode versions, but it seems to me to be much more useful to include Unicode version identification in the registry. I believe that is fully consistent with your reading of 5892. (2) Whether a collection of derived property tables, explicitly tied to versions of Unicode, is useful. Vint has already asked that question and gotten a couple of affirmative answers. Others might disagree, but it seems to me that we need to arrive at a conclusion somehow. (3) If we conclude that it is useful to identify the Unicode version under which a derived property table was compiled and/or to keep a historical thread of tables, how do we get from "here" (one table, no Unicode version identification) to "there". My personal preference, strongly motivated by the amount of energy that has been consumed by the non-change in 5892bis, would be for the IESG to simply request that IANA make those changes; doing so is, IMO, clearly within their authority. If a separate document is needed, I guess I volunteer to write a short I-D. In any event and as suggested above, I don't see any changes in this area as appropriately being part of 5892bis. Tuning what IANA should be keeping in the registry and how it should be identified is not a topic that 5892bis addresses at all. Moreover, if we do need an RFC to make any changes that are desired, that RFC actually would update a standards-track RFC and would hence itself need to be standards-track. Different critter. So I suggest that: (i) We get 5892bis wrapped up and published. It says pretty much what it should say, it doesn't change the basic specification, and even those who don't like the decisions it represents appear to believe that we have spent enough time on it and that continued delay is problematic. (ii) The relevant ADs consider whether a document clarifying the registry content and/or identification information is needed and consult with IANA on that topic as appropriate. If the answer is "yes", let's get that document posted and start debating what changes, if any, should be made using it as a foundation (rather than finding new weeds to drag 5892bis into). john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf