Changing DISALLOWED (was Re: Reserved general punctuation)
debbie at ictmarketing.co.uk
Fri May 2 16:46:17 CEST 2008
>> Can not happen (yet) as we have no such procedure in place. And if we
have, and require for example a 4 week comment period, what is the real
difference between this and issuing a new RFC?
Realistically, about 6-12 months, as a minimum, is the difference.
> -----Original Message-----
> From: idna-update-bounces at alvestrand.no
> [mailto:idna-update-bounces at alvestrand.no] On Behalf Of
> Patrik Fältström
> Sent: 02 May 2008 10:38
> To: Mark Davis
> Cc: phoffman at imc.org; idna-update at alvestrand.no; John C
> Klensin; Vint Cerf
> Subject: Re: Changing DISALLOWED (was Re: Reserved general
> On 1 maj 2008, at 04.17, Mark Davis wrote:
> > 1. We say that once DISALLOWED, always DISALLOWED.
> This is what the RFC says. Only changes that happens "automatically"
> is UNASSIGNED -> "SOMETHING ELSE" when new Unicode versions
> are released.
> > 2. We say that characters can only be removed from DISALLOWED by an
> > obsoleting RFC.
> Obsoleting an RFC can always change whatever is in the RFC.
> And this include (today) the algorithm, the exceptions table etc.
> Yes, we have talked about "an expert group" and such things,
> and long term yes I absolutely think we will have such a process.
> BUT, until then, the only reliable review process we have for
> changes is by issuing a new RFC.
> > 3. We say that characters can only be removed from
> DISALLOWED by the
> > committee/mechanism that controls CONTEXT/exceptions, and only in
> > extremis.
> Can not happen (yet) as we have no such procedure in place.
> And if we have, and require for example a 4 week comment
> period, what is the real difference between this and issuing
> a new RFC?
> > 4. We say that characters can only be removed from
> DISALLOWED by the
> > committee/mechanism that controls CONTEXT/exceptions, and but that
> > committee is not designed to be conservative.
> This is for me out, but mainly because it is today so
> extremely hypothetical that I do not see it being possible to discuss.
> And, btw, it is _ALWAYS_ easy to make the barrier lower in
> the future for changes. Rising the barrier is not easy.
> So I am a supporter of (2).
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update