Bind och åäö?

[fhe]

Då kan du glömma alla tecken förutom a till z, 0 till 9 och "-".

 

Senast jag kollade rfc830 så fanns det faktiskt ingen specad begränsning till a-z 0-9 och -, de talar hela tiden om octets (8 bitar). Det som däremot begränsar är alla protokoll som är byggda ovanpå domännamn-systemet (mail t.ex) där det är specat till 7 bitar (eftersom de oftast är skrivna av amerikaner som har vanlig järnkoll

Alla andra lösningar är inte globala

Nu innebär förvisso även ett 8-bitars teckensystem precis som du säger en begränsning, jag tror emellertid inte polacker och serber bryr sig flasklock om ifall räksmörgås inte ser ut som räksmörgås.se på deras datorer. Jag tror inte ens de är intresserade att surfa till räksmörgås.se, vill man vara global väljer man ett globalt namn.

 

Det naturliga steget vore naturligtvis att låta de åtta bitarna användas för att koda utf-8 och fixa alla trasiga protokoll som inte har support för oktetter i headers och annat.

 

Varför bara låsa upp sig till HTTP med speciella förbehåll?

 

Tja, det är ingen direkt låsning, det handlar snarare om att använda befintlig infrastruktur där den fungerar. ACE innebär ju i praktiken att ALLA klienter (och de flesta servers om administratörer ska slippa skriva konfiguration ACE-kodat) måste göras om för att man ska kunna fortsätta att använda protokoll som borde ha uppdaterats till nåt vettigare (t.ex UTF-8) för länge sedan. ACE är ju inget annat än ytterligare en helt ny uppfinnarrunda av hjulet. Om man prompt vill hålla sig till 7-bitars tecken i botten för att rädda interoperabilititet med all gammal hårdvara som ännu inte klarar att hantera 8 bitar i taget aå kunde man ju åtminstone valt något av alla de system som redan är uppfunna.

 

Om du kör en egen DNS på ett eget intern nätverk kan du göra precis som du vill.

 

Jag vet redan hur det fungerar, hur IETF tycker att det ska fungera och har med undantag av föregående stycke i denna text inte antytt vad jag tycker om ACE som lösning på "problemet".

 

Varför jag skulle behöva en egen toppdomän förstår jag inte, både ACE, UTF8 och .nu-varianten fungerar utsökt även på de icke-tld:er jag har i mina dns:er om jag orkade pilla dit nåt dyligt. I dagsläget är det emellertid bara .nu-varianten som fungerar med mer än någon enstaka klient och/eller server och utan klienter och servrar är nätet rätt tråkigt.

 

Faktum är att .nu-systemet t.om funkar ovanpå ACE om man vill, det finns ingenting som hindrar att man låter dns-uppslag av www.räksmörgås.se (om det kommer sådana från en icke-ACE-stödjande 8-bitars klient) kasta tillbaka ett CNAME www.zq--rksmrgs-5wao1o.se istället för något annat. Vips så funkar både nya uppdaterade ACE-klienter och de klienter som redan tidigare klarade att hantera oktetter.

 

Kan vi nu återgå till att hjälpa Cariad (han är förvisso redan hjälpt) istället för att hitta på nya subtrådar som inte är speciellt on-topic?

 

 

Redigering: Om tonen lät hård i ovanstående text så var det oavsiktligt och inte meningen, jag försökte vara saklig och tillföra något. Sandpapprade bort de värsta kantigheterna :-)

[inlägget ändrat 2002-09-29 23:08:15 av fhe]

[Coldbringer]

 

"Senast jag kollade rfc830 så fanns det faktiskt ingen specad begränsning till a-z 0-9 och -, de talar hela tiden om octets (8 bitar)."

 

Den RFC:n överlevde inte. Den blev inte någon "standard" eller BCP. Det du far efter är nog rfc1034 och 35:

 

3.5. Preferred name syntax

 

< snip >

 

