[ccnso-idncctld] Conference call for Tuesday 29th - the language committee - thoughts
- To: <ccnso-idncctld@xxxxxxxxx>
- Subject: [ccnso-idncctld] Conference call for Tuesday 29th - the language committee - thoughts
- From: "Chris Disspain" <ceo@xxxxxxxxxxx>
- Date: Mon, 28 Apr 2008 20:52:59 +1000 (EST)
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
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
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.
CEO - auDA
Australia's Domain Name Administrator
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