Exception table (was: Re: 06FD and 06FE should be PVALID for
vint at google.com
Wed Apr 2 15:11:43 CEST 2008
FWIW I think John has laid out a pretty rational argument for his
On Apr 2, 2008, at 3:53 AM, John C Klensin wrote:
> (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
> 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).
> --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
>> - 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.
More information about the Idna-update