Dear all,
AD suggests that we send a last call summary to the list.
Below is the summary for IESG last call to 5892bis draft.
Any comments are welcome.
Jiankang Yao as a co-chair of APPSAWG
---------------------------
Summary:
The IESG last call for draft-faltstrom-5892bis-04.txt ended on 6 June.
Most participants support the publication of this draft. Nobody explicitly say that they object the publication of this draft.
Below are some questions or issues discussed during the IESG last call
-------------------------
issue1: About the text of the first paragraph of the Introduction
Peter Saint-Andre:The first paragraph of the Introduction contains a few infelicities and grammatical errors, and I suggest some modifying.
Clarification from John C Klensin: We should leave the editing work or modifying work to RFC Editor.
--------------------------
issue2: About the old IDNAbis WG's decision
Clarification from John C Klensin: the WG concluded that Unicode changes of character
properties that affected IDNA needed to be evaluated in the IETF
on a case-by-case basis as to whether they were important enough
to justify an addition to that exceptions table or whether the
balance fell on the side of keeping the table small.
---------------------------
issue3: About the IANA consideration section
Roni Even: 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.
Clarification from Paul Hoffman: 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").
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.
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.
----------------------------
issue4: Add the IANA IDNA registry or replace the old one?
Comment from John C Klensin: 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.
Comment from Paul Hoffman: While John's interpretation could be one thing we might have meant, it is not what is reflected in the RFC or the registry.
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.
*****We are waiting for John and Paul reaching the agreement about this issue*******
----------------------------
isse5: About non-backward-compatible changes of the table of derived property values
Roni Even: 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.
Clarification from Paul Hoffman: We intended that as "non-backwards-compatible";we can change the wording to make that explicit.
---------------------------
issue6: About the reference of the IANA registry for derived property value
Roni Even: The IANA registry for derived property value has RFC 5892, does this draft want to change the reference, how will it be done?
Clarification from Paul Hoffman: 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".
5892bis(RFC) will not be listed in the registry.
---------------------------
issue7: About the impacts on the current implementation of RFC 5892 (the relationship between the rules and the tables)
Simon Josefsson：If the document does not update RFC 5892 (or some other document), I
support publishing this document because it will not affect my
implementation of RFC 5892. If it marks updating RFC5892, I am afraid that I has to update the implementation.
Clarification from John C Klensin:
The text in Section 4 of this draft says:
"The table in Appendix B shows, for illustrative
purposes, the consequences of the categories and
classification rules, and the resulting property values."
"The list of code points that can be found in Appendix B
is non-normative. Sections 2 and 3 are normative."
Those tables containing U+19DA character are not normative, so it is not possible to say "I
implemented the tables in RFC 5892 and therefore I conform to
the standard". The closest you can get would be to say "I
implemented the rules and tested against the tables when those
rules were applied to Unicode 5.2 and therefore have great
confidence in my implementaton", but conformance statements stop
with "implemented the rules correctly".
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf