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

[Mark Davis]

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?

Mark

On 6/13/07, Harald Tveit Alvestrand <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20070613/ca5ea884/attachment.html