<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Paul,<div><br class="webkit-block-placeholder"></div><div>I used a phrase that apparently wasn't as clear as I thought. When I said "reimplementation of filtering" I simply had in mind that the filtering system would/might need to change to accommodate the new status of a previously UNASSIGNED code point. So changing the table used for filtering was what I was thinking when I used the term "reimplementation" - thanks for the clarification.</div><div><br class="webkit-block-placeholder"></div><div>Coming back to UNASSIGNED and DISALLOWED, is it correct to say  that all UNASSIGNED code points are DISALLOWED (since allowing them makes no sense if the code point has no character associated with it). </div><div><br class="webkit-block-placeholder"></div><div>vint</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br><div><div>On May 1, 2008, at 11:41 AM, Paul Hoffman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div>At 5:25 AM -0400 5/1/08, Vint Cerf wrote:</div> <blockquote type="cite" cite="">At the risk of prolonging this thread, I am assuming that DISALLOWED is a condition that makes sense only for an ASSIGNED character and that UNASSIGNED means the code point has not been assigned any meaning or character.</blockquote> <div><br></div> <div>That is not a good assumption. As Mark said yesterday:</div> <div><br></div> <div>At 6:59 PM -0700 4/30/08, Mark Davis wrote:</div> <blockquote type="cite" cite="">In Unicode, what we've been referring to as "unassigned" (more precisely gc=Cn) means that a code point (from 0 to 10FFFF) is not assigned *<i>to a character</i>*. The code point may actually have properties even though it does not represent a character: it might have bidi properties, block properties, or, as in this case, be default-ignoreable or a noncharacter.</blockquote> <div><br></div> <div><br></div> <blockquote type="cite" cite="">This suggests that anything UNASSIGNED should be rejected at the protocol level (no registration... no lookup either?).</blockquote> <div><br></div> <div>That could be true regardless of whether or not TUC had given the gc=Cn properties.</div> <div><br></div> <blockquote type="cite" cite="">Wouldn't this imply that a new revision of UNICODE that ASSIGNS a previously UNASSIGNED character may require reimplementation at protocol level of filtering since the previously UNASSIGNED code point now has properties that might allow it to be used in IDNs.</blockquote> <div><br></div> <div>Now we fall into capitalization-in-specs issues.</div> <div><br></div> <div>- If TUC moves a character out of gc=Cn (that is, they assign a code point to a character), and that character had the IDNA property of UNASSIGNED, TUC's action would the change IDNA property from UNASSIGNED to something else.</div> <div><br></div> <div>- If TUC moves a character out of gc=Cn (that is, they assign a code point to a character), and that character had the IDNA property other than UNASSIGNED, TUC's action might or might not change the IDNA property.</div> <div><br></div> <div>Neither would "require reimplementation at protocol level of filtering". The first would, and the second might, change the table used for filtering.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Idna-update mailing list</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a href="http://www.alvestrand.no/mailman/listinfo/idna-update">http://www.alvestrand.no/mailman/listinfo/idna-update</a></div> </blockquote></div><br></div></body></html>