Changing DISALLOWED (was Re: Reserved general punctuation)

Vint Cerf vint at google.com
Fri May 2 00:02:38 CEST 2008


John et al,

I agree with your point and Patrick's idea to test for unassigned first.

v

On May 1, 2008, at 12:43 PM, John C Klensin wrote:

>
>
> --On Thursday, 01 May, 2008 09:20 -0700 Paul Hoffman
> <phoffman at imc.org> wrote:
>
>> At 12:04 PM -0400 5/1/08, Vint Cerf wrote:
>>> Coming back to UNASSIGNED and DISALLOWED, is it correct to
>>> say  that  all UNASSIGNED code points are DISALLOWED (since
>>> allowing them makes  no sense if the code point has no
>>> character associated with it).
>>
>> Not at all. See section 1 of Patrik's protocol document. The
>> two are completly disjoint.
>
> Vint,
>
> Assuming that we have a very crisp definition of "unassigned",
> the difference is that a code point can move from UNASSIGNED to
> any of the other categories just by assignment of a character
> and its properties.  No special IETF action (committee, RFC, or
> otherwise) is required.  For any of the other categories, some
> specific IETF consideration and action is required (how
> significant that should be is really a separate question,
> although it has obviously gotten entwined with this one).  This
> distinction is at the very core of the "version agnostic"
> strategy.
>
> I think Patrik's proposed change to "tables" to test
> "unassigned" and assign that category first solves the problem
> with the crisp definition.   If we were going to make any
> classification assumptions based on the properties of code
> points to which no character had yet been assigned (see Mark's
> notes and Paul's followup), we would need to be certain that all
> of those properties were absolutely immutable (in the
> plain-language, as well as Unicode, senses).   While that might
> be possible for some properties (e.g., block membership) and
> some code points, it does not appear to me to be generally
> possible and hence leads us into all sorts of places where we
> don't want to be.
>
>     john
>



More information about the Idna-update mailing list