setting aside interpretation and semantics for a moment, would there be utility in maintaining tables for each instance of Unicode?
v On Tue, Jun 7, 2011 at 10:45 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > On Jun 7, 2011, at 6:24 PM, John C Klensin wrote: > > > I think this is an improvement but there is one issue about > > which we have slightly different impressions. I hope the > > difference can be resolved without needing yet more tedious > > arguments about documentation. Indeed, if such arguments are > > required, I'd prefer that we just forget about it. > > > > 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 tables, > > clearly identified by version, for each and every Unicode > > version from 5.2 forward. In other words, the tables for the > > [most] current version would be added to, not replace, whatever > > previous version tables were around. The reasons for this, in > > terms of systems and implementations in various stages of > > development, implementation, and deployment, seem obvious... but > > maybe it was too obvious to some of us at the time to get the > > wording exactly right. > > 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: > > 5.1. IDNA-Derived Property Value Registry > > IANA has created a registry with the derived properties for the > versions of Unicode released after (and including) version 5.2. The > derived property value is to be calculated in cooperation with a > designated expert [RFC5226] according to the specifications in > Sections 2 and 3 and not by copying the non-normative table found in > Appendix B. > > If non-backward-compatible changes or other problems arise during the > creation or designated expert review of the table of derived property > values, they should be flagged for the IESG. Changes to the rules > (as specified in Sections 2 and 3), including BackwardCompatible > (Section 2.7) (a set that is at release of this document is empty) > require IETF Review, as described in RFC 5226 [RFC5226]. > > 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 Hoffman > >
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
