[vip] Types of variants: do we have consensus?

Vladimir Shadrunov vlad.london.uk at gmail.com
Fri Jul 29 10:50:31 UTC 2011


Very good remark, Francisco. These are two separate topics indeed.

However, IMO we still need a good name for what you call "two strings
that are no variants (for a given and agreed definition of variant)
but still the registrant wants them to be treated as one".

Best regards,
Vladimir Shadrunov

2011/7/28 Francisco Arias <francisco.arias at icann.org>:
> Hello,
>
> Perhaps we are conflating two sets of issues, which makes the discussion
> more difficult. I think that we have (at least) two set of issues that can
> be decoupled:
>
> 1. The general discussion about what is a variant, types of variants, etc.
> I.e., The "variant definition" set of issues.
>
> 2. The "name aliasing" set of issues. This refers to the idea of having a
> mechanism (e.g., DNAME in DNS, or other mechanism at a higher level) that
> allows to names to "behave as one".
>
> I think there would be cases in which you want to use a name aliasing
> mechanism that allows such variants to "behave as one". But there are
> other cases in which you only want to allocate (not delegate n DNS),
> reserve, or block certain names considered variants. Since there is no
> delegation, there is no name aliasing tool in use.
>
> Conversely, you may have two strings that are no variants (for a given and
> agreed definition of variant) but still the registrant wants them to be
> treated as one. For example, company ABC acquires company XYZ, and as one
> of the steps of the transition they setup name "xyz.tld" as an alias of
> "abc.tld".
>
> I'd propose to treat the two set of issues above independently. Thoughts?
>
> Regards,
>
> __
> Francisco
>
>
>
> On 7/28/11 11:36 AM, "Vladimir Shadrunov" <vlad.london.uk at gmail.com> wrote:
>
>>Thanks, Chris and all who responded.
>>
>>Just to clarify: I am not trying to insist that we introduce special
>>class of semantic variants or phonetic variants. My point is that the
>>reason why two strings are considered variants may be not that
>>important for the purpose of our study. Besides, depending on the
>>context (i. e. ccTLD labels, gTLD labels, second-level labels etc.)
>>these reasons may vary.
>>
>>Best regards,
>>Vladimir Shadrunov
>>
>>On 28 July 2011 15:22, Dillon, Chris <c.dillon at ucl.ac.uk> wrote:
>>> Dear all,
>>>
>>> This is not an argument in favour of semantic variants, but I think
>>>there would be more of a case for the following Japanese situation.
>>>
>>> All of these (and probably several more, but they are not on the
>>>Japanese Ministry of Educations official character list [改定常用漢字表]) are
>>>ways of writing hakaru 'plan; measure':
>>> 計る==測る==量る==諮る==図る==謀る
>>>
>>> According to 漢字の用法[=The uses of characters] / 武部良明. - 第2版. - 東京 :  角川書
>>>>, [1982] there are the following nuances:
>>> 計 when counting and thinking
>>> 測 when measuring length etc.
>>> 量 when measuring weight; probability
>>> 諮 consult
>>> 図 plan to do something
>>> 謀 plot, scheme
>>>
>>> There is overlap in the use of the various characters, although to a
>>>lesser extent perhaps with謀 because of its negative implications!
>>>
>>> Regards,
>>>
>>> Chris.
>>> ==
>>> Faculty Information Support Officer
>>> for Arts & Humanities and Laws
>>> Arts & Humanities Faculty Office
>>> Andrew Huxley Building
>>> UCL, Gower St, London WC1E 6BT
>>> Tel 020 7679 1599 (int. 31599)
>>> http://www.ucl.ac.uk/isd/staff/fiso/ah
>>>
>>>
>>> -----Original Message-----
>>> From: vip-bounces at icann.org [mailto:vip-bounces at icann.org] On Behalf Of
>>>Joseph Yee
>>> Sent: 26 July 2011 19:31
>>> To: Giovanni Seppia
>>> Cc: vip at icann.org
>>> Subject: Re: [vip] Types of variants: do we have consensus?
>>>
>>> Dear All,
>>>
>>> Personally I believed that ICANN question (IDN ccTLD or IDN gTLD) and
>>>variant issues are two separate issues.  The *sequence of characters*
>>>combined together, regardless meaningful or not to community and/or
>>>ICANN, still has variance (mileage varies) issues.
>>>
>>> Claiming semantic as variant is hard, very close to impossible.  If one
>>>tried to claim that RED==RUBY==CRIMSON are variant of each semantically,
>>>one would expect rejection not just from authority but from large
>>>communities as well.
>>>
>>> And worse, the meaning of string changes over time.
>>>
>>> One question that I think is interesting to all of us (us as Variant
>>>Study Team)
>>> What characters are *universally* changeable and/or swappable in each
>>>script? and in each language? and under Unicode?
>>>
>>> Best,
>>> Joseph
>>>
>>>
>>> On 2011-07-26, at 11:40 AM, Giovanni Seppia wrote:
>>>
>>>> Dear All,
>>>>
>>>> In following up some of the comments circulated so far regarding the
>>>>association of meaningfulness to a string, I would like to highlight
>>>>that one of the criteria applied by ICANN when submitting a string
>>>>application within the ccTLD IDN Fast Track process is "meaningfulness
>>>>of the string". ICANN does not approve any string request if this
>>>>element is not adequately addressed by the applicant.
>>>>
>>>> Best,
>>>>
>>>> Giovanni
>>>>
>>>>
>>>> On 26 Jul 2011, at 09:59, Daniel Kalchev wrote:
>>>>
>>>>>
>>>>>
>>>>> On 26.07.11 02:30, Andrew Sullivan wrote:
>>>>>> "Meaning or restatement of string in English. The applicant will
>>>>>>provide a
>>>>>> short description of what the string would mean or represent in
>>>>>>English."
>>>>>> Thank you for bringing this requirement to my attention; I somehow
>>>>>> missed it in previous readings of the guidebook.  I'm sure you can
>>>>>> work out what my (personal) opinion of this requirement is.
>>>>>
>>>>> I always wished our work to be useful at all levels of DNS, but TLDs
>>>>>are definitely supposed to have meaning. So therefore, if we are to
>>>>>focus on variants in the context of TLDs (primarily), then we must
>>>>>consider the meaning "variants".
>>>>>
>>>>> Even if we do not consider the "meaning" as a string variant, it will
>>>>>surely be considered as such at some other policy level.
>>>>>
>>>>> If we talk about meaning of the string at any level in DNS, then I
>>>>>could justify your opinion -- however the policies at different levels
>>>>>are quiet different. On many levels "anything goes".
>>>>>
>>>>>>> I think it is safe to claim that TLDs do have meaning _associated
>>>>>>>to them_
>>>>>> Semioticians will tell us that _everything_ has meaning associated to
>>>>>> it.  Of course DNS labels have more or less meaning for a given
>>>>>> person, and over time a user community might come to converge on a
>>>>>> conventional meaning.  On the other hand, I've often heard it said
>>>>>> that .org domains are for non-profits.
>>>>>
>>>>> This I believe was coined during the Bucharest ICANN meeting, where
>>>>>the .ORG TLD was subject to bids. RFC1591 says about .ORG:
>>>>>
>>>>> ORG - This domain is intended as the miscellaneous TLD for
>>>>> organizations that didn't fit anywhere else. Some non-
>>>>> government organizations may fit here.
>>>>>
>>>>> On the other hand, would ICANN agree for a gTLD .ОРГ (same phonetics,
>>>>>same abbreviated meaning in Bulgarian, at least) to exist separately
>>>>>from .ORG? If not, why?
>>>>> It is different, because:
>>>>> - has different script (Cyrillic)
>>>>> - does not have visual similarity (oh yes, 'Г' is equivalent with 'R'
>>>>>:)
>>>>> - does have different Abstract Characters and produces different
>>>>>punnycode.
>>>>>
>>>>> There are many cases like this, that support the non-character base
>>>>>to define variants in DNS.
>>>>> Of course, none of these are technical.
>>>>> But then, character variants are not technical as well. :)
>>>>>
>>>>> Daniel
>>>>>
>>>>>
>>>>
>>>> Giovanni Seppia
>>>> External Relations manager
>>>>
>>>> EURid
>>>> Woluwelaan 150
>>>> 1831 Diegem - Belgium
>>>> TEL: +32 (0) 2 401 2750
>>>> MOB:+39 335 81 41 733
>>>> giovanni.seppia at eurid.eu
>>>> http://www.eurid.eu
>>>
>>>
>>>
>>>
>>>
>>
>
>
>


More information about the vip mailing list