Historic scripts as MAYBE?

[Mark Davis]

If anything can happen if the RFC is updated, then we absolutely cannot
promise people that DISALLOWED will never change in the future -- that would
just lead people down a garden path.

But I would far rather that we design a mechanism and process that allows us
to avoid such disruptions.

Mark

On Mon, Apr 28, 2008 at 12:31 AM, Patrik Fältström <patrik at frobbit.se>
wrote:

> On 28 apr 2008, at 08.55, Mark Davis wrote:
>
>  So these are both referring to versions of IDNA data, not Unicode data,
> > and
> > considering what would happen if we (in this committee, not Unicode)
> > exceptionally allow characters to change status, AND it happens that the
> > IANA committee or whoever decides changes to the context/exception
> > tables
> > adds MODIFIER LETTER RHOTIC HOOK to PVALID, removing it from DISALLOWED.
> >
> > The rest of the message is trying to consider what the consequences
> > would
> > be.
> >
> > Is it clearer now what I'm saying?
> >
>
> Yes, I was confused when you talked about 5.1 and 5.2 which to me
> reference Unicode versions.
>
>  "Let's suppose that IDNA 2008 is issued based on Unicode 5.1"
> >
>
> IDNA2008 is not based on Unicode 5.1. It is defining an algorithm that is
> to be applied to any version of Unicode. The table is non-normative. So a
> codepoint that is assigned DISALLOWED will not move from DISALLOWED if not
> one of three things happens:
>
> - UTC changes the data in the Unicode tables
> - A codepoint is added to the exceptions table
> - The algorithm is changed
>
> You say the first is out. Good.
>
> My personal view is that as we do not have MAYBE, things should _NEVER_
> move from DISALLOWED or ALWAYS. Same reasons as always. Due to changes in
> ability for registration, requirement for sunrise, risk for applications to
> have the domain names no longer be accessible (or not able to access newly
> registered domain names) etc.
>
> As it is now, my view is that the change that is "ok" is move from
> UNASSIGNED to one of the other categories.
>
> But, of course changes like these can be made when the RFCs are updated.
> And when an RFC is updated, anything can happen.
>
>   Patrik
>
>


-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080428/c1f03c24/attachment-0001.html