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

[Paul Hoffman]

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

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

[rontlv]

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

[Paul Hoffman]

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

[rontlv]

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

[Paul Hoffman]

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

[John C Klensin]

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

[Paul Hoffman]

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

[Alexey Melnikov]

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

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

[Alexey Melnikov]

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

[John C Klensin]

+1

--On Wednesday, June 08, 2011 12:50 +0100 Alexey Melnikov
 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

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

[Vint Cerf]

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

Contents of the IDNA Derived Properties registry (was; Re: Gen-ART LC review of draft-faltstrom-5892bis-04)

[John C Klensin]

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

[Russ Housley]

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