(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(_dot_)hoffman(_at_)vpnc(_dot_)org> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf