DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   Web aplikacije, web servisi i software (http://www.devprotalk.com/forumdisplay.php?f=30)
-   -   .RS - Redovan sex se nastavlja, ovaj put sa developerske strane (http://www.devprotalk.com/showthread.php?t=7586)

zira 10. 06. 2009. 23:21

.RS - Redovan sex se nastavlja, ovaj put sa developerske strane
 
Scenario vjerujem da je/bice cest ukoliko u aplikacijama imate podatak o email adresi korisnika. Nestankom .yu domena, u bazama je ostao veliki broj email adresa (jos gore ako se za login koristi email/password kombinacija) koje uglavnom vise ne funkcionisu.

Sad recimo, imate N naloga, ako imate domaci sajt 10% ili 20% od njih su sa .yu domenom kao email adresom. Ta adresa vise nije aktivna. Ako korisnik ima login sa .yu emailom, primjecujem da pri logovanju pocinju da unose .rs umjesto .yu, jer pretpostavljaju da je ta promjena bila globalna, i ta je to sve promijenjeno "automatski" :)

Varijanta koja mi pada na pamet kao najbezbolnija i ujedno najmanje elegantna i efikasna je pozvati te korisnike da promijene adresu. Jedino preko sajta, jer im ne znate novi/pravi email (govorim u automatici), jer nisu svi domeni .yu preslikani u .rs ekvivalent.

Sta raditi sa takvim nalozima? Jako losa stvar...

Peca 11. 06. 2009. 00:41

30-tog septembra odraditi:
update USERS_TABELA set EMAIL = replace (EMAIL, '.co.yu', '.rs');

nixa 11. 06. 2009. 00:43

a sta ako sajt nije pazario .rs , vec je samo kupio .co.rs ?

Peca 11. 06. 2009. 00:47

nista...
ionako bi mu nalog bio zarobljen sa co.yu

drugo, takvih slucajeva je bas malo.

naravno, ovo sto navedoh je samo poslednji korak.
pre ovoga lepo pozoves ljude da promene email, ko sto Zira rece.

misk0 11. 06. 2009. 12:28

Zavisi koliko cijenis svoje korisnike :)
Ako ih cijenis, radices update za svaki domen manuelno. Znaci provjeris koji je domen korisnik koristio prije i sta je bilo sa tim domenom sad i radis isti taj replace.
Naravno sve zavisi koliko vremena imas, koliko korisnika imas, koliko domena RS korisnici koriste i tako dalje. :)

zira 11. 06. 2009. 12:39

Pade mi na pamet nesto sto je smarkovic spominjao, da oni u RNIDS-u imaju podatke koje su proslijedili Guglu u cilju azuriranja podataka o .yu domenima. Mozda bi to moglo da se iskoristi.

zira 11. 06. 2009. 12:41

E da, Peco, takva automatika ne dolazi u obzir, u pitanju su vazni ($) nalozi, vise bi stete napravila nego koristi. :)

Peca 11. 06. 2009. 13:16

Citat:

Originalno napisao zira (Napišite 70530)
E da, Peco, takva automatika ne dolazi u obzir, u pitanju su vazni ($) nalozi, vise bi stete napravila nego koristi. :)

uz svo duzno postovanje, bojim se da nisi razumeo moju ideju :)
prvo, pozovi ljude da promene email.
iskoristi sve moguce nacine koji ti padnu na pamet.

na samom kraju - 30. septembra - nista ti vise nece preostati nego da izvrsis onaj moj query.

1. nista ne gubis, jer ce preostali co.yu emailovi ionako prestati da rade
2. bar si ih prebacio na .rs
3. verujem da je 99% domena uzelo .rs

svi provajderi su uzeli .rs
to ti je vec 95% emaila.
svaka iole pametna firma je uzela .rs.

dakle, gubitak si sveo na 1%
ti koji nisu uzeli .rs ili uopste nisu ni uzeli nacionalni domen [ni co.rs], ili su tamo neka firma za prodaju vodokotlica.

mislim, sta ti je alternativa?
da ih ostavis na co.yu? :)

eventualno da iz baze izvuces spisak co.yu domena, pa napravis skriptu koja bi probala da resolve-uje .rs i .co.rs domene, pa onda da upise u bazu dostupni domen.

