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

Fri Jul 29 14:28:49 UTC 2011

We could call that "name aliasing".

__
Francisco

On 7/29/11 6:50 AM, "Vladimir Shadrunov" <vlad.london.uk at gmail.com> wrote:

>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] / 武部良明. - 第２版. - 東京 :  角
川書
>> 店
>>>>, [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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>