ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

IDN WORKSHOP
ICANN MEETING
WEDNESDAY, 6 DECEMBER 2006
SAO PAULO, BRAZIL

>>TINA DAM: GOOD AFTERNOON, EVERYBODY.

WELCOME TO THE IDN WORKSHOP.

WE'RE GOING TO GET STARTED IN JUST A FEW MINUTES.

AND IF I CAN ASK SPEAKERS AND PANEL MEMBERS TO COME BE SEATED ON THE STAGE.

OKAY, WE'RE GETTING STARTED.

MY NAME IS TINA DAM.

I WORK FOR ICANN.

AND I WORK ON ALL THE IDN-RELATED TOPICS.

AND THIS IS THE INTERNATIONALIZED DOMAIN NAMES WORKSHOP.

A COUPLE OF PRACTICAL REMARKS AS WE GET STARTED.

I MIGHT WANT TO SUGGEST TO THE PEOPLE IN THE BACK OF THE ROOM TO MOVE A LITTLE BIT FURTHER IN THE FRONT.

WE DO HAVE TWO PARTICIPANTS DIALING IN, AND THE AUDIO IS NOT VERY LOUD.

SO IF YOU WANT TO MAKE SURE THAT YOU CAN ACTUALLY HEAR WHAT THEY'RE SAYING, IT HELPS TO BE A LITTLE BIT CLOSER UP IN THE FRONT BY THE MICROPHONES.

THERE WILL BE REMOTE PARTICIPATION AND CHAT ROOM OPTION AVAILABLE.

IF YOU GO TO THE PUBLIC SITE AT SP.ICANN.ORG, YOU WILL FIND CHAT ROOM NUMBER 13.

THERE IS ALSO A LINK TO THAT FROM THE AGENDA THAT IS ON THE MEETINGS AGENDA FOR THIS WORKSHOP.

BUT I'M JUST GOING TO REPEAT IT ONE MORE TIME FOR THOSE OF YOU WHO ARE PARTICIPATING VIA AUDIO OR VIDEO, THAT THE CHAT ROOM WILL BE AT SP.ICANN.ORG.

AND THEN YOU NEED TO FIND A CHAT ROOM IN THERE, OR JUST DIRECTLY ADD SLASH CHATROOMS/CHAT13.

AND IT'S ALL IN ONE.

THE PRESENTATIONS TODAY WILL BE A SET OF SIX DIFFERENT PRESENTATIONS RELATED TO VARIOUS TOPICS GOING ON WITHIN THE COMMUNITY WORKING ON IDNS.

THERE WILL FIRST BE SOME INTRODUCTION FROM CARY KARP AND A STATUS REPORT ON THE GUIDELINES WORK.

THEN I'LL BE GIVING A STATUS REPORT ON HOW THE ICANN TECHNICAL TESTS ARE GOING.

JOHN KLENSIN WILL THEN GIVE A REVIEW OF THE REVISION OF THE IDNA PROTOCOL.

THEN WE'LL HAVE TWO POLICY STATUS UPDATES, ONE FROM THE CCNSO, ONE FROM THE GNSO, FOLLOWED BY A PRESENTATION FROM THE GAC THE ACTIVITIES WITHIN THE GAC WORKING GROUP.

THERE WILL BE PANEL DISCUSSIONS AND OPEN MICROPHONE AFTER EACH PRESENTATION.

AND YOU'LL SEE THAT PRESENTERS AND PANEL MEMBERS ARE SITTING UP HERE.

THE PANEL MEMBERS ARE MEMBERS OF THE PRESIDENT'S ADVISORY COMMITTEE FOR IDNS THAT ARE PRESENT HERE IN SAO PAULO.

SO I'M JUST GOING TO ASK EVERYBODY ON THE STAGE TO JUST QUICKLY INTRODUCE YOURSELF.

AND, ERIN, CAN I ASK YOU TO START.

>>ERIN CHEN: GOOD EVENING, EVERYBODY.

I'M ERIN CHEN, AND I COME FROM TWNIC.

>>BRUCE TONKIN: HELLO, MY NAME IS BRUCE TONKIN. FOR THE PURPOSE OF THIS SESSION, I'M THE ACTING CHAIR OF THE GNSO IDN WORKING GROUP.

>>HONG XUE: I'M HONG XUE, MEMBER OF AT-LARGE ADVISORY COMMITTEE, AND ALSO A MEMBER OF PRESIDENT'S ADVISORY COMMITTEE ON IDN.

>>PAT KANE: PAT KANE, VERISIGN, MEMBER OF THE IDN-PAC.

>>PANKAJ AGRAWALA: PANKAJ AGRAWALA, INDIA'S REPRESENTATIVE IN GAC, CONVENOR OF THE IDN WORKING GROUP IN GAC, AND A MEMBER OF THE PRESIDENT'S ADVISORY COMMITTEE.

>>HIRO HOTTA: MY NAME IS HIRO HOTTA, FROM JPRS, CCTLD FOR .JP.

AND ALSO A MEMBER OF IDN-PAC.

>>MARIA FARRELL: I'M MARIA FARRELL.

I'M WITH ICANN STAFF.

AND I WILL BE READING OUT ANY COMMENTS THAT ARE POSTED IN THE CHAT ROOM.

>>TINA DAM: AND CARY AND JOHN, IF I CAN HAVE YOU JUST INTRODUCE YOURSELF AS WELL, CARY FIRST AND THEN JOHN, AND WE CAN SEE HOW THIS AUDIO IS WORKING.

>>CARY KARP: WELL, FOR THE PURPOSE OF THIS SESSION, I AM A SPEAKER.

I AM ON THE PRESIDENT'S ADVISORY COMMITTEE.

AND I'M THE ONE WHO HOLDS THE PENS FOR THE GROUP MAINTAINS THE IDN GUIDELINES THAT WILL BE PRESENTING.

>>JOHN KLENSIN: AND I AM JOHN KLENSIN.

AND FOR THE PURPOSES OF THIS SESSION, I'M A SPEAKER AND FAIRLY HEAVILY INVOLVED IN THE IETF IDN REVIEW AND REVISION WORK.

>>TINA DAM: THANK YOU.

THE FIRST PRESENTATION IS BY CARY.

AND, CARY, YOUR SLIDES ARE UP ON THE SCREEN.

SO PLEASE GO AHEAD.

>>CARY KARP: OKAY.

TINA, HOW DO YOU WANT ME TO TELL YOU WHEN I WANT YOU TO CHANGE THE SLIDES?

JUST SAY "SLIDES," AND YOU PUSH THE BUTTON?

>>TINA DAM: THAT'S PERFECT.

>>CARY KARP: OKAY.

WELL, THEN IF WE CAN GO TO THE FIRST OF THE SUBSTANTIVE SLIDES.

I AM GOING TO BE INTRODUCING WHAT IS GOING TO BECOME A VERY DENSE PRESENTATION OF NUMEROUS ASPECTS ABOUT THE PROTOCOL BASIS FOR IDN.

AND THE SPECIFIC THING, THESE IDN GUIDELINES, ARE THE END OF THAT CHAIN.

THERE ARE NUMEROUS DECISIONS THAT NEED TO BE MADE.

SOME CAN BE AUTOMATED, SOME CAN'T BE AUTOMATED.

AND THE GUIDELINES HAS ITS POSITION IN THAT.

BUT THE PROTOCOL BASIS FOR ALL OF THIS IS DESCRIBED IN AN OVERRIDING DOCUMENT, RFC 3490, INTERNATIONALIZING DOMAIN NAMES AND APPLICATIONS, WHICH WAS PUBLISHED IN MARCH 2003.

THERE ARE THREE OTHER DOCUMENTS IN THE PROTOCOL SUITE THAT DEFINES THE BASICS OF IDN.

OKAY.

BUT IN THAT OVERRIDING DOCUMENT, AN INTERNATIONALIZED DOMAIN NAME IS DEFINED AS A DOMAIN NAME IN WHICH EVERY LABEL IS AN INTERNATIONALIZED LABEL.

THIS IMPLIES THAT EVERY ASCII DOMAIN IS AN IDN, WHICH IMPLIES THAT IT'S POSSIBLE FOR A NAME TO BE AN IDN WITHOUT CONTAINING ANY NON-ASCII CHARACTERS.

AND AN ASCII -- SORRY, AN INTERNATIONALIZED LABEL IS EVERY ASCII LABEL THAT SATISFIES THE 63-CHARACTER LENGTH RESTRICTION.

AND IT SHOULD BE NOTED THAT THAT RESTRICTION IS NOT A PART OF THE DNS.

THAT'S MORE FUNDAMENTALLY ENMESHED IN THE INTERNET PROTOCOLS.

SO THERE'S BEEN A LOT OF DISCUSSION ABOUT THERE BEING SOME BIAS BEING THRUST UPON PEOPLE BY THAT LIMITATION.

BUT, AGAIN, IT IS EXTERNAL TO THE DNS, ON A LOWER LEVEL.

OKAY.

ALL OF THIS IMPLIES THAT AN INTERNATIONALIZED -- FOR THE TERM INTERNATIONALIZED DOMAIN NAME DESIGNATED ANY DISPLAYED FORM OF A DOMAIN NAME, NO MATTER WHAT THE DISPLAY CHARACTERS ARE.

OKAY.

THE STORED FORM OF A DOMAIN NAME, HOWEVER, IS STILL RESTRICTED TO ASCII, ALSO, WITHOUT ANY REGARD TO WHAT THE DISPLAY FORM IS.

OKAY.

SO, TINA, CAN WE GO TO THE SLIDE THAT HAS "SAO PAULO" ON IT.

I SHOULD HAVE BEEN SAYING, SLIDE, SLIDE, SLIDE, ACTUALLY.

I'VE JUST JOGGED THROUGH SIX SLIDES.

>>TINA DAM: YES, WE'RE THERE RIGHT NOW.

>>CARY KARP: OKAY.

SO IT WOULD BE PERFECTLY REASONABLE TO REGISTER A NAME IN THE FORM SAO PAULO DOT WHATEVER THE TLD HAPPENS TO BE.

AND THAT IS WHAT WILL BE DISPLAYED IN WHATEVER CONTEXT ONE WISHES TO DISPLAY IT.

BUT THE ACTUAL NAME STORED IN THE DNS IS THE ASCII SEQUENCE, ACCENT DASH DASH SO DASH SIA .PAULO.TLD.

THIS PAIR OF NAMES THAT IS AN IDN, THE ONE THAT IS THE DISPLAYED FORM, THE OTHER, THE STORED FORM, CAUSES QUITE A BIT OF CONFUSION.

BUT IT'S ACTUALLY ONLY ONE OF THE REASONS WHY IDN IS REGARDED AS A COMPLICATED MATTER.

NEXT SLIDE.

OKAY.

A SECOND REASON IS THAT THE DEFINITION THAT'S IMPLIED IN THE IDNA DOCUMENT DIFFERS FROM THE POPULAR UNDERSTANDING OF THE TERM.

AND WE'VE ACTUALLY NOT QUITE FOUND A REALLY GOOD WAY TO DEFINE THAT IN A MANNER THAT ELIMINATES RATHER THAN JUST PROPAGATES THIS CONFUSION.

OKAY.

SLIDE, PLEASE.

AND THERE'S A THIRD REASON WHY THIS IS REGARDED AS SO COMPLICATED, AND THAT IS, THERE IS A VERY, VERY IMPORTANT DISTINCTION BETWEEN THE SETS OF GRAPHIC SYMBOLS THAT ARE USED FOR WRITING LANGUAGES, THINGS THAT ARE CALLED -- SPEECH AGGREGATE BEING TERMED AS "SCRIPT."

AND THE SLIDES THEMSELVES.

THE CYRILLIC SCRIPT IS USED FOR WRITING THE BULGARIAN, RUSSIAN, SERBIAN, UKRAINIAN, AND NUMEROUS OTHER LANGUAGES.

SLIDE.

THE ROMAN SCRIPT IS ALSO CALLED LATIN SCRIPT, BUT I'M CALLING IT ROMAN HERE SIMPLY TO DISTINGUISH BETWEEN THE LANGUAGE NAMED LATIN AND THE SCRIPT NAMED ROMAN.

OKAY.

AND HERE WE HAVE ANY NUMBER OF LANGUAGES.

I'VE LISTED A FEW OF THEM.

ALBANIAN, ENGLISH, FRENCH, GERMAN, PORTUGUESE, SPANISH, SWAHILI.

ALL OF THESE LANGUAGES ARE WRITTEN USING THE ROMAN SCRIPT.

AND THE ASCII CHARACTER SET IS COMPLETELY INADEQUATE -- SORRY, "COMPLETELY" IS THE WRONG WORD -- IS INADEQUATE FOR THE FULL ORTHOGRAPHIC REPRESENTATION OF ALL OF THESE LANGUAGES WITH ONE EXCEPTION.

I'LL ALLOW YOU TO GUESS WHAT THAT EXCEPTION IS.

BUT IT IS NOT ENGLISH.

ENGLISH CAN AS LITTLE BE REPRESENTED WITH ASCII AS MANY OTHER LATIN-BASED, ROMAN-BASED LANGUAGES CAN.

THERE'S A THRESHOLD OF PAIN THAT OBVIOUSLY INCREASES THE MORE NON-ASCII CHARACTERS YOU REQUIRE.

BUT IT IS A MYTH TO ASSUME THAT ALL OF THIS SUITS THE PURPOSE OF ENGLISH PERFECTLY AND SUITS OTHER PURPOSES INCREASINGLY LESS PERFECTLY.

NEXT SLIDE, PLEASE.

THERE'S A UNIVERSAL CHARACTER SET BEST KNOWN PERHAPS AS UNICODE, WHICH IS DIVIDED INTO 64 DIFFERENT SCRIPTS.

AND THERE ARE A FEW MORE IN WHAT'S CALLED THE PIPELINE.

BUT NOT ALL OF THESE SCRIPTS ARE ACTUALLY USED FOR THE WRITING OF CONTEMPORARY LANGUAGES, AND A SMALLER NUMBER THAT REMAIN ARE GOING TO APPEAR IN ANY REASONABLE DISCUSSION OF IDN.

THERE'S ALSO SOME OVERLAP, SOME SIMILARITY BETWEEN THESE SCRIPTS THAT IS RELEVANT IN THE CONTEXT OTHER THAN IDN, BUT NOT TO OUR PURPOSES.

NEXT SLIDE, PLEASE.

I'M RESTRICTING THIS DISCUSSION TO CYRILLIC AND ROMAN SIMPLY BECAUSE I CAN BE ABSOLUTELY CERTAIN THAT TINA IS USING A COMPUTER THAT WILL ALLOW ME TO SHOW YOU CHARACTERS IN THESE TWO SCRIPTS.

BUT THE REALLY RICH SCRIPTS, THE ONES THAT SUPPORT LARGE NUMBERS OF LANGUAGES WITH THE LARGEST SPEECH COMMUNITIES, ARE, IN FACT, OTHERS.

CHINESE IS A VERY GOOD EXAMPLE.

ARABIC IS USED IN MASSIVE NUMBERS OF CONTEXTS.

BUT, AGAIN, JUST THE TECHNICAL RESTRICTIONS OF THE POWERPOINT MEDIUM MAKES IT ADVISABLE FOR ME NOT TO DEMONSTRATE JUST HOW ERUDITE I THINK I COULD GET ON THE SUBJECT.

THE NUMBER OF LANGUAGES THAT ARE LIKELY TO APPEAR ULTIMATELY IN THE IDN SPACE IS PROBABLY HUNDREDS.

THE BEST CURRENT LINGUISTIC ESTIMATE OF THE NUMBER OF LANGUAGES SPOKEN IN THE WORLD TODAY -- AND IT'S A ROUGH ESTIMATE -- TENDS TO BE AROUND 6,500.

THAT'S THE MOST OFTEN-CITED FIGURE.

BUT CERTAINLY LESS THAN 10% -- A SMALL FRACTION OF THEM ARE WRITTEN, AND A FRACTION OF THOSE, AGAIN, ARE GOING TO APPEAR IN IDN.

SO WE NEED TO ACCOMMODATE DOZENS OF SCRIPTS AND HUNDREDS OF LANGUAGES.

AND IT IS VERY IMPORTANT TO NOTE THAT THESE TWO TERMS ARE NOT SYNONYMOUS.

OKAY.

UNICODE DESCRIBES -- NEXT SLIDE, PLEASE -- NUMEROUS CHARACTER ATTRIBUTES THAT CAN BE USED TO AUTOMATE THE PROCESS OF MAKING DECISIONS ABOUT IDN.

IF TWO CHARACTERS CAN APPEAR TOGETHER OR NUMBERS OF OTHER CONTEXTUAL THINGS.

THE EXTENT TO WHICH THIS CAN BE EXTENDED FOR A REALLY USEFUL AUTOMATION OF LANGUAGE-BASED POLICY ENFORCEMENT IS CURRENTLY THE SUBJECT OF SOME SCRUTINY AND DEBATE.

WE ARE IN THE PROCESS, AS WILL YOU HEAR MORE LATER, ABOUT HOW FAR WE CAN GET ON WHAT -- WELL, THE TERM IS ALGORITHMIC.

WHAT WE CAN DO ALGORITHMICALLY, WHAT MACHINES DECIDE WHAT WE CAN BE PERMITTED TO DO AS HUMAN BEINGS AND WHAT WE CANNOT DO.

REGARDLESS OF THE OUTCOME OF THIS, HOWEVER FAR WE GET IN THIS PROCESS ON AN AUTOMATED BASIS, AT SOME POINT, THE RESPONSIBLE DEPLOYMENT OF IDN IS GOING TO REQUIRE REGISTRIES TO ADOPT POLICIES THAT ARE SPECIFIC TO THE COMMUNITIES THAT THEY SERVE.

IN THE CC CONTEXT, THOSE COMMUNITIES ARE VERY LIKELY TO BE LANGUAGE-BASED.

IN THE GTLD CONTEXT, THEY ARE GOING TO BE COMMUNITY-BASED, WITH OTHER ATTRIBUTES THAT UNDERLIE THE COHESION IN THAT DOMAIN.

AND IN COMPLETELY UNRESTRICTED DOMAINS, IT'S SIMPLY GOING TO BE A MATTER OF A DOMAIN THAT SOME PROSPECTIVE NAMEHOLDER REGARDS AS ATTRACTIVE

ALL OF THESE, HOWEVER, NEED TO SPEND SOME CLEAR THOUGHT TO HOW THEY ARE GOING TO SUPPORT IDN.

SIMPLY SUPPORTING ALL OF THE CHARACTERS THAT THE PROTOCOLS PERMIT TO BE USED HAS CAUSED THE SITUATION THAT HAS US TALKING ABOUT THIS TODAY.

IT'S THE WAY WE GOT STARTED, AND WE'VE LEARNED DURING THE PAST THREE YEARS THAT IT'S NOT A VERY SATISFACTORY WAY TO PROCEED.

NEXT SLIDE.

OKAY.

NOW, VERY SHORTLY AFTER THE AVAILABILITY OF THE IDNA PROTOCOLS, ICANN RELEASED THE FIRST VERSION OF ITS GUIDELINES FOR THE IMPLEMENTATION OF INTERNATIONALIZED DOMAIN NAMES.

THIS HAD A PRETTY CLEAR RELATIONSHIP TO THE CONTRACTUAL BOND BETWEEN ICANN AND THE NEW GTLDS, AND EACH GTLD THAT WISHED TO OFFER SUPPORT FOR IDN NEEDED TO SIGN A STATEMENT OF INTENTION TO ADHERE TO THE GUIDELINES AND TO COLLABORATE IN THEIR FURTHER DEVELOPMENT.

NOW, AT THE TIME THESE GUIDELINES WERE DRAFTED, FOR A NUMBER OF REASONS, THE CONCEPT OF SCRIPT AND THE CONCEPT OF LANGUAGE WERE EQUATED TO A CERTAIN EXTENT, AND THERE WAS CERTAIN UNWILLINGNESS TO DEAL WITH THE -- WITH THE POTENTIAL POLITICAL RAMIFICATIONS OF PROCEEDING ON A SCRIPT-BASED PLATFORM.

SO IT WAS DECIDED IN THESE GUIDELINES THAT ALL POLICIES ATTACHING TO AN IDN WOULD BE SET ON THE BASIS OF LANGUAGE.

IN IMPLEMENTING THE IDN STANDARDS, TOP-LEVEL DOMAIN REGISTRIES WILL ASSOCIATE EACH REGISTERED INTERNATIONALIZED DOMAIN NAME WITH ONE LANGUAGE OR SET OF LANGUAGES.

THE PROBLEM IS -- NEXT SLIDE, PLEASE -- I'M SORRY.

I'M BEING VERY POOR ABOUT TELLING YOU, TINA, HOW TO ADVANCE THESE.

I'M ON SLIDE 21 NOW.

>>TINA DAM: THAT'S OKAY.

WE'RE ON THE RIGHT SLIDE, STARTING WITH "THIS LEFT."

>>CARY KARP: OKAY.

THANKS.

THE CONCEPT OF SET OF LANGUAGES WAS REALLY FUZZY, COUPLED WITH THE FACT THAT UNICODE DOESN'T SAY WHAT LANGUAGES ARE.

UNICODE SIMPLY AGGREGATES SOME INDIVIDUAL CHARACTERS INTO SCRIPTS.

THERE WAS JUST A LOT OF WHAT TURNED OUT TO BE UNFORTUNATE LATITUDE.

IF A REGISTRY, FOR EXAMPLE, DECIDED THAT IT WAS GOING TO BE SUPPORTING BOTH GERMAN AND RUSSIAN AND DECIDED THAT THESE TWO LANGUAGES REASONABLY BELONGED IN THE SAME SET, WHAT DID THAT MEAN?

