ICANN ICANN Email List Archives

[ccnso-idncctld]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [ccnso-idncctld] Conference call for Tuesday 29th - the language committee - thoughts

  • To: "'Chris Disspain'" <ceo@xxxxxxxxxxx>, <ccnso-idncctld@xxxxxxxxx>
  • Subject: RE: [ccnso-idncctld] Conference call for Tuesday 29th - the language committee - thoughts
  • From: "Janis Karklins" <janis.karklins@xxxxxxxxxx>
  • Date: Mon, 28 Apr 2008 19:00:58 +0200

Chris,

Thanks for your e-mail and thoughts. 

For me, personally, it is clear that neither IANA staff, nor Board will have
knowledge of all possible scripts and languages which they will be dealing
with during the IDN deployment. Therefore, they need a support from people
who has appropriate knowledge. We may call it linguistic committee, but we
can also call it pool of experts who will be contacted by or asked to liaise
on behalf of IANA staff during the process of developing FT applications.
Their service may be needed also in a longer term because it is hard to
imagine that IANA/ICANN will hire people with knowledge of all scripts and
languages, unless complete reference table will be developed.

Maybe we should discuss and write down what language committee will not do,
to help better understand its role

JK

 

PS. In my view failure is not an option. It is the easiest way forward. JK

 

  _____  

From: owner-ccnso-idncctld@xxxxxxxxx [mailto:owner-ccnso-idncctld@xxxxxxxxx]
On Behalf Of Chris Disspain
Sent: pirmdiena, 2008. gada 28. aprīlī 12:53
To: ccnso-idncctld@xxxxxxxxx
Subject: [ccnso-idncctld] Conference call for Tuesday 29th - the language
committee - thoughts
Importance: High

 

All,

I suggest that we concentrate our discussion tomorrow on the issue of the
language committee which seems to be the main cause of dissension in the WG.
If we can come up with an acceptable solution for this then we will have
covered a significant number of the issues and have a methodology that, in
the main, has a level of consensus in the WG, I believe.

So, some thoughts.

The original purpose of the a ‘language committee’ was to provide a ‘tick in
a box’ that the string was a meaningful representation of the name of the
territory within the definition provided in the methodology.

What does this mean in practice (and this assumes that you accept that there
is a need for the string to be meaningful and that the definition we have
suggested is acceptable)?

The committee would NOT be required in circumstances where a territory
applies for the long form or short form name listed in the ‘list of country
names’ in the attached document (from page 185) in a script also listed in
that document.

The committee would be required if a) a territory is NOT listed on the
attached list but IS listed on the ISO 3166-1 list (obvious examples, Hong
Kong, Taiwan) and/or b) the territory applies for a string that is NOT the
long or short form name on the attached list or is NOT in a script listed in
that document (any language apart from Hindi in India for example).

What does NOT having a language committee mean in practice? It means that
any territory can ‘declare’ that a string is meaningful within the
definition. Thus the adherence to the definition becomes entirely self
assessed.

Does this matter?

Some questions to consider:

1. Does there even need to be a requirement that the string is meaningful?
In my opinion, yes because that is the only way we can ensure that we do NOT
impinge on the development of the full policy. We have to take a
conservative view. The alternative would be to allow (just as an example)
Laos to apply for the Laotian abbreviation of Los Angeles rather than a
meaningful representation of Laos in Laotian. So, assuming that the
definition of meaningful is part of the fast track but adherence to it self
assessed then:

2. Would the ICANN Board have the right to refuse to delegate because they
do not believe that the string is meaningful?
Note that under current policy the Board seeks advice from IANA on a
delegation or re-delegation on issues that IANA deals with. Thus if IANA
advises that the government has not endorsed the application or the local
internet community does not support the ccTLD manager then the Board can
refuse to delegate or re-delegate and send the ‘application’ back for more
work to be done. This happens relatively regularly.

3. If the answer to 2 is no then there is no point in having the requirement
is there? In which case we cannot ensure that we don't impinge on policy
development and we must abandon the fast track as unworkable and wait for
the complete policy to be developed.

4. If the answer to 2 is yes then presumably we would want the Board to be
properly advised. By linguistic experts. And if that's the case, it has to
be better to have the linguists liaise with the 'applicant' at an early
stage if there might be an issue rather than wait until a full blown
'application' is before the Board.

5. Is the problem just a case of wording? Or is the mere principle of having
any form of linguistically expert committee considering a string endorsed by
a government totally unacceptable? If the latter then presumably the answer
to 2 is no and we revert to 3 and abandon the fast track.

6. Is there an alternative? Well, yes, maybe. We could say that FOR THE
PURPOSES OF THE FAST TRACK you can only apply for a string that is a) in a
script listed in the table in the attached document and b) that is or is a
part of the long form or short form name listed in that script in the table.
No questions asked (apart from all the technical stuff of course). And....if
your script is not so listed then you have to get it listed and then you can
apply. That means that governments go and deal with other government
organisations to get their required script and/or name in that script listed
on this formal document and then and only then will ICANN delegate an IDN
ccTLD.

This is basically the same requirement as currently exists for ASCII ccTLDs.
There is no way that Serbia could be delegated a ccTLD until it had gone
through the process of having Serbia placed on the ISO list and having ISO
assign rs as being the 2 letter code for the territory. Until both those
things had happened it didn't matter how pressing a need there was for
Serbia to have its own ccTLD, it couldn't have one.

So maybe that's the answer here. Maybe we need to go back to basics,
understand that the fast track cannot be and is not for everyone and provide
a way that a currently 'non-qualifying' territory can use the fast track
(remembering the intention that it be an open time frame pending the
development of the full policy) by making itself 'qualifying' by getting its
script and/or name in that script listed on the list of country names in the
attached document.

Note however that I do not know if there is a formal method for achieving a
listing and the attached document excludes certain territories from the list
itself (Hong Kong, Taiwan, European Union for example) so there may need to
be some exceptions. And it also means that 'Macedonia' can have Macedonia as
it is a part of their long form name. Which may, or may not, cause a
problem.

Just some thoughts to consider for our call tomorrow.

Cheers,

Chris Disspain
CEO - auDA
Australia's Domain Name Administrator
ceo@xxxxxxxxxxx
www.auda.org.au
 
Important Notice - This email may contain information which is confidential
and/or subject to legal privilege, and is intended for the use of the named
addressee only. If you are not the intended recipient, you must not use,
disclose or copy any part of this email. If you have received this email by
mistake, please notify the sender and delete this message immediately.
Please consider the environment before printing this email.
 



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy