06FD and 06FE should be PVALID for Sindhi
patrik at frobbit.se
Wed Apr 2 08:42:16 CEST 2008
To continue this discussion, which I think is important, I think the
main reason for having it as an RFC is that we do NOT have to come up
with all rules regarding changes of things in the table. Will we only
be allowed to add things? Can we change things, and in that case what?
Can we only add new previously unallocated codepoints etc?
A lot of this are in the documents John has written, but we do not
have firm enough rules so that even an IANA appointed expert can do
their job. I claim.
Because of that, I suggest two things:
- We try to come up with rules so that we at some point in time can
have an appointed expert that help IANA with the review, and the table
is "just" with IANA like the language registry.
- Until we feel comfortable we have The Rules, we understand we have
to update the tables document each time we make changes to the
exceptions. I will still add to -06 text that instruct IANA to hold
the exception (and backward compatibility) lists found in the tables
On 2 apr 2008, at 05.45, Vint Cerf wrote:
> point taken - however I think it also important that there be an
> automatic way to capture and utilize the tables in the same sense
> that valid TLD tables are going to be important to maintain and to
> automate instantiation of "valid TLD" checking software.
> On Apr 1, 2008, at 11:08 PM, Patrik Fältström wrote:
>> On 2 apr 2008, at 02.13, John C Klensin wrote:
>>>> This leads to an interesting question about maintenance of the
>>>> exception tables for IDN200X - it sounds like something that
>>>> should end up as an IANA-maintained table. Does that sound
>>> I think that has been our general assumption. As usual with IANA-
>>> maintained tables these days, the key issue is not who maintains
>>> the table but how the decisions to add or alter entries are made.
>> To start with, I personally would like to have it as part of the
>> tables document, so that RFC action is needed to change it. Having
>> the list "too dynamic" would not be fun as I have no idea what the
>> real implications will be for interoperability with multiple of
>> those in the wild.
More information about the Idna-update