p.s. imaj na umu i .org.yu, .edu.yu, .gov.yu, .ac.yu

zira 11. 06. 2009. 16:16

Da, da, nego stos je sto ako imas login sa email/password kombinacijom (kao Facebook npr), time im automatski ubijas login :) A vaznije mi je da se mogu ulogovati nego da im mogu poslati mail.

kodi 11. 06. 2009. 16:37

btw, juche je FB izbacio poruku da ce uskoro moci da se izabere username za login umesto email-a :)

zapita se chovek da li je pametnije od pochetka furati username ili email ili je najbolja varijanta kao sto sam video na par sajtova da mozes da se ulogujes i sa username i sa email?

mogla bi neka rasprava o tome? eventualno split..

ljtruba 11. 06. 2009. 16:39

Ja sam exportovao mailing listu, sa find and replace zamenio eunet, sezam i poznate isp-ove, a ostalo isao peske. Proveravao koji je novi domen i onda radio zamenu.

za 2000 mailova i nije bilo tako strasno

Peca 11. 06. 2009. 16:56

Citat:

Originalno napisao zira (Napišite 70542)
Da, da, nego stos je sto ako imas login sa email/password kombinacijom (kao Facebook npr), time im automatski ubijas login :) A vaznije mi je da se mogu ulogovati nego da im mogu poslati mail.

sacuvaj stari email u zasebno polje old_email i omoguci login i preko tih starih emailova :)

bluesman 11. 06. 2009. 17:10

Kod email adrese je dobro to sto je automatski unique (osim ako vec nisi registrovan ili si stavio pogresan email). Kada pokusavas da se registrujes sa username, bar meni se cesto desi da mi prijavi kako "username already exists" a nemam pojma da li sam se ja to nekada davno registrovao pa zaboravio na to (i da li da pokusavam "reset password") ili je to neki tudji account.

Takodje, kada je recimo forum u pitanju, i neko vidi neki nick "pera12345" moze da pokusava da se loguje na njegov account, zna mu username, samo da jos pogodi password. A posto znamo da ljudi cesto koriste passworde koji se lako pogadjaju - nekom upornom ne bi bilo tesko da se uloguje umesto "pera12345".

Ali, ako se pera12345 loguje sa email-om, onda taj "uporni" mora ne samo da pogodi password nego da zna i njegov tacan email, sto je teze, narocito ako se ne poznaju.

Ja sam za login preko email-a, a ako hocete prebacicemo tu pricu u novu temu.

japan 11. 06. 2009. 17:32

Citat:

Originalno napisao kodi (Napišite 70543)
juche je FB izbacio poruku da ce uskoro moci da se izabere username za login umesto email-a :)

čini mi se da nigde ne spominju login, nego samo username u URL-u, umesto id-a...

http://blog.facebook.com/blog.php?post=90316352130

smarkovic 11. 06. 2009. 19:51

@zira
RNIDS je poslao Google samo DNS zone za aktivne .yu i .rs domene, a Google je onda radio "svoju magiju" sa tim podacima, tako da taj slučaj nije primenljiv na ovu situaciju.

Što se tiče email adresa i tranzicije, moram da priznam da sam i ja u velikom problemu sa tim (zbog velike Internodium liste i još nekoliko mailing lista koje održavam), ali čini mi se da su jedine mogućnosti:

1. pozvati korisnike da sami promene svoje adrese
2. promeniti sve postojeće .yu adresu u .rs sa search&replace
3. ako poruke krenu da se vraćaju posle prethodne akcije, proveriti ručno (whois, web sajt) da li je korisnik možda prešao sa .co.yu direktno na .rs domen

Pozdrav,
Sloba

Peca 11. 06. 2009. 19:58

jel mogu da pitam ovde - ko je odredio rok da se .yu ugasi ovako rano?
kazem rano jer negde procitah da je SSSR-ov TLD bio aktivan vise od jedne decenije [a mozda je i jos aktivan?]
i ima li ikakvih sansi da se taj rok prolongira?

Markok 11. 06. 2009. 21:31

@Peca
Naravno da jos radi, imaju 85000 domena.
Evo ih tvoji imenjaci http://www.vesti.su/

torbica 12. 06. 2009. 01:38

