Dokumentnummer: 2007-R2 Senast sparat: 23 mars 2007 SE, Stiftelsen för Internetinfrastruktur 2007
1 Dokumentkontroll Dokument information & säkerhet Uppgjord av Faktaansvarig Dokumentansvarig Amel Amel Amel Säkerhetsklass Öppen Filnamn 2007-RX-IDN.doc Godkänd av Datum Namn Roll Revisioner Datum Version Namn Beskrivning 2007-03-13 PA1 Amel 2007-03-22 PA2 Amel Komplettering 2007-03-23 A Amel Slutversion Dokumentnummer: 2007-R2 Sida 2 av 17
2 Innehållsförteckning 1 Dokumentkontroll... 2 2 Innehållsförteckning... 3 3 Introduktion... 4 3.1 Förkortningar och ordförklaringar...4 3.2 Referenser...4 3.3 Typsnitt...5 3.4 Om.SE...5 4 Bakgrund till utökad teckenrepertoar i.se... 6 4.1 Steg 1 av IDN...6 4.2 Steg 2 av IDN...6 4.3 Steg 3 av IDN...6 5 Målsättning med IDN... 7 6 IDN inom.se... 8 6.1 Motiv för utökad teckenrepertoar...8 6.2 Sveriges officiella minoritetsspråk...8 6.3.SE:s ståndpunkt för utökning av IDN...9 7 Hantering av IDN-domännamn... 10 7.1 Unicode...10 7.2 Effekter av användning av Unicode...10 7.3 Risk för förväxlingsbarhet...10 7.4 Normalisering...11 7.5 Punycode...11 7.6 Skript...11 8 Ansvarsfördelning -.SE/Ombud/Slutkund... 12 8.1 Representation vid avisering m.m....12 8.2 Tillgängliga kodpunkter i.se...13 8.3 IDN-ombud...13 8.4.SE:s kundtjänst...13 8.5 Tvist om IDN-domännamn...13 8.6 Prissättning för IDN-domännamn...14 9 Förslag till hantering av.se:s övergång till utökad teckenrepertoar... 15 9.1 Startidpunkt...15 9.2 Tillvägagångssätt...15 10 Frågor att besvara i remissen... 17 Dokumentnummer: 2007-R2 Sida 3 av 17
3 Introduktion Dokumentet innehåller en beskrivning av förslagen och en handlingsplan för den fortsatta utvecklingen av hantering av IDN-domännamn för sådana specificerade delar av Unicodestandarden som.se anser bör rymmas inom en utökad teckenrepertoar under.se. 3.1 Förkortningar och ordförklaringar ACE DNS IDN IDNA LDH-tecken NS Unicode URI URL UTF ASCII Compatible Encoding Domain Name System Internationalized Domain Name Internationalizing Domain Names in Applications (ASCII letters, digits and hyphen) Name Server, Namnserver Internationell standard för teckenkodning med samma teckenallokeringar, teckennamn och kodningsformer (UTF-8, UTF- 16, UTF-32) som ISO/IEC 10646 Universal Resource Identifier Universal Resource Locator Unicode Transformation Format 3.2 Referenser [1] RFC 3454 - Preparation of Internationalized Strings ("stringprep") [2] RFC 3490 - Internationalizing Domain Names in Applications (IDNA) [3] RFC 3491 - Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) [4] RFC 3492 - Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) [5] RFC 4690 Review and recommendations for Internationalized Domain Names (IDNs) [6] ISO/IEC 10646 - Universal Multiple-Octet Coded Character Set [7] UTR # 36 Security Considerations in the Implementation of Unicode and Related Technology [8] Unicode Technical Reports, http://www.unicode.org/reports/. Information om status och utvecklingsprocess - tekniska rapporter. [9] Unicode Teckendatabas [UCD]. För en översikt över teckendatabasen och en förteckning över associerade filer. [10] Unicode Standard, Version 5.0 (5th Edition),The Unicode Consortium version 5.0. 2006. 0-321-48091-0 [11] Versioner av Unicodestandarden http://www.unicode.org/standard/versions/. Information om versioner med utdrag och referenser till Unicodestandarden, Unicodes teckendatabas och Unicode tekniska rapporter. [12] SIS 63 21 27 (SS 63 21 27 utg. 2 1984) [13] Verva (tidigare Statskontoret) tekniska norm nr 3 (3:2 från 1984; 3:3 från 1993). Dokumentnummer: 2007-R2 Sida 4 av 17
3.3 Typsnitt [14] Sveriges Officiella Minoritetsspråk, Svenska språknämnden, 2003 [15] Språk och skrift i Europa, Ingår i Språkrådets skriftserie, SNS Förlag, 2004 resp. 2006, ISBN 91-85355-83-6 I detta dokument används följande typsnitt: 3.4 Om.SE Liten fetstil Används för biblioteksstruktur, filnamn samt in- och utmatningar. STORA BOKSTÄVER Datornamn skrivs alltid med stora bokstäver. Stiftelsen för Internetinfrastruktur (.SE) ansvarar för Internets svenska toppdomän,.se. Kärnverksamheten är registrering av domännamn samt administration och teknisk drift av det nationella domännamnsregistret under.se..se är en oberoende allmännyttig organisation som verkar för en positiv utveckling av Internet i Sverige. Genom.SE:s Internetfond avsätter stiftelsen varje år medel till projekt som på olika sätt bidrar till Internets utveckling och användning. Se mer på www.iis.se Dokumentnummer: 2007-R2 Sida 5 av 17
4 Bakgrund till utökad teckenrepertoar i.se.se:s styrelse har tidigare beslutat att.se på sikt ska tillåta och möjliggöra registrering av domännamn för alla kodpunkter ur Unicode-standarden som kommer att finnas förtecknade som möjliga att användas i domännamn i.se..se har deklarerat avsikten och förberett möjligheten att inom.se-domänen erbjuda IDNdomännamn generellt för i stort sett alla delar av UNICODE-standarden som.seanvändare har behov av, med undantag för bl.a. de tecken som över huvud taget inte tillåts i domännamn och givet förutsättningarna i olika normativa dokument som utarbetas inom t.ex. IETF. Utökningen av teckenrepertoaren för IDN i.se sker stegvis. Steg 1 genomfördes 2003, Steg 2 är det som planeras genomföras under Q2 2007 och föremålet för denna remiss. Steg 3 är en möjlig framtida utökning. 4.1 Steg 1 av IDN Första steget av IDN i.se infördes i oktober 2003 då möjligheten att registrera domännamn med tecknen å, ä, ö, ü och é utöver a-z, 0-9 och bindestreck erbjöds. Bakgrunden till att valet föll på just dessa tecken var en konsultation med dåvarande Statskontoret som rekommenderade dessa tecken som i princip varit med i folkbokföringssystemet sedan det datoriserades. 4.2 Steg 2 av IDN I det andra steget i genomförandet av IDN vill.se erbjuda möjligheten att registrera domännamn på alla i Sverige enligt lag fastställda, officiella minoritetsspråk. I detta steg ska även de nordiska ländernas språk kunna hanteras, dvs. även danska, norska, färöiska och isländska..se planerar och förbereder införandet med målet att kunna ta emot registreringar under Q2 2007, enligt föreslagen tidplan med start den 30 maj 2007. 4.3 Steg 3 av IDN I ett tredje steg ska möjligheten övervägas att även tillåta registrering av domännamn på de språk som förekommer inom EU:s medlemsländer, samt de många andra språk som används av större och mindre grupper av invånare i Sverige. Detta tredje steg är ännu inte planlagt när det ska genomföras. Dokumentnummer: 2007-R2 Sida 6 av 17
5 Målsättning med IDN Målet med IDN är att kunna använda tecken på alla språk i de applikationer som använder domännamn som del av sin adressering, som t.ex. SMTP för e-post och HTTP för webb. Detta innebär inte att det därmed också måste gå att använda internationella tecken i DNSprotokollet, även om det teoretiskt skulle vara möjligt. Frågan om hur tecken ur Unicode-standarden utöver ASCII LDH-tecken ska kunna användas i domännamn har diskuterats under många år. Det har diskuterats utgående från såväl tekniska som säkerhetsaspekter och inte minst ur policysynpunkt. IDN har också kommit att bli föremål för en omfattande diskussion med kulturella hänsyn som grund. Tekniskt har möjligheten skapats genom att domännamn med nationella tecken kodas om med så kallad ACE-kodning (ASCII Compatible Encoding). Domännamnssystemet (DNS) hanterar fortfarande bara tecknen a-z, 0-9 och bindestreck men IDN-domännamnen kodas alltså om så att de passar in i systemet. Principen är att alla IDN-domännamn ges ett prefix för att signalera att det inte är ett klassiskt domännamn utan att det representerar en kodning av de nationella tecknen. Därefter kan domännamnet avkodas i till exempel webbläsare eller e-postprogram igen och visas med de nationella tecknen angivna i sin ursprungliga form. För närvarande fungerar IDN enbart för HTTP och i princip alla webbläsare. Arbete pågår med att utveckla stöd i SMTP, dvs. för e-post, men där finns ännu ingen färdig lösning. Dokumentnummer: 2007-R2 Sida 7 av 17
6 IDN inom.se.se anser det angeläget att Internetanvändare har en möjlighet att ange sin hemvist på nätet på det språk och med de tecken de själva använder..se vill inte heller se någon lokal svensk lösning och har aktivt deltagit i det internationella standardiseringsarbetet med syftet att kunna enas om en gemensamt accepterad standard för hantering av andra tecken i domännamn. Att använda olika lösningar i olika delar av världen kommer i värsta fall att orsaka att DNS faller sönder. Det kommer i sin tur att göra adresseringen på Internet ineffektiv då problem kommer att uppstå mellan t.ex.: Olika applikationer som körs på samma dator Olika operativsystem Olika typer av utrustning (dator, mobiltelefon och andra Internetanslutna typer av utrustning) För multinationella företag och organisationer skulle problemen vara uppenbara. 6.1 Motiv för utökad teckenrepertoar Innan juni 2003 var de enda tecken som tilläts i domännamnssystemet de 26 bokstäverna i det latinska alfabetet, a-z, de tio siffrorna, 0-9 och bindestreck (-). Under juni 2003 färdigställdes internationella protokollstandarder och procedurer som gjorde det möjligt att tillåta en mycket större mängd tecken. Dessa tecken hämtas ur ett system som används för i princip alla språk, specificerade i Unicode-standarden. En TLD-registry som erbjuder möjligheten att registrera IDN-domännamn kan välja att göra ett urval av de språk som ska göras tillgängliga och explicit förteckna de Unicodetabeller som ska erbjudas. När det gäller cctld:er skulle man kunna hävda att valet av språk är uppenbart och att reglerna därmed går att göra relativt enkla. Samtidigt har cctld:er på senare år öppnat möjligheten för betydligt fler aktörer att registrera domännamn under den egna toppdomänen, med hänvisning till att Internet är en global företeelse som inte tar hänsyn till nationella gränser. Inom Europa finns förbud mot handelshinder som i princip innebär att ett EUmedlemsland inte får ha begränsningar som drabbar ett annat EU-medlemsland och som motverkar den fria handeln på en öppen marknad. Utöver de officiella språken inom EU finns ett antal minoritetsspråk som också bör beaktas. I Sverige finns exempelvis lagstiftning som slår fast vilka minoritetsspråk som är officiella och som reglerar den absoluta rätten att använda vissa språk inom vissa områden i kontakt med förvaltning och domstolar. 6.2 Sveriges officiella minoritetsspråk Regeringen överlämnade i juni 1999 en proposition till riksdagen om Nationella minoriteter i Sverige (prop. 1998/99:143). Förslagen innebar att Sveriges nationella minoriteter erkänns och att minoriteternas språk ges det stöd som behövs för att de ska hållas levande. De nationella minoriteter som regeringen föreslog ska erkännas är samer, sverigefinnar, tornedalingar, romer och judar. Minoritetsspråken är samiska, finska, meänkieli (tornedalsfinska), romani och jiddisch. Dokumentnummer: 2007-R2 Sida 8 av 17
Lagen trädde i kraft den 1 april 2000. Frågan hanterades inom Justitiedepartementets enhet för integration och mångfald. Den absoluta rätten att använda vissa språk inom vissa områden i kontakt med förvaltning och domstolar har alltså slagits fast. I Sverige har vi olika samiska dialekter; nordsamiska, sydsamiska och lulesamiska. 6.3.SE:s ståndpunkt för utökning av IDN.SE ser det som en viktig utveckling att kunna erbjuda svenska språkliga minoriteter möjligheten att registrera domännamn på sitt eget språk. Teckenuppsättningar för svenska minoritetsspråk ingår i version 3.2 av Unicode-standarden. Med den teckenrepertoar som sedan 2003 erbjuds under.se ryms redan förutom svenska också finska och meänkieli. Jiddisch är ett väldefinierat språk som förhållandevis enkelt kan inordnas i teckenrepertoaren. När de gäller de samiska språken finns det källor att vända sig till för att få uppgift om vilka tecken som krävs. Den svåraste delen att definiera är romani shib..se har beslutat att använda ett minimiset, vilket är att använda den teckenrepertoar som används i litteraturen på romani och som Skolverket låtit publicera. Utöver detta ska även diakritiska tecken i de nordiska ländernas språk kunna hanteras. Den utökade repertoaren för IDN Steg 2 innehåller därmed närmare 200 tecken. Först och främst rör det sig om cirka 150 latinska tecken. Dessa ger stöd för samtliga språk som använder sig av det latinska alfabetet, inklusive de skandinaviska språken och de svenska minoritetsspråken, med undantag för jiddisch som kräver ytterligare omkring 30 tecken. Färöiska kräver också komplettering med ytterligare några tecken. Den föreslagna teckenrepertoaren finns i bilaga 1, IDN Teckentabell för.se. Tabellen innehåller den teckenrepertoar som krävs för att representera de officiella minoritetsspråken i Sverige, i alla former som dessa används inom landet. Den innehåller dessutom den teckenrepertoar som för närvarande stöds av registryerna för.dk,.fi,.is,.no, and.se, samt den färöiska teckenrepertoar som listas i registreringsreglerna för.fo (men som ännu inte är tillgänglig för aktiv registrering). Uppgiften i tabellen om språk är endast ett sätt att generellt ange var ett specifikt tecken kan förekomma, många indikerar fler än ett specifikt språk. Den teckenrepertoar som anges av de andra cctld:erna kan själva ha stöd för fler former av respektive språk. De olika tecknen i tabellen är namngivna helt i överensstämmelse med den terminologi som används i Unicode-standarden..SE kommer även att publicera en tabell med svenska trivialnamn. Hänsyn har även tagits till de särskilda villkor som rör utvecklingen av teckenrepertoaren för jiddisch där exempelvis vissa tecken enbart får förekomma i kombination med något specifikt annat tecken. Dokumentnummer: 2007-R2 Sida 9 av 17
7 Hantering av IDN-domännamn Varje registrerat IDN-domännamn måste genomgå ett antal steg för att konverteras från ett namn representerat på något språk till en i DNS accepterad ASCII-sträng. Detta sker med stöd av ett antal standarder, och en definierad process. 7.1 Unicode Som grund för IDN används teckentabellerna som finns återgivna i Unicode version 3.2. Hantering av Unicode krävs i vissa modernare standarder som XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, WML, etc., och är det officiella sättet att implementera ISO/IEC 10646. I Unicode tilldelas varje existerande teckenglyf från världens alla skriftsystem ett heltal eller en s.k. kodpunkt. Varje kodpunkt betecknas som U+hexadecimalsiffra, exempelvis representeras α (grekiska lilla alfa) som U+03B1. Dessa kodpunkter representeras i sin tur av multiplar av oktetter, s.k. teckenkoder, vilka varierar beroende på UTF-metod. Även matematiska symboler och några få skriftsystem som numera är utdöda finns representerade. Unicode har plats för över en miljon tecken - varav drygt 70 000 tecken redan är tilldelade - och kan ersätta några hundra olika äldre former av teckenkodningssystem. I Unicode-standarden finns tre olika typer av tecken; tecken som är Assigned i Unicode och som får användas i domännamn (klass1), en andra klass tecken som också är Assigned men som ändå inte får användas i domännamn utan att först översättas till klass 1, och slutligen den tredje klassen som inte är Assigned men som kan komma att bli det i framtiden. Vissa tecken bör inte användas som del av domännamn, men det är en av flera delmängder, och lämnas åt sidan i den här diskussionen. I zonfilen för DNS är det den ASCII-kodade versionen som lagras. Det innebär att processen för hanteringen av IDN-namn innefattar momenten att ta emot en Unicodesträng från en kund, översätta eller normalisera, ASCII-koda och lägga in i systemet. Kunden ska ha så lite problem som möjligt, och vara befriad från att behöva veta dels vilka tecken som går att skicka in i processen. 7.2 Effekter av användning av Unicode På många sätt skulle användningen av enbart Unicode-baserade programvaror rent teoretiskt kunna bli mer robust och säker. När system använder en blandning av flera olika teckenuppsättningar för att representera tecken finns det alltid en risk för att någon utnyttjar skillnaderna mellan olika uppsättningar eller det sätt på vilket program konverterar eller översätter mellan dem. Eftersom Unicode innehåller ett så stort antal tecken kan felaktig användning dock även här exponera program eller system för möjliga attacker. Överväganden kring säkerhet måste därför finnas med i utvecklingen av system som ska hantera Unicode. 7.3 Risk för förväxlingsbarhet I Unicode Teknisk rapport # 36 [7] beskrivs överväganden om säkerhet som är viktiga att vara medveten om för den som arbetar med Unicode. Dokumentet är under kontinuerlig förbättring och kommer att utvecklas över tiden. Tillägg görs när det anses nödvändigt. Det är viktigt att alla som hanterar domäner inom.se är uppdaterade kring säkerhetsaspekterna på Unicode och domännamn. Dokumentnummer: 2007-R2 Sida 10 av 17
I den refererade versionen diskuteras två områden: kanonisk representation och visuell spoofing. Spoofing innebär i det här fallet en avsiktlig felstavning av ett domän- eller användarnamn för att lura in omedvetna användare i interaktion med förfalskade webbsidor som om de vore de riktiga. Spoofing kan vara mycket effektivt, t.ex. går det att lura användare genom att använda siffran 1 i stället för bokstaven l. Unicodestandarden innehåller många tecken vars glyfer antingen av historiska skäl eller av en ren slump liknar varandra. Problemet är inte unikt för Unicode. Många av dagens teckenuppsättningar, inklusive ISO/IEC 8859-1, innehåller förväxlingsbara och medför i sig samma risker när det gäller spoofing. Skillnaden är bara att essa element i allmänhet är färre än i den totala Unicodemängden. Utförligare resonemang kring dessa frågor finns på http://www.unicode.org/faq/security.html#1 Frågan om förväxlingsbarhet är det främsta skälet till att omkodningen av internationaliserade domännamn bör ske så nära källan (dvs. den som vill registrera ett namn) som möjligt. 7.4 Normalisering I normaliseringsprocessen (nameprep) reduceras skillnader i den teckenmängd som ska representeras. Om någon kommer och vill registrera ett domännamn som består av en blandning av versaler, gemener och tecken som inte tillåts i domännamn så reduceras dessa skillnader. Det kan för övrigt nämnas att protokollsviten i vilken nameprep ingår är föremål för revision i syfte att kunna erbjuda en snabbare anpassning till nyare versioner av Unicode. 7.5 Punycode Punycode är en metod för att uttrycka strängar av Unicode med bara tecknen a-z, 0-9 samt bindestreck. Strängen "räksmörgås" blir med Punycode "rksmrgs-5wao1o". Punycode utvecklades för att möjliggöra IDN. I ett IDN-namn markeras en sträng kodad med Punycode-metoden med prefixet "xn--", "räksmörgås.se" blir därmed "xn--rksmrgs-5wao1o.se", men prefixet utgör i sig inte en del av Punycode. Det är inte meningen att den punykodade varianten av en domän ska vara synlig för alla användare, utan program som kan tolka och förstår Punycodevarianten ska avkoda strängen och visa den som vanlig text med korrekt representation. 7.6 Skript Skript är definitionen av den uppsättning grafiska tecken som används i ett specifikt språkligt sammanhang. Ett skript kan användas för flera språk, t.ex. Latin för engelska, svenska m.fl. eller Kyrilliska för ryska, bulgariska m.fl. Ett mindre antal språk använder flera olika skript i sitt skrivsystem som t.ex. japanska som använder fyra helt olika teckenuppsättningar. Dokumentnummer: 2007-R2 Sida 11 av 17
8 Ansvarsfördelning -.SE/Ombud/Slutkund Frågan om en uppdelning i ansvarsfördelningen mellan de olika aktörerna, t.ex..se som registry, till ombud (registrar) och slutkund (registrant) blir särskilt tydlig när nya tjänster utvecklas. I IDN-fallet väljer exempelvis slutkunden vad som ska registreras, och det är viktigt att det verkligen är slutkunden som bestämmer..se och ombudet ska påverka så lite som möjligt när det gäller valet av vad som registreras. Processen kan i korthet beskrivas enligt följande: 1. Slutkunden ber ombudet registrera någon godtycklig teckensträng. 2. Ombudet granskar teckensträngen så att strängen enbart innehåller tecken tillåtna i.se och att den inte innehåller en blandning av tecken ur olika skript. (LATIN är exempel på ett skript). 3. Ombudet genomför en ACE-kodning och domännamnet konverteras till en teckensträng som inleds med xn- - som är det som faktiskt registreras i DNS-databasen. 4. Ombudet skickar in registreringen till.se som i sin tur kommer att göra en kontrollkonvertering innan registreringen genomförs (mostvarande 2. ovan). Principen är alltså att prefixet xn-- visar att det handlar om ett IDN-domännamn följt av de tecken som inte berörs och på slutet en kodning för de nya tecknen samt en markör om var i namnet de hör hemma. Kodningen och tekniken är inget som slutkunden behöver tänka på utan det hanteras av ombud och.se. För att det inte ska uppstå några tveksamheter i vad som kodas, och för att man inte ska behöva kunna återge alla upptänkliga tecken så behöver ombuden använda eller tillhandahålla ett verktyg som - givet att man skriver in ACE-koden - t.ex. kan generera en bild av representationen i något standardiserat format. På så sätt kan man filtrera bort eventuella fel redan i startskedet. ACE-koden är den normativa, och den som.se ansvarar för att lägga in i.se-zonen..se genomför en kontroll av ACE-koden och överensstämmelsen med det som skickas in av ombudet. Det är i mångt och mycket en administrations- och informationsfråga att presentera detta på ett sätt som kunden förstår. Det är också viktigt att ansvaret för tolkningen ligger närmast kunden och inte hamnar på registryfunktionen. 8.1 Representation vid avisering m.m. Hantering av ett domännamn i.se-zonen innebär bl.a. hantering av avisering från.se till domännamnsinnehavare eller dennes billingkontakt. I DNS-databasen publiceras också information om domänen, och publiceringen hanteras i DNS-applikationen, dvs. i namnserversystemet för den som hanterar DNS för den domän som är registrerad. Det går alltså inte att dölja själva ACE-kodningen för den som innehar domänen. Trots att det inte är användarvänligt så är det därför ACE-kodningen av domännamnet som är minsta gemensamma nämnare och som måste presenteras i kommunikation mellan slutkund, ombud och.se eftersom det är vad som finns i DNS. Det ACE-kodade namnet ska därför alltid finnas med på årsavin, vilket är det som slutkunden och dennes billingkontakt måste känna till, och som ska lagras i den lokala Dokumentnummer: 2007-R2 Sida 12 av 17
namndatabasen. För de fall IDN-domännamnet innehåller tecken som inte kan hanteras vid aviseringen kommer en länk till en konverteringsfunktion hos.se att anges på avin i stället för IDN-domännamnet. Det är emellertid önskvärt att också IDN-domännamnet visas på årsavin då det är möjligt. 8.2 Tillgängliga kodpunkter i.se För att undvika oönskade konsekvenser av ett införande av full Unicode i.se har vi gjort en utförlig inventering av olika bieffekter, och kommit till en som vi anser rimlig bedömning av vilka tecken som bör stödjas i.se och i vilken takt de bör införas. Ett internationaliserat domän namn måste alltså omkodas till ASCII-tecken för att kunna registreras under toppdomänen.se. Ett till ASCII-tecken omkodat IDN-domännamn utgör ett s.k. ACE-kodat domännamn..se publicerar en lista över vilka kodpunkter ur respektive skript som accepteras som underlag för registrering av IDN-domännamn i.se. Det kommer inte att vara tillåtet att blanda tecken från olika skript i samma namndel, dvs. om någon vill registrera ett namn bestående av jiddisch så hämtas kodpunkterna i sin helhet ur Unicode-tabellen och det skript som benämns HEBREW och som innefattar det relevanta alfabetet. Det kommer alltså inte att gå att blanda kodpunkter från olika skript (utom möjligen i några väldigt specifika undantagsfall som i så fall definieras i den av.se publicerade listan över tillåtna tecken och som då även kontrolleras i.se:s registreringssystem). Listan över tillåtna tecken kommer löpande att revideras. Blandningsförbudet mellan de två skript som nu föreslås stödjas uttalas enbart av administrativa skäl. Det finns en spärr mot sådan blandning direkt i IDN-protokollet (observera att eventuella kommande utvidgningar till Kyrilliska och Grekiska kommer att fordra lokala tekniska åtgärder för att förhindra förväxlingar). 8.3 IDN-ombud Med hänsyn till den komplexitet och det ansvar som kommer att ligga på de ombud som vill utföra registreringar av IDN-domännamn ställer det särskilda krav på.se:s ombud i detta avseende. Exempelvis måste ett ombud kunna validera Punykod-varianten av IDNdomännamnet för att se till att detta står i överensstämmelse med vad slutkunden faktiskt vill registrera och dessutom presentera det för kunden på ett otvetydigt sätt. Det är frivilligt för.se:s ombud att tillhandahålla IDN-registreringar. För att.se:s kunder ska veta vilka ombud som tillhandahåller IDN behöver dock.se få in uppgifter från ombuden om detta. 8.4.SE:s kundtjänst.se:s kundtjänst kommer även i fortsättningen enbart lämna information på svenska och engelska..se kommer att tillhandahålla en IDN-konverterare som hanterar just den specifika teckenrepertoar som.se erbjuder. 8.5 Tvist om IDN-domännamn Ett IDN-domännamn skiljer sig i detta avseende inte från andra domännamn. Den som anser sig ha en namnrättighet och kan styrka detta kan även ansöka om ATF hos.se. Dokumentnummer: 2007-R2 Sida 13 av 17
Ett IDN-domännamn kan dessutom antingen medvetet eller av en slump komma att få en utformning som motsvarar något känt varumärke eller annan rättighet. ATF-förfarandet ska kunna hantera även sådana situationer. 8.6 Prissättning för IDN-domännamn IDN-domännamn skiljer sig inte hanteringsmässigt från vilket annat domännamn som helst och därmed föreslås även priset vara detsamma. Dokumentnummer: 2007-R2 Sida 14 av 17
9 Förslag till hantering av.se:s övergång till utökad teckenrepertoar Beslut har fattats av.se:s ledning om att föreslå en kontrollerad övergång enligt följande principer. 9.1 Startidpunkt Möjligheten att ställa sig i kö för registrering av IDN-domännamn med den utökade teckenrepertoaren kommer att öppnas onsdagen den 30 maj. Själva registreringen kommer att ske efter 14 dagar, dvs. onsdagen den 13 juni. Endast en ansökan per domännamn och organisations- eller personnummer kommer att tillåtas. En 14 dagar lång förregistreringsperiod genomförs enligt nedan beskrivna tillvägagångssätt. Inga domäner kommer att registreras på riktigt, dvs. de kommer inte att kunna pekas ut, pekas om, överlåtas eller avregistreras förrän efter de 14 kalenderdagarna. 9.2 Tillvägagångssätt Inför registreringen kommer.se att skapa två olika köer för IDN2-domännamn. Dessa två köer kommer att benämnas "trademarks" respektive "public". Trademarks-kön är till för dem som anser sig kunna styrka att de har en namnrätt till de domännamn de vill ha. Den andra kön, public-kön är för allmänheten utan särskild namnrätt. 9.2.1 TRADEMARKS 9.2.2 PUBLIC Trademarks-kön öppnar onsdagen den 30 maj och fylls på med registreringar under en period om sju kalenderdagar. Det har ingen betydelse för turordningen när under perioden ansökan skickas in. Under perioden publiceras domänerna i kön för trademarks löpande på.se:s webbplats. Efter dessa sju dagar kommer det under nästkommande sju kalenderdagar för de domännamn där det finns fler som anser sig ha rätt till samma namn att finnas en möjlighet att för.se förete underlag som ger stöd för rätt till namnet. Om sådana handlingar lämnas till.se med avsikten att styrka rätt till namnet från flera sökande görs domännamnen oåtkomliga för registrering till dess att ett avgörande nås om vem som har bättre rätt till namnet. Det avgörandet kommer att fällas av inom området kunniga jurister. När perioden är slut registreras de domännamn i Trademarks-kön som ingen har invänt mot (dvs. som inte blivit föremål för prövning av namnrätt) i slumpvis ordning för alla domäner i kön. Public-kön öppnar onsdagen den 30 maj och fylls på med registreringar under en period om 14 dagar. Det har ingen betydelse för turordningen när under perioden ansökan skickas in. Namnen i Public-kön registreras först efter det att Trademarks-kön har bearbetats. Om det finns fler ansökningar för samma domännamn görs en slumpmässig fördelning av turordning. Dokumentnummer: 2007-R2 Sida 15 av 17
9.2.3 PRAKTISKA DETALJER För att lösa skillnaden mellan nya IDN-registreringar med den utökade teckenrepertoaren och den vanliga registreringen tar.se också fram ett nytt formulär vi kallar IDN3.0. Det gör att den vanliga mailprocessor-kön inte behöver ta hand om dessa formulär, medan förtursköerna endast tar hand om IDN3.0-formulären. För att ett registreringsformulär ska kunna läggas till kön krävs det att e-postformuläret valideras korrekt, att ombudet är aktivt, och att kombinationen av domännamn och organisationsnummer/personnummer är unikt för den kön. För de fall där det blir fel så returneras registreringen till ombudet med en beskrivning av felet, och ansökan lagras inte i kön. Under den tid som köerna processas för registrering "på riktigt" kommer den normala registreringen av domännamn att vara tillfälligt avstängd. Det kommer dock att vara möjligt att skicka in ansökningar som vanligt, och dessa kommer att läggas i kö och registreras så fort IDN-registrering är avslutad. Skulle ombudet under tiden fram till registrering bli inaktivt kommer den aktuella domänen inte att registreras. 9.2.4 REGISTRERINGSAVGIFT För varje förregistrering har.se för avsikt att ta ut en avgift på 50 kr exkl moms. Skälet till detta är att minska risken för massregistrering av vissa särskilt attraktiva domännamn i spekulationssyfte. Dokumentnummer: 2007-R2 Sida 16 av 17
10 Frågor att besvara i remissen Vi är tacksamma för alla synpunkter och kommentarer till det som beskrivs i dokumentet, och vi vill gärna få belyst följande: Fråga 1: Ser du några hinder för ett införande av en utökad teckenrepertoar för.se enligt förslaget? Fråga 2: Anser du att den föreslagna utökningen av IDN är rimlig? Om inte, anser du att: a).se enbart ska införa stöd för de officiella minoritetsspråken i Sverige? b).se enbart ska införa stöd för minoritetsspråk samt något av eller både danska och norska? c).se enbart ska införa stöd för minoritetsspråk samt något av eller både isländska och färöiska? Fråga 3: Anser du att den föreslagna teckentabellen är korrekt? Fråga 4: Anser du att tidplanen är rimlig? Fråga 5: Har du några synpunkter på det föreslagna tillvägagångssättet? Fråga 6: Ser du några klara för- respektive nackdelar med en utökning av teckenmängden? Fråga 7: Har du några synpunkter på det föreslagna tillvägagångssättet? Ytterligare frågor att besvaras enbart av.se-ombud: Fråga 8: Erbjuder ni f.n. registrering av IDN-domännamn? Fråga 9: Anser du att det även i fortsättningen ska vara frivilligt för ombud att erbjuda registrering av IDN-domännamn? Dokumentnummer: 2007-R2 Sida 17 av 17