New version, draft-faltstrom-idnabis-tables-02.txt, available

[Harald Tveit Alvestrand]

The intent of "MAYBE YES" and "MAYBE NO" was:

- ALWAYS: We guarantee that these codepoints will be permitted in IDNs (at 
this level of the standard).
- NEVER: We guarantee that these codepoints will never be permitted in IDNs
- MAYBE YES: At this stage of the development process, the rules that we 
are using will make these characters permitted. However, we are not able to 
give any guarantees.
- MAYBE NO: At this stage in the development process, the rules that we are 
using will make these characters not permitted. However, we are not able to 
give any guarantees.

A reasonable behaviour for a reasonable registry would be:

- Permit ALWAYS in registrations (subject to other rules)
- Do not permit NEVER in registrations
- If already permitting MAYBE YES characters, go on permitting them, on the 
assumption that they will still work. Don't add more permitted ones unless 
there's an operational need to (careful introduction).
- If permitting MAYBE NO characters, either stop permitting them, or go 
lobby the rulewriters to change the rules.

A reasonable behaviour for a reasonable software implementor of software 
that won't be upgraded in 5 years would be:

- Give a syntax error for attempts to type in IDNs with NEVER characters
- Permit all others (you can't be sure where they will end up)

OTOH, an online web-app provider might choose to regard all of MAYBE NOT as 
a syntax error, and bet on his ability to upgrade the software in the case 
where a MAYBE NOT character migrates to MAYBE YES or ALWAYS.

Those examples could go into this doc, but I think they'd fit better in 
-framework, actually....