--On Tuesday, June 07, 2011 14:43 -0700 Paul Hoffman
Section 5.1 of RFC5892 says "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." . My question was if the change is backward
compatible. The 5892bis draft does not say it.
Ah, very good catch! My earlier comment about us listing this
new RFC in the registry is, in fact, wrong.
When we wrote RFC 5892, we said:
IANA has created a registry with the derived properties for
the versions of Unicode released after (and including)
That's one registry that has the properties for
most current version of Unicode at any given time. Thus, the
registry would be updated *even if* we didn't publish 5892bis.
We are not updating either 5892, nor the registry, by
publishing 5892bis. We are simply giving IETF consensus advice
about what we think the expert reviewer who updates the
registry should consider.
Our IANA considerations in 5892bis are:
IANA is to update the derived property value registry
according to RFC 5892 and property values as defined in The
Unicode Standard version 6.0.
That might sound like they are initiating the registry update,
but they really aren't: the update was already specified in
5892. We can change the IANA considerations to reflect that:
IANA will update the derived property value registry according
to RFC 5892 and property values as defined in The Unicode
Standard version 6.0, regardless of the content of this RFC.
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.
Ietf mailing list