I think the following misrepresents my position:<br><div style="margin-left: 40px;"> "It is that area of flexibility with CONTEXT, especially<br>
CONTEXT-OTHER, where my view that "Disallowed" is permanent,<br>
with no path (or a very difficult one) out of that category,<br>
converges with what I understand of <span class="nfakPe">Mark</span>'s desire to make<br>
migration out of DISALLOWED relatively <span class="nfakPe">easy</span>."<br></div><br>I'm not looking to make it easy. I think there are a few possible positions we could take in IDNAbis.<br><br>1. We say that once DISALLOWED, always DISALLOWED.<br>
<br><div style="margin-left: 40px;">This is not a firm promise, because an obsoleting RFC could change it, but would certainly set a very high bar.<br></div><br>2. We say that characters can only be removed from DISALLOWED by an obsoleting RFC.<br>
<br><div style="margin-left: 40px;">A slightly lower bar. While it could be changed, it would certainly be difficult.<br></div><br>3. We say that characters can only be removed from DISALLOWED by the committee/mechanism that controls CONTEXT/exceptions, and only in extremis.<br>
<br><div style="margin-left: 40px;">This should, in my view, also be quite difficult; not quite to the same level as an RFC, but carefully, with sufficient time for deliberation, with solid consensus by a broad set of experts.<br>
</div><br>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.<br><br><div style="margin-left: 40px;">This, I think, would be a very bad choice. My presumption has always been that the committee/mechanism that controls CONTEXT/exceptions should be extremely conservative in its changes; that changes are only made very carefully.<br>
</div><br>I think #3 would be the best, and #2 acceptable, while #1 and #4 are extremes that could cause problems.<br><br>Mark<br><br><div class="gmail_quote">On Wed, Apr 30, 2008 at 6:02 AM, John C Klensin <<a href="mailto:klensin@jck.com">klensin@jck.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
--On Wednesday, 30 April, 2008 04:16 -0700 Vint Cerf<br>
<div class="Ih2E3d"><<a href="mailto:vint@google.com">vint@google.com</a>> wrote:<br>
<br>
> My naïve assumption is that anything unassigned has the<br>
> potential to become assigned so we need to have a state in<br>
> which the code point is not allowed for current use but could<br>
> be permitted at a later time. Do we have the semantics to<br>
> accommodate that? V<br>
<br>
</div>Short answer: No. I presume that is why we are having this<br>
discussion.<br>
<br>
Longer answer:<br>
<br>
While we have concluded that the problems it would cause<br>
outweigh the advantages, these areas of uncertainty are a large<br>
part of what motivated having MAYBE categories.<br>
<br>
I think that putting anything into UNASSIGNED that isn't<br>
actually unassigned (i.e., given no code point assignment in the<br>
then-current version of Unicode) is looking for trouble. As you<br>
point out, such code points have the potential to become<br>
assigned. While one might make some educated guesses from the<br>
block context in which the code point is located, we can't<br>
predict, with 100% certainty, the properties that a code point<br>
will have if and when it is assigned in the future.<br>
<br>
So, for a code point that is actually assigned, I think we have<br>
only three choices:<br>
<br>
* Allow it, as Protocol-Valid. For general punctuation<br>
this is, I hope obviously, not a good idea.<br>
<br>
* Disallow it and assume that, if we discover we need it<br>
enough later, we will do whatever drastic revisions or<br>
disaster corrections are required. Of course, that sets<br>
a very high bar to ever allowing those characters, but<br>
that may not be unreasonable.<br>
<br>
* Assign it to "context required" but do not assign a<br>
rule. Under the current proposed model, that means<br>
that it can neither be registered nor looked up. On the<br>
other hand, we could, in the future, allow it in the<br>
cases where it is actually required by assigning an<br>
appropriate rule and then waiting for software to be<br>
upgraded (something that would presumably happen more<br>
quickly in places where the character is important than<br>
in places where it isn't).<br>
<br>
It is that area of flexibility with CONTEXT, especially<br>
CONTEXT-OTHER, where my view that "Disallowed" is permanent,<br>
with no path (or a very difficult one) out of that category,<br>
converges with what I understand of Mark's desire to make<br>
migration out of DISALLOWED relatively easy. In the middle<br>
ground, we try to identify the characters about which we may be<br>
uncertain and identity them as CONTEXTO with no expectation of<br>
assigning rules unless it turns out that they are really needed.<br>
That approach assume that we can anticipate characters that<br>
_might_ need to be moved, i.e., characters about which are are<br>
not certain that DISALLOWED is globally correct. I think that<br>
is probably correct. Indeed, I believe that, if it is not<br>
correct, this entire approach is built on a house of cards and<br>
we may need to drop it.<br>
<br>
And, FWIW, the argument for putting Cf into CONTEXTO precisely<br>
follows the reasoning above -- these odd and sometimes-invisible<br>
cases (see U+2060, 2062..2064; WORD JOINER, INVISIBLE TIMES/<br>
SEPARATOR/ PLUS) are precisely the sorts of thing that someone<br>
might, conceivably, argue passionately are required in some IDN<br>
contexts. If I correctly understand the use of these<br>
characters, my own view is that I would argue strongly about<br>
permitting them. But I think it would be better to have that<br>
argument on the basis of substantive requirement to have the<br>
characters in IDNs versus risks and complexity and not on the<br>
basis of an artifact of how we had defined things.<br>
<font color="#888888"><br>
john<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mark