List of issues for draft-ietf-idnabis-tables

Patrik Fältström patrik at
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.


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,

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- 

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.


More information about the Idna-update mailing list