DID THAT MEAN THAT CYRILLIC AND ROMAN CHARACTERS COULD APPEAR IN THE SAME LABEL?

AND THERE ARE, IN FACT, EXAMPLES OF NAMES LIKE THAT.

THERE'S A VERY FAMOUS PAYPAL SITUATION, WHICH IS A MIXTURE OF ROMAN AND CYRILLIC LETTERS, THAT TRIGGERED THE PRESENT REVIEW OF THE RESTRAINT, THE CONSTRAINT THAT'S NEEDED FOR IDN TO BE SOMETHING BOTH USEFUL AND NONTHREATENING TO THE INTEGRITY OF THE DNS.

NEXT SLIDE, PLEASE.

SO IT WOULD BE ENTIRELY POSSIBLE IN THAT CASE TO HAVE THIS LIST OF -- HOW MANY NAMES DO I HAVE HERE? -- EIGHT NAMES.

EACH OF THESE IS AN ENTIRELY SEPARATE LABEL.

THEY ARE NOT IDENTICAL IN ANY REGARD OTHER THAN THAT LOOKING AT THEM, YOU'D SURE THINK THAT THEY WERE.

THE FIRST OF THEM IS THREE ROMAN A'S.

THE SECOND IS THREE CYRILLIC A'S.

AND EACH OF THE REMAINING ONES IS TWO OF ONE, ONE OF THE OTHER, IN ALL POSSIBLE PERMUTATIONS.

OKAY, NEXT SLIDE.

AND JUST TO HAVE IT SAID, HOW CAN ONE SAY WHAT LANGUAGE IS INTENDED WHEN A LABEL IS AAA OR ANY NUMBER OF ABSOLUTELY REASONABLE IDENTIFIERS THAT ARE NOT INTENDED TO BE WORDS IN ANY LANGUAGE?

SO THE CONCEPT OF LANGUAGE AND THE CONCEPT OF DOMAIN IDENTIFIER DON'T MATCH PERFECTLY.

HOWEVER, EVERY DOMAIN IDENTIFIER STILL NEEDS TO BE EXPRESSED IN A SCRIPT OR COMBINATION OF SCRIPTS.

SO WE CAN DESCRIBE BOTH NAMES, WORDS, LABELS, ALPHANUMERIC IDENTIFIERS IN TERMS OF SCRIPTS.

BUT, ACTUALLY, ONLY IN -- IN THE CASE THAT A LABEL HAPPENS TO BE A DICTIONARY WORD AND IT'S CLEAR WHAT THAT LANGUAGE IS CAN WE SPEAK WITH ANY SURETY ABOUT LANGUAGE.

OKAY.

AND IN ADDITION TO THOSE IDENTICAL SETS OF A'S, THERE ARE ALL SORTS OF, MY GOODNESS, WHAT IS THIS ALL ABOUT, DECORATED, AS THEY'RE CALLED, VERSIONS OF THIS LETTER.

AND IF I WANTED TO USE MORE THAN SIMPLY THE CHARACTER THAT LOOKS LIKE AN "A," THIS COULD BE EXTRAORDINARILY ARTFUL AND EXTRAORDINARILY CONFUSING.

WE UNDERSTAND THAT IT IS TOO CONFUSING TO BE PERMITTED TO CONTINUE WITHOUT SOME INJECTION OF ADDITIONAL CONSTRAINT.

OKAY.

WE KNEW THAT, ACTUALLY, PRETTY EARLY ON.

AND THE IDN GUIDELINES -- SORRY -- YES, THE IDN GUIDELINES -- THE IDN GUIDELINES WERE REVISED IN NOVEMBER 2005.

THAT'S JUST OVER A YEAR AGO.

AT THIS TIME, WHAT HAPPENED WAS, THE PRIMARY CONSTRAINT WAS ATTACHED, THE PRIMARY POLICIES WERE ALL LINKED TO SCRIPT.

IN IMPLEMENTING THE IDN STANDARDS, TOP-LEVEL DOMAIN REGISTRIES WILL ASSOCIATE EACH LABEL IN A REGISTERED INTERNATIONALIZED DOMAIN NAME AS IT APPEARS IN THEIR REGISTRY WITH A SINGLE SCRIPT.

OKAY.

BUT IT RECOGNIZES THAT THIS MIGHT NOT BE ADEQUATE IN AND OF STEP AND ALLOWS, IF GREATER SPECIFICITY IS NEEDED, THE ASSOCIATION MAY BE MADE BY COMBINING THE SCRIPT FOR BOTH LANGUAGE AND SCRIPT.

HERE NOW WE'RE GETTING BACK INTO WHAT EXACTLY DOES THIS MEAN LANGUAGE, AND WE STILL HAVE THE LOOPHOLE WHERE REFERENCE IS MADE TO SETS OF LANGUAGES, ALTHOUGH THERE'S FURTHER REFERENCE MADE TO THE CONDITIONS UNDER WHICH SETS OF LANGUAGES -- UNDER WHICH LABELS CAN BE ASSOCIATED WITH A SET OF LANGUAGES.

BUT THAT DOESN'T MEAN THIS SUBSET OF LANGUAGE CONCEPT IS NO LONGER AMENABLE TO ANY FORM OF ABUSE.

OKAY, NEXT SLIDE.

THE GENERAL BAN ON SCRIPT MIXING WOULD MAKE THAT LIST OF AAA LOOK-ALIKES FAR SHORTER THAN IT IS.

WE'D ONLY HAVE THE PURELY CYRILLIC OR THE PURELY ROMAN ALTERNATIVE.

BUT THE NUMBER OF COMBINATIONS THAT WE CAN HAVE OF LEGITIMATELY DECORATED ROMAN CHARACTERS IS STILL ENORMOUS.

IN FACT, OF THE LIST THAT YOU SAW, THERE WAS ONLY ONE OF THEM THAT WOULD DISAPPEAR.

>>TINA DAM: CARY, WHAT SLIDE NUMBER ARE YOU ON?

>>CARY KARP: 29.

>>TINA DAM: GREAT.

>>CARY KARP: OKAY.

AND FOR REASONS THAT REALLY BAFFLE THOSE OF US WHO HAVE BEEN WORKING WITH THE WORDSMITHING OF THESE GUIDELINES, WE HAVE A GUIDELINE THAT RESTRICTS THE USE OF PUNCTUATION MARKS AND ALL OF THE OTHER GRAPHIC SYMBOLS THAT DON'T CORRELATE TO THE PHONETIC COMPONENTS OF SPOKEN LANGUAGE.

AND HERE'S THE TEXT.

AND I DON'T KNOW WHY PEOPLE REGARD IT AS DIFFICULT TO UNDERSTAND.

THIS IS THE ONE THAT I WILL NOT BOTHER READING.

BUT IT DOES SAY THAT PURELY GRAPHIC THINGS, LINE-DRAW CHARACTERS, BOXES OF WHAT ARE CALLED DINGBATS, ALL OF THESE HAVE NO PLACE IN A DOMAIN NAME.

AND, IN FACT, THAT IS SUBJECT TO SOME DEBATE.

THERE ARE PEOPLE WHO DO FEEL THAT A TELEPHONE SYMBOL IS A REASONABLE THING TO HAVE IN A DOMAIN IDENTIFIER.

AND THIS IS AN ASPECT OF THE DISCUSSION THAT IS NOT SIMPLY ONGOING, BUT -- WELL, IT IS SIMPLY ONGOING.

BUT IT'S ON ITS WAY INTO LEVELS OF UNPRECEDENTED COMPLEXITY, AND WE'RE NOT QUITE SURE WHEN WE'LL BEGIN TO EMERGE ON THE OTHER SIDE.

BUT WE CAN, WITH SOME CERTAINTY, NOTE THAT WE HAVE TO EMERGE ON THE OTHER SIDE.

OKAY.

SLIDE -- THE NEXT ONE -- MY GOODNESS, MY SLIDE NUMBERS HAVE JUST CHANGED ON ME.

I HAVE A SLIDE NUMBER 10, RIGHT AFTER SLIDE 31 IN MY DECK.

BUT IT DOESN'T MATTER.

IF YOU GO TO THE NEXT SLIDE.

TO WHATEVER EXTENT WE CAN FIGURE OUT HOW TO AUTOMATE THE REDUCTION OF THE HUNDREDS OF THOUSANDS OF CHARACTERS THAT ARE LISTED ON THE UNIVERSAL CHARACTER SET TO A SAFER REPERTOIRE FOR DNS.

AND THIS IS SOMETHING THAT WE CAN ONLY DO ON THE BASIS OF SCRIPT.

TURNING THIS INTO SOMETHING THAT IS A TRULY DNS SAFE CHARACTER REPERTOIRE IS GOING TO REQUIRE QUITE A BIT OF GOODWILL, SHARED GOODWILL AND COMMON SENSE, AND A FEELING OF RESPONSIBILITY, NOT SIMPLY FOR THE LANGUAGE AND CULTURAL REQUIREMENTS OF THE COMMUNITIES THAT WE ARE MEMBERS OF, BUT ALSO FOR THE INTEGRITY OF THE DOMAIN NAME SPACE.

THIS THING WAS NEVER DESIGNED TO BE A MEDIUM FOR LITERARY EXPRESSION.

AND ALTHOUGH THERE IS A WHOOPING DIFFERENCE BETWEEN WHAT COULD BE REGARDED AS LITERARY EXPRESSION AND TEN OR SO ELEMENTS FROM A GIVEN SCRIPT, IT'S STILL A SAMPLE MATTER OF FACT THAT EVERYTHING THAT WOULD BE NECESSARY FOR THE NORMAL WRITING OF A LANGUAGE IS SIMPLY NOT AVAILABLE FOR INCLUSION IN A DOMAIN NAME.

AND I DON'T THINK THERE'S ANY MASSIVE BIAS IN FAVOR OF OR AGAINST ANY LANGUAGE OTHER THAN THIS BUSINESS ABOUT THE ABILITY SIMPLY TO GRIN AND BEAR THE CONSTRAINTS THAT THE PRE-IDN ASCII REPERTOIRE IMPOSED.

LANGUAGE IS GOING TO FIGURE VERY PROMINENTLY IN THE DISCUSSION ABOUT WHAT THIS LEVEL OF SAFETY CAN AND SHOULD BE.

WE'RE TALKING ON THE ONE HAND ABOUT THE PERSPECTIVE OF THE TECHNICAL COMMUNITY THAT HAS A VERY, VERY CLEAR UNDERSTANDING OF WHAT THE INTERNET CAN SUSTAIN, WHAT THE DOMAIN NAME SYSTEM CAN SUSTAIN, AND ON THE OTHER HAND, THE SPEECH COMMUNITIES THAT WISH TO BECOME ALL THE MORE ACTIVELY CONTRIBUTING TO AN INTERNET THAT, INDEED, IS AVAILABLE FOR EVERYBODY AND CONTAINS MEANINGFUL CONTENT IN LANGUAGES THAT EVERYBODY UNDERSTANDS.

BUT THERE MAY BE SOME ELEMENT OF EXAGGERATED EXPECTATION ABOUT THE ROLE THAT IDN PLAYS IN THIS.

SO ONE VERY CLEAR WAY TO INDICATE LANGUAGE IDENTITY IN A DOMAIN NAME CAN, INDEED, BE TO TAKE A WORD THAT IS RECOGNIZABLY AN ELEMENT OF THE DICTIONARY OF ONE LANGUAGE AND NO OTHER LANGUAGE.

BUT IT MAY ALSO BE SO THAT THERE IS SOME NUANCE OF IT, SOME GRAPHIC REPRESENTATION, THAT CAN BE CONVEYED THERE.

AND THESE ARE THE KINDS OF THINGS THAT HAVE TO BE TALKED ABOUT.

SOME HEIGHTENED SENSE OF UNDERSTANDING OF CULTURAL REQUIREMENT PROBABLY DOES NEED TO BE REQUIRED IN SOME QUARTERS OF THE TECHNICAL COMMUNITY, AND IT IS CERTAINLY TRUE THAT MY SENSE OF UNDERSTANDING ABOUT THEM, JUST HOW MUCH OF A TECHNICAL STRAITJACKET IS IMPOSED UPON ALL OF THIS NEEDS TO BE ASSIMILATED BY PEOPLE WHOSE ONLY INTEREST IN THIS IS THE VERY LEGITIMATE ONE OF BEING ABLE TO PARTICIPATE IN USING THEIR LANGUAGE AND NOT SOMEBODY ELSE'S.

OKAY.

NEXT SLIDE.

THERE'S BEEN SOME SUGGESTION THAT THE SENSITIVITY OF THAT DEBATE WOULD BE LESS IF WE COULD FOCUS ON SCRIPT RATHER THAN LANGUAGE.

BUT, IN FACT, THERE ARE VERY, VERY SENSITIVE CULTURAL CONDITIONS THAT ATTACH BOTH TO SCRIPT AND TO LANGUAGE, WHERE THERE ARE SCRIPTS THAT PRIMARILY EXIST BECAUSE THERE'S A SACRED WRITING THAT USES THEM.

AND IT IS THE CHARACTERS THEMSELVES THEIR IMBUED WITH THE RELIGIOUS SIGNIFICANCE, IF ONE WILL.

SO, YES, THERE'S AN AWFUL LOT THAT IS -- THAT NEEDS TO BE STRAIGHTENED OUT IN THE DISCUSSION OF LANGUAGE, AND THERE IS AN AWFUL LOT THAT NEEDS TO BE STRAIGHTENED OUT IN THE DISCUSSION OF SCRIPT. AND WE DO NEED TO DISCUSS BOTH OF THEM IF WE'RE GOING TO DISCUSS RESPONSIBLE IDN POLICIES THAT DON'T JEOPARDIZE THE OPERATION OF THE DNS AND DON'T IN ANY WAY IMPOVERISH ANYONE CULTURALLY MORE THAN ANYONE ELSE AS THEY EXPRESS THEMSELVES IN THE DOMAIN NAME SPACE, WHICH, PLEASE NOTE, IS NOT THE SAME THING AS THE CONTENT SPACE.

BUT AGAIN, WE ARE NOT GOING TO MAKE THIS DISCUSSION ANY LESS PASSIONATE BY SAYING PLEASE, FOLKS, CAN WE FOCUS ON EITHER SCRIPT OR LANGUAGE.

BOTH OF THEM ARE JUST LADEN WITH ALL SORTS OF THINGS THAT WE NEED TO WORK THROUGH.

NEXT SLIDE.

NOW, THE ICANN GUIDELINES, DESPITE THEIR ORIGINS AND THE CONTRACTUAL RELATIONSHIP BETWEEN ICANN AND THE GTLDS, THESE GUIDELINES ARE INTENDED TO DESCRIBE TLD REGISTRY PRACTICE IN A MANNER THAT CAN BE USEFULLY APPLIED ON ANY LEVEL IN THE DOMAIN NAME SYSTEM. SO ANY REGISTRY, IF IT'S THE SECOND LEVEL, THIRD LEVEL OR FOURTH LEVEL REGISTRY THAT WISHES TO SUPPORT IDN WILL HOPEFULLY DERIVE SOME BENEFIT FROM THAT BY THE GUIDELINES.

AND BECAUSE THE COMPELLING ATTRIBUTE OF THEIR USE IS RESTRICTED TO SUCH A SMALL SEGMENT OF THE REGISTRY OPERATING COMMUNITY, THESE GUIDELINES ARE TO BE FRAMED AND PUT FORWARD IN A MANNER THAT IS INHERENTLY COMPELLING.

THE OPERATOR OF ANY REGISTRY NEEDS TO READ THESE THINGS AND SAY, HEY, THIS REALLY DOES MAKE GOOD SENSE. AND WE ARE GOING TO DO OUR BEST TO FOLLOW THIS AS WE IMPLEMENT IDN IN OUR REGISTRY.

ONE OF THE OTHER UNCOMFORTABLE TRUTHS ABOUT THE WAY THE DNS IS SET UP IS THERE IS REALLY NO CLEAR ENFORCEMENT MECHANISM.

THE ROOT OPERATORS CAN SAY WHAT POLICIES NEED TO BE APPLIED TO IDN IN THE ROOT ZONE.

THE TLD OPERATORS CAN DECIDE WHAT POLICIES NEED TO BE OBSERVED BY THE HOLDERS OF SECOND-LEVEL NAMES IN THEIR TLDS. BUT WHAT HAPPENS ON THE THIRD LEVEL, WHAT HAPPENS ON THE FOURTH LEVEL, WHAT HAPPENS ON THE FIFTH LEVEL IS SOMETHING THAT IS BEYOND THE CONTROL OR, IN FACT, EVEN KNOWLEDGE OF THE OPERATORS OF THE TLDS.

SO WE TLD OPERATORS CAN, INDEED, AGREE UPON POLICIES THAT WILL BE APPLIED ON THE SECOND LEVEL OF THE DOMAIN NAME SYSTEM, BUT THE ONLY WAY TO ENSURE AT LEAST SOME REASONABLE DEGREE OF CONSISTENCY FURTHER DOWN IN THE NAME TREE IS, AGAIN, A COMMON-SENSE BASIS. THAT WHAT IS BEING DONE IS SO CLEARLY NECESSARY TO DO THAT EVERYBODY IS GOING TO WANT TO DO IT.

I REALIZE HOW INCREDIBLY NAIVE AND BLUE-EYED A STATEMENT LIKE THAT IS, BUT WE ARE ULTIMATELY VULNERABLE TO THAT.

IF NOTHING OTHER THAN INTEREST IN JUST HOW FAR ALL OF THIS CAN BE STRETCHED IS MANIFESTED, WE ARE IN A REAL AWKWARD SITUATION.

AND THE EXTENT TO WHICH PROTOCOL LEVEL CONSTRAINT CAN BE APPLIED TO THIS IS, IN FACT, APPLICABLE ON ALL LEVELS OF THE DOMAIN NAME TREE, BUT THAT'S ACTUALLY -- IT WON'T BE ENOUGH IN AND OF ITSELF.

WE CAN CERTAINLY MAKE THE SITUATION CLEARLY BETTER THAN IT CURRENTLY IS, AND WE ARE IN THE PROCESS OF DOING THAT, BUT WE CANNOT MAKE IT GOOD WITHOUT THE ASSISTANCE OF EVERY PARTICIPANT EXERCISES THIS GRAND ADVENTURE.

ALTHOUGH ICANN HAS MADE A NUMBER OF ATTEMPTS AND OTHER ORGANIZATIONS HAVE MADE A NUMBER OF ATTEMPTS A ESTABLISHING PUBLIC DISCUSSION FORUMS WHERE ALL OF THIS CAN BE AIRED IN THE SPECIFIC CONTEXT OF THE IDN GUIDELINES -- TINA, WILL YOU SHOW THE FINAL SLIDE -- SINCE I HOLD THE PEN AND I AM IN A POSITION TO PROMISE THOSE THAT ARE HEARING ME SAY IT, THAT ANYTHING THAT IS CONTRIBUTED TO THIS FORUM WILL BE CAREFULLY HEEDED AS THE GUIDELINES ARE DEVELOPED FURTHER, PLEASE, IF THIS IS A MATTER OF INTEREST TO YOU, LET US KNOW.

THAT'S IT. THAT'S THE PRESENTATION AND I'LL GLADLY ANSWER ANY QUESTIONS YOU HAVE.

>>TINA DAM: THANK YOU VERY MUCH, CARY. SO THE FLOOR IS OPEN FOR QUESTIONS. AND PANEL, AS WELL, IF YOU HAVE ANY QUESTIONS OR COMMENTS.

AND I AM GOING TO SEE IF WE CAN MAKE SOME SORT OF QUEUE GOING BACK AND FORTH BETWEEN THE TWO.

>>AMADEU ABRIL I ABRIL: THE QUEUE IS HERE, THE MICROPHONE IS NOT.

>>TINA DAM: THE MICROPHONE IS ON THE WAY.

>>AMADEU ABRIL I ABRIL: THANKS.

THANKS A LOT.

MY NAME IS AMADEU ABRIL I ABRIL, AND I HAVE BEEN INVOLVED IN THIS ISSUE BOTH AS FORMER TLD MANAGER AND USER OF IDNS.

CARY, I HAVE ONE QUESTION AND ONE DISAGREEMENT WITH SOMEONE -- SOMETHING YOU HAVE SAID. THE QUESTION IS WHEN YOU TALK ABOUT SCRIPTS AND LANGUAGES, WE SEEM TO GO FROM ONE EXTREME TO THE OTHER. THAT IS, FOR INSTANCE, WE PRETEND TO HAVE, YOU KNOW, A LANGUAGE TABLE OR A POLICY FOR LATIN OR ROMAN, AS YOU PREFER, BASED LANGUAGES. THIS IS VERY COMPLEX BECAUSE THERE ARE SOME HUNDREDS OF LANGUAGES THAT USE VERY DIFFERENT SPECIAL CHARACTERS, YOU KNOW, ON TOP OF THE ASCII BASIC ONES.

BUT IF WE DO THINGS LIKE, YOU KNOW, A POLICY FOR ROMANCE OR LATIN-BASED LANGUAGES, PROBABLY THE SET OF CHARACTERS, YOU KNOW, IS SLIGHTLY OVER -- IS JUST 25, I THINK, FOR ALL THE LATIN LANGUAGES. AND THEN THERE ARE LOTS OF COMMONALITIES, AND ESPECIALLY SHARED KNOWLEDGE THAT WOULD ALLOW TO MAKE (INAUDIBLE) POLICY -- THAT IS, THERE ARE PEOPLE THERE, LINGUISTS THERE, WHO UNDERSTAND THE PROBLEMS THAT ARE SHARED WITH ALL THESE LANGUAGES AND CAN ADVISE IN MAKING SENSIBLE POLICY. WHILE IT IS VERY DIFFICULT TO FIND SOMEONE WHO HAS ENOUGH KNOWLEDGE ABOUT (CITING LANGUAGES) KATUA, BAMBARA, CATALAN, FINNISH AND WHO KNOWS WHAT ELSE THAT ALL OF THEM USING LATIN-BASED VARIANTS OF THE SAME SCRIPT WITH EXTENDED AND SUPPLEMENTAL CHARACTERS.