Ja kad vidim da se nekome bouncuje mail, pozovem ga :)

ps. Mozda poslati svima mail da dok jos mogu, da ga zamene?

ps. .yu ce da radi barem do 2010...

Peca 12. 06. 2009. 01:45

otkud taj info?
[tnx God]

torbica 12. 06. 2009. 02:24

Citat:

Originalno napisao Peca (Napišite 70580)
otkud taj info?
[tnx God]

iz pouzdanih izvora :)

MorenoArdohain 12. 06. 2009. 02:33

To mi nije jasno, na samom sajtu RNIDS pise da ce .YU domeni vaziti do 30. septembra 2009?

torbica 12. 06. 2009. 04:51

Citat:

Originalno napisao MorenoArdohain (Napišite 70582)
To mi nije jasno, na samom sajtu RNIDS pise da ce .YU domeni vaziti do 30. septembra 2009?

kome vise verujes? :)
hoces opkladu? :1042:

valeksic 12. 06. 2009. 12:26

Citat:

Originalno napisao Peca (Napišite 70555)
jel mogu da pitam ovde - ko je odredio rok da se .yu ugasi ovako rano?
kazem rano jer negde procitah da je SSSR-ov TLD bio aktivan vise od jedne decenije [a mozda je i jos aktivan?]
i ima li ikakvih sansi da se taj rok prolongira?




Minutes for Special Meeting of the ICANN Board of Directors
11 September 2007


Delegation of the .ME ( Montenegro) Domain
Delegation of the .RS ( Serbia) Domain
Redelegation of the .YU (former Yugoslavia) Domain

Kim Davies advised that the delegation of .ME ( Montenegro) and .RS ( Serbia) and the redelegation of .YU ( Yugoslavia) were interrelated. At the time that Serbia and Montenegro became new countries, the ISO 3166-1list was altered to give the two countries individual codes .RS and .ME respectively. To date, the countries covered have been using the .YU domain. The YU code is no longer in the ISO 3166-1 list and has been replaced with .ME and .RS and as such should be decommissioned in a responsible way. The transition plan from .YU to .RS and .ME involves an MOU between the two entities and would see that .YU is assigned to the proposed .RS sponsoring organization, which is effectively the same operator as today. They would act as caretaker for .YU for two years to allow for a stable transition. ICANN’s proposed resolution language is consistent with this plan however a three-year transition period is proposed to allow for contingencies. The proposed resolutions support the two new delegations and acknowledge the two parties involved in de-commissioning of the .YU domain, and state it is to be retired in three years time.

In addition to explaining the ICANN evaluation of the delegation applications, the board was also advised of last-minute correspondence IANA had received in relation to the delegation of the .ME domain.

Steve Goldstein asked if there is any provision in the agreement to restrict new registrations in .YU. Kim Davies advised that he would have to check to be certain, but as soon as new registrations are allowed in .RS and .ME it was his understanding that it would not be possible to register new domains in .YU.

Steve Goldstein asked why the preference for a three-year transition rather than two. Kim Davies advised they didn’t want to propose something that was too aggressive. The applicants had proposed a two-year transition period, but the Board could consider a different length.

The Chair proposed that the language in the resolution could be changed to be up to and no more than three years.

Steve Crocker acknowledged that some transitions have taken a long time. An additional suggestion would be to ask for regular reports with metrics measuring progress towards the outcome.

Kim Davies noted that the resolution proposed does suggest that the .YU registry report every 6 months to ICANN Staff on progress. The proposed resolution also makes it clear the domain must be removed no later than 2010, which was considered a responsible timeframe that was neither too aggressive, nor unnecessarily prolonged. If the community felt it could transition quicker there is nothing to stop that from happening.

Paul Twomey suggested that the wording be slightly amended asking that they report progress against appropriate metrics.

There were no objections to the suggested amendments.

Dave Wodelet asked if it mattered if they take till 2008, 2009 or even 2010 and the Chair responded that we do want a certain end date.

Kim Davies advised that there is no strong precedent for how long transition will take from one to the other. There have only been a small number of transitions of country codes in the history of ccTLDs. In trying to determine what they considered a reasonable timeframe for transition the closest comparable situation that IANA was aware of is when telephone-numbering systems change. These transitions generally take place in one-to-two years.