<let-dig-hyp> ::= <let-dig> | "-"

 

<let-dig> ::= <letter> | <digit>

 

<letter> ::= any one of the 52 alphabetic characters A through Z in

upper case and a through z in lower case

 

<digit> ::= any one of the ten digits 0 through 9

 

< snip >

 

"Det som däremot begränsar är alla protokoll som är byggda ovanpå domännamn-systemet (mail t.ex) där det är specat till 7 bitar (eftersom de oftast är skrivna av amerikaner som har vanlig järnkoll "

 

Även herr Altman rättade sin Sendmail efter reglerna ovan. Det är standard idag och det lär dröja innan man har uppgraderat alla servrar/klienter ;-)

 

"Nu innebär förvisso även ett 8-bitars teckensystem precis som du säger en begränsning, jag tror emellertid inte polacker och serber bryr sig flasklock om ifall räksmörgås inte ser ut som räksmörgås.se på deras datorer. Jag tror inte ens de är intresserade att surfa till räksmörgås.se, vill man vara global väljer man ett globalt namn.

 

Det naturliga steget vore naturligtvis att låta de åtta bitarna användas för att koda utf-8 och fixa alla trasiga protokoll som inte har support för oktetter i headers och annat."

 

Om man använder svenska tecken som vissa hemmahck gör så finns det ingen info om vilken teckenuppsättning som körs. Därför måste alla DNS användare i förväg veta vilka tecken som används. Att bara säga ISO-8859-1 räcker inte.

 

Och hur skall man göra med matchningsreglerna? T.ex är <LATIN CAPITAL LETTER A WITH A RING ABOVE> samma sak som <LATIN CAPITAL LETTER A> omedelbart följt av <COMBINING RING ABOVE>? Det_ser_ok ut för ögat fast något annat kan dölja sig bakom. Ett stort säkerhetsprobelm finns här.

 

"Tja, det är ingen direkt låsning, det handlar snarare om att använda befintlig infrastruktur där den fungerar. ACE innebär ju i praktiken att ALLA klienter (och de flesta servers om administratörer ska slippa skriva konfiguration ACE-kodat) måste göras om för att man ska kunna fortsätta att använda protokoll som borde ha uppdaterats till nåt vettigare (t.ex UTF-8) för länge sedan. ACE är ju inget annat än ytterligare en helt ny uppfinnarrunda av hjulet. Om man prompt vill hålla sig till 7-bitars tecken i botten för att rädda interoperabilititet med all gammal hårdvara som ännu inte klarar att hantera 8 bitar i taget aå kunde man ju åtminstone valt något av alla de system som redan är uppfunna."

 

Igen - UTF-8-kodad UNICODE löser inte alla teckenuppsättningsproblem. Vi vill ha en global lösning som inte lastar ned DNS öket ytterligare. Om man inser att alla dessa lösningar är temporära och lokala - fine. Men då skall företag inte sälja dem som globala.

 

"Jag vet redan hur det fungerar, hur IETF tycker att det ska fungera och har med undantag av föregående stycke i denna text inte antytt vad jag tycker om ACE som lösning på "problemet"."

 

Visst är det så. John Klensin var ett tag mycket uppgiven och sa rakt ut att det kanske inte finns någon lösning. Och sedan kom patentproblemet, men som sedan löstes. Inom IDN så finns det trots allt ett ljus i slutet av tunneln. Hoppas att det inte är ett tåg.

 

"Varför jag skulle behöva en egen toppdomän förstår jag inte, både ACE, UTF8 och .nu-varianten fungerar utsökt även på de icke-tld:er jag har i mina dns:er om jag orkade pilla dit nåt dyligt. I dagsläget är det emellertid bara .nu-varianten som fungerar med mer än någon enstaka klient och/eller server och utan klienter och servrar är nätet rätt tråkigt"

 

Bill Semichs NU-BIND hack är beställt utav Paul Mockapetris. Men den kräver att frågan ställs mot en .nu server och endast för HTTP. Jag vill ha en lösning som även funkar alla andra applikationer som vi använder idag.

 