SO PERHAPS HAVING THESE SETS OF SCRIPTS BASED ON THE, YOU KNOW, ACCEPTABLE SCIENTIFIC TERM OF LANGUAGE GROUPS THAT, YOU KNOW, THEY ARE THERE, THEY ARE SPECIFIED, WOULD HELP.

SECOND, THE DISAGREEMENT IS IN THE SAME POINT. IF WE -- YOU SAID THAT GOING THE SCRIPT WAY DOES NOT HELP AT ALL IN, YOU KNOW, REDUCING THE LEVEL OF PRESSURE SOMEHOW THAN GOING THE LANGUAGE. I DISAGREE.

IF YOU GO -- FROM A PRACTICAL POINT OF VIEW IN A GTLD REGISTRY, IF YOU WANT TO DO SPANISH, POLISH, AND (CITING LANGUAGES) AND CREOLE, WELL, THIS MEANS DURING THE LANGUAGE OF THOSE FOLKS, YOU HAVE TO CONTACT THEM AND THE GOVERNMENTS AND ACADEMIES AND UNIVERSITIES, EVERYBODY FEELS VERY EMOTIONAL.

IF YOU DO SIMPLY, YOU ADD THE CHARACTERS FOR ALL LATIN-BASED SCRIPT LANGUAGES, THAT IS PORTUGUESE, (CITING LANGUAGES) CATALAN, FRENCH, ITALIAN OR WHATEVER, YOU KNOW, THIS BECOMES A LITTLE BIT MORE SCIENTIFIC AND PRACTICAL QUESTION.

AND YOU ARE NOT TOUCHING THAT DIRECTLY THE DIRECT EMOTIONS AND SOVEREIGNTY OF SOME PARTIES BECAUSE YOU ARE NOT DECIDING WHAT'S CATALAN, SPANISH, PORTUGUESE OR HAITIAN, CREOLE.

YOU ARE OFFERING CHARACTERS THAT HAVE REGISTERING IN ALL THESE LANGUAGES.

SO INDEED, YOU MAY MENTION 20 EXAMPLES IN WHICH THIS DOESN'T HAPPEN BECAUSE THE LANGUAGE AND THE SCRIPT IS THE SAME, AND THAT'S VERY TIED TO SOME CHOICES.

BUT IN 180 OTHER CASES, YES, THIS WOULD HELP.

>>CARY KARP: AMADEU, I ACTUALLY THINK YOU AND I ARE SAYING THE EXACT SAME THING.

THE ONLY THING THAT WE CAN OPERATE ON ALGORITHMICALLY IS WHAT IS IDENTIFIED AS SCRIPT IN THE UNICODE CODE CHART.

AND THE ATTRIBUTES THAT THEY ATTACH TO THE INDIVIDUAL CHARACTERS THERE, WHERE LANGUAGE IS NOT ONE OF THOSE ATTRIBUTES.

THERE ARE 1,070 CODE POINTS IN THE UNIVERSAL CHARACTER SET THAT ARE LATIN-SOMETHING-OR-OTHER.

AND I AM SUGGESTING THAT WE NEED TO CONSIDER LANGUAGE IN ORDER TO REDUCE THAT EXTREMELY LARGE NUMBER TO A SAFER SMALL NUMBER.

AND WHAT JUST DID WAS DESCRIBE A LANGUAGE-BASED METHODOLOGY FOR EXACTLY THAT.

YOU SAID TAKE THE FOLLOWING LANGUAGES AND USE THEIR CHARACTER REPERTOIRES. AND THAT SEEMS TO ME TO BE A STATEMENT OF NEED FOR CONSIDERING LANGUAGE IN A REASONED MANNER TO REDUCE THE RESULT OF WHAT WE CAN OBTAIN BY ALLOWING A MACHINE TO OPERATE ON SCRIPT.

>>TINA DAM: THANKS, CARY, AND THANKS, AMADEU. ARE THERE ANY OTHER QUESTIONS FROM THE PANEL OR THE PARTICIPANTS IN THE ROOM?

AND, MARIA, YOU JUST MENTION IF THERE IS ANYBODY IN THE CHAT ROOM. SO WE WILL MOVE ON TO THE NEXT PRESENTATION. THIS IS A STATUS REPORT ON HOW THINGS ARE GOING WITH THE TECHNICAL TESTS THAT ICANN HAS UNDERTAKEN TO SHOW -- OR TO MAKE SURE THAT THIS ABILITY OF THE DNS WILL STAY AS IT IS AS WE'RE INTRODUCING INTERNATIONALIZED TOP-LEVEL LABELS OR THE PUNYCODE EQUIVALENT OF THAT INTO THE ROOT ZONE.

SO THE TECHNICAL TEST PLANS ARE DIVIDED INTO TWO PHASES. FIRST IS A LABORATORY TESTING THAT ONLY TAKES INTO CONSIDERATION THE DIFFERENT ROOT SOFTWARE AND RESOLVER SOFTWARE PACKAGES. AND THAT KIND OF TEST IS SET UP TO DEMONSTRATE THE STABILITY OF THAT AREA OF THE DNS.

THE SECOND PHASE IS THEN A PRE-DEPLOYMENT TESTING THAT WILL SHOW AGAIN THE RESULT OF THE LABORATORY TESTING BUT ALSO EXPAND THE TESTING TO INCLUDE APPLICATION AND END-USER INTERFACES.

RIGHT NOW, WE'RE UNDERWAY WITH THE LABORATORY TESTING PLANS, AND THIS IS UNICODE -- PUNYCODE INSERTION OF NS RECORDS INTO A REPLICATION OF THE ROOT ZONE.

AND AS I SAID, THERE'S NO FURTHER END-USE APPLICATION TESTING INCLUDED IN THAT.

AS I THINK YOU KNOW, WE MADE AN AGREEMENT WITH AUTONOMICA THAT THEY WOULD BOTH DRAFT A TEST DESIGNED, CONDUCT THE TEST AND SUPPLY REPORTS ON HOW THE TESTING IS GOING.

THEY HAVE MADE A DRAFT TEST DESIGN AVAILABLE FOR US THAT CURRENTLY IS POSTED FOR COMMENTS.

THE TEST SYSTEM THEY HAVE SET UP WILL CONSIST OF A FEW DIFFERENT BLOCKS. THERE ARE TWO ROOT NAME SERVERS. THERE IS THE TOP-LEVEL DOMAIN SERVER.

THERE IS ITERATIVE MODE RESOLVERS AND QUERY GENERATORS IN THE CONNECTING NETWORK.

I KNOW THIS SLIDE MIGHT BE A LITTLE BIT DIFFICULT FOR YOU TO SEE HOW THE SETUP ACTUALLY WORKS BUT IT'S PART OF THE DOCUMENTATION IT WAS POSTED JUST THE OTHER DAY ON THE ICANN WEB SITE.

AND IF YOU TAKE A LOOK AT IT, YOU WILL SEE HOW IT'S THE ROOT AND THE RESOLVER AREA THAT'S EVALUATED AND LIMITED IN THE TEST.

THE DRAFT DESIGN THAT'S AVAILABLE ONLINE WILL ALSO SHOW YOU WHAT KIND OF SOFTWARE THAT AUTONOMICA HAS DECIDED TO USE IN THEIR TEST THERE IS A DIFFERENT BIND VERSIONS AND THEN THERE IS THE MICROSOFT DNS SERVER IN WINDOWS 2000 AND 2003.

BUT MORE DETAILS ABOUT THAT IN THAT DOCUMENT ONLINE.

THE TEST DESIGN HAS SPECIFICALLY BEEN SUBMITTED TO THE RSSAC, THE ROOT-SERVER ADVISORY COMMITTEE, FOR THEIR COMMENTS, AND WE ARE ALSO ASKING ANYONE WHO IS INTERESTED OUTSIDE OF THAT FOR COMMENTS THAT CAN BE POSTED ONLINE.

WE WILL THEN TAKE A LOOK AT THOSE COMMENTS AND DISCUSS THEM WITH THE STAFF AT AUTONOMICA WHO THEN WILL REVISE THE STAFF -- THE -- REVISE THE DESIGN AS APPLICABLE BASED ON ANY COMMENTS THAT WE RECEIVED.

A LITTLE BIT ABOUT THE RESULTS SO FAR. AUTONOMICA PERFORMED A SUCCESSFUL FEASIBILITY TEST, AND THAT IS REALLY JUST TO VERIFY THAT THE WAY EVERYTHING WAS SET UP AND THE DESIGN WAS CRAFTED WAS FUNCTIONAL AND THAT WAS SUCCESSFUL. SO A GOOD INDICATION AS THE DESIGN IS REVISED ACCORDING TO COMMENTS AND THE FINAL TESTS ARE CONDUCTED THAT THINGS WILL SHOW WHAT IT IS THAT WE ARE LOOKING FOR.

THERE WAS ONE INSTANCE OF TESTING ALL THE WAY TO THE END-USER LEVEL COMPLETED, PRETTY MUCH BECAUSE WE WERE REALLY EXCITED ABOUT SEEING HOW THIS IS GOING TO WORK OUT.

SO CARY WAS HELPFUL ENOUGH TO SET UP A 63-CHARACTER TOP-LEVEL DOMAIN IN SWEDISH, AND WE HOOKED UP A COMPUTER TO A PRIVATE NETWORK THAT HAD THAT TLD SET IN THERE, AND TESTED OUT MUSEUM DOT, AND THEN THIS LONG STRING.

AND YOU CAN SEE IT ON THE SLIDE THERE, WHAT IT IS.

THE RESULT WAS GOOD. WE TESTED IT OUT IN TWO BROWSERS. ONE DIDN'T WORK, BUT IT ESSENTIALLY WAS NOT BECAUSE OF THE IDNA PROTOCOL IMPLEMENTATION.

THE OTHER BROWSER WORKED WELL. SO VERY POSITIVE RESULTS THERE.

NOW, THIS KIND OF APPLICATION AND END-USER SOFTWARE TESTING IS SOMETHING THAT WE NEED TO DO SOME MORE ABOUT, SO PHASE II IS THE APPLICATION SOFTWARE TESTING.

THIS IS WHERE WE WILL PROCEED IF THE FULL LABORATORY TEST RESULTS ARE POSITIVE.

THERE HAS BEEN SEVERAL DISCUSSIONS AROUND HOW SHOULD THIS APPLICATION TESTING BE COMPLETED. IT WAS THE MAIN TOPIC OF DISCUSSION AT THE PRESIDENT'S ADVISORY COMMITTEE MEETING WHICH TOOK PLACE LAST NIGHT. AND WE WILL START DEVELOPING SOME PLANS AND WRITING DOWN SOME PROCESSES AROUND HOW THIS IS GOING TO BE WORKING.

THESE PLANS NEED TO BE DISCUSSED FURTHER WITH THE TECHNICAL COMMUNITY BEFORE IT'S FINALIZED AND THOSE KIND OF TESTINGS ARE INITIATED.

BUT THAT'S WHERE WE STAND RIGHT NOW WITH THE TECHNICAL TESTING FROM THE ICANN SIDE.

SO I WILL OPEN UP FOR ANY QUESTIONS OR COMMENTS.

AND I CAN SEE FROM THE EXPRESSION OF THE FACES OF THE COMMITTEE MEMBERS THAT THEY TALKED ABOUT IT A LOT LAST NIGHT, AND SO IF THERE IS ANY COMMENTS MAYBE FROM THE FLOOR OR IDEAS OR ANYTHING.

>>WERNER STAUB: MY NAME IS WERNER STAUB. I HEARD RUMORS, AGAIN THIS MAY BE AN (INAUDIBLE) SITUATION WHERE THERE ARE RUMORS, THAT THERE WAS AN UNDERSTANDING THAT THE NEW GTLDS WOULD HAVE TO WAIT UNTIL THE IDN TESTINGS WERE ALL COMPLETED, WHICH OF COURSE CAUSED CONCERN THAT THE TEST IS GOING TO TAKE FOREVER BECAUSE THERE IS ALWAYS SOMETHING TO TEST.

AND SO WE WOULD FACE ADDITIONAL DELAYS.

COULD ANYONE COMMENT ON THAT?

>>TINA DAM: SO THAT IS IN RELATION TO THE POLICY WORK THAT'S GOING ON WITHIN THE GNSO RIGHT NOW. IS THAT WHAT YOU ARE REFERRING TO? THE POLICY DEVELOPMENT PROCESS FOR NEW GTLDS?

>>WERNER STAUB: INDEED. I DID NOT HERE THAT WITHIN THIS POLICY DEVELOPMENT PROCESS AT ALL. I HEARD IT FROM COMMENTS THAT PEOPLE SPEAK OUTSIDE THAT THERE WAS AN UNDERSTANDING THAT NEW TLDS WOULD HAVE TO WAIT UNTIL ALL THE IDN TESTING WAS PERFORMED.

>>TINA DAM: BRUCE, WOULD YOU COMMENT ON WHETHER IDNS ARE INCLUDED IN THE NEW GTLD POLICY DEVELOPMENT PROCESS OR NOT?

>>BRUCE TONKIN: YES, THEY ARE. AND I'LL COMMENT ON THAT FURTHER. BUT JUST TO DEAL WITH THE RUMOR ISSUE, WERNER, IN TERMS OF TIMING, THE POLICY WORK NEEDS TO BE COMPLETED AND THEN THERE WOULD BE AN RFP, AND THEN THERE WOULD BE SORT OF FOUR MONTHS' NOTICE GIVEN OF THAT RFP.

BY THE TIME YOU ARE LOOKING AT A NEW GTLD IMPLEMENTATION, WE ARE PROBABLY TALKING ABOUT, I'M ASSUMING, JANUARY OF 2008, JUST SORT OF WORKING THROUGH THE DIFFERENT STEPS THAT NEED TO HAPPEN.

AND THEN IT'S AN IMPLEMENTATION ISSUE AS TO WHETHER, AT THAT STAGE, THE ICANN COMMUNITY FEELS THAT IDNS ARE ABLE TO BE ADDED TO THE ROOT OR NOT.

SO THEY ARE KIND OF SEPARATE DECISIONS, REALLY.

BUT I DON'T THINK THERE'S ANY SENSE THAT THE NEW GTLD PROCESS WOULD NECESSARILY NEED TO WAIT. BUT I THINK IT'S PREMATURE TO MAKE A DECISION ON THAT UNTIL THE POLICY WORK IS COMPLETE. AND AT THAT STAGE, AN ASSESSMENT COULD BE MADE ON THE CURRENT STATUS OF THE IDN TESTS.

>>WERNER STAUB: WELL, I AM GLAD TO HEAR THAT. ESSENTIALLY, I THINK THAT IF THERE IS A NEW TLD APPLICATION FOR AN IDN STRING, IT IS SENSIBLE TO EXPECT THAT THE APPLICANT WOULD BE EXTREMELY CAREFUL IN THE CHOICE OF THAT TLD, AND IF, INDEED, THERE WERE TECHNICAL ISSUES DISCOVERED AT A LATE STAGE, THEN THIS WOULD ONLY AFFECT THAT STRING AND NOT THE OTHERS.

THANK YOU.

>>SOPHIA BEKELE: MY NAME IS SOPHIA BEKELE. I AM ON THE GNSO COUNCIL, NOMCOM, AND I AM ALSO ON THE IDN WORKING GROUP.

MY QUESTION -- I GUESS ANYONE ON THE PANEL OR PEOPLE WHO ARE DOING THE APPLICATION SOFTWARE TESTING OR ANYONE ON THE FLOOR COULD ANSWER.

I WAS JUST WONDERING IF THERE WAS AN ALTERNATIVE IDEA THAT WAS EXPLORED, IT MAY BE ACADEMIC, BUT CERTAINLY IT'S A TECHNICAL ONE. THERE ARE A LOT OF VOICES, IF NOT A LOT, AT LEAST STRONG VOICES ON THE IDN WORLD RIGHT NOW THAT IS ASKING ABOUT INTERNATIONALIZING THE DNS ITSELF AS AN ALTERNATIVE. MEANING THE DNS, WHEN IT WAS ORIGINALLY PUT TOGETHER, I GUESS IT SUPPORTS ONLY THE ASCII CHARACTER SET.

SO WHAT IS THE TECHNICAL TESTING THAT'S GOING ON RIGHT NOW? IS THERE ANYTHING -- ANYONE LOOKING AT THAT AS AN ALTERNATIVE OR IS THAT PREMATURE OR ACADEMIC?

THANK YOU.

>>TINA DAM: I'M LOOKING AT THE PANEL.

I CAN TAKE THAT OR, BRUCE, DID YOU WANT TO SAY SOMETHING?

SO THE IDEA ABOUT MAKING THE DNS CAPABLE OF HANDLING UNICODE CHARACTERS DIRECTLY IN THERE, WITHOUT DOING THE CHANGE FROM THE UNICODE CHARACTERS INTO PUNYCODE, WHICH IS ONLY ASCII, IS SOMETHING THAT I THINK HAS BEEN EXPLORED MANY TIMES FROM THE TECHNICAL COMMUNITY. AND AT LEAST IN SOME POINT IN TIME, THE DECISION WAS MADE NOT TO DO SO.

I DON'T KNOW, JOHN, IF YOU ARE ON THE PHONE. DID YOU WANT TO MAKE CLARIFICATION ON THAT?

>>JOHN KLENSIN: YES, THANK YOU. THIS IS JOHN KLENSIN REMOTELY.

WE HAVE LOOKED AT THE QUESTION OF DOING INTERNATIONALIZATION OF THE DOMAIN NAME SYSTEM WITHOUT DOING THE KIND OF ENCODING THAT THE CURRENT SYSTEM IMPLIES.

THERE ARE A NUMBER OF ISSUES THERE BUT LET ME MENTION TWO OF THEM THAT MAY BE CLEAR TO THIS AUDIENCE.

THE FIRST IS THAT MOST OF THE ISSUES CARY TALKED ABOUT AND SEVERAL OF THE ISSUES THAT I TALKED ABOUT IN TERMS OF UNIQUENESS OF CHARACTERS AND CHARACTERS LOOKING LIKE EACH OTHER AND MATCHING OR NOT MATCHING DON'T GO AWAY IF WE ELIMINATE THIS CODING PROBLEM. THEY ARE STILL THERE AND THEY STILL HAVE TO BE DEALT WITH SOMEWHERE.

TO TRY TO DEAL WITH THEM DIRECTLY IN THE DNS SERVERS WOULD MAKE THOSE SERVERS BOTH MORE COMPLEX AND IN AN ENTIRELY DIFFERENT ENVIRONMENT THAN THEY ARE TODAY.

AND THAT'S THE FIRST PROBLEM.

THE SECOND PROBLEM IS ONE OF APPLICATIONS.

THE CODE RULES THAT SAY IN GENERAL THE DNS NAMES HAVE TO CONSIST OF ASCII LETTERS, DIGITS AND UNDER SOME RESTRICTED CIRCUMSTANCES A HYPHEN ARE NOT IN GENERAL ENFORCED BY THE DNS ITSELF. THEY ARE ENFORCED BY THE APPLICATIONS.

SO THE NOTION OF DOING SOMETHING THAT PUTS UNICODE CHARACTERS OR UTF-8 STRINGS DIRECTLY INTO THE DNS IMPLIES TAKING ALL THOSE APPLICATIONS AND CHANGING THEM, PROBABLY ALL AT ONCE RATHER THAN A GRADUAL TRANSITION THAT THIS CODING SYSTEM PERMITS.

AND THE THIRD VERY GENERAL ISSUE OUT OF TWO IS THE ONLY WAY WE KNOW HOW TO DO THAT KIND OF TRANSITION TO ENCODING UNICODE DIRECTLY INTO THE DNS RATHER THAN USING THIS INTERMEDIATE KIND OF ENCODING, WE LOOKED AT IT SOMEWHAT, WE KNOW HOW TO DO IT AND THE EASIEST WAY TO DO IT -- I WON'T TELL YOU THE ONLY PRACTICAL WAY, BUT POSSIBLY SO -- INVOLVE SOME -- A LITTLE DNS REFORM THAT WOULD REQUIRE SHUTTING DOWN THE INTERNET A FEW DAYS WHILE WE MADE THE TRANSITION AND BRINGING IT BACK UP AGAIN WITH AN ENTIRELY NEW SET OF NAMES AND ROOTS AND STRUCTURES AND AN ENTIRELY NEW SET OF APPLICATIONS.

FOR THOSE OF YOU THAT ARE INTERESTED IN STABILITY, THAT'S PROBABLY NOT A GOOD IDEA. FOR THOSE OF YOU WHO ARE INTERESTED IN PRESERVING THE CURRENT RELATIONSHIPS IN THE DOMAIN NAME MARKET, THAT'S PROBABLY NOT A GOOD IDEA.

FOR THOSE OF YOU WHO THINK THE CURRENT DOMAIN NAME MARKET AND ENVIRONMENT IS ALREADY A MESS AND WOULD LIKE TO START OVER, THAT COULD BE AN ABSOLUTELY WONDERFUL IDEA.

>>TINA DAM: THANKS, JOHN.

ANY OR QUESTIONS ON THIS TOPIC? OR COMMENTS?

OKAY.

SO, JOHN, WE'RE GOING TO MOVE AHEAD WITH YOUR STATUS REVIEW OF THE IDNA PROTOCOL AND YOUR SLIDES ARE UP ON THE SCREEN.

>>JOHN KLENSIN: SORRY, I HAD TO FIND THE MUTE BUTTON AGAIN.

