tables document, IANA instructions
John C Klensin
klensin at jck.com
Tue Jul 15 14:18:15 CEST 2008
--On Tuesday, 15 July, 2008 07:06 +0200 Patrik Fältström
<patrik at frobbit.se> wrote:
> My guess is that the core questions hidden in here is what is
> needed for the actual change to the backward compatible list
> (or any other part of the tables document) to change.
> Experience from the IETF say that increasing the
> requirements is not possible, but relaxing is very easy.
> Because we do not know what the requirements should be for
> selection of 1, 2 or 3 above, I am personally strongly in
> favor of a requirement for IESG decision for a change. The
> reason for this is that that forces the IETF to issue a last
> call, so noone is surprised over the change.
> When we have gone through at least one release of Unicode and
> tested this process, we can also talk about relaxing the
> But for creation of the derived property list, (as many people
> will copy it, as Ken says), I propose the following:
> Expert Review (or Designated Expert) - approval by a Designated
> Expert is required. The required documentation and
> review criteria for use by the Designated Expert should
> be provided when defining the registry. For example,
> see Sections 6 and 7.2 in [RFC3748].
> Examples: EAP Method Types [RFC3748], HTTP Digest AKA
> algorithm versions [RFC4169], URI schemes [RFC4395],
> GEOPRIV Location Types [RFC4589].
> I.e. someone should be appointed to actually create the
> derived property list, ensure there are no "problems", and
> double.check that it is actually correct (no bugs) according
> to the specification.
But, Patrik, doesn't "Expert Review" eliminate the IETF Last
Call that you have suggested (I think persuasively) we should
require until we get some experience. I agree that having
someone with responsibility to create an initial list is wise,
but that can be done simply by requiring posting of an I-D,
etc., that is a normal first step in the IETF Review process.
More information about the Idna-update