<div dir="ltr"><font color="#000066"><font size="2"><font face="tahoma,sans-serif">Hello all,<br><br>Agreed with the view of Nadya Morozova on the point of variants. <br></font></font></font><br><div class="gmail_quote">2011/6/23 Nadya Morozova <span dir="ltr"><<a href="mailto:nad.morozova@gmail.com">nad.morozova@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">Hello all,</font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">Please accept
my apologies if I’ll be re-iterating what has been discussed, and furiously
argued, over the previous sessions that I missed. Having read this thread
starting from Patrik’s post, here are some of thoughts, I hope these can help. </font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><font size="3"><span lang="EN-US"><font face="Calibri">There are a
number of very broad issues being discussed here, and it may make sense to try
and ring-fence those that this work group can address within reasonable time. I
agree with James Seng that A1 and A2 should be of priority</font></span><span>. </span></font></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">I hate to
come back to the definitions here, but it’s important to agree what we’re
trying to regulate here. For example, Patrik’s post, mentions case A4, same
word in two different languages. From a linguistic point of view, it is not
possible as each language is a standalone system, so cross-language
similarities should probably be kept out of the scope. It’d be interesting to
see a rare case where two TLD applications claim the same string but in
different languages. </font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><font face="Calibri"><font size="3"><span lang="EN-US">Also,
Daniel says that in Cyrillic, variants are word-based rather than
character-based and gives an example of E and </span><span lang="RU">Ё</span><span lang="EN-US"> in one word. I’m not sure I follow the example and logic and tend to
disagree, although the exception of “</span><span lang="RU">обед</span><span lang="EN-US">” given later
on makes a point. I’ll be happy to have a separate discussion with the Cyrillic
group to clarify this, but as a linguist and native Russian speaker, I do not
see a problem with </span><span lang="RU">Ё</span><span lang="RU"> </span>using E forming variant domain names. There is always a
character layer, pure spelling with no pronunciation issues, and that’s what we
need to focus on, as that’s what makes up an FQDN. </font></font></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">So, taking
on board Siavash’s advice, I’ve made up a short list of working definitions for
the purpose of this discussion, just to make myself clear. For me, an atomic
unit here is a specific character within a specific language, and the variations
this character produces when forming a (domain) name. Then “variant” can be a
string of characters that is similar and interchangeable with another string;
all “variant” strings form a “bundle”, an atomic domain unit that can be
treated as one – cf. the SC & TC treatments in ccTLD registries. If two
strings are similar but one cannot be mistaken for another, they are not
variants. I don’t know what to call similar strings as in a language they are
just “different words”, and no-one defines the degree of differentiation. I’ll
use a random word like “pancakes” to mean unique strings that are similar but
not interchangeable. Pancake cases may be useful where two words differ only in
diacritics.</font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">So, from my
standpoint, there are several layers here: </font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 0pt 36pt"><span lang="EN-US"><span><font size="3" face="Calibri">1.</font><span style="font-size-adjust:none;font-stretch:normal"> </span></span></span><span lang="EN-US"><font size="3"><font face="Calibri">Ring-fencing character variants within
different scripts, with sub-groups for specific languages where needed (for example,
where the same character is used in different languages differently – cf.,
Arabic Alif and Cyrillic Yer (Hard sign); explained below). Any pancakes need
to be identified and not mixed with variants. <span> </span></font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 0pt 36pt"><span lang="EN-US"><span><font size="3" face="Calibri">2.</font><span style="font-size-adjust:none;font-stretch:normal"> </span></span></span><span lang="EN-US"><font size="3"><font face="Calibri">Determining policies to define all
variants of a specific character forming a bundle, its Unicode representations,
font implications within a language, and any cross-language specifics. </font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt 36pt"><span lang="EN-US"><span><font size="3" face="Calibri">3.</font><span style="font-size-adjust:none;font-stretch:normal"> </span></span></span><span lang="EN-US"><font size="3"><font face="Calibri">Where possible, forming recommendations
on technical implementations of those policies within the DNS or at higher
levels. </font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">Ok, so I
have my own terms and my own plan of action. Starting with point one and
looking at the practical experiences presented at the Wednesday session, here
are my initial thoughts. This is part one of a series of rants, and I plan to continue
with French and more thoughts on Cyrillic in a separate email. </font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">I don’t
speak Arabic and mostly base my assumptions on the Internets – presentations,
wiki, etc. Please accept my apologies if I’m wrong, I’ll gladly stand corrected.</font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">From what I
see, most “variants” in Arabic scripts stem from the optional tashkeel diacritics
modifying consonant letters to show which vowels to read them with. Tashkeel
are optional and vary in different scripts, thus it is impossible to distinguish
between words formed written with and without diacritics. That’s why ccTLD
registries in the region treat them as variants and block the possible options,
once a variant is written. To me, this sounds reasonable although policy work
could help determine how these variants are managed, and what can be done to
simplify and improve management of shadow-domains. </font></font></span></p><font size="3" face="Times New Roman">
</font><p style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3"><font face="Calibri">Perhaps,
there’s a special case for the Arabic Hamza, a glottal stop separating two
syllables, which can be represented as a diacritic or use a carrier. If Hamza
is required and cannot be omitted, then should words without it be treated as
variants of the word with Hamza? </font></font></span></p><font size="3" face="Times New Roman">
</font><div style="margin:0cm 0cm 10pt" class="MsoNormal"><font size="3"><font face="Calibri"><span lang="EN-US">By the way,
in Russian, there’s a similar glottal stop situation with the old character Yer
or Hard Sign, </span><span lang="RU">ъ</span><span lang="EN-US">, often replaced by an apostrophe in
modern Russian. No other language
using Cyrillic alphabet has this character except Bulgarian, where it denotes a
specific sound. For Russian IDNs, should the spelling with no Yer be a variant
of the spelling with it, and vice versa? There are a number of other characters
in Russian that are somehow “special”, including the mentioned </span><span lang="RU">Ё</span><span lang="EN-US"> or characters that in some fonts may be confusingly similar to other
letters. In some cases, it is not reasonable to treat these similarities as
variants; instead, the confusion can be avoided prohibiting registration of
names that can be confusingly similar to a canonical string that has already been
registered. </span></font></font></div><div style="margin:0cm 0cm 10pt" class="MsoNormal"><font size="3"><font face="Calibri"><span lang="EN-US">Perhaps, Vladimir Shadrunov from the .tel Registry could share
Telnic’s experiences in defining language policies for Russian and other
supported IDN languages in .tel. </span></font></font></div><font size="3" face="Times New Roman">
</font><div style="margin:0cm 0cm 10pt" class="MsoNormal"><span lang="EN-US"><font size="3" face="Calibri">Kind regards,</font></span></div><div style="margin:0cm 0cm 10pt" class="MsoNormal">
<span lang="EN-US"><font size="3" face="Calibri">Nadya Morozova</font> </span></div><font color="#888888"><font size="3" face="Times New Roman">
</font><br><br></font><div class="gmail_quote"><div class="im">2011/6/20 Patrik Fältström <span dir="ltr"><<a href="mailto:patrik@frobbit.se" target="_blank">patrik@frobbit.se</a>></span><br></div><div><div></div><div class="h5">
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204, 204, 204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
Hi, I am sending this as an interested individual, and not as SSAC Chair...<br>
<br>
I have a few times this weekend already tried to explain my view on "variants", and after doing that in a chat, I felt it start to (for me) make sense, so I wanted to share with you.<br>
<br>
We have, I think, a problem divided in two different questions. And unfortunately many people think of the solution only the form of "answers to the second question". Let me try to explain.<br>
<br>
First, whether something is a variant or not (note: word is undefined), is actually a grayscale from "yes" to "no". There are various shades of gray there. For example:<br>
<br>
A.1. Two characters in Unicode really are to be treated as being equivalent. I presume one could say that the Hangul SC/TC issues fall in that category.<br>
A.2. Two different spellings of the same word in the same script and same language, like color/colour.<br>
A.3. Same word in the same language in two different scripts (bulgarian)<br>
A.4. Same word in two different languages<br>
<br>
And then there are many A.1.1, A.1.2, A.2.1 etc, and I did even hear today people say "two variants are two different accepted spellings of the same word that _sound_ the same". I do not even know where to put that.<br>
<br>
But one thing I because of that think should be done, and could be done, by people is to list all different "variants" they can come up with...<br>
<br>
The one draw the line, what is and what is not? Is the line drawn at A.1.1232 or A.2.56?<br>
<br>
Ok, given we have some agreement on what is a variant and not, we have to discuss what implications it has. I here also see a number of different questions to be answered. For example:<br>
<br>
B.1. Should an application with more TLDs than one be counted as one application if the TLDs in the application are variants of each other? And if so, should there be only one fee per application?<br>
B.2. Should two different variants be able to be managed by two different registries or not, and if not, what should happen with the variants? One primary and others like the bundling tactics in some TLDs (i.e. choice between "yes delegation" or "just block for other to register")?<br>
<br>
And then there might be a technical question in there...<br>
C.1. Given two domain names are variants of each other, is there something that can be done in the DNS from a technical point of view to express that, or can we only do delegations?<br>
<br>
The really tricky question is of course to really draw the line between variants and not variants. I think the line from a technical point of view, AND the implications on the second questions, should be for the new TLD approval process be as conservative as possible.<br>
<br>
Default answer: If someone want two domain names, just send in two applications.<br>
<br>
Exception: As you desperately need both and not only one of the domain names, you will get both treated as one application.<br>
<br>
Then ICANN ask IETF formally "can you please let us know if it is possible to have some kind of solution for _technically_ link two TLDs with each other, in a safe and stable way". Via a letter to IAB.<br>
<br>
Until and if IETF give such a solution, ICANN only have the following two alternatives for the ones that do get two variants approved:<br>
<br>
1. Get both delegated<br>
<br>
2. Get one delegated and the other blocked<br>
<br>
Then MAYBE there will be a third option:<br>
<br>
3. Get both with some alias solution<br>
<br>
But these are things which are implications given a definition on what "variants" are, and that discussion is in the future -- although I am pretty sure some parties really would like to have certain solutions to the problem...<br>
<font color="#888888"><br>
Patrik<br>
<br>
<br>
</font></blockquote></div></div></div><br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">If you have any query then feel free to call me <br><br>With regards,<br> <br>Satyendra Kumar Pandey<br> Advocate<br>
<br>Call me : +91-9460263991
<br><a href="http://in.linkedin.com/in/satyendrakpandey" title="View public profile" name="SafeHtmlFilter_SafeHtmlFilter_webProfileURL" target="_blank">http://in.linkedin.com/in/satyendrakpandey</a><dl><dd><p>
</p>
</dd></dl><font style="background-color:rgb(255, 255, 255);color:rgb(51, 102, 255)" size="2">Residence: D 3/ 191, Chitrakoot Vaishali Nagar Jaipur<br><br>Home: D 61/22 A, Siddhgiri bag, Varanasi - 221010</font><br>
------------------------------------------------------------------------------------------------------------------------------<br>This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.<br>
------------------------------------------------------------------------------------------------------------------------------<br></div><br>
</div>