Exception table (was: Re: 06FD and 06FE should be PVALID for Sindhi)

[Vint Cerf]

FWIW I think John has laid out a pretty rational argument for his  
"slight" preference.

vint

On Apr 2, 2008, at 3:53 AM, John C Klensin wrote:

> Patrik,
>
> (Changing the subject line and dropping the arabicscript list  
> because this is getting pretty far down into IETF procedures and  
> protocol parameter registration models.)
>
> I think we agree about the principles, but I'm a little concerned  
> about the implementation.
>
> The principle, as I see it, is that
>
>    At least until we are able to figure out what the rules
>    should be for making exceptions (I don't expect that will
>    happen in any deterministic way, ever, but hope I'm wrong),
>    modifying the exceptions table should require a full
>    standards-track process.
>
> My concern is that the tables document is big.  While we are  
> (fortunately) not seeing the backlogs of a few years ago, the RFC  
> Editor still doesn't do really well with big documents and there is  
> no way to predict how well some (possibly different) RFC Editor  
> entity will do in the future.  Small textual errors are almost  
> inevitable in large documents and our errata process, while getting  
> better, is still not efficient.   So I also think it is important  
> not to get tied up with a process that could, itself, turn into a  
> problem.
>
> In addition, periodic replacement of the Tables document just to  
> add or delete an exception list entry or two is likely to create a  
> perception of less stability than I think this set of standards  
> should and will have in practice.
>
> I think there are two ways out of those problems.  I have a slight  
> preference for the second (hence the earlier response to Vint) but  
> want to stress "slight" -- I can live with either.
>
>    One is to pull the exception list out into a separate RFC
>    that can be processed and updated/obsoleted separately, with
>    IANA holding the current correct copy of the full tables.  A
>    new exception proposal would then take the form of an I-D
>    that, if approved, would replace ("obsolete") the previous
>    Exception Table RFC, update the copy of the full character
>    table in the base Tables document, and issue some updating
>    instructions to IANA.   And, exclusive of boilerplate, it
>    would probably be a page or, at the most, two pages, long.
>
>    The other is to do this by an IANA registry for which the
>    conditions for modification required a process essentially
>    equivalent to the above, even if getting that process
>    requires an exception to, or updating of, the usual set of
>    template IANA instructions.
>
> The advantage of the second is that, properly designed and  
> specified, it provides a standard and very stable place to look for  
> the latest exception table and the history of such tables. It keeps  
> them tightly linked to the current version of the (derived) full  
> character-classification table and does so without the user having  
> to page through a collection of "this obsoletes all of the  
> preceding ones" RFCs, none of which can ever advance past Proposed  
> Standard (keeping the rest of the collection there unless an  
> exception is made).  The advantage of the first is that we clearly  
> understand how to do it and it is guaranteed to not require any new  
> process bits.
>
> It is perhaps also worth reminding ourselves that standing WGs to  
> review things have rarely worked well and that the odds of spinning  
> up a full WG to review a small handful of characters (or fewer) are  
> very small (I offer the length of time we spent of the charter for  
> this effort as an example of why).   So, even if we selected the  
> first model, the relevant RFCs would almost certainly have to be  
> handled as individual submissions.  Review quality on those is, as  
> you know, uneven (as is review quality on WG efforts, of course).   
> It is possible that we could design an open "expert" review  
> committee process, subject to IETF Last Call, for the second model  
> that would ensure a higher quality of review than we could  
> plausibly expect from the first (modified analogies to ISO  
> Maintenance Agencies come to mind here).
>
>   john
>
>
> --On Wednesday, April 02, 2008 8:42 AM +0200 Patrik Fältström  
> <patrik at frobbit.se> wrote:
>
>> 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 document.
>
>
>
>