GOOD AFTERNOON, EVERYONE. MY APOLOGIES FOR NOT BEING THERE WITH YOU.

I AM GOING TO TALK TODAY A LITTLE BIT ABOUT THE WORK WHICH IS GOING ON TO TRY TO LOOK AT IDNA AND LOOK AT SOME OF THE ISSUES AND PROBLEMS WHICH HAVE ORIGINATED OVER THE LAST YEAR OR THREE, AND WHAT WE ARE GOING TO DO ABOUT THEM.

CARY'S TALK LAID THE GROUNDWORK FOR MUCH OF WHAT I AM GOING TO SAY, AND I HAVE LARGELY ASSUMED -- SLIDE TWO, PLEASE -- THAT PEOPLE IN THE AUDIENCE UNDERSTAND BASIC IDN TERMINOLOGY AND SOME OF THE THINGS THAT SHOULD HAVE BEEN COVERED IN PRIOR TUTORIALS, INCLUDING SOME OF THE WORK WHICH WAS DONE ON SUNDAY.

I WORKED ON PRESENTATIONS. SO I HOPE AT THIS STAGE THAT THAT'S TRUE, BUT IF IT ISN'T, THAT'S NOT A PROBLEM I CAN SOLVE IN A 20-MINUTE PRESENTATION.

AND I AM ALSO GOING TO MAKE SOME GUESSES ABOUT WHERE WE WILL END UP IN THE FUTURE THAT MAY BE HELPFUL, ALTHOUGH PERHAPS NOT.

NEXT SLIDE.

IT'S IMPORTANT TO UNDERSTAND WHEN LOOKING AT WHERE WE ARE TODAY THAT THE ORIGINAL STANDARD WAS DEVELOPED UNDER A CERTAIN AMOUNT OF STRESS FROM ICANN AS WELL AS A NUMBER OF OTHER PLACES.

THE PEOPLE WHO WERE DOING THE DEVELOPMENT WERE TOLD REPEATEDLY THAT THEY NEEDED TO DEVELOP SOMETHING, EVEN IF IT WAS WRONG, IN ORDER TO GET SOMETHING OUT THERE BEFORE THE DNS BLEW APART UNDER SOME SORT OF CENTRIFUGAL FORCES, AND AS A RESULT OF THAT, SOME OF THE DETAILS OF THE STANDARD DID NOT GET WORKED OUT AS THOROUGHLY AS THEY MIGHT HAVE BEEN WITH A LITTLE BIT MORE TIME. THAT WAS ARGUABLY A GOOD DECISION IN TERMS OF GETTING US WHERE WE ARE TODAY, BUT IT MEANS WE HAVE TO DO SOME CORRECTION WORK.

IN PARTICULAR, THE DESIGN MODEL WAS THAT WE WEREN'T GOING TO MAKE CHANGES TO THE DOMAIN NAME SYSTEM ITSELF. THE REASONS FOR THAT WERE ACTUALLY THE ONES I JUST EXPLAINED. THAT AS A CONSEQUENCE, WE PROCESS UNICODE INTO A FORM THAT WAS COMPATIBLE WITH THE EXISTING DNS FOR THE SAME REASON. THAT WE WOULD USE WHAT UNICODE CALLS NORMALIZATION TO DEAL WITH STRUCTURAL FORMS. THAT THE ACTUAL DNS ENTRY WOULD BE THIS SO-CALLED ASCII COMPATIBLE ENCODING THAT WE CALL PUNYCODE. AND THAT THE SYSTEM WOULD BE EXTREMELY STRONGLY LINKED AND TIED TO UNICODE 3.2.

THAT DESIGN MODEL INVOLVED A NUMBER OF ASSUMPTIONS, THAT THERE WOULD BE UNIVERSAL IMPLEMENTATION OF THIS FAIRLY QUICKLY, THAT THE USERS WOULD BASICALLY NEVER SEE PUNYCODE WITH ANY APPLICATION THAT HAD BEEN UPGRADED, AND MAYBE NOT THEN. THAT WE COULD INCLUDE ALL THE UNICODE CHARACTERS UNLESS THERE WAS A REASON NOT TO. THAT THERE WERE EXTENSIVE MAPPINGS AMONG UNICODE CHARACTERS. THAT THERE WOULD BE NO MAJOR CONFUSION PROBLEM AMONG CHARACTERS (INAUDIBLE) SCRIPTS AND THAT WE COULD GET AWAY WITH SPECIFYING A VERSION OF UNICODE, IN THAT CASE 3.2. AND EVERY ONE OF THAT LIST OF ASSUMPTIONS HAS TURNED OUT TO BE INCORRECT. IF PEOPLE WANT TO UNDERSTAND WHY OR HAVE QUESTIONS ABOUT THAT, WE CAN TALK ABOUT IT LATER WHEN TALKING ABOUT IT IN OPEN MICROPHONE.

WHERE ARE WE TODAY? IN THE LAST FEW YEARS WE HAVE A LOT OF CONFUSING CHARACTER PAIRS AND BAD GUYS ARE CAPABLE OF USING THEM FOR -- SORRY, I AM ON THE NEXT SLIDE, PLEASE. THE BAD GUYS ARE CAPABLE OF USING THEM FOR SPOOFING AND PHISHING.

WE'VE GOT USER AND REGISTRANT CONFUSION ABOUT THE MAPPINGS. THERE'S A GROWING SENSE OF RISK WHEN IDNS ARE USED OUTSIDE THEIR NATIVE CONTEXT. IF SOMEBODY IS OPERATING WITH AN IDN IN CHINESE IN A COMPLETELY CHINESE ENVIRONMENT WHERE WEB PAGES AND E-MAIL CLIENTS ARE IN CHINESE AND EVERYBODY THEY ARE COMMUNICATING WITH IS OPERATING IN CHINESE, THEN THERE'S BASICALLY NO PROBLEM WITH IDNS THAT WE DON'T KNOW HOW TO SOLVE.

BUT WHEN THE IDNS USE SCRIPT OR IN AN ENVIRONMENT THAT'S LOCALIZED WITH OTHER SCRIPT, POSSIBLY BECAUSE SOMEBODY IS MULTILINGUAL, POSSIBLY BECAUSE SOMETHING IS PASSED AROUND THE INTERNET, THINGS GET MORE COMPLICATED AND THERE'S GROWING (INAUDIBLE) THAT CAUSES RISK.

AS A CONSEQUENCE OF THAT SENSE OF CAUSING RISK, THE IMPLEMENTERS ULTIMATELY DEAL WITH THE USERS ABOUT THESE THINGS RATHER THAN DEALING WITH THE DOMAIN NAME SPACE (INAUDIBLE) HAVE STARTED TO MAKE THEIR OWN RULES TO PROTECT USERS.

WE HAVE SEVERAL BROWSERS WHO HAVE DECIDED THAT SOME COMBINATIONS ARE BAD AND THEY WILL DISPLAY PUNICODE RATHER THAN DOMAIN NAMES. INTERNET EXPLORER 7 LOOKS AT THE SCRIPTS ONE AS CONFIGURED FOR YOUR LOCAL MACHINE AND IF AN IDN COMES ALONG THAT IS NOT IN THOSE SCRIPTS OR IS OF MIXED SCRIPT OR LANGUAGE, THEY DISPLAY PUNYCODE.

WHAT WE ASSUMED IS ORIGINALLY THE USERS WOULD NEVER SEE PUNYCODE, ALTHOUGH WE ARE SEEING LOTS OF PUNYCODE AND WE ARE GOING TO SEE LOTS OF PUNYCODE IN THE FUTURE.

AS I COMMENTED IN PREVIOUS TALKS, WHEN YOU TAKE A USER WHO HAS BEEN LIVING WITH AN ASCII TRANSLITERATION OF A NAME FOR MANY YEARS AND HATING IT EVERY MINUTE AND YOU SAY CONGRATULATIONS, WE HAVE THIS WONDERFUL NEW SYSTEM FOR YOU THAT'S FULLY INTERNATIONALIZED, AND YOU PRESENT THAT USER SOMETHING WHICH LOOKS LIKE XN DASH DASH AND A NUMBER OF UNINTELLIGIBLE CHARACTERS, THE USERS DON'T SEE THIS AS A NET IMPROVEMENT.

BUT THE SOLUTION THERE IS NOT CHANGING THE DNS. THE SOLUTION THERE IS GETTING MUCH BETTER AT THESE PRESENTATION ISSUES AND MUCH BETTER AT ACTUALLY NOT GETTING THE PUNYCODE IN FRONT OF THE USERS.

NEXT SLIDE.

SO AS A RESULT OF THE FORMAT THAT I HAVE BEEN TALKING ABOUT, THE INTERNET ARCHITECTURE BOARD STARTED A PIECE OF WORK WHICH BECAME RFC 4690 WHICH TALKS ABOUT THE NEXT STEPS IN LOOKING AT IDNS.

ONE OF THE MAJOR CONCLUSIONS ABOUT 4690 -- OF 4690 AND ONE OF THE THINGS IT REPORTS ON AT LENGTH IS A WHOLE SERIES OF USER EXPECTATIONS ABOUT IDNS WHICH TURN OUT NOT TO BE REALISTIC.

ONE OF THOSE EXPECTATIONS IS THAT WE WOULD HAVE LANGUAGE-DEPENDENT MATCHING. THAT WHETHER OR NOT TWO CHARACTERS ARE THE SAME WOULD DEPEND UPON THE PARTICULAR LANGUAGE CONTEXT IN WHICH THOSE CHARACTERS ARE USED.

THIS IS EXACTLY WHAT WE DO IN THE REAL WORLD WITH REAL LANGUAGES AND REAL SCRIPTS.

A SECOND IS THAT WE COULD PREVENT MIXED LANGUAGE WRITING SYSTEMS IN A LABEL AS A CONSEQUENCE OF THE PROTOCOL. IT TURNS OUT THE WORK IS ACTUALLY A COROLLARY FOR THE THINGS AMADEU WAS SAYING.

THERE WAS AN EXPECTATION THAT WE COULD COME UP WITH A COMPLETE CURE FOR CONFUSABLE CHARACTERS. WELL, WE CAN'T. THOSE CHARACTERS ARE CONFUSABLE BECAUSE THEY ARE CONFUSABLE IN THE REAL WORLD AND WRITING SYSTEMS BECAUSE MANY SCRIPTS USE CHARACTERS WHICH ARE DERIVED FROM OTHER SCRIPTS.

THERE IS AN EXPECTATION THAT WE CAN FIGURE OUT A FULLY COMFORTABLE AND CULTURALLY APPROPRIATE SOLUTION FOR MIXING RIGHT TO LEFT STRINGS AND LEFT TO RIGHT STRINGS. PROBABLY THAT'S NOT POSSIBLE IN THE MOST GENERAL SENSE. WE CAN GET BETTER OR WORSE AT IT FOR PARTICULAR IMPLEMENTATIONS. AND THERE IS AN EXPECTATION THAT WE SHOULD BE ABLE TO USE THE INTERNET WITHOUT ANY ROMAN-BASED CHARACTERS AND WITHOUT SIGNIFICANT WORK ON PRESENTATION TO HIDE THE ROMAN-BASED CHARACTERS. AND UNTIL WE GET FIGURE OUT A WAY TO GET RID OF THE HTTP COLON SLASH SLASH AND ALL OF ITS RELATIVES, THAT'S NOT GOING TO HAPPEN EITHER.

4690 ALSO SUGGESTED A FEW FAIRLY OBVIOUS RECOMMENDATIONS.

WE HAVE TO MOVE TO MAKE IDNS UNICODE VERSION AGILE. WE CAN'T KEEP IT STUCK AT UNICODE 3.2 BECAUSE 3.2 EXCLUDES A GREAT MANY SCRIPTS AND LANGUAGES WHICH ARE FAIRLY IMPORTANT IN THE WORLD, AT LEAST TO THE PEOPLE WHO SPEAK AND USE THEM.

AND WE CAN'T MOVE TO 5.0 AND GET STUCK THERE FOR THE SAME REASON.

WE NEED TO MOVE, AS CARY MENTIONED, TO AN INCLUSION LIST RATHER THAN ASSUMING THAT EVERY UNICODE CHARACTER SHOULD BE USABLE UNLESS THERE IS A FAIRLY GOOD REASON WHY NOT.

AND WE NEED TO REVIEW AND UPDATE THE PROTOCOL AND THE TABLES.

THE MAJOR CONTENT OF 4690 IS ISSUES, NOT PROPOSALS.

AND THERE'S A CLEAR UNDERSTANDING THAT NOT ALL OF THE PROBLEMS THAT 4690 IDENTIFIES CAN ACTUALLY BE SOLVED.

IDNS WILL NOT MAKE THE INTERNET MULTILINGUAL.

THEY MAY BE AN IMPORTANT PIECE OF A BIGGER PICTURE.

I'LL TALK ABOUT THAT A LITTLE MORE LATER.

IN THE PROCESS OF LOOKING AT THIS WORK AND OTHER DISCUSSIONS WHICH OCCURRED IN VARIOUS COMMUNITIES IN THE LAST MANY MONTHS, WE HAVE DISCOVERED SOME FAIRY TALES ABOUT IDNS.

WE'VE HEARD THAT YOU CAN'T POSSIBLY USE THE INTERNET EXCEPT IN ENGLISH.

PEOPLE WHO ARE LOOKING TODAY AT WEB PAGES AND E-MAIL IN ALL SORTS OF LANGUAGES AND SCRIPTS WOULD BE A LITTLE BIT SURPRISED ABOUT THAT, BUT THE STATEMENT NONETHELESS FLOATS AROUND.

THERE'S ANOTHER STATEMENT THAT IF ONLY WE HAD TOP-LEVEL DOMAINS, EVERY COUNTRY IN THE WORLD WOULD BE WELL CONNECTED.

WELL, THE REALITY THAT IDNS DON'T HAVE A LOT TO DO WITH INTERNET CONNECTIVITY.

PEOPLE THINK THAT USERS USE IDNS.

IN MOST CASES, USERS DON'T USE IDNS; THEY USE PROTOCOL IDENTIFIERS IN URIS, THEY USE IRIS IN COMING DAYS.

BUT IDNS ALONE ARE VERY RARELY USED BY USERS EXCEPT AS ABBREVIATIONS FOR URIS.

HTTP:// IS NOT GOING TO GO AWAY.

IF ONE MANAGES TO TREAT IT AS A DEFAULT AND IGNORE IT, HTTPS COLON, FTP COLON, MAILTO COLON, JABBER COLON, SIP COLON, AND SO ON AND THESE SYNTAXES ARE NOT GOING TO GO AWAY.

THESE ARE LOCKED TO ROMAN CHARACTERS, AND THE RIGHT WAY TO HIDE THEM FROM USERS WHO DON'T WANT TO SEE THEM INVOLVES PRESENTATION AND NOT TAMPERING WITH THE DNS, BECAUSE DNS CAN'T FIX THAT.

ANOTHER FAIRY TALE WAS, PEOPLE WOULD BE ABLE TO TAKE A SET OF CHARACTERS IN A LANGUAGE THEY HAD NEVER SEEN BEFORE AND A SCRIPT THEY HAD NEVER SEEN BEFORE AND ACCURATELY TRANSCRIBE IT ONTO A COMPUTER.

AND THAT'S OBVIOUSLY NOT GOING TO WORK VERY WELL, EITHER.

NEXT SLIDE.

THERE ARE MORE UNREASONABLE EXPECTATIONS.

CARY TALKED A LITTLE BIT ABOUT SOME OF THESE.

ONE OF THEM IS THAT ANY VALID WORD IN ANY LANGUAGE SHOULD BE EXPRESSIBLE WITH DNS.

ANOTHER IS, YOU SHOULD BE ABLE TO WRITE WHOLE SENTENCES OR NOVELS IN DNS.

AND A THIRD IS, YOU SHOULD BE ABLE TO MIX SCRIPTS, ESPECIALLY CLOSELY RELATED SCRIPTS, WITHOUT CAUSING CONFUSION AND RISK.

UNLESS WE CAN GET PAST THESE KINDS OF EXPECTATIONS, WE'RE NOT GOING TO BE ABLE TO MAKE IDNS WORK IN A SATISFACTORY FASHION.

WE'VE ALSO SEEN SOME UNREALISTIC IDEAS ABOUT HOW THE DNS WORKS.

ONE OF THEM IS THAT WE HAVE TWO TREES IN THE DNS, TWO TOP-LEVEL DOMAINS AND THE THINGS UNDERNEATH THEM, WITH TRANSLATIONS WHICH RUN ALL THE WAY DOWN THE TREE.

THIS IS ONE EXAMPLE.

MORE COMPLEX EXAMPLES HAVE BEEN SUGGESTED.

BUT IT'S VERY, VERY HARD, IF NOT IMPOSSIBLE, TO MAKE THE DOMAIN NAME SYSTEM WORK THAT WAY.

EVEN IF ONE CAN MAKE IT WORK THAT WAY, IT'S IMPOSSIBLE TO MAKE IT WORK THAT WAY IN A CONSISTENT WAY OVER TIME, UNLESS ONE ENTITY IS CARRYING THE ENTIRE TREE, WHICH IS TO SAY THAT THESE WOULD ONLY REPRESENT TWO ZONES, NOT TWO SEPARATE SETS OF DOMAINS WHICH ARE DELEGATED OUT.

ANOTHER IDEA IS THAT ONE CAN ENFORCE HOMOGENEITY TECHNICALLY BETWEEN THE LABELS OF A FULLY QUALIFIED DOMAIN NAME THAT IF A PARTICULAR TOP-LEVEL DOMAIN IS IN ONE LANGUAGE, THAT THE SECOND-LEVEL DOMAIN NAME AND THE THIRD-LEVEL DOMAIN NAME AND THE FOURTH-LEVEL DOMAIN ARE ALL IN THE SAME SCRIPT.

YOU MAY BE ABLE TO ENFORCE THAT ADMINISTRATIVELY.

YOU CANNOT ENFORCE THAT TECHNICALLY.

A THIRD UNREALISTIC IDEA IS ONE CAN TAKE A LOOK AT THE NAME OF THE TLD OR THE SCRIPT IN WHICH THE TLD IS WRITTEN AND DECIDE ON THAT BASIS HOW THE SUBTREE IS GOING TO GET RESOLVED AND WITH WHAT MECHANISMS.

WE JUST DON'T KNOW HOW TO DO THAT IN THE DNS AS IT EXISTS TODAY.

WE COULD THROW THE DNS AWAY AND START OVER IN ORDER TO ACCOMPLISH THAT, BUT PROBABLY THAT WOULD BE MORE DISRUPTION THAN WE'RE WILLING TO ACCEPT.

NEXT SLIDE.

WE TALK ABOUT SOLUTIONS.

WE THINK THERE ARE THREE MAJOR COMPONENTS, ALL OF WHICH ARE IMPORTANT.

THE FIRST IS SUGGESTING THE PROTOCOLS.

THAT'S WHAT I'VE BEEN TALKING ABOUT TODAY AND WILL CONTINUE TO TALK ABOUT.

THE SECOND IS SUGGESTING REGISTRATION MODELS AND REGISTRATION RESTRICTIONS, WHICH IS WHAT CARY TALKED ABOUT IN THE IDN ICANN GUIDELINES ARE ADDRESSED TO.

AND THE THIRD IS THE PRESENTATION ISSUES, THE QUESTION OF EXACTLY WHAT IT IS THE USER SEES WHEN A DOMAIN NAME SHOWS UP SOMEHOW THAT (INAUDIBLE) THE COMPUTER.

WHATEVER WE DO, THERE WILL BE RISKS.

THERE ARE RISKS WITH ASCII DOMAIN NAMES AS WELL, BUT THERE ARE MANY MORE CHARACTERS HERE, AND THAT MAKES THE SCOPE OF THE RISKS BROADER.

NEXT SLIDE.

BASICALLY, I WANT TO TALK ABOUT THAT PROTOCOL SITUATION.

THINGS WHICH WE DO THEY PROTOCOLS APPLY TO EVERY LEVEL OF THE DNS AND TO ALL DOMAINS.

IF WE NEED SOMETHING TO APPLY TO EVERY LEVEL OF THE DNS AND ALL DOMAINS, WE HAVE TO TRY TO FIGURE OUT A WAY TO DO IT IN THE PROTOCOLS.

IF THE PROTOCOL ISSUES DON'T APPLY EVERYWHERE, THEN WE LOSE INTEROPERABILITY AND WE LOSE THE ABILITY TO HAVE A GLOBAL REFERENCE WHICH ACTUALLY WORKS AND ARE GLOBALLY USABLE.

WHAT -- MAKING CERTAIN THAT THINGS WORK IN THE LONG TERM IS TO REFORMULATE IDNA A BIT.

THE CHANGES ARE FEW BUT VERY SUBSTANTIVE.

BUT THE IDEA IS THAT RIGHT NOW WE HAVE DISCOVERED THAT VERY FEW PEOPLE UNDERSTAND WHAT IDNA DOES.

IT IS ALL AN ALGORITHM ON A SET OF TABLES.

AND NOBODY KNOWS QUITE WHERE THE TABLES COME FROM EXCEPT THOSE WHO CREATED THEM.

SO WE'RE TALKING ABOUT A MODEL WHICH IS EASY TO UNDERSTAND AND BETTER TIED TO CONCEPTS WHICH WE CAN ACTUALLY EXPLAIN.

IF THIS TALK WERE A LITTLE BIT LONGER, I'D SHOW YOU THE SLIDE WHICH TRIES TO LAY OUT AND EXPLAIN THOSE CONCEPTS.

