The normal convention is to use uppercase for the official Unicode/10646 character name, but there is no character with the name "URDU FULL STOP". Do you mean:<br><br><code><a target="c" href="http://unicode.org/cldr/utility/character.jsp?a=06D4">U+06D4</a></code> ( ۔ ) ARABIC FULL STOP<br>
<br>Mark<br><br><div class="gmail_quote">On Sat, Feb 23, 2008 at 11:00 AM, Sarmad Hussain <<a href="mailto:sarmad.hussain@nu.edu.pk">sarmad.hussain@nu.edu.pk</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;">
Dear John Klensin and all,<br>
<br>
Thank you for your comments. I understand and agree. This is exactly what<br>
I am arguing for as well, i.e. :<br>
<div class="Ih2E3d"><br>
"if you need to use a convention locally to permit easier typing of that<br>
character, you can substitute any convenient punctuation (or other<br>
disallowed) character for it... as long as it is mapped to ASCII period<br>
before you store it in a file or transmit it on the wire"<br>
<br>
</div>However, if IDN standards stop short of providing clear auxiliary<br>
recommendations on WHICH "convenient punctuation" to substitute and HOW<br>
(i.e. map which UNICODE characters onto which ASCII characters),<br>
applications providers like Microsoft, Mozilla, etc., tend to implement<br>
their own interpretation for the browsers. Unfortunately, many user<br>
communities do not have experience to get their voice to these application<br>
providers.<br>
<br>
So if the standards list these auxiliary recommendations, there is a likely<br>
chance that they will be supported by the application providers as well,<br>
even if language communities are not able to contact them directly.<br>
<br>
In summary, I am not asking that 06D4 be tramitted on the wire. I am<br>
suggesting that, to ensure that URDU FULL STOP is processed on application<br>
end, relevant IDN standards should explicity recommend that application<br>
providers map 06D4 onto a dot, if they see it in a domain name, before<br>
transmitting it on the wire.<br>
<br>
<br>
<br>
Best regards,<br>
<font color="#888888">Sarmad<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
> -----Original Message-----<br>
> From: John C Klensin [mailto:<a href="mailto:klensin@jck.com">klensin@jck.com</a>]<br>
> Sent: Saturday, February 23, 2008 10:15 PM<br>
> To: Sarmad Hussain<br>
> Cc: <a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a><br>
> Subject: Label separators (was: Re: Urdu and SPACE, FULL STOP (Re:<br>
> comments on IDNAbis: draft-faltstrom-idnabis-tables-04.txt Arabic))<br>
><br>
> Dr. Hussain (and others),<br>
><br>
> I've been distracted by other work for a few days, but want to<br>
> address the FULL STOP problem, which, as Harald pointed out, is<br>
> associated with a label separator issue and not an issue with<br>
> "tables" at all.<br>
><br>
> The problem we face here is that the single most critical<br>
> consideration in looking at IDNA is that the DNS, and DNS<br>
> applications that are not IDNA-aware, must continue to work well<br>
> and predictably when confronted with IDN labels in either native<br>
> Unicode character or ACE form.<br>
><br>
> Personally, I frequently wish that constraint did not exist<br>
> because one can imagine many interesting things that could be<br>
> done without it. But the price of eliminating the constraint is<br>
> modifications to the DNS that would take us considerable effort<br>
> and probably many years to deploy. No one wants to wait that<br>
> long so we are stuck with the constraint.<br>
><br>
> For label separators, the constraint has even stronger<br>
> implications than it does for matching rules (I've discussed the<br>
> latter in another note) because applications and systems that<br>
> are otherwise unaware of the DNS itself (not just unaware of<br>
> IDNA) have to be able to parse full domain names into labels in<br>
> order to map back and forth between the "labels separated by<br>
> full stops" format that we usually see and the DNS internal<br>
> format (a list of labels with explicit length information).<br>
> Even the language of IDNA2003 about mapping of period-like<br>
> characters isn't sufficient to prevent those characters from<br>
> showing up in contexts in which they would interfere with domain<br>
> name parsing. However the intent is clear, and that intent is<br>
> to be sure that, by the time a domain name makes it into a file<br>
> or out on the Internet, the things that look like full stops<br>
> must be translated into ASCII periods and the latter substituted.<br>
><br>
> Oddly, this is where the "no mapping in the protocol" principle<br>
> of the IDNA200X proposals become very helpful. The IDNA2003<br>
> version says, in essence, "these characters (and no others) are<br>
> considered appropriate alternative forms of label separators,<br>
> but you have to map them to ASCII period when you see them".<br>
> The IDNA200X version is equivalent to "the only valid label<br>
> separator on the wire or in interchange is ASCII period.<br>
> However, since we have prohibited all other punctuation<br>
> characters (other than hyphen) from ever actually appearing in a<br>
> domain name, if you need to use a convention locally to permit<br>
> easier typing of that character, you can substitute any<br>
> convenient punctuation (or other disallowed) character for it...<br>
> as long as it is mapped to ASCII period before you store it in a<br>
> file or transmit it on the wire".<br>
><br>
> That is clearly not a perfect solution, but it gives you the<br>
> flexibility you need while preserving both global<br>
> interoperability and the ability for non-IDNA applications to<br>
> unambiguously parse domain names into labels.<br>
><br>
> john<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