List of issues for draft-ietf-idnabis-tables
Patrik Fältström
patrik at frobbit.se
Mon Jul 28 13:00:53 CEST 2008
This is based on -02 of the document, with comments that say what I
have planned (so far) for -03.
All editorial comments (from Mark and Ken specifically) has been taken
care of, if I have ack:ed them in the separate email with "ok".
I am looking for more email with comments...but please let me know in
private if you still feel I have lost something.
Patrik
========================
P1: Order of codepoints in for example the exceptions table
Current state: Order is by codepoint value
Proposal: Sort by value instead of code point, for clarity. Ideally
each value would be in its own subsection: PVALID,
CONTEXTO,...
Comment from editor: I have seen more voices against this proposal
than in favor.
Suggested action: None
========================
P2: Split appendix A (non-normative list of codepoints) in one list
per property value
Current state: The list is not split
Proposal: Split the list in one per property value, or at least order
by property value.
Comment from editor: I suggested this after seeing [P1]. Voices where
rised against this proposal.
Suggested action: None
========================
P3: IANA is to update the Backward Compatible list.
Current State: IANA is to host a list of derived values such as the
one in appendix A, and update this list whenever a new version of
Unicode is published. IANA is not to update any of the tables in this
document. That is done only by updating this RFC.
Proposal 1: Have the backwards compatible character list, the
exceptions list, and the context rules all be in a single document
published by IANA, and controlled by the group discussed in rationale.
Proposal 2: Have the backwards compatible character list should be
part of the documentation of the derived property for each version of
Unicode which is called for in the current document. Contextual rules
are different. If some new context rule proves necessary, then it
should probably be done with thorough review, and in the IETF context,
if that requires updating the RFC and requiring IESG action
Comment from editor: Most voices want changes to THIS document be by
updating it, i.e. by requiring IESG action.
Suggested action: None
========================
P4: Remove Appendix A
Current state: Appendix A holds a non-normative table of derived
property values for Unicode 5.1.
Proposal: Remove the appendix as developers and readers do not
understand the difference between the appendix being normative or non-
normative.
Comment from editor: At least during development of this I-D, the
appendix has helped. I also think personally people do understand the
difference. So I personally am not as worried.
Suggested action: None
========================
P5: IANA Considerations section more clearly written
Status in -02: Confusing
Status in -03: Separate more clearly between the different tasks, and
difference between normative and non-normative items.
Action: Please review text when -03 is published and send comments.
Patrik
More information about the Idna-update
mailing list