NajpopulßrnejÜou slu₧bou dneÜn²ch poΦφtaΦov²ch sietφ je bezpochyby elektronickß poÜta, ktorß pri¥ahuje stßle viacej u₧φvate╛ov. Aj ke∩ ide o slu₧bu, ktorß m⌠₧e by¥ v sie¥ach r⌠zneho typu implementovanß odliÜn²m sp⌠sobom, jej celkov² efekt je pre u₧φvate╛a prakticky v₧dy rovnak².
Elektronick· poÜtu je mo₧nΘ oznaΦi¥ za novodob² fenomΘn, ktor² zßsadne menφ sp⌠sob, ak²m ╛udia spolu komunikuj·. Ak sa vrßtime do minulosti, tak naprφklad v 18. storoΦφ trvalo nieko╛ko t²₧d≥ov, ne₧ sa nejakß sprßva dostala z Eur≤py do Ameriky, zatia╛ Φo dnes sa prenos sprßv aj na druh· stranu planΘty meria na sekundy. V∩aka elektronickej poÜte a ∩alÜφm modern²m sp⌠sobom komunikßcie dnes nie je problΘmom komunikova¥ s ktor²mko╛vek Φlovekom na Zemi.
Hist≤ria a dostupnos¥ elektronickej poÜty
PrvΘ e-mailovΘ systΘmy boli vyvinutΘ koncom 60. a zaΦiatkom 70. rokov. Tieto systΘmy boli preva₧ne malΘ s·kromnΘ systΘmy v rßmci oddelenφ, s malou snahou sprφstupni¥ jednotliv²m e-mailov²m systΘmom komunikßciu medzi sebou. Koncom 70. a zaΦiatkom 80. rokov sa stali dostupnΘ verejnΘ e-mailovΘ slu₧by prostrednφctvom poskytovate╛ov AT&T Mail, MCI Mail a CompuServe. V²skumnΘ a akademickΘ e-mailovΘ slu₧by sa vyvinuli do toho, Φo sa nesk⌠r stalo internetom. Preto₧e slu₧by pre posielanie sprßv sa stßvali populßrnejÜie a viacej pou₧φvanΘ, rßstla aj potreba vzßjomnej interoperability. Ako v²sledok toho boli vyvinutΘ tieto Ütandardy:
* ètandardy pre elektronickΘ posielanie sprßv a poÜtu zaistila rada doporuΦenφ X.400 od CCITT (Consultative Commitee for International Telegraphy and Telephony). Prvß verzia Ütandardov X.400 sa objavila v roku 1984 a je znßma ako MHS 84 (Message Handling System, 1984). SystΘmy X.400 dnes be₧ne sl·₧ia ako chrbtica pre doruΦovanie sprßv medzi e-mailov²mi systΘmami.
* Protokol SMTP (Simple Mail Transfer Protocol) v sade protokolov IP (Internet Protocol) zaistil e-mailovΘ Ütandardy a protokoly pre internet.
* Koniec 90. rokov a zaΦiatok tisφcroΦia s╛ubuj· pre elektronick· poÜtu nieko╛ko ∩alÜφch v²vojov²ch krokov:
* Rast Üφrky pßsma, cez e-mail bude mo₧nΘ posiela¥ aj obrovskΘ s·bory. Prebieha u₧ plßnovanie pre gigabitovΘ ·rovne a diskutuje sa dokonca o sie¥ach s terabitov²mi r²chlos¥ami.
* Podpora pre video, audio a grafiku v poÜtov²ch slu₧bßch posielania sprßv. Smernice t²kaj·ce sa sp⌠sobu, ak²m sa mß s t²mito dßtami pracova¥, zabezpeΦuj· rozÜφrenie Multipurpose Internet Mail Extension (MIME). Preto₧e tieto rozÜφrenia predstavuj· iba zaΦiatok, je pravdepodobnΘ, ₧e v tejto oblasti d⌠jde k zßsadnΘmu v²voju.
* Vznik inteligentn²ch agentov, ktor² pomßhaj· s obsluhou a doruΦenφm poÜty.
* V²voj bezdr⌠tov²ch poÜtovn²ch slu₧ieb bude pokraΦova¥ a prispeje tak k podnieteniu zlepÜenia v oblasti bezdr⌠tov²ch sietφ.
* Zobecnenie elektronickej poÜty a posielanie sprßv, ktorΘ zasahuje do elektronickΘho obchodu (naprφklad prostrednφctvom EDI, Electronic Data Interchange).
* Pou₧itie Üifrovania, digitßlnych podpisov a ∩alÜφch bezpeΦnostn²ch technφk, ktorΘ uchovaj· obsah e-mailov²ch sprßv skryt² pred neautorizovan²mi oΦami.
Toto s· zßkladnΘ vylepÜenia e-mailu, pokia╛ sa mß sta¥ prostriedkom pre elektronick² obchod. Prφkladom takΘhoto bezpeΦnostnΘho opatrenia je PEM (Privacy Enhanced Mail). Pre Üifrovanie je mo₧nΘ pou₧i¥ tie₧ algoritmus PGP (Pretty Good Privacy).
SystΘm prenosu sprßv elektronickej poÜty
UA (User Agent) - v systΘme spracovania sprßv CCITT X.400 aplikaΦn² proces (program), ktor² poskytuje u₧φvate╛ovi prφstup k systΘmu prenosu sprßv (MTS). UA vytvßra rozhranie, prostrednφctvom ktorΘho m⌠₧e u₧φvate╛ vyu₧φva¥ slu₧by elektronickej poÜty. Pou₧φvate╛ ho sp·Ü¥a a₧ na zßklade potreby.
MTA (Message Transfer Agent) - programy, ktorΘ maj· na starosti vlastn² prenos sprßv a nevÜφmaj· si obsah sprßvy. Zaujφma ich predovÜetk²m adresa prφjemcu. Be₧ia na jednotliv²ch poΦφtaΦoch a musia vzßjomne spolupracova¥. Takto vzßjomne spolupracuj·ce MTA naz²vame Message Transfer Systems.
V modeli X.400 je MTA s·Φas¥ systΘmu obsluhy sprßv (Message Handling System - MHS), ktorß je zodpovednß za ukladanie alebo prenos sprßv ∩alÜφm MTA, u₧φvate╛sk²m agentom alebo inΘmu autorizovanΘmu prφjemcovi. MTA je v prostredφ TCP/IP porovnate╛n² s poÜtov²m agentom Mail Transfer Agent.
MTS (Message Transfer System) - proces, ktor² prenßÜa sprßvy medzi u₧φvate╛mi. Za t²mto ·Φelom MTS vyu₧φva iba vlastnΘ komponenty (MTA). MTS sa vyznaΦuj· t²m, ₧e pou₧φvaj· jednotnΘ konvencie a protokoly.
Elektronickß poÜta je bezpochyby najrozÜφrenejÜia zo vÜetk²ch slu₧ieb, ktorΘ internet pon·ka. Elektronickß poÜta je ako vΣΦÜina slu₧ieb internetu zalo₧enß na modeli klient - server (obr. 2). Zßkladom elektronickej poÜty je existencia tzv. poÜtovej schrßnky Mail Box, ktorß vychßdza z filozofie Post Office Boxu. Ka₧d² u₧φvate╛ mß vlastn· elektronick· poÜtov· schrßnku (mailbox, jedineΦn² adresßr pre ukladanie elektronickej poÜty) a ostatnφ u₧φvatelia mu m⌠₧u posiela¥ e-mailovΘ sprßvy. Tieto sprßvy sa posielaj· na e-mailov· adresu. E-mailovß adresa je urΦenß dvojicou ·dajov: identifikßtorom schrßnky v rßmci danΘho poΦφtaΦa a adresou poΦφtaΦa. Pokia╛ je poÜta ulo₧enß v schrßnke prφjemcu, m⌠₧e u₧φvate╛ tejto schrßnky vyvola¥ akΘko╛vek pre neho d⌠le₧itΘ alebo zaujφmavΘ sprßvy. Pokia╛ nejakß e-mailovß sprßva nem⌠₧e by¥ doruΦenß, m⌠₧e by¥ doΦasne ulo₧enß v poÜtovnom ·rade (post office). To je slu₧ba, ktorß umo₧≥uje uklada¥ sprßvy s mo₧nos¥ou periodicky kontrolova¥, Φi je prφjemca pripraven² doruΦen· poÜtu prevzia¥. Elektronickß poÜta nie je nikdy zais¥ovanß jedin²m programom, v₧dy ide o spoluprßcu viacer²ch programov, ktorΘ s· r⌠znym sp⌠sobom ÜpecializovanΘ. Naprφklad existuj· programy, ktorΘ sa staraj· iba o prenos sprßv, prezeranie sprßv, vytvßranie a ich odosielanie. Zßkladn²mi RFC dokumentmi, ktorΘ sa zaoberaj· elektronickou poÜtou, s·:
RFC 821 [11] - definuje zßkladn² model elektronickej poÜty a jej prenos pomocou protokolu SMTP;
RFC 1521 [13 ] - definuje rozÜφrenie elektronickej poÜty MIME, ktorΘ umo₧≥uje prenos aj in²ch s·borov ako textov²ch.
Okrem t²chto zßkladn²ch dokumentov existuje eÜte ve╛a ∩alÜφch, ktorΘ ich dopσ≥aj·, avÜak vÜetky vychßdzaj· z uveden²ch RFC dokumentov.
Adresovanie sprßv
P⌠vodn² systΘm UUCP (Unix-to-Unix Copy) pou₧φval adresy v tvare:
poΦφtaΦ!u₧φvate╛
V²kriΦnφk sa vyslovuje ako bang, tak₧e tomuto sp⌠sobu adresovania sa hovorilo "bang notßciaÄ. Pokia╛ je cie╛ov² poΦφtaΦ vzdialen², musφ sa obyΦajne Üpecifikova¥ kompletnß cesta, po ktorej sa bude sprßva ubera¥. Prφkladom m⌠₧e by¥ UUCP adresa v tvare
poΦφtaΦ1!poΦφtaΦ2!poΦφtaΦ3!poΦφtaΦ4!u₧φvate╛
V²znam tejto adresy je tak², ₧e sprßva sa najprv odoÜle na poΦφtaΦ1, ten ju po prijatφ odoÜle na poΦφtaΦ2, poΦφtaΦ2 ju ∩alej odoÜle na poΦφtaΦ3 , ten ju odoÜle na poΦφtaΦ4, kde ju obdr₧φ konkrΘtny u₧φvate╛. Cesta v tomto tvare m⌠₧e obsahova¥ a₧ 20 poΦφtaΦov. Zßkladn² dokument RFC 822 definuje nov² sp⌠sob takzvanΘho domΘnovΘho adresovania, ktor² sa pou₧φva dnes. Takßto adresa mß tvar
u₧φvate╛@domΘnovΘ_meno
kde domΘnovΘ_meno je utvorenΘ pod╛a pravidiel Domain Name System (DNS). U₧φvate╛ je identifikßtor poÜtovej schrßnky v rßmci danΘho poΦφtaΦa. V domΘnovom adresovanφ je mo₧nΘ Üpecifikova¥ medzistanicu (poÜtov· brßnu), cez ktor· mß danß sprßva prejs¥. Formßt takejto adresy je nasleduj·ci:
u₧φvate╛%cie╛ov²_poΦφtaΦ@brßna
Ak je na strane odosielate╛a sprßvne nakonfigurovan² poÜtov² software, je formßt tejto adresy potrebn² len ve╛mi zriedka.
Formßt poÜtovej sprßvy
Ka₧dß poÜtovß sprßva sa skladß z dvoch Φastφ: hlaviΦky (header) a tela sprßvy (body). Telo sprßvy obsahuje vlastn² text sprßvy a z poh╛adu systΘmu elektronickej poÜty nie je nijako Ütrukt·rovanΘ - ani u₧φvate╛skΘ zlo₧ky (UA), ani prenosovΘ zlo₧ky (MTA) t·to Φas¥ sprßvy neinterpretuj· (okrem Üpecißlnych prφpadov, ako naprφklad pri potrebe konverzie z jednej znakovej sady do druhej). Naopak hlaviΦka musφ by¥ ve╛mi presne Ütrukt·rovanß, lebo obsahuje informßcie, pod╛a ktor²ch s· jednotlivΘ sprßvy odosielanΘ, prenßÜanΘ a doruΦovanΘ. Ka₧d² systΘm elektronickej poÜty (MHS, Message Handling System) musφ presne definova¥, Φo mß by¥ v hlaviΦke obsiahnutΘ a ak²m konkrΘtnym sp⌠sobom to mß by¥ vyjadrenΘ. To preto, aby si u₧φvate╛skΘ zlo₧ky (UA) a prenosovΘ zlo₧ky (MTA) dokßzali v hlaviΦke sprßvy nßjs¥ tie informßcie, ktorΘ potrebuj· k svojej Φinnosti. Syntaxom hlaviΦky sa podrobne zaoberß dokument RFC 822 [12]. HlaviΦka sa musφ nachßdza¥ pred telom sprßvy a telo sprßvy musφ by¥ od hlaviΦky oddelenΘ najmenej jedn²m prßzdnym riadkom (CRLF CRLF). To z toho d⌠vodu, ₧e vÜetko, Φo nasleduje za prv²m prßzdnym riadkom, sa pova₧uje za text sprßvy. HlaviΦku sprßvy dokument RFC 822 definuje ako postupnos¥ polo₧iek, ktor²m sa v originßli hovorφ header fields (polia hlaviΦky). Ka₧dß polo₧ka hlaviΦky musφ zaΦφna¥ na novom riadku (na prvej pozφcii riadku) a m⌠₧e pokraΦova¥ na ∩alÜφch riadkoch (v takom prφpade ale nesmie zaΦφna¥ od prvej pozφcie riadku). Ka₧dß polo₧ka zaΦφna nejak²m k╛·Φov²m slovom (zakonΦen²m dvojbodkou), ktorΘ definuje jej v²znam. Za k╛·Φov²m slovom a dvojbodkou nasleduje vlastn² obsah prφsluÜnej polo₧ky. HranatΘ zßtvorky maj· v²znam v mene poΦφtaΦa; signalizuj·, ₧e meno poΦφtaΦa nemß by¥ prekladanΘ pomocou DNS (obr. 3 ). BodkoΦiarka mß v²znam separßtora, pou₧φva sa naprφklad pri odde╛ovanφ adresßtov v hlaviΦke v poli To:. Text uzatvoren² v obl²ch zßtvorkßch je pova₧ovan² za komentßr a pri interpretßcii niektor²ch polφ hlaviΦky je ignorovan². LomenΘ zßtvorky (< >) zase oznaΦuj· ·daje prednostne urΦenΘ pre poÜtov² program. Naprφklad poÜtov· adresu je mo₧nΘ zapφsa¥ aj takto:
"Bill Gates" <bill@microsoft.com>
Bill Gates <bill@microsoft.com>
<Bill.Gates@microsoft.com>
PoÜtov² program si vezme iba ·daje uzatvorenΘ v lomen²ch zßtvorkßch. Dokument RFC 822 nepredpisuje povinnΘ poradie jednotliv²ch polo₧iek hlaviΦky. ┌daje uvedenΘ v hlaviΦke musia by¥ k≤dovanΘ v klasickom 7-bitovom ASCII formßte.
From: E-mailovß adresa odosielate╛a, prφpadne jeho skutoΦnΘ meno. Pre toto pole existuje ve╛a formßtov zßpisu adresy. Jeden z mo₧n²ch zßpisov je na obr. 3 .
To: E-mailovß adresa, eventußlne i meno prφjemcu.
Cc: Carbon Copy. Za t²mto k╛·Φov²m slovom nasleduj· adresy t²ch pou₧φvate╛ov, ktor²m sa dßva list alebo sprßva na vedomie. JednotlivΘ adresy sa odde╛uj· Φiarkou.
Bcc: Blind Carbon Copy. Tu sa Üpecifikuj· adresy prφjemcov k≤pie, u ktor²ch nechceme, aby t·to skutoΦnos¥ adresßt vedel. Toto pole sa pred odoslanφm sprßvy zma₧e.
Reply-To: Pole obsahuje adresu, na ktor· sa mß odosielate╛ovi posla¥ prφpadnß odpove∩. M⌠₧e by¥ u₧itoΦnΘ vtedy, ak mßte nieko╛ko poÜtov²ch adries, ale pritom chcete dostßva¥ poÜtu iba na jednu adresu, ktor· pou₧φvate najΦastejÜie.
In-Reply-To: Obsah tohto po╛a identifikuje predchßdzaj·cu koreÜpondenciu, ktorß je odpove∩ou na vaÜu sprßvu.
Subject: StruΦn² popis obsahu sprßvy.
Sender: èpecifikuje odosielate╛a sprßvy (ak je to niekto in² ne₧ autor sprßvy, pre ktorΘho je urΦenß polo₧ka From:).
Date: Dßtum odoslania sprßvy, vrßtane ·dajov o Φasovom posuve vzh╛adom k svetovΘmu Φasu.
References: Obsah tohto po╛a identifikuje in· koreÜpondenciu, na ktor· sa tßto sprßva odkazuje.
Message-ID: Re¥azec, ktor²m je sprßva identifikovanß - je automaticky generovan² poÜtov²m programom.
Keywords: K╛·ΦovΘ slovß charakterizuj·ce obsah. JednotlivΘ slovß s· od seba oddelenΘ Φiarkou.
Comments: Poznßmka; komentßr.
Encrypted: èifrovanΘ (zastaralΘ).
Received: Toto pole vlo₧φ do hlaviΦky ka₧d² poÜtov² uzol (e-mailov² server) na ceste medzi stanicami odosielate╛a a prφjemcu, ktor² sa danou sprßvou zaoberal. Pole obsahuje nßzov poÜtovΘho uzla, Φφslo id sprßvy, Φas a dßtum, kedy dan² uzol sprßvu obdr₧al, ∩alej od ktorΘho poÜtovΘho uzla sprßva pochßdza a ktor² transportn² software bol pou₧it² k doruΦeniu sprßvy. Tieto informßcie sa uvßdzaj· z toho d⌠vodu, aby bolo mo₧nΘ vystopova¥, kadia╛ sprßva iÜla, a h╛ada¥ zdroj eventußlnych problΘmov. Pole Received: sa sprßvne Φφta zdola nahor. V tomto poli sa m⌠₧u vyskytova¥ nasleduj·ce slovß: from - poΦφtaΦ, z ktorΘho bola sprßva prijatß, by - poΦφtaΦ, ktor²m bola sprßva prijatß, via - fyzickß cesta, with - sie¥ov² alebo poÜtov² protokol, id - prφjemcova identifikßcia sprßvy, for - pre koho je sprßva urΦenß (napr. ak je adresßtom bill@microsoft.com, potom sa tu zachovßva p⌠vodn² adresßt, t.j. bill@microsoft.com).
Return-Receipt-To: Pokia╛ hlaviΦka obsahuje toto pole, zaÜle sa po ·speÜnom doruΦenφ do schrßnky adresßta potvrdenie na uveden· adresu. Hodnotu takΘhoto potvrdenia je treba bra¥ s rezervou, preto₧e jeho nedoruΦenie nemusφ znamena¥, ₧e sprßva nedorazila na miesto urΦenia.
X-anything: Tento re¥azec sa pou₧φva kv⌠li implementßcii doplnkov²ch vlastnostφ, ktorΘ zatia╛ neboli uverejnenΘ v dokumentoch RFC, alebo ktorΘ ani uverejnenΘ nebud·. Prφkladom je polo₧ka X-Mailer:, ktorß zvyΦajne obsahuje typ a verziu poÜtovΘho programu, z ktorΘho bola sprßva odoslanß. Ak poÜtov² program nepoznß v²znam niektorΘho po╛a zaΦφnaj·ceho X-, mal by ho ignorova¥. ╧alÜie polo₧ky tohoto typu s· naprφklad X-Accept-Language:, X-Priority:, X-UIDL a pod.
Resent- Pri automatickom odovzdßvanφ sprßvy (napr. vrßteniu nedoruΦite╛nej sprßvy) sa pred p⌠vodnΘ hlaviΦkovΘ polia vlo₧φ re¥azec Resent- (napr. Resent-From alebo Resent-Cc a pod.).
Nie vÜetky uvedenΘ k╛·ΦovΘ slovß s· povinnΘ, RFC 822 urΦuje minimßlne po₧iadavky na hlaviΦku sprßvy takto:
Date: 26 Aug 76 1429 EDT
From: Jones@Registry.org
Bcc:
alebo
Date: 26 Aug 76 1429 EDT
From: Jones@Registry.org
To: Smith@ Registry.org
Zßznam v poli Bcc: m⌠₧e by¥ prßzdny, zatia╛ Φo v poli To: je po₧adovanß aspo≥ jedna adresa.
Formßt tela sprßvy - rozÜφrenie MIME
P⌠vodn² dokument RFC 821 a RFC 822 obsahoval iba rßmcovΘ smernice pre formßt tela poÜtovej sprßvy. Znakovß sada bola obmedzenß zßkladn²m 7-bitov²m ASCII k≤dom a poΦet znakov v jednom riadku bol obmedzen² Φφslom 1000. To bol aj d⌠vod, preΦo pri pφsanφ poÜtov²ch sprßv nebolo mo₧nΘ pou₧φva¥ znaky s interpunkΦn²mi znamienkami (ASCII k≤d takΘto znaky neobsahuje). Okrem toho sa elektronickß poÜta ukßzala by¥ vhodn²m prostriedkom aj pre prenßÜanie r⌠znych binßrnych s·borov (obrßzky, audio, formßtovan² text a pod.). Preto sa pou₧φvali r⌠zne externΘ k≤dovacie schΘmy, naprφklad v Unixe programy uuencode a uudecode, ktorΘ umo₧≥ovali transformova¥ ╛ubovoln² binßrny s·bor do tvaru, ktor² vyhovoval norme RFC 821 [11]. SystΘmovΘ rieÜenie bolo dosiahnutΘ prostrednφctvom takzvan²ch rozÜφrenφ MIME (Multipurpose Internet Mail Extensions), Üpecifikßcia ktor²ch je obsiahnutß v normßch RFC 1521 a RFC 1522. MIME je Ütandardom, ktor² dopl≥uje normu RFC 822 a zßrove≥ zabezpeΦuje spΣtn· kompatibilitu. RozÜφrenie MIME zaviedlo tieto novΘ hlaviΦkovΘ polia (obr. 4):
Content-Type: èpecifikuje typ a podtyp dßt posielan²ch v tele sprßvy (text, audio, video a pod.).
Content-Transfer-Encoding: èpecifikuje typ k≤dovania, pomocou ktorΘho je sprßva transformovanß do formßtu, ktor² vyhovuje RFC 821, t.j. do krßtkych riadkov v 7-bitovom ASCII k≤de.
Content-ID: Identifikßcia sprßvy pou₧ite╛nß v mo₧nom odkaze.
[7] Lhotka, L.: SERVER v INTERNETU, KOPP, ╚eskΘ Bud∞jovice, 1997
[8] Peterka, J.: Co je Φφm ... v poΦφtaΦov²ch sφtφch, COMPUTERWORLD Φ. 4, 7, 9, 17, 21, 3 5, 44, 1994
[9] Sterling, B.: Short History of the Internet, The Magazine of Fantasy and Science Fiction, 1993
[10] RNDr. Dostßlek, L., Ing. Kabelovß, A.: MIME - Multipurpose Internet Mail Extension, http://info.pvt.net/mime.htm, 1997
[11] Postel, J. B.: Simple Mail Transfer Protokol, RFC # 821, August 1982
[12] Crocker, D. H.: Standard For The Format Of Arpa Internet Text Messages, RFC # 822, August 1982
[13] Borenstein, N., Freed, N.: MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC # 1521, September 1993
[14] Borenstein, N., Freed, N.: Multipurpose Internet Mail Extension (MIME) Part One: Format of Internet Message Bodies, RFC # 2045, November 1996
[15] Rose, M.: Post Office Protocol - Version 3 , RFC # 1225, May 1991
[16] Rose, M., Myers, J.: Post Office Protocol - Version 3 , RFC # 1725, November 1994
[19] Pal·ch, P.: Poznßte Linux?, PC Revue Φ. 2, 1998
[20] Rivest, R.: The MD5 Message-Digest Algorithm, RFC # 13 21, Aprφl 1992
[21] RNDr. Dostßlek, L. a kol.: Velk² pr∙vodce protokoly TCP-IP BezpeΦnost, Computer Press, Praha, 2001
Vysvetlivky
RFC (Request for Comments) Sada Φlßnkov, v ktor²ch sa dokumentuj· a zverej≥uj· Ütandardy internetu, nßvrhy Ütandardov a obecne ods·hlasenΘ myÜlienky.
DNS (Domain Name System) SystΘm domΘnov²ch mien. Distribuovan² hierarchick² informaΦn² systΘm vyu₧φvan² v IP sie¥ach, umo₧≥uj·ci preklad symbolick²ch domΘnov²ch mien (napr. www.zoznam.sk) na ΦφselnΘ IP adresy (195.85.36.45).