"Faktum är att .nu-systemet t.om funkar ovanpå ACE om man vill, det finns ingenting som hindrar att man låter dns-uppslag av www.räksmörgås.se (om det kommer sådana från en icke-ACE-stödjande 8-bitars klient) kasta tillbaka ett CNAME www.zq--rksmrgs-5wao1o.se istället för något annat. Vips så funkar både nya uppdaterade ACE-klienter och de klienter som redan tidigare klarade att hantera oktetter."

 

Ta bort Semichs NU-BIND burk och se vad som händer.

 

"Kan vi nu återgå till att hjälpa Cariad (han är förvisso redan hjälpt) istället för att hitta på nya subtrådar som inte är speciellt on-topic?"

 

Visst. Men de berör trots allt det probem han har. Om han använder sin operatörs resolver eller han en egen cache-only DNS som skickar frågan vidare till sin operatörs DNS så är diskussionen av vikt. Just nu så vet jag ingen större operatör i Sverige som släpper igenom frågor med otillåtna tecken. Allra helst nu efter Buffer Owerflow problemet i BIND resolver libbarna.

 

"Redigering: Om tonen lät hård i ovanstående text så var det oavsiktligt och inte meningen, jag försökte vara saklig och tillföra något. Sandpapprade bort de värsta kantigheterna :-)"

 

Inge fara. Tycker du ar varit saklig hela tiden.

 

 

 

 

 

 

 

 

 

 

 

 

[fhe]

3.5. Preferred name syntax

"Preferred" betyder just "Preferred" och inget annat, tanken är att alla system, oavsett generation skulle klara av att använda domännamn istället för IP. Eftersom dagens lösningar (det finns fler än .nu) alla kräver att man har ett "a-z"-namn också så är det ju inget större problem.

 

Därför måste alla DNS användare i förväg veta vilka tecken som används. Att bara säga ISO-8859-1 räcker inte.

 

Det är ingen som har sagt "bara iso-8859-1", det jag sa var 8 bitar, det kan inkludera vilken iso-8859 som helst, koi8 eller tillåmed japansk kodning (de kodar föresten redan in sin japanska redan nu). Den enda nackdelen med det är att det inte blir interoperabilitet mellan användare i de olika sonerna, men om man vill ha ett domän-namn som funkar oavsett språkgrupp så väljer man inte ett svenskt ord, lika lite som man väljer att döpa sitt företag till något jättesvenskt namn om man tänker vara verksam utomlands. Det medför en massa andra problem.

 

Igen - UTF-8-kodad UNICODE löser inte alla teckenuppsättningsproblem

 

Du har så rätt, man kan säkert hitta problem oavsett lösning, frågan är hur många av problemen som är relevanta.

 

Ta bort Semichs NU-BIND burk och se vad som händer.

 

För länge sedan gick det bra att surfa till http://bäst.rock.just.nu för att komma till bandit (om man inte satt bakom en trasig proxy), jag är väldigt säker på att det inte var tack vare Semichs NU-Bind. Jag tror t.o.m det var innan .nu släppte på svenska namn.

I en subdomän skulle jag tillåmed kunna tänka mig ett par lösningar där det är helt ointressant att ens skicka åäö genom dns:en, ska resultatet till en webserver räcker det med ett vanligt wildcard och sen kan webservern hantera resten när den avgör vilken virtuell server som ska få requesten (baserat på host-headern).

 

Hursomhelst så tycker jag att .nu:s lösning är en ok tillsvidarelösning på problemet, det kommer att ta flera år innan det finns klienter som klarar en mer långsiktig lösning och ännu längre tid tills ALLA klienter klarar lösningen. Långt innan dess kommer charmen med TV-reklam som säger "surfa till öhmans.com, fast utan prickarna då" att ha försvunnit (exemplet är helt fabricerat, jag har kollat om det finns nån ohmans.com).