Types of variants: do we have consensus?
Dear All, It is always useful, when working in a group, to periodically ask yourself "why are we here", "what problem we are trying to solve", "what is supposed to be the outcome of our work". Why has this group been convened? I believe we are here because there's a vague perception in the community that there are situations when two or more TLD strings should be treated "the same". However, there is no clear understanding as to what exactly "the same " means, i. e. what the behaviour of these variant TLDs should be. And here we are to remove the vagueness and better formulate the issue before further discussion may occur in the technical and policy development groups. Am I right capturing the mission? Note that nothing in the above suggests what these variant TLD strings should be and how they relate to each other. I do appreciate the work that has been done on the definitions document. However, I can't help noticing that this document is centred around the concept that variant labels are the ones that are generated by means of character-by-character substitution via Language Variant Tables (I'll refer to them as character-based variants). It has been already suggested by several members that variant strings can also be based on other types of similarity/equivalence, such as: - *visual* (strings that have different code points, but are visually identical) - *phonetic* (strings that are written differently, but sound the same) - *semantic* (strings that "mean" the same, with full understanding that not every DNS label has a meaning. Some labels, however, do have meanings so "semantically equivalent TLD variant strings" doesn't at all sound outrageous to me). These situations are not covered in the current definitions document and continuing to ignore this issue may produce a wrong impression that there is a group consensus that variant labels can only be character-based. I do not think presense of such a consensus is the case (can easily be tested via a poll). Don't you think having a consensus on such an important underlying issue is important for the group? Thanks, Vladimir Shadrunov
Dear colleagues, On Mon, Jul 25, 2011 at 06:06:45PM +0100, Vladimir Shadrunov wrote:
However, I can't help noticing that this document is centred around the concept that variant labels are the ones that are generated by means of character-by-character substitution via Language Variant Tables (I'll refer to them as character-based variants).
That is entirely correct. I'm a little concerned, however, that the following message hasn't come through clearly: there is no requirement that these definitions form the basis of individual teams' reports. The request is that, if you want to use one of these terms, you use it in exactly the sense that it is defined in the document. If a given definition does not work for your case, it is entirely appropriate to define some new term in order to capture that meaning. To emphasise, the most recent posting of the definitions includes this in the note to readers: The purpose of the definitions document is to define and reserve a number of unambiguous terms. The definitions are not required to be used by the case study teams; but if the teams wish to use these terms, they are asked to use them as defined in this document and not in any other way. If the case study teams use these terms, they will be interpreted as they are defined here. (see https://community.icann.org/download/attachments/16842765/initial_definition...)
It has been already suggested by several members that variant strings can also be based on other types of similarity/equivalence, such as:
- *visual* (strings that have different code points, but are visually identical) - *phonetic* (strings that are written differently, but sound the same) - *semantic* (strings that "mean" the same, with full understanding that not every DNS label has a meaning. Some labels, however, do have meanings so "semantically equivalent TLD variant strings" doesn't at all sound outrageous to me).
I agree very strongly that each of these is an important topic, and that each one may need some thought and consideration. Speaking only personally, one of the good things I think is in the definitions provided to the teams is that they refer to external, well-reviewed documents. Even if one thinks that a given definition is wrong, each one is by and large comprehensive. (So far, the exceptions are all ones that were identified by the Cyrillic team; these were addressed in the version posted at the URL above, and I was delighted that the review turned up these omissions.) The first class you identify above seems to be the case covered by the definitions. For that case, we can produce an operational definition of the kinds of sameness for which we are trying to test. Moreover, that case is historically well-explained: we know, for instance, that the same Abstract Character is sometimes encoded in more than one way in Unicode. So there is a simple, practical, technical reason to try to cause two different DNS labels to resolve such that there is minimal difference between them. This class, however, contains a smaller number of cases than some people would like to address. In the case of the second class -- phonetic similarity -- I am not sure where we might find a document that provides the operational definition of this case. "Sound the same" is at least a tricky problem, particularly if one wants to specify this algorithmically (it's not impossible, of course, at least in some scripts). Moreover, I also don't know what the basis for treating this case the same as the first class would be. Strings that sound the same (when spoken) need not even be related to one another. To use a simple example in English, the string "your" and the string "you're" are pronounced similarly, and in some regional accents indistinguishably -- so much so that these are often mistakenly substituted for one another in running text. But they have quite different meanings, since the former means "belonging to you" and the latter means "you are". A rigorous definition in this area would be most helpful, and some additional work to explain why sound-alike labels ought properly to be treated as "the same", for some value of "same". For traditionally, sound-alike labels are just different labels. Why shouldn't that continue to be the case? In the case of the third class -- semantic similarity -- I first of all deny the premise. I claim that _no_ DNS label has a meaning. It is possible (indeed likely) that some people use labels as though they had meaning, but that is quite a different matter from the labels actually having such meaning. That you might attribute a meaning to a given label could well mean that you understand it to have the same meaning as some other label. But that is not the same as deciding that the label has that meaning in itself -- for instance, the same pair might not be related for me. How would one determine this? What authority would one depend on? And how is this to be determined algorithmically? Moreover, given that the tradition in the DNS runs exactly counter to this -- traditionally, the labels "color" and "colour" are simply different labels, period -- what justification is there for including this type of similarity in the work of the teams? Nevertheless, if you and your colleagues need to define these terms for your purpose, then I encourage you to do so, always remembering that any definition other than an operational one will be almost impossible to use in any report that is intended to inform a final policy. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com
Hi Andrew In the case of the third class -- semantic similarity -- I first of all deny the premise. I claim that _no_ DNS label has a meaning. It is possible (indeed likely) that some people use labels as though they had meaning, but that is quite a different matter from the labels actually having such meaning. That you might attribute a meaning to a given label could well mean that you understand it to have the same meaning as some other label. But that is not the same as deciding that the label has that meaning in itself -- for instance, the same pair might not be related for me. How would one determine this? What authority would one depend on? And how is this to be determined algorithmically? Moreover, given that the tradition in the DNS runs exactly counter to this -- traditionally, the labels "color" and "colour" are simply different labels, period -- what justification is there for including this type of similarity in the work of the teams? I would like to point out (considering that this group deals with IDN TLDs issues) that the FIRST requirement for IDN gTLD application in gTLD Application Guidebook states as the following: "Meaning or restatement of string in English. The applicant will provide a short description of what the string would mean or represent in English." I think it is safe to claim that TLDs do have meaning _associated to them_ (and ICANN could very well be the authority if needs to be). I am not sure if semantically similar strings are actually variant strings the way we define variant strings, but I agree with Vladimir that on a conceptual level this is a case of similarity and will need to be addressed. Best Regards, Alexey
On Mon, Jul 25, 2011 at 03:58:15PM -0700, Alexey Mykhaylov wrote:
I would like to point out (considering that this group deals with IDN TLDs issues) that the FIRST requirement for IDN gTLD application in gTLD Application Guidebook states as the following:
"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 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. But there are no restrictions on the non-profit status of registrants using a .org address. And indeed, as far as I know the owners of slashdot.org hope to make money from it. I have grave doubts about the ability to hold the meaning of a domain name label stable, and I've yet to see evidence presented that such meaning is a sound basis for a programme of treating different strings as the same.
I am not sure if semantically similar strings are actually variant strings the way we define variant strings, but I agree with Vladimir that on a conceptual level this is a case of similarity and will need to be addressed.
And as I suggested in my mail, it is indeed an important issue and needs to be considered. I am suggesting, however, that it needs to be treated separately; I was also attempting to point out the difficulty of dealing with this case. Finally, I was attempting to point out that there is a fundamental dissimilarity in the traditions here for the DNS. In the case of different Abstract Characters that are encoded with more than one Valid Code Point, the plain fact is that different input methods appear to result in the same string; but as a matter of fact, those strings are not equivalent. This situation does not have a precedent under the traditional LDH rules. The case of two strings that have the same meaning when treated as words in some language, however, _does_ have a precedent: we treat them as different labels. I want to know why that tradition should be thrown over when we introduce some new code points. Best regards, Andrew -- Andrew Sullivan ajs@anvilwalrusden.com
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
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@eurid.eu http://www.eurid.eu
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@eurid.eu http://www.eurid.eu
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@icann.org [mailto:vip-bounces@icann.org] On Behalf Of Joseph Yee Sent: 26 July 2011 19:31 To: Giovanni Seppia Cc: vip@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@eurid.eu http://www.eurid.eu
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@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@icann.org [mailto:vip-bounces@icann.org] On Behalf Of Joseph Yee Sent: 26 July 2011 19:31 To: Giovanni Seppia Cc: vip@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@eurid.eu http://www.eurid.eu
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@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@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@icann.org [mailto:vip-bounces@icann.org] On Behalf Of Joseph Yee Sent: 26 July 2011 19:31 To: Giovanni Seppia Cc: vip@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@eurid.eu http://www.eurid.eu
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@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@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@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@icann.org [mailto:vip-bounces@icann.org] On Behalf Of Joseph Yee Sent: 26 July 2011 19:31 To: Giovanni Seppia Cc: vip@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@eurid.eu http://www.eurid.eu
We could call that "name aliasing". __ Francisco On 7/29/11 6:50 AM, "Vladimir Shadrunov" <vlad.london.uk@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@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@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@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@icann.org [mailto:vip-bounces@icann.org] On Behalf Of Joseph Yee Sent: 26 July 2011 19:31 To: Giovanni Seppia Cc: vip@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@eurid.eu http://www.eurid.eu
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@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@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@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@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@icann.org [mailto:vip-bounces@icann.org] On Behalf Of Joseph Yee Sent: 26 July 2011 19:31 To: Giovanni Seppia Cc: vip@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@eurid.eu http://www.eurid.eu
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@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@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@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@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@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@icann.org [mailto:vip-bounces@icann.org] On Behalf Of Joseph Yee Sent: 26 July 2011 19:31 To: Giovanni Seppia Cc: vip@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@eurid.eu > http://www.eurid.eu
participants (9)
-
Alexey Mykhaylov -
Andrew Sullivan -
Daniel Kalchev -
Dillon, Chris -
Francisco Arias -
Giovanni Seppia -
JFC Morfin -
Joseph Yee -
Vladimir Shadrunov