The Chair noted that the language proposed by Paul Twomey seems acceptable, an alternative to an extra year would be to stick with two years to 2009 and if the party needs more time they could come back and explain why, which may be the best option. Putting in a two-year timeframe provides them with leverage to help their community to promptly perform the transition. The Chair recommended the alternative on the basis it was made clear to them that if they have a problem with two years they can come back with an explanation to ICANN as to why they need more time.

Susan Crawford noted that she understands the direction and appreciates the conservative approach, but asked what mechanism should be used if the transition moves too slowly.

The Chair reflected that if they come back and have a reasonable explanation, then this should be okay. He believed you would help them with a shorter deadline as they can point to that as a mandate to move ahead and transition to other the domain.

Janis Karklins noted that human nature suggests they will take as much time as they are given for transitioning. He suggested that the resolution should include a point that ICANN Staff should keep the Board informed of the progress of the transition.

In summation, the Chair suggested that the Board approves all three requests, and that ICANN Staff is expected to keep the Board informed on the retirement of .YU domain. Paul Twomey added that they communicate according to appropriate metrics.

Steve Goldstein moved and Vanda Scartezini seconded the following resolution:

Delegation of .ME

Whereas, the .ME top-level domain is the designated country-code for

Montenegro ,

Whereas, ICANN has received a request for delegation of .ME to the Government of Montenegro,

Whereas, ICANN has reviewed the request, and has determined that the proposed delegation would be in the best interest of the local and global Internet communities,

Resolved (07.75), that the proposed delegation of the .ME domain to the Government of Montenegro is approved.

Delegation of .RS

Whereas, the .RS top-level domain is the designated country-code for Serbia,

Whereas, ICANN has received a request for delegation of .RS to the Serbian National Register of Internet Domain Names,

Whereas, ICANN has reviewed the request, and has determined that the proposed delegation would be in the best interest of the local and global Internet communities,

Resolved (07.76), that the proposed delegation of the .RS domain to the Serbian National Register of Internet Domain Names is approved.

Redelegation of .YU

Whereas, the .YU top-level domain is currently used by the citizens of both Serbia and Montenegro,

Whereas, ICANN has delegated the .RS domain for use in Serbia, and the .ME domain for use in Montenegro,

Whereas, the ISO 3166-1 standard has removed the “YU” code, and the ISO 3166 Maintenance Agency recommends its use be discontinued,

Whereas, ICANN is not responsible for deciding what is or is not a country, and adheres to the ISO 3166-1 standard for guidance on when to add, modify and remove country-code top-level domains,

Whereas, there is a transition plan to move registrations in .YU to the new domains .RS and .ME, with the operator of .RS acting as the temporary caretaker of .YU until the transition is complete,

Resolved (07.77), that the .YU domain be redelegated to the Serbian National Registry of Internet Domain Names in a temporary caretaker capacity.

Resolved (07.78), that the Serbian National Registry of Internet Domain Names be instructed to report their progress on decommissioning the .YU domain every six months to ICANN against a relevant set of metrics.

Resolved (07.79), that the Serbian National Registry of Internet Domain Names, and the Government of Montenegro, work to complete the transition from the .YU domain to the .RS and .ME domains, so that it may be removed from the DNS root zone no later than 30 September 2009.


A voice vote was taken of all Board Members present and all three motions were approved by a vote of all members present 13-0, with one abstention from Peter Dengate Thrush.

Peter Dengate Thrush explained that his reservation was associated with his belief that such policy decisions concerning delegation should rest with the ccNSO as specifically provided under the bylaws. He noted that he has raised this issue on a number of occasions suggesting that this matter should be referred to the ccNSO but to no avail.

The Chair noted that these practices have been in existence prior to the formation of the ccNSO, and that if policy is required in this area that the ccNSO work on a policy proposal, that might be properly considered.


http://www.iana.org/reports/2007/rs-...11sep2007.html

smarkovic 12. 06. 2009. 12:41

@Peca @Markok
O trajanju tranzicije za .yu domen odlučio je UO ICANN ovom odlukom iz septembra 2007:

http://www.iana.org/reports/2007/rs-...11sep2007.html