IT INVOLVES SEPARATING THE STEPS FOR REGISTRATION AND LOOKUP A LITTLE BIT, PARTIALLY TO MAKE MIGRATION BETWEEN UNICODE VERSIONS A LITTLE BIT EASIER AND TO MAKE IT POSSIBLE TO INCREMENTALLY ADD (INAUDIBLE) CHARACTERS AND SCRIPTS TO A PERMITTED SET.

AND AS YOU MENTIONED EARLIER, WE UNLOCKED THE WAY TO GET FROM ONE UNICODE VERSION TO ANOTHER, SO WE DON'T HAVE TO REVISE THE PROTOCOL AND RISK REVISING THE NAMES WHICH HAVE BEEN REGISTERED ALREADY WHEN WE MAKE A CHANGE.

MOVING TO AN INCLUSION LIST PROHIBITING NONLANGUAGE CHARACTERS, AND AS MUCH AS POSSIBLE, REMOVING SOME OF THE MAPPINGS WHICH CAUSE A GREAT DEAL OF CONFUSION WITH THE EXISTING VERSION OF IDNA FROM THE PROTOCOL.

IF, UNDER THE CURRENT VERSION OF IDNA, A CHARACTER IS TURNED INTO ANOTHER CHARACTER, BECAUSE IT'S A DIFFERENT FONT OR BECAUSE IT'S A DIFFERENT LAYOUT OR A DIFFERENT EXPRESSION, THE NOTION IN THE NEW SCHEME IS TO PROHIBIT THAT FIRST CHARACTER ALREADY.

YOU'LL NOTICE THIS DOESN'T CHANGE AT ALL THE NUMBER OF THINGS WHICH CAN BE REGISTERED, NOR DOES IT CHANGE ANY EXISTING REGISTRATION, BUT IT CHANGES THE THINGS WHICH ARE SEEN BY THE USER AS MORE OR LESS EQUIVALENT TO WHAT IS REGISTERED, WITH THE IMPORTANT EMPHASIS BEING ON LESS RATHER THAN MORE.

WE EXPECT SOME OF THE THINGS WE PROHIBIT AS FAR AS IDNA IS CONCERNED WILL BECOME MATTERS FOR LOCAL USER INTERFACE MAPPING, THAT PEOPLE WILL DECIDE IN SOME CASES THAT SOME OF THESE CHANGE CHARACTERS ARE APPROPRIATE TO TREAT AS EQUIVALENT TO THE USER INTERFACE, AND THEY CAN CERTAINLY DO THAT.

THERE WILL BE SOME NECESSARY EXCEPTIONS TO THAT RULE.

AT THE SAME TIME, WE'RE ALLOWING SOME THINGS WHICH ARE NOW PROHIBITED IN ORDER TO PERMIT A WIDER RANGE OF CHARACTERS AND SCRIPTS, AND THE ONES OF THOSE WHICH GET THE MOST ATTENTION ACROSS THE MOST LANGUAGES AND SCRIPTS ARE FIXING SOME PROBLEMS IN BIDIRECTIONAL ALGORITHMS, RIGHT TO LEFT SCRIPTS, ESPECIALLY WHEN MIXED WITH RIGHT TO LEFT CHARACTERS.

AND DOING SOMETHING ABOUT THE ZERO-WIDTH BREAKING AND NON-BREAKING SPACES, WHICH ARE ESSENTIAL TO PROPER RENDERING A PRESENTATION AND WRITING OF A NUMBER OF LANGUAGES.

IN SOME CASES, WE'RE STILL DISCOVERING HOW TO DO IT, BUT IT'S CLEAR THAT THIS HAS TO BE DONE.

SO, WE'RE WORKING IN THE IDNA REFORMULATION AS WE SPEAK.

NEW TABLES ARE BEING WORKED ON VERY ACTIVELY, AND THE RULES NEEDED TO DEFINE THOSE TABLES ARE BEING WORKED ON VERY ACTIVELY.

WE ARE TRYING TO WORK ON THAT JOINTLY AS AN ACTIVITY BETWEEN PEOPLE FOR THE IETF AND THE UNICODE TECHNICAL COMMITTEE IN THE HOPES OF GETTING IT RIGHT THIS TIME.

AND, AS I MENTIONED, TRYING TO FIX THE BIDIRECTIONAL RULES TO PERMIT A LARGER RANGE OF LANGUAGES AND CLARIFY A SERIES OF EDGE CASES.

IMPACT ON THE PROTOCOL, AS I SAID EARLIER, NO FUNDAMENTAL CHANGES TO THE ALGORITHMS, NO CHANGES TO THE PREFIXES.

LITTLE EFFECT ON NONTEST REGISTRATIONS THAT CONFORM TO THE EXISTING GUIDELINES.

SOME STRINGS NOW PROHIBITED BY THE GUIDELINES WILL BE PROHIBITED BY THE PROTOCOL.

ABILITY TO REGISTER MORE LANGUAGES AND MORE PRACTICAL STRINGS AND NAMES.

REGISTRATION PIECE OF THE ISSUE, CARY'S TALKED ABOUT A LITTLE BIT.

INCLUDING ANYTHING THAT REQUIRES LANGUAGE RULES OR CULTURE LIMITATIONS.

ANYTHING TO -- REDUCE LANGUAGE OR CONTEXT-BASED CONFUSION HAS TO BE A REGISTRY ISSUE.

ANYTHING INVOLVING VARIANT PROCESSING HAS TO BE A REGISTRY ISSUE, JUST AS IT IS TODAY.

MANY OF THESE THINGS REQUIRE THAT WE BE VERY STRICT TO BE CERTAIN THAT THE CONCEPT OF A NAME NOT BE FOUND IN THE DNS RARELY COMES BACK AS NOT FOUND.

BUT WE NEED TO REMEMBER REGISTRATION RESTRICTIONS ARE PROBABLY NOT EFFECTIVE BELOW THE DNS.

PRESENTATION IS EQUALLY IMPORTANT.

BUT WHAT WE'RE WORRIED ABOUT HERE IN MOST CASES IS NOT WHAT'S GOING ON IN THE DNS OR NOT WHAT'S GOING ON IN OUR INTERNAL ISSUES, BUT WHAT THE USER ACTUALLY SEES OR TYPES OR SAYS OUT LOUD.

WE NEED TO LOOK AT HOW MUCH WE CAN LOCALIZE IN A PARTICULAR ENVIRONMENT CONSISTENT WITH KEEPING A GLOBAL NETWORK.

WE NEED TO LOOK AT THE QUESTION OF WHEN IT'S UNSAFE TO DISPLAY NATIVE CHARACTERS, WHICH IS THE ISSUE ABOUT DISPLAY PUNYCODE.

WE NEED TO UNDERSTAND BETTER TO DO WHAT TO DO WHEN WE WANT TO DISPLAY NATIVE CHARACTERS AND WE CAN'T BECAUSE WE DON'T HAVE THE RIGHT FONTS OR RENDERING MACHINERY.

WE NEED TO LOOK AT WHAT HAPPENS WHEN A USER DOESN'T RECOGNIZE A CHARACTER THEY'VE SEEN ON A BUSINESS CARD OR A WALL OR POSTER, BUT NEED TO GET IT INTO THE DNS OR INTO A BROWSER OR MAIL PROGRAM REGARDLESS.

WE NEED TO LOOK AT THE COMMUNITY ISSUES ABOUT WHAT HAPPENS TO A USER WHO'S USED TO WORKING IN A VERY LOCALIZED ENVIRONMENT BUT WHO TRAVELS.

WE NEED TO UNDERSTAND BETTER ABOUT THE PRESENTATION OF RIGHT TO LEFT AND LEFT TO RIGHT STRINGS.

AND WE NEED TO UNDERSTAND WHAT TO DO WITH INVISIBLE CHARACTERS IF WE HAVE TO INTRODUCE THEM, WHICH WE CERTAINLY WILL.

AND ULTIMATELY, WE NEED TO UNDERSTAND THAT ICANN AND IETF WILL HAVE VERY LOW IMPACT ON THE DECISIONS ABOUT THESE THINGS, BUT THAT THESE ARE THE QUESTIONS WHICH WILL AFFECT THE USERS AND WHAT HAPPENS TO USERS.

NEXT SLIDE.

AS WE'RE DOING THIS, WE NEED TO MAINTAIN A BALANCE, A BALANCE AMONG USABILITY, MAXIMIZING LOCALIZATION.

THE REQUIREMENTS OF KEEPING THE GLOBAL INTERNET, KEEPING THE DNS STABLE AND REFERENCES STABLE.

THERE WILL BE RISKS.

WE MUST BE REALISTIC ABOUT THE PROBLEMS IDN CAN SOLVE AND WE NEED TO LEAVE THE DOOR OPEN FOR DNS SUPPORT OF OTHER NAVIGATION TECHNIQUES BESIDES IDNS.

SKIP THE NEXT SLIDE.

GO TO THE ONE AFTER THAT.

I'M GOING TO TAKE A MINUTE AND MAKE SOME EDITORIAL COMMENTS AS SOMEBODY WHO'S BEEN INVOLVED WITH TRYING TO MAKE IDNS WORK FOR A LONG TIME.

THEY'RE VERY IMPORTANT.

WE NEED TO REMEMBER THEY'RE VERY IMPORTANT FOR SOME PURPOSES WHICH ARE CRITICAL BUT STILL LIMITED.

THEY'RE NOT ALONE GOING TO MAKE THE INTERNET MULTILINGUAL.

TO MAKE THE INTERNET MULTILINGUAL, THE KEY ISSUES MOSTLY HAVE TO DO WITH CONTENT.

>>TINA DAM: JOHN, THIS IS TINA.

COULD YOU JUST MENTION WHAT SLIDE YOU'RE ON, WHAT IS THE HEADING OF IT?

>>JOHN KLENSIN: IT SAYS PERSONAL EDITORIAL AT THE TOP.

>>TINA DAM: GOT IT.

>>JOHN KLENSIN: THE COMMUNITY, INCLUDING THE ICANN COMMUNITY, COULD KILL IDNS BY ACCIDENT AND BY EXCESSIVE ENTHUSIASM.

WE CAN OVERREACT TO SOME OF THE RISKS WE'VE BEEN TALKING ABOUT.

WE COULD PUT SOME PUNYCODE IN FRONT OF USERS THAT USERS DECIDE THAT IDNS AREN'T REALLY THERE.

WE CAN COME UP WITH BETTER SOLUTIONS TO INTERNATIONALIZATION THAT DON'T INTEROPERATE AND DOESN'T WORK WITH THE PRESENT DNS.

WE CAN OVERWHELM SERIOUS WORK AND DESIGN OF THE KINDS WE HAVE BEEN TALKING ABOUT WITH (INAUDIBLE) DNS-RELATED GOAL AND WITH DISCUSSIONS AND DECISIONS WHICH ARE BASED ON PASSION RATHER THAN INTELLIGENCE AND WHICH -- AND PASSION MIXED WITH EXTREMES OF IGNORANCE, WHICH WE HAVE SEEN A GREAT DEAL OF IN THE WIDER COMMUNITY ALTHOUGH I HOPE NOT IN THE PARTICULAR ICANN ONE.

AND WE NEED TO FOCUS ON THOSE RISKS TO MAKING IDN WORK AND AVOID THEM.

SO IDNS PROVIDE US WITH AN OPPORTUNITY, AN OPPORTUNITY TO MAKE THE INTERNET MORE ACCESSIBLE TO MANY COMMUNITIES AND TO HELP WITH THE VERY IMPORTANT TASK OF PRESERVING CULTURE AND LANGUAGES.

THEY ALSO POSE RISKS, INCLUDING THE RISK OF BREAKING THE DNS, THE RISK OF INCOMPATIBLE IMPLEMENTATION THAT WOULD CAUSE DIFFERENT NAMES TO MEAN DIFFERENT THINGS IN DIFFERENT CONTEXTS, AND THE RISK OF IMPEDING INNOVATION IN OTHER TECHNOLOGIES AND OTHER TECHNIQUES, WHICH WOULD REST ON TOP OF THE DNS AND MAKE THINGS MORE INTERNATIONALIZED, MORE APPROPRIATELY LOCALIZED, AND MORE ACCESSIBLE TO USERS.

NEXT SLIDE.

SO AN OPTIMISTIC VIEW OF WHAT'S NEXT, IS THE IETF MOVES SWIFTLY AHEAD OF PROTOCOL ADJUSTMENTS AND ICANN TAKES THE KIND OF RISKS AND ISSUES WHICH I HAVE BEEN TALKING ABOUT AND CARY HAS BEEN TALKING ABOUT SERIOUSLY.

IF WE INVEST IN UNDERSTANDING, WE MAKE DECISIONS BASED UPON MAXIMUM IDN CAPABILITY CONSISTENT WITH THE DNS WHICH IS FULLY FUNCTIONAL TO THE USERS, AND WE AVOID DECISIONS BASED ON TRYING TO SATISFY THOSE PEOPLE WHO ARE MAKING UNREALISTIC DEMANDS OVER A CONCERN SIMPLY WITH AN ABILITY TO REGISTER AND RETRIEVE NAMES RATHER THAN USE THEM.

IF WE DON'T DO THAT AND TAKE THAT VIEW, WE RISK NEXT-GENERATION NAVIGATION TECHNIQUES THAT DON'T WORK OR DON'T RELY ON THE DNS OR GET OURSELVES INTO A SITUATION WHERE WE HAVE TO DISCARD THE DNS AND START OVER SOMEHOW.

THANK YOU VERY MUCH.

>>TINA DAM: THANK YOU, JOHN.

SO THE MICROPHONES ARE OPEN FOR COMMENTS AND QUESTIONS TO JOHN.

>> HI. JAY DALEY, FROM NOMINET, THE U.K. DOMAIN NAME REGISTRY.

JOHN, THAT WAS A VERY INTERESTING SPEECH.

CAN I ASK WHEN THE IETF GROUP THAT'S WORKING ON ALL OF THIS IS GOING TO BE OPENED UP FOR THE REST OF THE COMMUNITY TO BE INVOLVED?

>>JOHN KLENSIN: IT'S OPEN NOW IN THE SENSE THAT THERE'S A MAILING LIST AND PARTICIPATION.

IF YOU LOOK AT THE DOCUMENTS FROM THAT EFFORT THAT ARE -- THAT TINA HAS LISTED ON THE WEB SITE, I'D RATHER NOT TRY TO READ URLS OVER THIS MICROPHONE -- YOU WILL SEE IN THOSE DOCUMENTS POINTERS TO WHERE THAT MAILING LIST IS, AND IT'S OPEN AND YOU'RE WELCOME TO SUBSCRIBE TO IT.

I WILL WARN YOU, HOWEVER, THAT THERE IS AN ASSUMPTION, AND THAT CERTAINLY WILL NOT AFFECT YOU AS AN INDIVIDUAL, BUT THERE'S AN ASSUMPTION IN THAT DISCUSSION THAT PEOPLE ARE PARTICIPATING IN IT ACTUALLY UNDERSTAND A FAIR AMOUNT ABOUT HOW THE IDNA STANDARD WORKS AND ABOUT HOW UNICODE WORKS AND IS STRUCTURED.

AND PEOPLE WHO DON'T HAVE THAT RUNG CERTAINLY WELCOME TO SUBSCRIBE TO THE LIST AND LISTEN IN AND LURK.

BUT IF YOU START SPEAKING UP, YOU'LL FIND A NUMBER OF THE PEOPLE ON THAT LIST ARE PRETTY INTOLERANT.

>>BOB HUTCHINSON: MY NAME IS BOB HUTCHINSON.

I JUST HAVE A QUESTION FOR JOHN, IF ANYBODY HAS ATTEMPTED TO COME UP WITH AN ESTIMATE OF THE HUMAN EFFORT NECESSARY TO DO THE KINDS OF TASKS THAT IS BEING PROPOSED FOR THE IDN PROCESSES THEMSELVES.

MY RECOLLECTION IS THAT UNICODE HAS TAKEN A CONSIDERABLE AMOUNT OF TIME SINCE ABOUT THE MID-'80S TO GET IT TO THE LEVEL THAT IT IS TODAY, AND IT IS STILL NOT COMPLETE. AND THAT'S JUST ONE PIECE OF THIS PUZZLE.

AND YOU'VE GOT A LOT OF PIECES THAT ARE, YOU KNOW, REALLY UNBOUNDED IN TERMS OF WHAT KIND OF EFFORT IT'S GOING TO TAKE IN ORDER TO WRITE THE RULES FOR EVERY DIFFERENT SET OF LANGUAGES.

>>JOHN KLENSIN: WELL, BOB, I -- THE GROUP (INAUDIBLE) I DON'T THINK WE NEED TO DO THAT ALL AT ONCE.

THERE'S -- IF WE HAD TRIED TO DO THIS AT ALL TEN OR 15 YEARS AGO BEFORE THE UNICODE MACHINERY REACHED THE LEVEL OF MATURITY IT WAS AT FOUR YEARS AGO, IT WOULD HAVE BEEN IMPOSSIBLE.

AND PART OF WHAT WE HAVE LEARNED IN THE LAST FEW YEARS ALONG WITH THE UNICODE PEOPLE IS THAT FOR THIS KIND OF APPLICATION, WE DIDN'T UNDERSTAND UNICODE AND THEY DIDN'T UNDERSTAND UNICODE AND ITS APPLICABILITY HERE NEARLY AS WELL AS WE THOUGHT WE DID OR WE HOPED WE DID.

SOME OF THE CHANGES I'M TALKING ABOUT -- I WAS TALKING ABOUT DOING NOW IN TERMS OF RECASTING THE IDNA PROTOCOL ARE POSSIBLE BECAUSE OF WORK WHICH WAS DONE ON THE UNICODE SIDE OVER THE LAST THREE YEARS OR SO AND SIMPLY DIDN'T EXIST WHEN THE IDNA WAS STARTED.

SO WE'RE ACTUALLY IN PRETTY GOOD SHAPE.

THE DIFFICULTY -- THE INTERESTING QUESTION IN TERMS OF GETTING THIS ALL DONE IS THAT IF SOMEBODY COMES ALONG TODAY WITH -- WHO'S A FLUENT SPEAKER OF LOWER SLABOVIAN, WHICH AS FAR AS I KNOW IS NOT A CURRENT LANGUAGE, AND COMES ALONG AND WANTS IDNS IN THAT LANGUAGE, THEN WE HAVE A WHOLE SERIES OF VERY INTERESTING PROBLEMS.

WE HAVE TO FIGURE OUT HOW IT'S WRITTEN, THE UNICODE FOLKS HAVE TO MAKE CHARACTERS FOR IT AND ASSIGN CODEPOINTS.

WE HAVE TO FIGURE OUT THESE KINDS OF RULES WITH TOP-LEVEL DOMAIN FOR LOWER SLABOVIA AND ANYBODY ELSE WHO SPEAKS THIS SORT OF LANGUAGE.

AND THAT COULD TAKE A VERY LONG TIME.

AND THE GOOD NEWS IS, THE REST OF US DON'T HAVE TO WAIT.

AND ONE OF THE REASONS WHY WE'RE TRYING TO MAKE CHANGES WHICH MAKE -- WHICH MAKE THIS SYSTEM NOT ONLY ADAPTABLE TO NEW VERSIONS OF UNICODE, BUT ADAPTABLE TO INCREMENTALLY ADDING SCRIPTS IS PRECISELY SO THAT WE CAN SAY TODAY, OKAY, IF WE GO TO A PARTICULAR LANGUAGE COMMUNITY AND THEY SAY, WE'RE READY TO DO THIS, WE UNDERSTAND HOW TO DO IT, AND THEN THE COMMUNITY SAYS -- THEY RETURN, GO TO IT.

WE GO TO A LANGUAGE COMMUNITY WHICH SAYS, WE'RE NOT READY, OR WHICH CLEAR ISN'T READY, AND WE GO MORE SLOWLY.

AND THERE ARE POLICY ISSUES ASSOCIATED WITH THE SENTENCES I JUST UTTERED.

BUT I WOULD HOPE THAT WE CAN BE REASONABLE AND FLEXIBLE ABOUT THIS AND JUST KEEP A BALANCE ABOUT GETTING THINGS TO WORK VERSUS THE RISKS OF HAVING TO BACK THINGS OUT IF WE GET THEM WRONG.

GETTING THE MAJOR LANGUAGES OF THE WORLD -- AND I SUSPECT THAT INCLUDES EVERY LANGUAGE REPRESENTED IN THE ROOM YOU'RE SITTING IN TODAY -- INTO THIS ENVIRONMENT IS LESS DIFFICULT THAN WE MIGHT EXPECT, BECAUSE THOSE LANGUAGES ARE FAIRLY WELL UNDERSTOOD.

THERE MAY BE SOME DETAIL QUESTIONS, AND THERE ARE CERTAINLY SOME TECHNICAL ISSUES WE NEED TO WORK OUT.

BUT FAIRLY WELL UNDERSTOOD.

I TOLD PEOPLE THAT I WOULD BE VERY SURPRISED (INAUDIBLE) IETF EFFORT IF WE'RE STILL HAVING THAT DISCUSSION A YEAR FROM NOW.

WITH REGARD TO THE ICANN EFFORT, KEEP IN MIND THAT MANY, MANY HUNDREDS, PROBABLY MANY THOUSANDS OR A FEW MILLION, IDNS HAVE ALREADY BEEN REGISTERED AND (INAUDIBLE) IN THE REST OF THE WORLD -- IN THE WORLD TODAY, AND MOST OF THEM ARE BEING USED FAIRLY SUCCESSFULLY.

THIS IS NOT A STOP NOW AND START OVER SITUATION.

AND IT'S NOT A WAIT UNTIL EVERYTHING IS COMPLETELY READY SITUATION.

WE UNDERSTAND THIS WELL ENOUGH TO BE ABLE TO MOVE FORWARD.

WE JUST NEED TO MOVE FORWARD CAUTIOUSLY WITH INTELLIGENT WITH REASONABLE EXPECTATIONS.

