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

[John C Klensin <[e-mail]>]

--On Tuesday, June 07, 2011 14:43 -0700 Paul Hoffman
<[e-mail]> wrote:

>> 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)
> version 5.2.   

> 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.

Paul,

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.

     john