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

[John C Klensin]

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.