>>TINA DAM: ALL RIGHT.

NEXT COMMENT.

>> SUBBIAH SUBRAMANIAN: HI, MY NAME IS SUBBIAH.

I'M WITH A COMPANY CALLED IDNS.NET.

I WAS PART OF THE TEAM THAT ORIGINALLY HELPED PIONEER ABOUT TEN YEARS AGO NOW THE CONCEPT OF WHAT WE NOW CALL IDN, AT LEAST THIS VERSION OF IT.

AND I ACTUALLY COINED THE PARTICULAR TERM "IDN."

NOW, WHAT QUESTION I HAVE FOR JOHN IS, I WOULD SAY THAT FOR MOST OF THE AUDIENCE HERE, 99% OF THE AUDIENCE HERE PROBABLY, THE TECHNICAL ASPECTS OF MUCH OF WHAT YOU SAID WAS PROBABLY NOT FULLY UNDERSTOOD.

THE MAIN MESSAGE THAT SEEMED TO COME FROM THE PRESENTATION WAS, IT'S VERY COMPLICATED, COMPLICATED, COMPLICATED, THERE ARE PROBLEMS, THERE ARE PROBLEMS, THERE ARE PROBLEMS.

AND --

>>JOHN KLENSIN: NO, SUBBIAH, I DON'T THINK I'VE SAID ANYTHING OF THE SORT.

AND I DON'T THINK YOU SHOULD INTERPRET IT THAT WAY.

>> SUBBIAH SUBRAMANIAN: A POLL MAY BE USEFUL.

BUT I WOULD LIKE TO ADDRESS TWO ASPECTS OF IT.

THIS HAS BEEN TEN YEARS SINCE, YOU KNOW, A LOT OF THIS HAS BEEN SUGGESTED.

NOT VERY MUCH HAS HAPPENED DURING THAT TEN YEARS IN TERMS OF ADDRESSING A LOT OF THESE ISSUES.

AND I JUST WANTED TO MAKE THREE OR FOUR POINTS.

ONE POINT IS -- I'M JUST PULLING OUT TWO OF THE SO-CALLED "BIG PROBLEMS" WITH GETTING IDN GOING OUT OF THE NUMBER OF PROBLEMS THAT YOU SUGGESTED.

ONE PROBLEM WAS THE SPOOFING ISSUE.

THE SPOOFING ISSUE, I THINK YOU'VE ACTUALLY ACKNOWLEDGED THAT IN PARTS OF YOUR TALK.

BUT -- BECAUSE YOU -- MANY THINGS WERE SAID, AND MAYBE THIS FACT IS NOT COMING OUT CLEAR.

SO I'M GOING TO ACTUALLY TRY TO CONFIRM AND REPEAT THIS.

THE SPOOFING ISSUE LARGELY GOES AWAY IF AT THE REGISTRATION POLICY LEVEL YOU JUST STICK TO ONE SCRIPT.

IF A TLD'S A PARTICULAR SCRIPT, THEN THE NAMES IN FRONT OF IT ARE PRETTY WELL RESTRICTED TO THAT SCRIPT OR THAT SCRIPT AND SOMETHING ELSE, A FEW CHARACTERS THAT COMMUNITY MIGHT WANT.

SO IF THAT WERE DONE, SINCE MOST LANGUAGES ARE SCRIPT, FOR THAT MATTER, I'M USING THE TERMS LOOSELY, DO NOT GO OUT AND MAKE UP CHARACTERS, MULTIPLE CHARACTERS THAT ARE THE SAME, LOOK THE SAME IN THAT LANGUAGE OR SCRIPT.

THEY DON'T DO THAT.

USUALLY A SINGLE SCRIPT OR A SINGLE LANGUAGE HAS ONLY, YOU KNOW, VERY CLEARLY DIFFERENT CHARACTER FORMS.

SO THIS -- THE ISSUE OF SPOOFING LARGELY ARISES BECAUSE ONE IS -- ONE IS PUTTING IN MULTIPLE SCRIPTS AND MULTIPLE LANGUAGES UNDER A SINGLE TLD, OR AT LEAST YOU'RE ALLOWING CHARACTERS FROM DIFFERENT SCRIPTS.

SO IF AT THE POLICY LEVEL, REGISTRATION POLICY LEVEL, YOU CAN JUST DO THAT, YOU JUST RESTRICT IT, MUCH OF IT GOES AWAY, LIKE THEY HAVE DONE, FOR INSTANCE, IN CHINA.

YOU KNOW, MOST OF IT GOES AWAY.

AND THIS CAN BE DONE.

I MEAN, YOU ALSO ACKNOWLEDGED THAT.

BUT I'D LIKE JUST TO SAY THAT THAT ISSUE IS NOT THAT BIG AN ISSUE IF YOU JUST RESTRICT IT GOING FORWARD.

AND PEOPLE ARE DOING THIS TODAY.

NOW, SECONDLY, THE ISSUE OF HTTP, HAVING TO TYPE THAT AND SOME TERMS WILL NOT BE FIXED BY ALL OF THIS, YOU ALSO ACKNOWLEDGED THAT WHILE THE DNS CAN'T REALLY, YOU KNOW, CHANGE -- WE HAVE TO DO A LOT MORE WORK TO CHANGE THAT PART OF IT, AT THE PRESENTATION LAYER THAT CAN BE REMOVED AT THE BROWSER LEVEL, SO ON AND SO FORTH, THAT CAN BE IMPLEMENTED.

I THINK YOU MENTIONED THAT.

SO THE CLARITY THERE THAT I'M TRYING TO SAY IS TWO OF THE LARGER SORT OF PROBLEMS THAT YOU MENTIONED IN YOUR LIST OF PROBLEMS ARE ACTUALLY NOT THAT BIG.

A COUPLE OF BROWSER MANUFACTURERS WHO ARE NOW GOING ALONG WITH THIS HAVE TO ACCEPT THEY HAVE TO ALLOW FOR THIS AND IT'LL BE OKAY.

SO I THINK THOSE ARE TWO.

THE LAST POINT I WANT TO ADDRESS IS THE ISSUE OF THE LAST SPEAKER, THE LAST QUESTIONER BROUGHT UP, WHICH IS THE ISSUE THAT IN ORDER TO GET EVERY OF THESE LANGUAGE SPACES AND GROUPS ACTUALLY TO GET IT RIGHT TO SOLVE SOME OF THESE PROBLEMS THAT ARE CUSTOMIZED TO THAT LANGUAGE GROUP COMMUNITY.

WELL, THAT REQUIRES THE INPUT OF THESE LANGUAGE COMMUNITIES.

AND, UNFORTUNATELY, IN THE LAST SEVERAL YEARS, THERE'S BEEN -- EXCEPT FOR THE CASE OF THE CHINESE, JAPANESE, AND KOREANS, WHO GOT TOGETHER, YOU KNOW, THROUGH -- ACTUALLY, THEY STARTED OUT WITH OTHER FORA THAN ICANN, THEY DID IT KIND OF INDEPENDENTLY LONG AGO.

AND THEY STARTED WORKING.

SO THE -- EXCEPT FOR SOME EXCEPTIONS OF LANGUAGE COMMUNITIES, MOST OF THE COMMUNITIES ARE NOT ACTUALLY ACTIVELY WORKING ON IT.

AND THE REASON IT'S -- THE REASON THAT'S HAPPENING IS BECAUSE NO EFFORT'S BEEN PUT INTO IT FROM ICANN FOR ALL THESE YEARS.

A LOT OF LAPSED TIME WHERE AT LEAST THE LARGER COMMUNITY HASN'T GONE OUT AND SOUGHT OUT THESE COMMUNITIES THAT EXIST OUT THERE THAT ARE INTERESTED AND PULL THEM AND SAY WE NEED TO FIX THESE THINGS IN CONJUNCTION WITH UNICODE.

IT'S NOBODY'S FAULT BUT IT HASN'T HAPPENED IN THE LAST FEW YEARS.

SO UNLESS WE ACTUALLY START BEING SERIOUS ABOUT THAT AND GOING FORWARD TO ACTUALLY ADDRESS THAT, WE'RE NOT GOING TO -- THAT PROBLEM IS STILL GOING TO REMAIN.

AS OF TODAY, I DON'T SEE THAT REALLY BEING CHAMPIONED BY ANYBODY, REALLY, IN A VERY INTERESTED FASHION.

>>TINA DAM: WE'RE RUNNING A LITTLE BIT LATE ON TIME.

>> THOSE ARE MY POINTS.

NOTHING ELSE.

>>TINA DAM: JOHN, I'M GOING TO LET YOU PROVIDE SOME COMMENT FEEDBACK ON THAT.

BUT BEFORE I DO THAT I'M GOING TO CLOSE THE KEY DOWN.

AFTER WERNER, I HAVE HONG XUE ON THE PODIUM AND THERE IS A COMMENT FROM THE FORUM.

JOHN, IF YOU WANT TO GIVE FEEDBACK, GO AHEAD.

>>JOHN KLENSIN: OKAY, LET ME TRY TO TAKE THESE IN TURN AND BRIEFLY.

THE FIRST, SUBBIAH, AND I WANT TO ACKNOWLEDGE THE CONTRIBUTION OF YOU AND YOUR COLLEAGUES TO GETTING THIS STARTED.

BUT AT THE SAME TIME, UNDERSTAND THAT THE THINGS HAVE TAKEN A RATHER DIFFERENT DIRECTION THAN AND YOU YOUR COLLEAGUES ORIGINALLY PROPOSED, STARTING WITH THE FACT THAT THE TERM "IDN" IS DISTINCT FROM THE TERM MULTILINGUAL DOMAIN NAME, CAME OUT OF THE IETF WHEN IT WAS REALIZED THAT NO ONE IN THE USER WORLD WANT A MULTILINGUAL DOMAIN NAME IN TERMS OF DIFFERENT LANGUAGES IN THE DOMAIN NAME. AND THAT EXACTLY ADDRESSES YOUR COMMENT ABOUT THE SPOOFING ISSUE.

THE SPOOFING ISSUE IS BOTH MORE AND LESS DIFFICULT THAN IT APPEARS.

I CERTAINLY AGREE WITH YOU THAT THERE'S BEEN MORE HYSTERIA ABOUT THAT THAN IT'S WORTH.

BUT AT THE SAME TIME, THE KINDS OF RESTRICTIONS YOU'RE TALKING ABOUT MAY NOT BE POSSIBLE.

WE CAN CERTAINLY SAY, WITHIN A GIVEN DOMAIN NAME LABEL, YOU CAN ONLY HAVE A CERTAIN SCRIPT.

BUT WHAT WE ACTUALLY KNOW ABOUT SCRIPTS IS THAT MANY OF THEM WERE DERIVED FROM OTHER ONES.

THE BOUNDARY BETWEEN WHAT IS THE GREEK SCRIPT AND THE ROMAN SCRIPT IS ACTUALLY A LITTLE BIT FUZZY.

THERE ARE -- IT IS POSSIBLE TO WRITE THINGS IN CYRILLIC WHICH LOOK JUST EXACTLY LIKE ROMAN CHARACTERS, IN SPITE OF BEING HOMOGENEOUS.

AND CARY ILLUSTRATED SEVERAL OF THOSE IN HIS TALK.

AND THOSE EXAMPLES HAVE BEEN AROUND, AND, UNFORTUNATELY, THE BAD GUYS HAVE ACTUALLY TESTED THOSE EXAMPLES.

AND THOSE THINGS ARE SINGLE SCRIPT, BUT CHARACTERS WHICH LOOK A LOT LIKE CHARACTERS IN ANOTHER SCRIPT.

YOU MADE THE OBSERVATION THAT SCRIPTS RARELY MAKE UP TWO CHARACTERS LOOK THE SAME.

BUT IN THE -- AMONG THE PEOPLE STUDYING THE LINGUISTICS AND DEVELOPMENT OF WRITING SYSTEMS, THERE'S ACTUALLY A DISTINCTION MADE BETWEEN SCRIPTS WHICH ARE HIGHLY DIFFERENTIATED, THE CHARACTERS ARE REALLY EASY TO TELL APART, AND SCRIPTS WHICH ARE NOT HIGHLY DIFFERENTIATED, IN WHICH THE DIFFERENCE BETWEEN CHARACTERS MAY DEPEND ON WHAT LOOKS TO SOMEBODY WHO IS NOT AN EXPERT IN LANGUAGE LIKE VERY, VERY SMALL VARIATIONS.

VARIATIONS GET EVEN SMALLER WHEN THE PEOPLE WORRYING ABOUT THE PRESENTATION CAN BEGIN TO FIDDLE AROUND WITH FONTS AND OTHER THINGS.

CERTAINLY WE HAVE BEEN -- THE PRESENTATION ISSUES ARE MUCH MORE IMPORTANT THAN THE IDNS ARE THEMSELVES.

VERY IMPORTANT ISSUE, BUT ONE WHICH, FORTUNATELY, WE DON'T NEED TO MAKE DECISIONS ABOUT AS A GLOBAL COMMUNITY.

AND I FULLY AGREE WITH YOU ABOUT THE INPUT OF LANGUAGE COMMUNITIES AND THE IMPORTANCE OF GETTING THAT INPUT AND THE IMPORTANCE OF EXPLAINING TO VARIOUS COMMUNITIES THAT THAT INPUT IS IMPORTANT AND IT BETTER COME FROM SOMEWHERE.

BECAUSE IF ICANN TRIES TO DO IT ON A GLOBAL BASIS, WE ARE REALLY GOING TO MESS IT UP AND MESS ICANN UP.

>>TINA DAM: WERNER, GO AHEAD.

SUBBIAH, MAKE IT REALLY SHORT IF YOU ARE GOING TO REPLY.

>> SUBBIAH SUBRAMANIAN: I DON'T THINK I DISAGREE WITH MOST OF WHAT YOU HAVE TO SAY.

I THINK I CAN AGREE WITH YOU MORE ON THE LAST PART.

IF WE TRY TO DO THIS ON A GLOBAL BASIS, WE WILL FAIL.

>>WERNER STAUB: THIS DISCUSSION REMINDS ME OF, OF COURSE, THE DISCUSSIONS EARLIER WHEN IDNA WAS BEING DEVELOPED, AND IN THOSE DAYS, THE SPOOFING PROBLEM WAS MENTIONED.

IT WASN'T THAT WE HADN'T SEEN IT. STILL, NO ACTION WAS TAKEN UNTIL THE SPOOFING PROBLEMS WERE SHOWN WITH SOME RATHER SPECTACULAR CASES. THEY WERE, OF COURSE -- DID NOT DO ANY DAMAGE, BUT STILL.

I WONDERED WHY THAT WAS, AND BASICALLY WHEN WE LOOKED AT THE SUGGESTIONS THAT WERE MADE AT THAT TIME, PRECISELY, THE SUGGESTION TO INTRODUCE A REGISTRATION POLICY, THIS WAS MADE WITHIN THE IDNA WORKING GROUP IN THE MAILING LIST, AND ESSENTIALLY IT WAS IGNORED OR NOT DISCUSSED BECAUSE THE IDNA WORKING GROUP FELT THAT THIS WAS NOT THEIR TASK.

SO I THINK THE REGISTRATION POLICY BIT WAS NOT DONE BECAUSE NOBODY FELT RESPONSIBLE.

IT WAS ALSO MAYBE NOT THAT DONE BECAUSE AT THAT TIME VERISIGN THOUGHT TOTAL LIBERTY WOULD BE PERFECTION IN TERMS OF REGISTRATIONS.

BUT IT WAS ESSENTIALLY NOBODY FELT CONCERNED, NOBODY FELT THAT IT WAS SOMETHING THAT HAD TO BE DONE. AND MAYBE IT WOULD REQUIRE SOME JOINT EFFORT AND, YOU KNOW, A GIVEN REGISTRY WOULDN'T DO IT SO THERE WERE NO REGISTRATION POLICIES.

IT WASN'T EVEN DISCUSSED -- I REMEMBER HAVING TRIED TO DISCUSS THIS, AND NOBODY WAS INTERESTED.

NOW, WE FEEL THAT IT IS ACCEPTED POLICY THAT EVERY REGISTRY SHOULD HAVE A POLICY.

NOW, WHEN NEW QUESTIONS COME UP, AND SOME PEOPLE HAVE PROPOSED IT, SHOULDN'T THIS POLICY BE COMPUTER READABLE? AND I THINK AGAIN, WE ARE IN THE SAME SITUATION. NOBODY FEELS CONCERNED. WE DON'T NEED TO DO THAT. WE SEE PEOPLE SAYING THAT BROWSERS TRYING TO MAKE THEIR OWN KINDS OF DECISIONS ABOUT WHAT TO DISPLAY OR NOT, WHAT A BAD THING THAT THE BROWSER DOES THAT.

WELL, MAYBE IT WOULDN'T JUST BE THE BROWSER'S DECISION IF THERE WAS A COMPUTER-READABLE POLICY THAT COULD BE FOUND SOMEWHERE ON THE INTERNET FOR A GIVEN TLD.

>>JOHN KLENSIN: WERNER, I WOULD LIKE TO EXPLORE PARTS OF THAT WITH YOU OFF-LINE.

I WOULD LIKE TO COMMENT, HOWEVER, ON THE HISTORY OF THE SPOOFING ISSUE FOR A MOMENT.

I AGREE THAT IT WAS BASICALLY IGNORED UNTIL THERE WAS GRAPHIC EXAMPLE IN THE EXTERNAL PRESS. BUT THE WORKING GROUP ESSENTIALLY TOLD THE IETF COMMUNITY, AND THE IESG TOLD EVERYBODY ELSE INCLUDING ICANN, THAT THIS WAS A RISK.

FOR THOSE OF YOU WHO REMEMBER THE TALK I GAVE AT THE MELBOURNE MEETING, WHICH WAS A VERY LONG TIME AGO, THERE WERE SLIDES IN THAT THAT TALKED ABOUT THE SPOOFING ISSUE AND ITS POTENTIAL.

AND I GUESS THERE IS A STYLE OF LEARNING IN THE COMMUNITY THAT SAYS WE DON'T DO ANYTHING UNTIL SOMEBODY GETS BITTEN.

I HAVE RAISED SOME OF THE ISSUES I RAISED TODAY DESPITE THE APPEARANCE OF COMPLEXITY, AND THIS IS COMPLEX UNDERNEATH BUT HOPE TO BE MADE SIMPLE FOR USERS. BUT DESPITE THAT RISK, ONE OF THE REASONS FOR RAISING THESE ISSUES IS PRECISELY IN ORDER TO HOPE THAT WE CAN GET AHEAD OF THIS CURVE RATHER THAN WAIT UNTIL SOMEBODY MAKES A BIG FLAP IN THE PRESS ABOUT A PROBLEM THAT WE KNEW ABOUT FOR YEARS EARLIER AND WE SUDDENLY START SCURRYING AROUND TRYING TO DEAL WITH IT.

AS FAR AS MAKING THESE POLICIES MACHINE READABLE, MY EXPERIENCE HAS BEEN IN DOING THAT WELL REQUIRES THAT ONE HAVE A MODEL AS TO WHAT THESE POLICIES ARE ABOUT, AND IT'S NOT CLEAR WE UNDERSTAND THAT WELL ENOUGH YET. BUT IT IS A DISCUSSION I WOULD BE DELIGHTED TO HAVE WITH YOU.

>>WERNER STAUB: OKAY. THANK YOU.

>>TINA DAM: ALL RIGHT. THANKS.

XUE HONG, YOU HAD A COMMENT?

>>XUE HONG: THANKS, TINA. I HAVE QUICK COMMENTS. CARY, JOHN AND OTHER TECHNICAL EXPERTS VERY PRECISELY EXPLAINED TO US IDN IS REALLY A COMPLICATED ISSUE. IT INVOLVES RISK AND IT HAS TECHNICAL LIMITATIONS AND RESTRAINTS.

HOWEVER, WHAT IS QUITE WELL-KNOWN TO THOSE TECHNICAL EXPERTS ARE NOT KNOWN TO ORDINARY USERS AT ALL. FOR USERS, THEY BELIEVE THAT WHERE THERE IS A WILL, THERE IS A WAY.

MY WILL IS TO USE MY NATIVE SCRIPTS IN DOMAIN NAME SYSTEM AND THERE SHOULD BE A WAY TO REALIZE THAT.

FROM THE TECHNICAL PERSPECTIVE, THAT MAY NOT BE TRUE.

I NOTE THAT ICANN IS COMMITTED TO IMPROVE THE COMMUNICATION WITH USER COMMUNITIES. THERE'S, INDEED, A VERY IMPRESSIVE IMPROVEMENT.

WITH RESPECT TO IDN, I THINK IT'S VERY IMPORTANT FOR ICANN TO OUTREACH TO THE USERS, TO LET THEM KNOW THAT USER -- WHAT IDN CAN DO AND WHAT IDN CANNOT DO.

BY DOING SO PROSPECTIVELY, I ASSUME ICANN CAN AVOID MANY COMPLAINTS OR MISUNDERSTANDINGS, AND THAT WILL REALLY SERVE THE SMOOTH AND SUCCESSFUL DEVELOPMENT AND DEPLOYMENT OF INTERNATIONALIZED DOMAIN NAMES.

FROM THE OTHER HAND, I AM A VERY LEARNED TECHNICAL EXPERT. WE WANT TO KNOW WHAT MAY SERVE THE USERS MORE EFFECTIVELY WITHIN THE TECHNICAL POSSIBILITY. WHAT IS THE BEST TECHNOLOGY THAT SHOULD BE USED TO SERVE THE USER?

ANY TECHNOLOGY IN THE END IS TO SERVE THE PEOPLE.

