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

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jun 2011 15:12:32 -0700

On May 29, 2011, at 4:13 AM, Roni Even wrote:

> Major issues:
> 
> 1.       I am not sure how the IANA consideration section is in-line with the IANA consideration section of RFC5892. Maybe some clarification text would be helpful.

We think that the IANA considerations here are, in fact, what RFC 5892 was designed for. That is, RFC 5892 says that the registry will be updated ("IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2"), and this is such an update. Please let me know if that doesn't match your understanding.

> 2.       The IANA registry for derived property value has RFC 5892, does this draft want to change the reference, how will it be done.

Section 2 of the draft is pretty clear here: "No change to RFC 5892 is needed based on the changes made in Unicode 6.0".

>   I think that it relates also to the issue of whether this draft updates RFC 5892.

And here too.

--Paul Hoffman

---

From: "rontlv" <[email-masked]>
Date: Tue, 7 Jun 2011 13:56:08 +0300

Hi Paul,

The IANA registry is in
http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml#idnabis-ta
bles-properties
I saw that in the beginning it has as reference RFC 5892 for the whole
table. Will it stay this way after the change proposed in this draft and
just the three individual values will change based on 1.1, 1.2 and 1.3? or
are there no changes in the IANA registry at all. This is unclear to me
according to the section 3 of your draft.

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.

Thanks
Roni

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Tuesday, June 07, 2011 1:13 AM
> To: Roni Even
> Cc: [email-masked]; [email-masked];
> 'IETF-Discussion list'
> Subject: Re: Gen-ART LC review of draft-faltstrom-5892bis-04
> 
> > 1.       I am not sure how the IANA consideration section is in-line
> with the IANA consideration section of RFC5892. Maybe some
> clarification text would be helpful.
> 
> We think that the IANA considerations here are, in fact, what RFC 5892
> was designed for. That is, RFC 5892 says that the registry will be
> updated ("IANA has created a registry with the derived properties for
> the versions of Unicode released after (and including) version 5.2"),
> and this is such an update. Please let me know if that doesn't match
> your understanding.
> 
> > 2.       The IANA registry for derived property value has RFC 5892,
> does this draft want to change the reference, how will it be done.
> 
> Section 2 of the draft is pretty clear here: "No change to RFC 5892 is
> needed based on the changes made in Unicode 6.0".
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 6185 (20110606) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6186 (20110607) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Jun 2011 09:38:47 -0700

> according to the section 3 of your draft.

The table will likely change, based on the input of the expert reviewer. I assume that a reference to this RFC-to-be would be added to the top of the table, next to "[RFC5892]". That is, this would be an additional reference, not a replacement. But that's up to IANA.

> change is backward compatible. The 5892bis draft does not say it.

The draft says:
   This imply the derived property value differs
   depending on whether the property definitions used are from Unicode
   5.2 or 6.0.
We intended that as "non-backwards-compatible"; we can change the wording to make that explicit.

--Paul Hoffman

---

From: "rontlv" <[email-masked]>
Date: Tue, 7 Jun 2011 22:30:40 +0300

Hi Paul,
My understanding that the new value does not replace the current one since
5892bis is not updating rfc5892. So should the IANA registry reflect that
you are not replacing the current value or is my understanding wrong
Roni Even

> Sent: Tuesday, June 07, 2011 7:39 PM
> To: rontlv
> The table will likely change, based on the input of the expert
> reviewer. I assume that a reference to this RFC-to-be would be added to
> the top of the table, next to "[RFC5892]". That is, this would be an
> additional reference, not a replacement. But that's up to IANA.
> 
> signature database 6186 (20110607) __________
> 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6188 (20110607) __________

http://www.eset.com

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Jun 2011 14:43:46 -0700

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jun 2011 21:24:15 -0400

--On Tuesday, June 07, 2011 14:43 -0700 Paul Hoffman
<[email-masked]> 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.
> 
>    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.
> 
>    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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Jun 2011 19:45:38 -0700

> maybe it was too obvious to some of us at the time to get the

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

---

From: Vint Cerf <[email-masked]>
Date: Wed, 8 Jun 2011 00:08:22 -0400

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 <[email-masked]> wrote:

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Jun 2011 12:50:09 +0100

Vint Cerf wrote:

> setting aside interpretation and semantics for a moment, would there 
> be utility in maintaining tables for each instance of Unicode?

Yes, because developers will have different versions of Unicode 
available to them. It would also help developers to migrate by seeing 
what has changed between versions.

> v
>
> On Tue, Jun 7, 2011 at 10:45 PM, Paul Hoffman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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>
>     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
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Jun 2011 12:55:08 +0100

>>maybe it was too obvious to some of us at the time to get the
That was my impression as well when I reviewed RFC 5982 while on IESG.

>Note that every reference to the registry is singular.
>
There is a single registry, but multiple versions of Unicode.

>Also, the registry at <http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml> doesn't mention "5.2" at all.
>
That might be an error created when the registry got setup by IANA.

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Jun 2011 07:56:11 -0400

+1

--On Wednesday, June 08, 2011 12:50 +0100 Alexey Melnikov
<[email-masked]> wrote:

> Vint Cerf wrote:
> 
>> setting aside interpretation and semantics for a moment,
>> would there  be utility in maintaining tables for each
>> instance of Unicode?
> 
> Yes, because developers will have different versions of
> Unicode available to them. It would also help developers to
> migrate by seeing what has changed between versions.