Re: Gen-ART LC review of draft-faltstrom-5892bis-04
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 paul.hoff...@vpnc.org mailto:paul.hoff...@vpnc.org 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
Paul Hoffman 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. That was my impression as well when I reviewed RFC 5982 while on IESG. 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. 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. 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
+1 --On Wednesday, June 08, 2011 12:50 +0100 Alexey Melnikov alexey.melni...@isode.com 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Contents of the IDNA Derived Properties registry (was; Re: Gen-ART LC review of draft-faltstrom-5892bis-04)
(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.hoff...@vpnc.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Contents of the IDNA Derived Properties registry (was; Re: Gen-ART LC review of draft-faltstrom-5892bis-04)
The discussion make it clear to me that the tasks for IANA are not clear. It seems that there needs to be a table for each supported version of Unicode. Thats document should state that clearly. It is a point where RFC 5892 seems to be vague, and we should take this opportunity to remove the ambiguity. This document or a future one needs to answer the following question: Who is responsible for generating a new table when the next version of Unicode comes out? Russ On Jun 8, 2011, at 8:32 AM, John C Klensin wrote: (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). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
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 paul.hoff...@vpnc.org 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-faltstrom-5892bis-04
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:paul.hoff...@vpnc.org] Sent: Tuesday, June 07, 2011 1:13 AM To: Roni Even Cc: draft-faltstrom-5892bis@tools.ietf.org; gen-...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-faltstrom-5892bis-04 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 __ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
On Jun 7, 2011, at 3:56 AM, rontlv wrote: 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. 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART LC review of draft-faltstrom-5892bis-04
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 -Original Message- From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] Sent: Tuesday, June 07, 2011 7:39 PM To: rontlv Cc: draft-faltstrom-5892bis@tools.ietf.org; gen-...@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-faltstrom-5892bis-04 On Jun 7, 2011, at 3:56 AM, rontlv wrote: 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. 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. 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. 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 __ Information from ESET NOD32 Antivirus, version of virus signature database 6186 (20110607) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6188 (20110607) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
On Jun 7, 2011, at 3:56 AM, rontlv wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
--On Tuesday, June 07, 2011 14:43 -0700 Paul Hoffman paul.hoff...@vpnc.org 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 theversions 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 toRFC 5892 and property values as defined in The Unicode Standardversion 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 toRFC 5892 and property values as defined in The Unicode Standardversion 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC review of draft-faltstrom-5892bis-04
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