"Resolved (07.79), that the Serbian National Registry of Internet Domain Names, and the Government of Montenegro, work to complete the transition from the .YU domain to the .RS and .ME domains, so that it may be removed from the DNS root zone no later than 30 September 2009."

Takođe, iz zapisnika sa sednice UO ICANN vidi se da postoji prostor za produženje ovog roka, ukoliko se utvrdi da je to potrebno:

http://www.icann.org/en/minutes/prel...rt-11sep07.htm

Skupština RNIDS je jednom od svojih odluka iz oktobra 2007. obavezala UO da u saradnji sa ICANN učini sve da se ovaj rok produži (strana 4):

http://www.rnids.rs/files/list0034.pdf

Ja upravo radim na konačnom izveštaju RNIDS o tranziciji .yu domena za ICANN i u njemu će biti predloženo da se rok za tranziciju dodatno produži. Koliko vremena ćemo eventualno dobiti (i da li ćemo uopšte dobiti) niko ne može pouzdano da zna u ovom trenutku. Ipak, na osnovu dosadašnjeg iskustva sa ICANN jasno je da ICANN neće tolerisati produžavanje na "neograničeni" rok, ali mi deluje realno moguće da dobijemo produženje u opsegu od 6-24 meseca. Mada, kao što sam već rekao, mogu da odluče i da se drže prvobitnog roka, pa da brišu .yu zonu posle 30.09. ove godine.

Imajući u vidu ovo što sam rekao, priče koje priča Torbica su čista nagađanja i klađenje sa njim ti je čista lutrija :)

Što se tiče .su domena, on je u istom statusu kao i .yu (Being Phased Out):

http://www.iana.org/domains/root/db/su.html

i Rusi uveliko vode pregovore sa ICANN o načinu trajnog zatvaranja .su registra.

Inače, osnovna premisa ICANN koja stoji iza potrebe da se registri zemalja koje ne postoje uklanjaju sa Interneta otprilike bi mogla da se opiše na sledeći način (pošto nije precizno kodifikovana):

Ako se prilikom odlučivanja o tome ko može da ima nacionalni domen konsultuje ISO 3166 lista država (saglasno RFC 1591), onda se mora održati usklađenost sa tom listom; jer ako se odstupi od usklađenosti sa ISO 3166 listom, onda čemu uopšte pozivanje na tu listu od početka.

Drugim rečima, pozicija ICANN je da bi trenutni režim dodele nacionalnih TLD (baziran na RFC 1591) bio doveden u pitanje, ako bi se Rusiji/Srbiji/bilo kome dozvolilo da aktivno koristi TLD nepostojeće države u neodređenom vremenskom periodu.

Sve dok se u okviru ICANN ne postigne saglasnost o tome da režim otvaranja nacionalnih domena, uspostavljen RFC 1591, treba zameniti nečim drugim, imaćemo situaciju kakva je sada.

Pozdrav,
Sloba

torbica 12. 06. 2009. 13:31

Citat:

Originalno napisao smarkovic (Napišite 70589)
Ja upravo radim na konačnom izveštaju RNIDS o tranziciji .yu domena za ICANN i u njemu će biti predloženo da se rok za tranziciju dodatno produži. Koliko vremena ćemo eventualno dobiti (i da li ćemo uopšte dobiti) niko ne može pouzdano da zna u ovom trenutku. Ipak, na osnovu dosadašnjeg iskustva sa ICANN jasno je da ICANN neće tolerisati produžavanje na "neograničeni" rok, ali mi deluje realno moguće da dobijemo produženje u opsegu od 6-24 meseca. Mada, kao što sam već rekao, mogu da odluče i da se drže prvobitnog roka, pa da brišu .yu zonu posle 30.09. ove godine.

Imajući u vidu ovo što sam rekao, priče koje priča Torbica su čista nagađanja i klađenje sa njim ti je čista lutrija :)

Cobe je kao i obicno skroman :)
Primam opklade, ja kazem da ce rok da se produzi, Cobe je superstar :1090:

Markok 12. 06. 2009. 13:42

Ne sumnjam da se trazi nacin da se zatvori .su domen ali ipak moram da primetim da na www.nic.ru i dalje prodaju nove .su sto sugerise da mozda i nemaju nameru da i stvarno zatvare taj domen i da zele da prolongiraju zatvaranje do beskonacnosti. Ne znam, samo mi tako izgleda, i traje vec dvadeset godina.