SO THAT WHAT I WANT TO SAY IS AT-LARGE ADVISORY COMMITTEE IS A USER INTERFACE IN ICANN; WOULD LIKE TO ENHANCE THE TWO-WAY COMMUNICATION BETWEEN ICANN AND THE USER COMMUNITY. THAT IS, TO BRING THE OPINION OF THE USERS TO ICANN. AND ALSO, TO OUTREACH ON BEHALF OF ICANN TO THE INDIVIDUAL USERS' COMMUNITIES.

I WANT TO REPEAT WHAT I SAID IN LAST NIGHT'S TELEPHONE CONFERENCE IS THAT AT-LARGE ADVISORY COMMITTEE IS NOW DOING A USER SURVEY. ONE PART IS ON IDN. SO WE ARE NOW ASKING USERS WHAT KIND OF TECHNOLOGY YOU PREFER TO USE TO REALIZE IDN.

AND WHAT WOULD BE THEIR EXPECTATION FROM THIS IMPLEMENTATION PROCESS OF INTERNATIONALIZED DOMAIN NAMES.

THANKS.

>>TINA DAM: CARY.

>>CARY KARP: STRAIGHT AWAY THAT ALL OF THE SCRIPTS THAT PEOPLE USE, AT LEAST TO THE EXTENT THAT THEY ARE ALREADY AVAILABLE IN UNICODE, CAN, TO A GREATER OR LESSER EXTENT, BE USED IN IDN. AND THE LESSER EXTENT IS NEVER HORRIFYINGLY CONSTRAINING.

THE PROBLEM IS THAT THERE IS AN EXPECTATION OF BEING ABLE TO USE A LANGUAGE IN IDN EXACTLY AS THEY USE IT IN OTHER CONTEXT. AND INDEED, WE DO NEED TO EXPLAIN WHY IT IS THAT THAT IS NOT ALWAYS TRUE AND CALL ATTENTION TO THE SITUATIONS WHERE IT IS LESS OF A CONCERN AND EXPLAIN EVEN MORE CAREFULLY WHERE IT'S MORE OF A CONCERN.

THAT'S THE AVAILABILITY OF SCRIPT AND EXTENSION OF THE AVAILABILITY OF LANGUAGE AND IDN.

BUT THEN THERE ARE ALL OF THE OTHER POLICY ISSUES. HOW DO WE THEN APPLY THIS IN A MANNER THAT IS BOTH REASONABLY RESPECTFUL OF THE CULTURAL REQUIREMENTS OF ALL THE LANGUAGE COMMUNITIES AND IS REASONABLY RESPECTFUL OF THE TECHNICAL -- OF THE FRAILTY OF THE INTERNET AND THE DNS? IT'S A ROBUST MECHANISM, BUT IT CAN'T SUSTAIN INFINITE ABUSE.

AND THE THIRD FACTOR OF ALL OF THIS, IS AS JOHN HAS POINTED OUT, ON THE APPLICATIONS DEVELOPMENT SIDE. THAT THERE ARE DECISIONS BEING MADE BY BROWSER DEVELOPERS ABOUT WHAT MAY SAFELY BE SHOWN TO THEIR USERS.

SO, INDEED, WHAT WE NEED TO HAVE IS A BROADER DIALOGUE ABOUT ALL OF THIS RATHER THAN MAKE IT SEEM AS THOUGH WE ARE CONFRONTING SOME HORRIFYINGLY COMPLEX TECHNICAL ISSUE.

THE COMPLEXITIES ARE NOT ON THE TECHNICAL LEVEL. THE COMPLEXITIES ARE ON ALL OF THE DETAIL WHICH IS NOT UNDERSTOOD AS RELEVANT IN MANY QUARTERS. AND ALL OF THE CULTURAL NUANCE OF THIS, WHICH IS NOT UNDERSTOOD AS RELEVANT IN OTHER QUARTERS.

SO THE TASK FOR I SEE IT IS PEDAGOGICAL MORE THAN ANYTHING ELSE AT THIS POINT.

>>TINA DAM: THANKS, CARY. SO WE ARE GOING TO MOVE FORWARD. WE ARE A LITTLE BIT DELAYED ON TIME.

THE FIRST THREE PRESENTATIONS OBVIOUSLY WAS VERY FOCUSED ON SOME OF THE TECHNICAL PROJECTS AND ACTIVITIES THAT ARE GOING ON.

AND THE THREE NEXT ARE GOING TO BE MORE POLICY FOCUSED. SO HIRO, PLEASE GO AHEAD WITH YOUR INFORMATION ABOUT WHAT'S GOING ON IN THE CCNSO.

>>HIRO HOTTA: YES, THIS IS HIRO HOTTA.

I WOULD LIKE TO MAKE A VERY BRIEF PRESENTATION ON THE IDN DISCUSSIONS IN CCNSO.

THIS IS A STATUS REPORT, SO THERE IS NO CONCRETE RESULT OR CONSENSUS FROM THE DISCUSSION YET.

YES. THIS IS MY BUSINESS CARD IN DAILY LIFE.

SO IF THE IDN TLD IS COMING, THIS CAN BE LIKE THIS (INDICATING).

SO I MAY REMAKE MY BUSINESS CARD.

SO BRIEF HISTORY OF CCTLD IDN DISCUSSION.

IT'S OLD, FROM 2000, DISCUSSION OF IDNS AS SECOND LEVEL DOMAIN AND THIRD LEVEL DOMAIN, OR SOMETHING LIKE THAT.

THERE WAS A DISCUSSION FOR SHARING THE BASICS AND SHARING THE EXPERIENCES AND SHARING ISSUES.

WE TALKED ABOUT THE IDNS IN OLDER DAYS IT'S LED BY CCTLD LIKE DOT CN DOT TW, DOT KR AND DOT JP WHICH WERE THE LEADERS OF THE IDN IMPLEMENTATION.

AND THEN DISCUSSION ON IDNS AS TLD. IN JUNE THIS YEAR, WE SHARE THE CONTENT OF THE GNSO ISSUE REPORTS ON IDN TLDS. AND IN OCTOBER, WE CREATED IDN WORKING GROUP.

AND YESTERDAY WE TALKED ABOUT THE IDNS ALSO IN CCNSO MEETING. WE DISCUSSED THE ISSUES FROM THE CCNSO PERSPECTIVE, AND CCNSO AND IDN WORKING GROUP HERE WAS APPOINTED WHO IS DR. LIANG FROM TWNIC.

AND DISCUSSION YESTERDAY.

AS I SAID, DISCUSSION WAS MADE TO UNDERSTAND AND DEFINE THE ISSUES. NO RESULT OR CONSENSUS HAS BEEN BUILT.

CCNSO MEMBERS MEETING DISCUSSED ABOUT IDN TLDS YESTERDAY. WE SHARED THE CURRENT STATUS FOR IDN TLD, ABOUT THE TECHNICAL TESTS AND IETF PROTOCOL REVISION, WHICH WAS ALREADY COVERED BY TINA.

AND POLICY RELATED ITEMS TO CONSIDER. WE DID SOME KIND OF BRAINSTORMING ON THIS. SAME ASPECTS AND DISTINCTIONS BETWEEN CCTLD AND GTLD. OF COURSE THERE ARE SOME ASPECTS WHICH SHARE BETWEEN CCTLD AND GTLD, AND SOME BIG DISTINCTION BETWEEN THEM.

WHAT IS AN INTERNATIONALIZED CCTLD?

THE DEFINITION OF CCTLD ITSELF. I'LL TOUCH THIS LATER, A BIT.

GAC PLAYS A ROLE IN DEFINING IDN CCTLD STRING. LANGUAGE COMMUNITY AND/OR LANGUAGE SCRIPT SHARING COMMUNITY PLAYS A ROLE IN DEFINING AND/OR OPERATING IDN TLD.

ONE IDN TLD PER ONE ASCII TLD IN THE FIRST ROUND. SOMETHING LIKE THAT.

FIRST IDN CCTLD STRING DEFINITION. THIS IS SOME KIND OF A BIG ISSUE. WHAT STRING? MAPPING TO RFC 1591, WHICH REFERS TO JUST ISO 3166 MAYBE YES.

AND IN WHAT SCRIPT? IN OFFICIAL LANGUAGE? MAYBE NOT, MAYBE YES.

SOME COUNTRIES EVEN HAVE NO DEFINITION OF OFFICIAL LANGUAGES. AND DAILY-USED LANGUAGE IS NOT AN OFFICIAL LANGUAGE IN SOME COUNTRIES. SO OFFICIAL LANGUAGE IS NOT THE ABSOLUTE SOLUTION.

AND SCRIPT X VERSION OF CCTLD-Y. FOR EXAMPLE, GREEK VERSION OF DOT AU, AUSTRALIA. FOR GREEK COMMUNITY IN AUSTRALIA, YES OR NO? AND ALL COMBINATIONS OF SCRIPT TIMES COUNTRY CODE. THIS IS AN ENORMOUS NUMBER. MAYBE NOT.

AND HOW MANY CHARACTERS?

AS IN ASCII SPACE, CCTLD HAS TO HAVE JUST TWO CHARACTERS? MAYBE NO. OR FULLY-SPELLED OFFICIAL COUNTRY NAME? THIS IS ALSO MAYBE NO.

SO WE HAVE TO DECIDE THIS.

AND AVOIDING SIMILAR-LOOKING STRING TO OTHER TLDS. TLDS MEANS, IN THIS CASE, CC AND G. IF YES, IN WHAT MECHANISM?

AND BY WHOM? LANGUAGE COMMUNITY. CAN WE DEFINE SUCH A LANGUAGE COMMUNITY?

OTHER ENTITIES SUCH AS GAC OR UNITED NATIONS. ISO MAY NOT BE THE OPTION WHO WILL DEFINE THE IDN VERSION OF CC, BECAUSE THE ISO DECLINED WHEN THEY ONCE ASKED FOR.

I HEARD THAT.

AND EXISTING CCTLD BY ITSELF. CAN A COUNTRY HAVING SCRIPT-X COMMUNITY RUN SCRIPT-X VERSION OF OTHER COUNTRY'S CCTLD?

THERE ARE SOME BACKGROUND ISSUES. DEFINITION OF CCTLD. THERE IS NO CLEAR DEFINITION, EVEN FOR ASCII CCTLD.

CURRENTLY, THE CC, CCTLD FOLLOWS ONLY THE -- BY REFERRING TO ISO 3166.

AND WHO IS THE CCTLD MANAGER FOR IDN VERSION? EXISTING CCTLD MANAGER FOR THE ASCII CC? IT'S EASY TO DEFINE THIS. BUT IS IT OKAY? OR IF NOT, IF NOT EXISTING CCTLD MANAGER, THEN WHO DECIDES?

AND IN THAT CASE, RELATIONSHIP TO THE EXISTING ASCII CC SPACE. THEY MUST BE INDEPENDENT OR THERE HAS TO BE SOME MAPPING. BETWEEN THEM.

AND HOW WE PROCEED? THIS IS THE LAST SLIDE.

IN THE CCNSO, WE HAD A FEELING THAT WE NEED TO COMMUNICATE WITH THE GAC IN DEFINING IDN CCTLD STRING. MAINLY FOR THE DEFINITION OF THE STRING, PER SE. WE MAY NEED TIME TO DECIDE COUNTRY NAME, SCRIPT, AND REPRESENTATION OF THE COUNTRY NAME IN THAT SCRIPT.

SO CCNSO FELT THAT GAC AND CCNSO MAY HAVE JOINT WORKING GROUP TO DISCUSS THIS. AND COMMUNICATION WITH GNSO IN DEFINING THE IDN CCTLD STRING, MAINLY FOR CONSISTENCY WITH GTLDS.

AND WE ALREADY HAVE JOINT WORKING GROUP BETWEEN CC AND G AND COMMUNICATION WITH OTHERS.

AND INSIDE CCNSO, WE ARE GOING TO DEFINE THE ISSUES IN A COUPLE OF MONTHS, AND WE WILL MAKE A DISCUSSION PAPER AND WE WILL MEET WITH OTHER ENTITIES IN THIS ONE.

OKAY. THAT'S IT.

>>TINA DAM: THANK YOU, HIRO.

ANY QUESTIONS OR COMMENTS TO HIRO?

>>WERNER STAUB: I WAS A LITTLE BIT SURPRISED WHEN I HEARD THAT THE USE OF THE FULL COUNTRY NAME WOULD NOT BE A SOLUTION, AND THEN ABOUT WHY THIS CAME, AND I THINK THE THINKING BEHIND YOUR STATEMENT MIGHT HAVE BEEN THAT YOU WERE LOOKING FOR A METHOD THAT WOULD BE VALID FOR ALL COUNTRIES AND FOR ALL LANGUAGE, SO TO SPEAK STANDARD COMPARABLE TO THE ISO 3166 TO BE USED FOR IDN. AND I THINK THAT IS HOPELESS. OF COURSE IT MAKES NO POINT WHATSOEVER TO LOOK FOR THAT KIND OF A STANDARD.

THE SOLUTION FOR A GIVEN IDN TLD THAT WOULD BE AN ALIAS TO THE CCTLD WOULD ACTUALLY BE SPECIFIC TO EACH COUNTRY, AND THAT COUNTRY OR COMMUNITY WOULD KNOW WHAT TO DO.

SO THE SOLUTION I WOULD PROPOSE IS THAT PERFECTLY WELL THE FULL COUNTRY NAME IN THE RESPECTIVE COUNTRY SCRIPT COULD BE USED IF THAT COUNTRY WANTS TO DO THAT.

BUT IF AN APPLICATION FOR THAT WOULD BE SUBMITTED IT WOULD BE TREATED AS A CCTLD.

IF IT WAS SOMETHING THAT DID NOT MATCH THE TERRITORY OF THE CCTLD, IT WOULD BE TREATED AS A GTLD.

>>HIRO HOTTA: OKAY. THANK YOU. WHAT I WANTED TO SAY IN THIS SLIDE WAS FULL NAME OF THE COUNTRY NAME COULD BE USED, BUT SOME COUNTRIES MAY HAVE A VERY LONG COUNTRY NAME, IN THAT CASE, FOR THAT COUNTRY, IT CANNOT BE ADJUSTED INTO 63 ASCII CHARACTERS.

THAT'S WHAT I SAID IN THIS.

>>WERNER STAUB: OKAY. I UNDERSTAND.

USUALLY ANY COUNTRY HAS A SHORT NAME, ALSO, WHICH IS ALSO SOME KIND OF A FULL NAME BUT IT'S UNDERSTOOD TYPICALLY IN THAT COUNTRY.

>>HIRO HOTTA: OKAY. THANK YOU.

>>TINA DAM: ANY OTHER QUESTIONS FOR HIRO?

YEAH, SOPHIA.

>>SOPHIA BEKELE:SORRY, IT JUST REMINDED ME OF SOMETHING WHEN YOU WERE DISCUSSING THE FULL COUNTRY NAMES. IT REMINDS ME OF WHEN CNN FIRST STARTED AND SOME OF THE REPORTERS OR THE ANCHOR PEOPLE COULD NOT PRONOUNCE THE WORD KAZAKHSTAN OR AZERBAIJAN, AND SO FORTH, AND THERE WAS A LOT OF CRITICISM. AND SO I THINK ICANN SHOULD MAKE A LOT OF EFFORT INTO ACCOMMODATING THE COUNTRIES AND THE NAMES WHEN YOU ARE BUILDING THIS UP.

THANK YOU.

>>TINA DAM: OKAY. WE ARE MOVING ON TO BRUCE TONKIN AROUND THE GNSO IDN WORK.

>>BRUCE TONKIN: OKAY. THANK YOU, TINA.

FIRSTLY, THE GNSO IS ATTEMPTING TO DESIGN ITS NEW GTLD POLICY TO BE GENERAL ENOUGH TO SUPPORT THE USE OF IDN STANDARDS FOR GTLD STRINGS. AND THE GENERAL APPROACH WE'RE TAKING HERE IS WE BELIEVE THERE NEEDS TO BE A CONSISTENT POLICY FOR ANY TYPE OF STRING USED AS A GTLD.

THAT DOESN'T MEAN THAT THE GNSO POLICY WORK IS TRYING TO SET DATES OR TRYING TO APPROVE THE INTRODUCTION OF IDN STRINGS INTO GTLDS. IT'S MERELY SAYING THAT WHEN THE COMMUNITY MAKES THAT DECISION AND TECHNICAL COMMUNITIES IS COMFORTABLE WITH THAT DECISION. THEN WE WANT TO MAKE SURE THAT OUR POLICY IS CAPABLE OF SUPPORTING IDN STRINGS FOR GTLDS.

PROBABLY THE AREA THAT'S MOST RELEVANT TO THIS DISCUSSION IS WHAT WE SAY THE CRITERIA SHOULD BE FOR INTRODUCING A NEW GENERIC TOP-LEVEL DOMAIN NAME AND OUR CATEGORIES ARE IN THREE AREAS. THEY ARE IN STRING CRITERIA, THEY ARE IN THE APPLICANT CRITERIA, WHETHER THE APPLICANT IS TECHNICALLY QUALIFIED, ET CETERA. AND THERE ARE PROCESS RULES THAT ICANN WOULD NEED TO FOLLOW BEFORE A TLD IS INTRODUCED.

THE STRING CRITERIA WE'RE TRYING TO CAPTURE SUCH THAT THEY WOULD APPLY TO BOTH AN IDN GTLD AS WELL AS A GTLD THAT DOESN'T USE THAT STANDARD, AND SO THE FIRST ONE IS PRETTY MUCH PICKING UP A LOT OF THE DISCUSSION WE HAVE HEARD SO FAR IN THAT ANY NEW STRING THAT'S INTRODUCED SHOULD NOT BE CONFUSINGLY SIMILAR TO AN EXISTING TLD.

THE STRING SHOULDN'T INFRINGE THE RIGHTS OF OTHERS, IT SHOULD NOT CAUSE TECHNICAL INSTABILITY. AND THIS IS ISSUES WHERE PARTICULAR STRINGS -- AND WE GIVE EXAMPLES LIKE DOT EXE, FOR EXAMPLE, MAY CAUSE ISSUES WITH SOME SOFTWARE THAT ASSUMES THAT'S AN EXECUTABLE FILE AS OPPOSED TO A DOMAIN NAME. AND THERE IS NO DOUBT THERE ARE IDN SCENARIOS HERE AS WELL THAT WE WOULD NEED TO TAKE INTO ACCOUNT.

AND WE'RE ALSO SEEKING INPUT FROM THE GOVERNMENTAL ADVISORY COMMITTEE ON SOME OF THE STRING ISSUES THAT THEY MAY HAVE. AN EXAMPLE OF A STRING ISSUE THAT THEY MAY HAVE IN TERMS OF PUBLIC POLICY IS THEY MAY STATE THAT A GENERIC TOP-LEVEL DOMAIN SHOULDN'T INCLUDE THE NAME OF A COUNTRY NAME OR PERHAPS THE NAME OF AN EXISTING PLACE.

AND PERHAPS IF SUCH -- IF SOMEBODY DID WISH TO INTRODUCE A NEW COUNTRY NAME OR A PLACE NAME OF SOME FORM, THEN THERE PERHAPS IS AN ALTERNATIVE PROCESS THAT'S USED, AND THAT PROBABLY CUTS INTO SOME OF THE WORK THAT THE CCNSO IS DOING, OR PLANNING TO DO WITH THE GAC ON SOME OF THOSE PROCEDURES.

AND THEN FINALLY, WE EXPECT THERE WILL BE SOME WORDS OR STRINGS THAT WILL BE RESERVED, AND WILL NOT BE ALLOWED TO BE REGISTERED BY ANYBODY. THERE IS AN EXISTING LIST THAT IS USED FOR THE SECOND LEVEL OF GENERIC TOP-LEVEL DOMAINS, AND THAT LIST WOULD NEED TO BE REVISED FOR THE PURPOSES OF THE TOP LEVEL.

ONE OF, I THINK, THE KEY INPUTS THAT THE POLICY NEEDS IS GUIDELINES RELATED TO THOSE POLICY PRINCIPLES. SO AS WELL AS IMPLEMENTING THE NEW POLICY, WE NEED EXTENSIVE GUIDELINES WHICH WOULD INCORPORATE IDN-BASED EXAMPLES, IF IDNS WERE TO BE INTRODUCED.

SO WE WOULD GIVE EXAMPLES OF THE SORTS OF IDN STRINGS THAT WOULD LIKELY CONFLICT WITH EXISTING TLDS. WE WOULD TRY TO PRODUCE THESE GUIDELINES WITH THE OBJECT TO MAXIMIZE THE CHANCE THAT A STRING PROPOSED BY A NEW GTLD WOULD NOT GET ANY OBJECTIONS FROM THE COMMUNITY.

SO IN TERMS OF THE PROCESS FOR INTRODUCING NEW GTLDS, ANY PROPOSED STRING WOULD BE PUBLISHED, AND WIDELY PUBLICIZED. AND OBVIOUSLY DEPENDING ON WHAT THAT STRING WAS, ICANN WOULD MAKE AN EFFORT TO CONTACT THOSE PARTIES THAT MAY BE AFFECTED.

SO OBVIOUSLY IF THE STRING HAPPENED TO INCLUDE PERHAPS CHINESE CHARACTERS, THEN ICANN WOULD MAKE AN EFFORT TO ADVISE PEOPLE IN THE CHINESE-SPEAKING COMMUNITIES AROUND THE WORLD OF THAT PROPOSED STRING.

