RE: [jig] Getting started

["Edmon Chung" <edmon@xxxxxxxxxxxxx>]

I think ICANN community has a role to play in promoting IDN TLD acceptance
(even if you think ICANN as a policy coordinator doesn't).

As you mentioned, it is a rather sticky issue... and as a gTLD operator with
a gTLD string of more than 3 characters I can tell you from experience that
it is useful for us to go about it with some unity... More specifically,
resolving the issue for a particular TLD may be different from resolving the
issue for universal acceptance of IDN TLDs (e.g. adding one more TLD to a
white list vs. utilizing an algorithm to determine the validity of a TLD vs.
checking a particular list, etc.)

So I do think this is an issue of common interest between IDN gTLDs and IDN
ccTLDs.

What we can do about it... perhaps is the discussion we can have in this
group later.

Edmon


> -----Original Message-----
> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of Avri
Doria
> Sent: Friday, November 27, 2009 7:25 PM
> To: jig@xxxxxxxxx
> Subject: Re: [jig] Getting started
> 
> 
> Hi,
> 
> I think it might be better called global interoperability for IDNxTLDS.
> 
> Though in order to bother implementing/deploying/replacing an application
that
> supports these new IDNxTLDs, one does need to accept that there is a
reason to
> do so.  This is going to get into the sticky issue of market reason to
bother, just
> like IPv6, people will need so see an incentive for changing all of the
code they
> run.
> 
> I am not sure, though, what part of this is an ICANN issue.  Not saying it
isn't, just
> not sure I understand why it would be.
> 
> IETF needs to make sure that the protocol standards worked.
> ICANN needs to make sure all of the policy issue related to stability and
security
> of the DNS are in place.
> 
> Especially with regard to IDNccTLDs, which are the only ones that will
exist for
> the first while, the sponsors of those IDNccTLDS will have the market
imperative
> of making sure they work in their market area  - which one can assume is
primarily
> in country.
> 
> a.
> 
> On 27 Nov 2009, at 04:05, Stéphane Van Gelder wrote:
> 
> > Thanks Edmon,
> >
> > Are you talking about universal acceptance solely at the technical
level?
> >
> > Stéphane
> >
> > Le 27 nov. 2009 à 04:23, Edmon Chung a écrit :
> >
> >> This sounds like a good conversation and one other clear item of common
> interest between IDN ccTLDs and IDN gTLDs is the acceptance of IDN TLDs by
> systems around the world.  ICANN has been working on the universal
acceptance
> of TLDs: http://www.icann.org/en/topics/TLD-acceptance/
> >>
> >> This issue would clearly be heightened when IDN TLDs are introduced.
> >>
> >> Perhaps one of the items this group can discuss is the universal
acceptance
> of IDN TLDs.
> >>
> >> Edmon
> >>
> >>
> >>
> >>
> >> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of
Terry L
> Davis, P.E.
> >> Sent: Friday, November 27, 2009 5:03 AM
> >> To: 'Andrei Kolesnikov'; jig@xxxxxxxxx
> >> Subject: RE: [jig] Getting started
> >>
> >> Andrei
> >>
> >> I think your suggestions are probably critical to success.
> >>
> >> Fahd, As the different entities begin to plan on their implementations
and
> script standards, I would encourage all to consider the difficulties of
managing
> spelling/script differences to such critical items such as:
> >> -          Firewalls
> >> -          Anti-virus
> >> -          Load balancers
> >> -          Virtualized services
> >> -          Replication services
> >> -          Etc
> >>
> >> Getting the standardized and certified tools to manage these will be
made
> more challenging by variations in the scripts especially if the tools must
> discriminate by the TLD of the domain name as to how they convert the IDN
> names.
> >>
> >> Remember that the “Puny code” name translations as stored in the DNS
are
> unintelligible to anyone, regardless of your native script.  So good tools
will be
> critical to full functionality.
> >>
> >> Take care
> >> Terry
> >>
> >> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of
Andrei
> Kolesnikov
> >> Sent: Tuesday, November 24, 2009 1:09 PM
> >> To: jig@xxxxxxxxx
> >> Subject: RE: [jig] Getting started
> >>
> >> Fahd,
> >>
> >> Just a common sense thought – less mixing of the various scripts, the
easier
> way to launch gTLDs. One of the core success factors of Fast Track is the
script
> restriction. If talking about Latin .arab TLD, you may find the
comfortable
> situation in case where there is no Latin allowed for second level
domains, only
> IDNs, let it be even extended script table, including all scripts you’ve
mentioned.
> You may find useful the same trick for any Arabic .IDN – prohibit Latin
script for
> the second level.
> >> The pressure to gNSO and new gTLDs has a name. This is big businesses
and
> trademarks from the Latin-script world and there is nothing wrong with it.
But this
> pressure can be minimized by restriction for two forms of IDNs:
> >> -          Only IDN second level domains in new latin gTLDs;
> >> -          No Latin second level domains in new IDN gTLDs.
> >>
> >> So, this is  question of  smart combination of Latin and other scripts.
Kind of
> “Fast Barak” (baracca, Italian – fast construction of the building). This
can go as a
> discussion sub-topic for already mentioned.
> >>
> >> If to apply for gTLDs in Cyrillic and understanding of the reality with
TM
> protection in Russia (and Cyrillic-use countries), I would recommend any
applicant
> to restrict gTLD only to Cyrillic and second/third/etc domains to Cyrillic
script only.
> >> “Big Cyrillic” is larger than Russian one, but it’s OK.
> >>
> >> --andrei
> >>
> >> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of
Fahd A.
> Batayneh
> >> Sent: Monday, November 23, 2009 3:01 PM
> >> To: jig@xxxxxxxxx
> >> Subject: Re: [jig] Getting started
> >>
> >> Hi Edmon,
> >>
> >> With respect to your first question, I would suggest discussing both
items
> since they might be of use to the IDN community.
> >>
> >> With regards to the Arabic script in specific and whether policies
should be
> applied alike for cc's and g's, my answer is NO! Since the Arabic script
consists
> of Arabic, Urdu, Farsi, Jawi, and Turkish languages, each community can
devise
> their own language table for their cc. However, as for g's, and since
various
> countries using the same script might require different variants or
digits, a
> different script table would be used. For example, we in Jordan are going
to use
> only the Arabic alphabets we use as an Arabic speaking community with no
> diacritics or variants. Also, we will prohibit digit mixing since digit
mixing is not
> required. However, as for the Arabic table devised for registering the
.arab
> domain (for the entire Arab region in Arabic), we might require some
variants and
> some possible digit mixing!
> >>
> >> We could discuss this issue further in our next telephonic conference
or f-2-f
> meeting.
> >>
> >> Cheers,
> >>
> >> -- FAB
> >> Sent from Amman, Jordan
> >>
> >> On Mon, Nov 23, 2009 at 8:41 AM, Edmon Chung <edmon@xxxxxxxxxxxxx>
> wrote:
> >> Hi Fahd,
> >>
> >> From your explanation, can I understand it to be interest to add an
item for
> discussion on one or both of:
> >> - IDN language table/policy at the root for IDN TLD strings
> >> - Consistency of language table/policy applied for 2nd/3rd level domain
> registrations across TLDs
> >>
> >> I understand that you are talking specifically about the Arabic script,
am trying
> to generalize what you are saying into an item for discussion for this
group.
> >>
> >> With regards to Arabic script specifically, can you share with us
perhaps
> whether you think that the policies should be applied across ccTLDs and
gTLDs
> alike when Arabic IDNs are concerned? and why...
> >>
> >> The JIG is intended to be a group to discuss issues that are common (or
> should be viewed as common or leads to an inter-relation) across IDN
ccTLDs
> and IDN gTLDs.  Especially policy implementation issues at the root and
those
> which ICANN (or IANA for that matter) would concern itself with in
coordinating the
> security and stability of the DNS.  [[Others please correct or add to this
:-)]]
> >>
> >> Edmon
> >>
> >>
> >>
> >>
> >>
> >> From: Fahd A. Batayneh [mailto:fahd.batayneh@xxxxxxxxx]
> >> Sent: Monday, November 23, 2009 2:25 PM
> >> To: Edmon Chung
> >> Cc: jig@xxxxxxxxx
> >> Subject: Re: [jig] Getting started
> >>
> >> Greetings Edmon and Members of the JIG working group,
> >>
> >> First of all, allow me to introduce myself. My name is Fahd, and I
represent JO
> (Jordan). I am one of the additions from the ccNSO.
> >>
> >> Since I am a member of the Arabic Script community, one challenge we
are
> facing is the issue of digit mixing. Other issues that have been discussed
and
> resolvedare the usage of diacritics, as well as zero-width joiners and
zero-width
> non-joiners.
> >>
> >> Since I am not aware of other scripts or languages other than the
Arabic script,
> and since I am not sure if the items I mentioned are of concern to this
working
> group, just thought of bringing them up in case...
> >>
> >> Cheers,
> >>
> >> -- FAB
> >> Sent from Amman, Jordan
> >>
> >> On Mon, Nov 23, 2009 at 6:37 AM, Edmon Chung <edmon@xxxxxxxxxxxxx>
> wrote:
> >>
> >> Hi Everyone,
> >>
> >> I understand that the ccNSO representatives along with some observers
are
> added to this list, and we are ready to get started finally :-)
> >>
> >> One of the discussions we had in Seoul (during the GNSO/ccNSO launch)
was
> that we anticipate the release of a report from the staff IDN team shortly
> (regarding IDN TLD length and variant management). It may be useful for
this
> group to observe some of the outcomes from that effort as well.
> >>
> >> I wonder if anyone can provide some update on the release of that
report?
> >>
> >> Based on previous discussions the 2 items that we have identified as
items of
> common interest were in fact:
> >> 1. Length of IDN TLD strings (ccTLD vs. gTLD)
> >> 2. Variant implementation at the root (for IDN TLD strings)
> >>
> >> Does anyone have any suggestion on other potential items to discuss?
> >>
> >> Edmon
> >>
> >