MorenoArdohain 12. 06. 2009. 13:48

Rad'te sta oc'te, samo mi produzite .yu na jos godinu dana! :1058:

Nemanja Avramović 12. 06. 2009. 14:56

Uloži neku kintu, da bude zanimljivije :)

torbica 12. 06. 2009. 16:00

Citat:

Originalno napisao Nemanja Avramović (Napišite 70593)
Uloži neku kintu, da bude zanimljivije :)

100.000 dinara na produzenje :1042:

Markok 12. 06. 2009. 17:11

Jedan moj prijatelj ima prilicno ozbiljan problem. Prodaje neki softver cija se aktivacija vrsi preko web servisa koji je na co.yu domenu. On ne moze da povuce nazad iz prodaje ono sto se tamo vec nalazi + korisnici imaju pravo na vise od jedne aktivacije.

Jedini drugi kontakt naveden na softveru je telefonski broj. Kada ugasite co.yu covek ce se pretvoriti u telefonsku sekretaricu.

artur_dent 12. 06. 2009. 17:59

To je gadan problem, ali je kriv onaj ko je projektovao soft posto je to "morao" da predvidi. Da drzava ne postoji, kao i da domen nece vecno trajati.

Podseti me na genijalni hack za aktivaciju CS suite na OSX, gde je dovoljno da u hosts dodate samo lokalni IP za activation.adobe.com.

Mali skript koji se distribuira uz soft resava problem bez patchovanja i potrebe za izbacivanjem nove verzije softa.

Markok 12. 06. 2009. 19:53

Nije to tako jednostavno. Ljudi su kupili sada vec stariju verziju proizvoda u periodu 2004-2008, sada reinstaliraju sistem ili kupe nov racunar, teba im, lepo pise da imaju pravo na dve ili tri aktivacije stisnu dugme... i desice se nista. Averag Joe ni ne zna sta znaci patch, update i te stranjske reči. Odma se vata za telefon.

Onaj ko je projektovao softver, prvo je logično pogledao kako to radi Microsoft za Windows. To mi zvuci logicno, tu bih i ja pogledao, isto imaju dve aktivacije plus telefon.

misk0 12. 06. 2009. 21:09

A da izbaci na sajtu update za taj software, posalje mass mail korisnicima sa tom informacijom i rijesi problem?

Markok 12. 06. 2009. 21:54

Uradio je tako, jos pre nego sto je ugasena prethodna tura domena. Ali to resi problem samo delomicno jer ljudi daju laznu e-mail adresu, ili je ne koriste vise ili najcesci slucaj prime e-mail, procitaju ga, zakljuce da im to trenutno ne treba, ne urade nista i zaborave na njega. Klijenti nisu iz IT sveta vec obicni ljudii, da ih nazovem tako.

Zna on sta radi ali neke stvari se ne mogu u potpunosti resiti, moze se samo minimalizovati steta.

misk0 12. 06. 2009. 23:57

Citat:

Originalno napisao Markok (Napišite 70611)
Zna on sta radi ali neke stvari se ne mogu u potpunosti resiti, moze se samo minimalizovati steta.

Cuj, dio odgovornosti lezi i na klijentima, ne mozes ti sve predvidjeti i rijesiti za njih. Na kraju krajeva, moze na sajtu staviti obavjestenje da svi koji imaju te probleme (a na sajt ce doci kad im program ne bude radio) da skinu novu verziju i nece ih imati.

Peca 13. 06. 2009. 00:23

Citat:

Originalno napisao smarkovic (Napišite 70589)
Sve dok se u okviru ICANN ne postigne saglasnost o tome da režim otvaranja nacionalnih domena, uspostavljen RFC 1591, treba zameniti nečim drugim, imaćemo situaciju kakva je sada.

Slobo, kukajte im. I to im kukajte mnogo.
Meni 50% emailova stizu sa co.yu [@eunet.yu, @sbb.co.yu]... ljudi jos nisu izmenili to...
ebanking softver se obraca 24x7.co.yu domenu...

uglavnom, imate valjane argumente da trazite produzavanje.
kukajte im, ozbiljno to kazem :)


Vreme je GMT +2. Trenutno vreme je 23:30.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.