A COMMUNITY CAN OBJECT TO THE STRINGS, BUT BASED ON THE STRING CRITERIAS. THEY CAN'T JUST BE "I OBJECT BECAUSE I DON'T LIKE THAT STRING." IT HAS TO BE "I OBJECT TO THAT STRING BECAUSE IT'S CONFUSINGLY SIMILAR TO AN EXISTING STRING" OR THEY BELIEVE THERE COULD BE TECHNICAL PROBLEMS WITH THAT STRING. AND THEY NEED TO PROVIDE EVIDENCE OF THAT. IT'S NOT ENOUGH TO SIMPLY SAY "I THINK THERE MIGHT BE CAUSE A PROBLEM." THEY WOULD NEED TO PROVIDE EVIDENCE THAT THERE WOULD, IN FACT, BE AN EVIDENCE.

ONE OF THE ISSUES FOR STAFF AT THIS STAGE IN LOOKING AT THE POSSIBLE IMPLEMENTATION OF THE DRAFT NEW GTLD POLICY IS INVESTIGATING POSSIBLE DISPUTE RESOLUTION PROVIDERS. AND WE HAVE IDENTIFIED THAT WITH THE EXISTING UDRP APPROACH FOR -- THAT IS USED FOR DOMAIN NAMES AT THE SECOND LEVEL, THERE ARE DOCUMENTED CASES NOW OF DISPUTES INVOLVING IDN-BASED STRINGS AT THE SECOND LEVEL.

SO WE ARE STARTING TO BUILD A BIT OF CASE HISTORY WITH RESPECT TO IDNS AT THE SECOND LEVEL AND HOPEFULLY SOME OF THAT COULD BE APPLIED POTENTIALLY BY THE SAME DISPUTE PROVIDERS FOR DISPUTES THAT ARE -- OCCUR AT THE TOP LEVEL.

I THINK OUR GENERAL COMMENTS, I OFTEN HEAR PEOPLE MENTION LANGUAGE AND THAT IDNS INTRODUCES LANGUAGE ISSUES.

LANGUAGE ISSUES ACTUALLY ALREADY EXIST, BECAUSE YOU CAN -- A NUMBER OF LANGUAGES USE THE LATIN SCRIPT ALREADY.

IT JUST HAPPENS TO BE SO FAR, ALL THE GTLDS WE HAVE HAVE SOME MEANING TO ENGLISH SPEAKERS, BUT CERTAINLY IN THE FUTURE, WE'D EXPECT THAT NON-ENGLISH SPEAKERS WOULD BE PROPOSING NEW GTLDS THAT CONTINUE TO USE THE LATIN SCRIPT.

SO LANGUAGE ISN'T SOMETHING NEW.

BUT WHEN WE LOOK AT ADDING NEW SCRIPTS USING IDNS, IT JUST MAKES IT ALL MUCH MORE DIFFICULT.

AND I THINK, ULTIMATELY, WE'RE GOING TO HAVE TO LEARN BY EXPERIENCE.

I DON'T THINK WE CAN POSSIBLY PREDICT ALL THE POSSIBLE STRING CONFLICTS AND STRING ISSUES THAT MAY OCCUR.

BUT OVER TIME, WE WILL BUILD THAT KNOWLEDGE.

AND AS NEW STRINGS ARE ADDED, WE'LL BE ABLE TO MAKE BETTER DECISIONS.

WE DO RECOGNIZE, HOWEVER, THAT WITHIN THE GNSO, WE MAY NOT HAVE IDENTIFIED ALL THE POLICY ISSUES.

AND SO WE HAVE FORMED A GNSO IDN WORKING GROUP WHOSE TASK IS TO IDENTIFY AND SPECIFY THE POLICY ISSUES THAT SHOULD BE CONSIDERED BY THE GNSO VIA OUR POLICY DEVELOPMENT PROCESS.

AND THESE ARE THE ISSUES THAT HAVE NOT ALREADY BEEN CONSIDERED WITHIN THE EXISTING NEW GTLD POLICY DEVELOPMENT PROCESS.

THE MEMBERSHIP OF THAT GROUP IS OPEN TO ANY MEMBER OF A GNSO CONSTITUENCY OR THE GNSO COUNCIL.

AND ICANN ADVISORY COMMITTEES, WHICH INCLUDE THE AT-LARGE ADVISORY COMMITTEE, MAY APPOINTED LIAISONS TO THAT WORKING GROUP.

AND RAM MOHAN, FROM AFILIAS, HAS RECENTLY BEEN ELECTED AS CHAIR OF THAT WORKING GROUP.

AND RAM IS ALSO A MEMBER OF THE PRESIDENT'S ADVISORY COMMITTEE ON IDNS.

SO THAT'S ALL I HAD.

TINA.

>>TINA DAM: THANK YOU, BRUCE.

ANY QUESTIONS AROUND HOW THINGS ARE GOING FORWARD AT THE GNSO LEVEL?

AND I'M JUST -- THERE'S A COUPLE OF PEOPLE GOING TO THE MICROPHONE.

I'M JUST GOING TO ASK YOU TO TRY TO KEEP IT SHORT, BECAUSE WE HAVE ONE LAST PRESENTATION TO DO AND WE'RE RUNNING UP A LITTLE BIT AGAINST TIME.

>> YOUNG EUM LEE: I'M JUST CONCERNED ABOUT THE FACT THAT THE GNSO IS CONSIDERING IDNS AS ANOTHER G SPACE TLD, BECAUSE, BASICALLY, GTLDS ARE MORE OR LESS GLOBAL.

AND IDNS ARE MORE OR LESS REGION OR LANGUAGE-SPECIFIC.

AND THE REASON FOR THE -- I MEAN, FOR THE DISCUSSION ABOUT IDNS IS BECAUSE THOSE SPECIFIC GROUP OF PEOPLE IN A SPECIFIC REGION, SOMETIMES WITHIN A COUNTRY OR ACROSS A COUPLE OF COUNTRIES, WOULD -- WHICH IS A SPECIFIC GROUP OF PEOPLE, HAVE SHARED THE SAME LANGUAGE SCRIPT, AND THERE NEEDS TO BE SPECIFIC ATTENTION, SPECIAL ATTENTION PAID TO THE FACT THAT THIS IS NOT A GLOBAL ISSUE AND THAT THE SPECIFIC GROUP OF PEOPLE SHARING THE SAME LANGUAGE SCRIPT NEED TO BE CONSULTED AND NEED TO BE TAKEN INTO CONSIDERATION WHEN WE ARE CREATING A TLD, AN IDN TLD IN THAT SPACE.

>>BRUCE TONKIN: JUST RESPOND VERY QUICKLY TO THAT, 'CAUSE I THINK THERE'S PERHAPS SOME INCONSISTENCIES THERE.

IT IS GLOBAL, BECAUSE THE TOP-LEVEL DOMAIN IS GLOBALLY ACCESSIBLE.

AS ANYBODY THAT HAS INTERNET CONNECTIVITY SHOULD BE ABLE TO GET TO THAT STRING TO RESOLVE IT.

SO IT IS A GLOBAL ISSUE, BECAUSE THE STRING IS GLOBALLY ACCESSIBLE.

THEN YOU MADE A COMMENT ABOUT THE CURRENT STRINGS ARE GLOBAL.

BUT I DON'T UNDERSTAND THAT, EITHER.

BECAUSE THE CURRENT STRINGS ARE PRETTY MUCH UNDERSTOOD BY ENGLISH-SPEAKING PEOPLE.

SO I THINK THE WHOLE ARGUMENT ABOUT INTRODUCING IDN SCRIPTS IS THAT THE STRINGS WE HAVE NOW AREN'T USEFUL FOR EVERYBODY ON THE GLOBE AND WE DO NEED TO INTRODUCE NEW STRINGS.

SO I THINK WE ARE TREATING IT IN THE SENSE THAT WE ARE CERTAINLY ENCOURAGING THOSE COMMUNITIES TO SUBMIT APPLICATIONS FOR A STRING, AND THAT STRING WOULD BE GLOBALLY ACCESSIBLE TO ANYBODY ON THE PLANET.

SO THAT'S WHY IT'S A GENERIC TLD.

>> YES.

BASICALLY, ALL TLDS ARE GLOBAL IN THE FACT THAT, I MEAN, IF YOU TAKE THAT REASONING, CCTLDS ARE ALSO GLOBAL.

BUT CCTLDS ARE VERY DIFFERENT FROM GENERIC TLDS.

AND I JUST WOULD LIKE TO POINT THAT OUT.

THANK YOU.

>>AMADEU ABRIL I ABRIL: OKAY?

OKAY.

MY NAME IS AMADEU ABRIL I ABRIL.

AND I HAD A COUPLE OF SUGGESTIONS FOR THE GNSO AND SOMETHING THAT'S NOTHING TECHNICAL, EVEN NOTHING VERY, YOU KNOW, LOGICAL IN POLICY LEVEL, BUT PROBABLY VERY PRACTICAL.

AS YOU SAID, ONE OF THE CRITERIAS YOU MAY OPPOSE THE STRING IS BECAUSE OF THOSE CONFUSINGLY SIMILAR.

I WOULD SAY TWO THINGS THAT SHOULD BE ADDED THERE.

THE FIRST ONE IS THAT, FOR INSTANCE, IF THE NEW STRING THAT'S BEING ADDED IS THE NAME OF A LANGUAGE, THAT THIS HAS TO BE RUN WITH THE INVOLVEMENT OF THAT COMMUNITY, WHICH MEANS INVOLVEMENT OF A PART OF THAT COMMUNITY, AND THIS ALSO INVOLVES THE LACK OF ABSENCE OF -- I'M SORRY -- THE ABSENCE OF A POSITION FROM, YOU KNOW, THE RELEVANT PART OF THAT LINGUISTIC COMMUNITY.

AND THERE ARE WAYS OF DEFINING THAT.

NOT BECAUSE THIS IS A REQUIREMENT, BUT BECAUSE THE COUNTRY WOULD CREATE AN INCREDIBLE POLITICAL PROBLEM TO ICANN AND IDNS IN GENERAL.

AND THE SECOND WOULD BE, FOR INSTANCE, IF YOU CREATE .DODGE OR .RUSKI, I MEAN, SOMEBODY PROPOSED .RUSKI OR .DEUTSCH, BEING THAT IN PURELY ASCII OR CYRILLIC SCRIPT, SO IDN OVER IDN.

THE SECOND IS, WHAT HAPPENS WITH IDNS WRITTEN IN OTHER SCRIPTS?

WELL, ONE DAY, THIS SHOULDN'T BE A QUESTION.

BUT I ALSO ADVISE THE GNSO TO PUT SOMEWHERE THAT THE FIRST STRING THIS TIME AS WE ARE OPENING THIS FOR IDN STRINGS PERHAPS NEXT TIME, AS WE ARE OPENING THIS, PERHAPS THE STRINGS THIS FIRST ROUND OF ANY STRING IN A GIVEN SCRIPT OR LANGUAGE SHOULD BE SOMEHOW ALSO RUN WITH INVOLVEMENT OF A PART OF THAT COMMUNITY.

THAT IS, IT DOESN'T MEAN THAT DOMAIN NAMES IN ENGLISH, WHICH ARE THE VAST MAJORITY THAT EXIST NOW, SHOULD BE RUN FROM ENGLISH-SPEAKING COUNTRIES OR MAINLY BY ENGLISH-SPEAKING PEOPLE.

THIS IS PROBABLY RIDICULOUS.

BUT I AM AFRAID THAT IF THE FIRST ARABIC SCRIPT DOMAIN NAME OR CYRILLIC SCRIPT DOMAIN NAME OR THE FIRST IDN TLD THAT'S IN ANY OTHER GIVEN SCRIPT AND LANGUAGE, IT'S RUN FROM COMPLETELY OUTSIDE THE COMMUNITY, ONCE AGAIN, WE WILL BE DOING A VERY POOR SERVICE TO THE IDN EFFORT.

>>TINA DAM: THANKS, AMADEU.

SO WE'RE MOVING FORWARD TO THE LAST SPEAKER OF THE DAY, PANKAJ AGRAWALA, FROM THE -- CHAIRING THE GAC IDN WORKING GROUP.

>>PANKAJ AGRAWALA: THANK YOU, TINA.

THERE IS NO PRESENTATION FROM MY SIDE.

I'M JUST GOING TO BE BRIEFING ABOUT HOW THE GOVERNMENTAL ADVISORY COMMITTEE IS DEALING WITH THE ISSUE OF IDNS.

IN THE PAST, FOR THE LAST FIVE OR SIX ICANN MEETINGS AND GAC MEETINGS, THE IDN WORKING GROUP HAS BEEN BRIEFING THE GOVERNMENTAL ADVISORY COMMITTEE ON THE TECHNICAL ASPECTS OF IDNS AND THE RELATED PUBLIC-POLICY ISSUES WITH THOSE TECHNICAL ASPECTS.

AT SAO PAULO, THE -- AT THE SAO PAULO MEETING, THE GAC ACKNOWLEDGED THE PROGRESS MADE BY THE ICANN'S PRESIDENT'S ADVISORY COMMITTEE ON IDNS AND ALSO THE LABORATORY TEST DESIGNS WHICH WERE POSTED ON THE 5TH OF DECEMBER.

IT IS UNDERSTOOD IN THE GOVERNMENTAL ADVISORY COMMITTEE THAT THE TECHNICAL ASPECTS HAVE TO COME FIRST, I MEAN, THEY HAVE TO BE -- THE DESIGNS HAVE TO BE FIRST PLACED AT A COMFORTABLE LEVEL.

AND TO THAT EXTENT, I THINK WE CAN EVEN SAY THAT THERE ARE NO UNREASONABLE EXPECTATIONS, AS RIGHTLY POINTED OUT BY JOHN KLENSIN.

AT THE SECOND LEVEL, THE GAC DEFINITELY FEELS THAT IT IS IMPORTANT THAT IDNS ARE DEPLOYED, AS THEY ARE A FACILITATOR FOR THE USE OF INTERNET IN RELATION TO NON-ASCII SCRIPT-BASED LANGUAGES.

AND HERE THERE IS CLARITY IN THE GOVERNMENTAL ADVISORY COMMITTEE THAT IDNS ARE NOT A MULTILINGUAL INTERNET, AND THEREFORE THEY ARE TWO DIFFERENT THINGS.

AND THE FACILITATION TO NON-ASCII-BASED SCRIPT LANGUAGE USERS IS WHAT IDNS ARE MEANT FOR.

THE GOVERNMENTAL ADVISORY COMMITTEE IS AWARE OF THE ISSUES THAT HAVE BEEN RAISED IN THE GNSO COUNCIL AS WELL AS IN THE CCNSO.

AND TOWARDS THAT, THERE IS A FEELING IN GOVERNMENTAL ADVISORY COMMITTEE THAT A GENERAL IDN POLICY SHOULD BE DEVELOPED IN CONSULTATION AND IN DISCUSSION WITH THE GNSO AND CCNSO CONSTITUENCIES FOR BRINGING IN MORE CLARITY ON THE IDN ISSUES TO ENSURE THAT THE REGISTRIES GIVE DUE CONSIDERATION TO KEY ELEMENTS OF IDN POLICIES.

IT ALSO ALLOWS GOVERNMENTS AND OTHER AUTHORITIES TO EVALUATE THE PROCESS FOR IDN DEPLOYMENT, TYPICALLY, THE LANGUAGE RULES, THE VALID CHARACTERS, CONTEXTUAL RULES, IDENTIFICATION OF VARIANTS, ALL THAT, AND IT ALSO STANDARDIZES THE IDN OVER THE EXTENSIVE -- EXTENSIBLE PROVISIONING PROTOCOL.

SO, BASICALLY, IT IS -- THE GAC WOULD BE ASSISTING ITS MEMBERS, THE MEMBER COUNTRIES, TO A GENERAL IDN POLICY PROFILE THAT WILL BE DEVELOPED IN CONSULTATION WITH THE GNSO AND CCNSO.

AS REGARDS ONE FINAL POINT, AND THAT IS THE DISPUTE RESOLUTION, IT IS FELT THAT THE CRITERIA THAT THE REGISTRANT'S DOMAIN NAME IS IDENTICAL OR CONFUSINGLY SIMILAR TO A NAME, TRADEMARK, OR SERVICE MARK IN WHICH THE COMPLAINANT HAS RIGHTS IS ONE ASPECT.

BUT IF WE ADD TWO MORE CRITERIA, ONE, THE REGISTRANT HAS NO RIGHTS OR LEGITIMATE INTERESTS IN RESPECT OF THE DOMAIN NAME, AND, TWO, THAT THE REGISTRANT'S DOMAIN NAME HAS BEEN REGISTERED OR IS BEING USED IN BAD FAITH.

IF THESE TWO ARE ADDED, A LOT MORE EFFECTIVE DISPUTE RESOLUTION CAN TAKE PLACE.

THAT'S ALL FOR -- ON BEHALF OF THE GOVERNMENT ADVISORY COMMITTEE.

OF COURSE, WE ARE LOOKING FORWARD TO THE -- TO ACTIVELY PARTICIPATE WITH THE RAM MOHAN COMMITTEE.

AND AS REGARDS THE CCNSO ISSUES RAISED BY MR. HIRO HOTTA, WE ARE IN TOUCH WITH THE CCNSO CONSTITUENCY TO ACT FURTHER ON HOW TO GO ABOUT IDENTIFYING CCTLD AND IDNS POLICY.

THANK YOU.

>>TINA DAM: THANK YOU, PANKAJ.

ANY QUESTIONS OR COMMENTS TO PANKAJ?

YEP.

>>BRUCE TONKIN: I GUESS THIS IS JUST A COMMENT, PANKAJ.

ONE OF THE THINGS THAT WE'VE BEEN LOOKING AT IN TERMS OF NEW GTLD POLICY IS LOOKING AT A STRING FILTERING PROCESS WHICH IS PRIOR TO THE USE OF THE STRING.

SO I WOULD IMAGINE YOUR COMMENTS THERE ABOUT BAD-FAITH USE WOULD HAVE TO APPLY AFTER THE STRING IS CREATED AND IT IS IN FACT USED.

HAVE YOU THOUGHT THAT THROUGH AT ALL?

BECAUSE I GUESS WE'RE LOOKING AT KIND OF TWO STAGES.

ONE STAGE IS WHERE THERE'S AN OBJECTION PROCESS AND A DISPUTE RESOLUTION PROCESS JUST ON THE STRING, NOT ON HOW THE STRING'S USED; AND THEN AT SOME FUTURE TIME, IF SOMEBODY WAS USING THE STRING IN BAD FAITH, THEN PRESUMABLY, THERE'S DISPUTE RESOLUTION AFTER THE FACT, WHICH IS CURRENTLY WHEN WE'RE INTRODUCING SECOND-LEVEL DOMAIN NAMES, THE DISPUTE RESOLUTION IS ESSENTIALLY AFTER THE FACT, AFTER THE NAME IS ALREADY CREATED.

>>PANKAJ AGRAWALA: YES, I AGREE WITH YOU ON THIS POINT THAT IN THE CASE OF THE TOP-LEVEL STRINGS, THERE MIGHT -- THIS MIGHT NOT WORK BECAUSE OF THE FACT THAT IF WE -- THIS BAD FAITH HAS TO BE PROVED, FOR THE ALLOCATION WOULD ALREADY HAVE TAKEN PLACE.

MY REFERENCE TO THIS WAS MORE FOR THE USERS IN THE DOMAIN NAME SPACE.

>>TINA DAM: GO AHEAD, CHUCK.

>>CHUCK GOMES: CHUCK GOMES FROM VERISIGN.

I DIDN'T UNDERSTAND YOUR POINT ABOUT REGISTRANT'S RIGHT OF OWNERSHIP.

COULD YOU CLARIFY THAT FOR ME.

>>PANKAJ AGRAWALA: DID -- WAS THIS USED FOR THE DISPUTE RESOLUTION OR WAS IT --

>>CHUCK GOMES: I WASN'T CLEAR.

THAT'S WHY I WAS ASKING.

IT WAS JUST BEFORE THE POINT THAT WERE JUST DISCUSSING IN RESPONSE TO BRUCE.

>>PANKAJ AGRAWALA: THIS WOULD BE PROBABLY -- I MEAN, THIS IS TALKING ABOUT THE DISPUTE RESOLUTION POLICY?

>>CHUCK GOMES: SO THAT'S WHAT YOU WERE TALKING ABOUT, A DISPUTE --

>>PANKAJ AGRAWALA: FOR REGISTRANTS,.

>>CHUCK GOMES: FOR REGISTRANTS?

AND YOU SAID SOMETHING TO THE EFFECT THAT THE REGISTRANT HAD NO RIGHT?

>>PANKAJ AGRAWALA: RIGHT.

WHAT I WAS TRYING TO SAY WAS THAT IN THE DISPUTE RESOLUTION, APART IN THE CONFUSINGLY SIMILAR, IF THE REGISTRANT HAS NO RIGHT AND THAT IS PROVED, THEN THE -- THE ARBITRATOR CAN GIVE THE JUDGMENT IN FAVOR OF THE COMPLAINANT.

>>CHUCK GOMES: OH, OKAY.

OKAY.

>>PANKAJ AGRAWALA: THAT'S FOR THE REGISTRANTS.

>>CHUCK GOMES: OKAY. AND IT'S IN A DISPUTE RESOLUTION CONTEXT.

>>PANKAJ AGRAWALA: THAT'S RIGHT. IN THE CONTEXT OF THE DISPUTE RESOLUTION.

>>CHUCK GOMES: THANK YOU.

>>TINA DAM: OKAY. I DON'T THINK I SEE ANY MORE COMMENTS.

ANYBODY?

AND IF NOT. THEN WE ARE ADJOURNED. THANK YOU VERY MUCH FOR THE PRESENTERS, PARTICIPANTS, EVERYBODY ON THE ONLINE CHAT FORUM.

BUSES ARE OUTSIDE READY TO TAKE YOU TO THE HOST RECEPTION, IF THAT'S WHAT YOU ARE PLANNING FOR DOING TONIGHT.

AND THANK YOU FOR TODAY.

(APPLAUSE.)