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

Mon Aug 1 18:54:10 UTC 2011

Adding a definition for name aliasing seems the sensible thing to do.

__
Francisco

On 7/29/11 12:18 PM, "Vladimir Shadrunov" <vlad.london.uk at gmail.com> wrote:

>I'm fine with this name. So once we move on to discussing the intended
>behaviour of multiple TLDs that we want to be "the same", we'll actually
>be talking about Aliasing, with Variants (per current definition) being
>one of the possible applications for Aliasing mechanism.
>
>Is that what you proposing? Do we need to add a definition for an Alias?
>
>Thanks,
>Vladimir Shadrunov
>
>On 29.07.2011 15:28, Francisco Arias wrote:
>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>> 
>