ugrás a tartalomhoz

ICANN opens up top-level domains

Török Gábor · 2011. Jún. 20. (H), 17.57
Jó pénzért tied lehet a .semmi
 ■
1

Lehúzás

janoszen · 2011. Jún. 21. (K), 07.09
Ebben egyébként az a hatalmas lehúzás, hogy ha mondjuk ketten pályáztok a .hotel végződésre, mindkettőtöknek be kell csengetni azt a néhány 10m Ft-ot, viszont aki elbukja, az is csak a pénz töredékrészét kapja vissza.
2

Poszt

Török Gábor · 2011. Jún. 21. (K), 08.51
Tök fasza lenne, ha leírnád erről a véleményed egy posztban. Engem érdekelne az is, hogy a szabadság-faktoron kívül praktikusan ennek mi értelme? És pont egy .hotel esetében hogy dől el, hogy most ezt ki kapja meg? És milyen időre?
3

Hűűűű

janoszen · 2011. Jún. 21. (K), 09.10
Szerintem, erre megpróbálom a főnökömet megfűzni, ő vizsgálta meg ezt a kérdéskört egy pár hónappal ezelőtt, úgyhogy sokkal jobban képben van.

Egyébként vicces lesz, ha valaki befoglalja a .dev TLD-t, lesz jó nagy kavarodás azon rendszerek körében, akiknél még nem jött rá a rendszergazda, hogy nem kifizetődő nem globálisan rekurzolható belső címeket használni. ;)
5

.dev miert okozna

Tyrael · 2011. Jún. 21. (K), 11.59
.dev miert okozna kavarodast?
gondolom aki eddig hasznalta, annak fel volt veve hostfile-ban/sajat dns-ben, ez viszony nyilvan felulcsapja a globalis erteket, szoval nem latom hol okozhatna problemat.

amugy ismerek egy ceget ahol a backoffice dns-ben barmilyen .dev vegzodesu domain felold egy belso halos cimre. :)

Tyrael
6

Panaszkodnak

janoszen · 2011. Jún. 21. (K), 13.05
Majd random alkalmazások, amik a netre akarnak kimenni, meglepődnek, hogy nem megy. Aztán fájhat a rendszergazdák feje, hogy állítják át az egész rendszert. :D
7

meg mindig nem latom, hogy

Tyrael · 2011. Jún. 21. (K), 13.44
meg mindig nem latom, hogy mire celzol. :)

ami szerintem valodi problema lesz, az a kulonbozo domain/host/email validator szolgaltatasok.
ezek egy resze (a butabbik) valami fix regexet hasznalt, ami szerint mondjuk a .nato vagy .museum nem valid tld, a masik resze valami lokalis tld listabol validal, amit eddig nem volt gond manualisan boviteni, ha felvettek evente 1 tld-t, viszont a mostani dontes pillanatok alatt elavulta tudna tenni.

Tyrael
8

Mégiscsak kifizetődőbb a

Joó Ádám · 2011. Jún. 21. (K), 16.22
Mégiscsak kifizetődőbb a specifikációkat követni, mint ún. gyakorlati megoldásokat készíteni, mi?
9

marmint milyen

Tyrael · 2011. Jún. 21. (K), 16.57
marmint milyen specifikaciot?
a helyes megoldas nyilvan az, ha feloldod a hostot, es ugy ellenorzod a domain letezeset, esetleg behellozol a mailszerverre megnezni, hogy van-e adott user (ez mar a spammerek miatt egyre kevesbe mukodik), viszont ez nem kicsit koltsegesebb eroforras szempontjabol mint egy regex.

Tyrael
10

Pontosan megvalósítani az

Joó Ádám · 2011. Jún. 22. (Sze), 15.45
Pontosan megvalósítani az RFC-t, és nem összedobni egy gyors regexet, mondván, hogy mindenki tudja, mit tartalmazhat egy tartománynév. Vö. hogy néz ki az átlagos regex az emailcímekre, és mennyivel komplexebb az RFC által megadott formátum.
11

ja, hat ha a valosag meg az

Tyrael · 2011. Jún. 22. (Sze), 17.35
ja, hat ha a valosag meg az RFC (5321,5322) kozott sem mindig teljes az osszhang.

szosszenet php-internalsrol, tavaly olvastam:
> Is this actually correct behavior? The top-level domain for the Vatican
> e.g. has MX records, so at least theoretically pope@va is a valid and
> routeable email address, no matter what RFC 5321 states.
>
> $ host -t MX va
> va mail is handled by 10 lists.vatican.va.
> va mail is handled by 20 paul.vatican.va.
> va mail is handled by 50 proxy2.urbe.it.
> va mail is handled by 90 john.vatican.va.


valasz

Yes, it is an interesting question, and if you look at the IETF
discussion(*) on it you will see that we can discuss it for months and
not come to a conclusion. Essentially the IETF failed to disallow it
early on, so we have ended up with some fringe TLDs with MX records. A
bunch of RFCs, not referring directly to email talk about single word
domains being local. If you go back in Internet history you can read
about the problems caused when the .cs tld was introduced and how it
conflicted with a bunch of email configurations at universities who had
user@cs go to the CS department. So, in order to attempt to rescue the
sinking ship, they have tried to patch this problem with that clause in
RFC 5321.

Personally I think they should allow a trailing . to indicate a tld. So
it would be pope##kukac##va. which would be distinct from a local machine named
"va" but the email RFCs do not allow that. I took a more pragmatic PHP
approach here. I think if people are validating email addresses they
want to know if it is likely to be a routeable address and will probably
want foo@bar to be rejected despite the fact that there are a handful of
addresses in the world that might potentially route that are of that
form. Of course if the isp that does the mail delivery has a "va"
machine in their local network chances are pope@va isn't going to leave
the network depending on how the MTA is configured. And since this
pragmatic approach actually lines up with the latest RFC on the matter
it makes sense to me.

(*) http://www.ietf.org/mail-archive/web/ietf/current/msg52148.html
Click thread-next (many many times) and you will see the discussion turn
to MX records on TLDs.


Tyrael
4

Magyarországon

vbence · 2011. Jún. 21. (K), 09.22
Magyarországon a domain-liberalizáció előtt volt olyan szabály, hogy nem szabad kizárólagosségot sugalló nevet bejegyezni. Talán ez volt a legértelmesebb rész a hazai szabályozásban... amíg el nem törölték. - Persze tudom, ez nem az amerikai módi. Small government, free market...