Re: [Gen-art] Gen-ART LC review of draft-faltstrom-5892bis-04

[Vint Cerf <[e-mail]>]

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 <[e-mail]> 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
>
>