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

Harald Alvestrand harald at alvestrand.no
Thu Jun 14 10:32:45 CEST 2007


Mark Davis wrote:
> I would not have even thought of this interpretation. I'm used to 
> having stability be a requirement; with this formulation, IDNAs that 
> are accepted by products and protocols currently may become invalid in 
> the future. Why on earth is such instability seen as a good thing?
Because we're trying to protect the users against the changes we have to 
make when we know what we don't know now.

We're in a situation where people are registering things that we will 
most likely put into the spec as "not permitted", and LOTS of stuff 
where we don't know whether it will be permitted or not. The 
convolutions we have to go through in order to safely use ZWNJ are one 
example; the most important part of that example is that at the time of 
the original IDNA, we didn't know there was a problem.

ALWAYS and NEVER are intended to be stable categories. But promising 
stability and then changing stuff is (in my opinion) much worse than 
promising stability on some things and warning that some other things 
may be unstable, and then changing what we warned might be unstable.

                   Harald


>
> Mark
>
> On 6/13/07, *Harald Tveit Alvestrand* <harald at alvestrand.no 
> <mailto:harald at alvestrand.no>> wrote:
>
>     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....
>
>
>
>
>
>
> -- 
> Mark 



More information about the Idna-update mailing list