Bazy danych w zastosowaniu telekomunikacyjnym
Transkrypt
Bazy danych w zastosowaniu telekomunikacyjnym
prof. Czesław Jędrzejek*, Tomasz Olejniczak, Maciej Kucewicz Instytut Technik Telekomunikacyjnych i Informatycznych, Poznań *także Zakład Systemów Telekomunikacyjnych Akademii Techniczno – Rolniczej w Bydgoszczy Podstawy zarządzania informacją w Internecie STRESZCZENIE Internet w większości zawiera nieuporządkowaną informację. Dostęp poprzez URL nie spełnia wymagań korzystania z bibliotek cyfrowych. IETF zamierza wprowadzić „Handle System”, ogólny schemat dostępu do obiektów cyfrowych w środowisku rozproszonym. System ten wprowadza uniwersalną przestrzeń adresową oraz znaczniki „handle” dostępu do informacji o następujących cechach: → globalna unikatowość, → trwałość, → wielokrotność informacji, → rozszerzalna przestrzeń adresowa, → oparcie o UNICODE 2.0, → rozproszony model usług i zarządzania, → zapewnienie bezpieczeństwa i wartości intelektualnych treści, → efektywny tryb wyszukiwania. „Handle System” ułatwi wprowadzenie wielu usług, np. globalnego cache’u, typu zaimplementowanego przez firmę Akamai. Będzie on miał duże znaczenie dla trybu korzystania z baz danych. WSTĘP Podstawą działania Internetu jest transmisja pakietowa i system adresowy protokołu IP. Ułatwienie w postaci DNS (Domain Name System) działa na zasadzie książki telefonicznej przekształca nazwę na adres cyfrowy. Gwałtowny wzrost Internetu prowadzi do zaśmiecenia informatycznego. Oprócz informacji wartościowej (często płatnej) pojawia się ogromna ilość informacji małowartościowej, amatorskiej i niezarządzanej. Mimo upowszechnienia protokołu XML oraz coraz sprawniejszych wyszukiwarek często nie jesteśmy w stanie odszukać żądanej informacji. Protokół HTTP działa w architekturze klient/serwer i używa standaryzowanego adresu URL (ang. Uniform Resource Locator). Adres URL ma postać http://domena/plik lokalny. URL jest postacią generycznego adresu URI (ang. Uniform Resource Identifier). Problem z adresami URL jest taki, że jeśli materiału, który nas interesuje nie ma pod adresem URL, co wynika z częstych zmian lokalizacji materiału, adres taki jest bezużyteczny. System adresowy URL jest bowiem związany z lokalizacją serwera, na którym znajduje się zasób, a nie z identyfikatorem materiału. W3C pracuje nad schematami URN (ang. Uniform Resource Name) w celu standaryzacji mechanizmów zapewnienia trwałości i integralności (materiał jest autentyczny i nie zmieniony) oraz niezawodności. Są to adresy, które dają gwarancję znalezienia materiału (gwarancja trwałości, ang. persistence). Schemat RDF (ang. Resource Description Framework) specyfikuje rejestrację usług rozpoznania adresów (ang. „resolution”). Prace nad URN trwają od lat, ale wdrożenia ciągle są odległe. Zbadano trwałość URL dla pewnej liczby czasopism on-line [1]. Procent aktualnych odsyłaczy (link) wyniósł 67% dla protokołu HTTP i 31% dla FTP. Półokres zaniku URL wynosi 44 dni. Widać więc, że dotychczasowy system zarządzania informacją w Internecie jest mało użyteczny, szczególnie w przypadku bibliotek cyfrowych. Z uwagi na ten fakt środowiska decydujące o przyszłości Internetu (główny udział w tej inicjatywie miał Robert E. Kahn) powołały w USA Korporację Inicjatyw Badawczych, Corporation for National Research Initiatives, CNRI (www.cnri.net). Jest to organizacja not-for-profit promująca strategiczne inicjatywy w dziedzinie informacyjnych technik sieciowych i wspomagająca W3C w rozwoju najbardziej zaawansowanych zastosowań. CNRI współpracuje z The International DOI Foundation (IDF) nad rozwojem systemu identyfikacji obiektów cyfrowych (Digital Object Identifier System [2]), standardu identyfikacji treści cyfrowej dla wydawców, zarządców oraz bibliotekarzy informacji cyfrowej przy wykorzystaniu CNRI Handle System [5] (nie będziemy tłumaczyć na język polski tego wyrażenia) jako technologii do implementacji tego celu. Celem jest wdrożenie Handle System jako zmodyfikowanego URN. Jednocześnie CNRI i IDF stworzyły Digital Object Architecture i zaimplementowały kluczowe składniki tej architektury w dwóch pilotażach w instytucjach amerykańskich, jednym w the Copyright Office a w drugim w Bibliotece Kongresu Amerykańskiego (Library of Congress) w ramach National Digital Library Program. ZAŁOŻENIA SYSTEMU IDENTYFIKACJI I DOSTĘPU DO OBIEKTÓW CYFROWYCH Działania CNRI i IDF doprowadziły do tego, że IETF (Internet Engineering Task Force) zamierza wprowadzić Handle System [5], ogólny schemat dostępu do obiektów cyfrowych w środowisku rozproszonym. System ten wprowadza uniwersalną przestrzeń adresową oraz znaczniki „handle” dostępu do informacji o następujących cechach: → → → → → → → → globalna unikatowość, trwałość, wielokrotność informacji, rozszerzalna przestrzeń adresowa, oparcie o UNICODE 2.0, rozproszony model usług i zarządzania, zapewnienie bezpieczeństwa i wartości intelektualnych treści, efektywny tryb wyszukiwania. DOI – (digital object identifier) – identyfikator obiektu cyfrowego - jest stałym identyfikatorem przypisanym do pliku lub dokumentu internetowego. Tak więc nawet, gdy zmieni się adres internetowy tego dokumentu, użytkownicy przekierowani zostaną na adres aktualny. Jako adresu dokumentu używa się adresu centralnie zarządzanego katalogu oraz identyfikatora dokumentu. System nadawania identyfikatorów opracowany został przez Stowarzyszenie Wydawców Amerykańskich (Association of American Publishers) przy współpracy z CNRI i jest obecnie administrowany przez międzynarodową fundację - International DOI Foundation. Skrót DOI może oznaczać zarówno identyfikator cyfrowy, jak też całą architekturę systemu zapewniającego rozpoznawanie i zarządzanie identyfikatorami. System identyfikatorów obiektów cyfrowych (DOI) określić można jako schemat przekierowywania zapytań internetowych poprzez centralnego nadzorcę. Obecnie istnieje jeden centralny katalog zarządzany przez Fundację DOI, jednak przewiduje się powstanie wielu tego typu katalogów zarządzanych np. przez duże korporacje. Przykładowy identyfikator ma następującą postać: doi:10.1002/ISBNJ0-471-58064-3 W przykładzie tym, oznaczenie doi jest identyfikatorem przestrzeni nazw (nid), natomiast ciąg 10.1002/ISBNJ0-471-58064-3 jest specyficznym ciągiem w tej przestrzeni (nss). Pierwszy człon ciągu (prefiks) – ”10.1002” – oznacza katalog ( samo „10” oznacza DOI), a po znaku „/” następuje dalsza część identyfikatora. W tym przypadku numer ISBN (International Standard Book Number) określa konkretną książkę wydaną przez określonego wydawcę, natomiast ostatnia cyfra – ”3” oznacza specyficzną część lub rozdział książki. Identyfikator DOI będzie skojarzony z odpowiednią stroną WWW lub adresem URL w katalogu. Aby umieścić odnośnik do dokumentu na stronie internetowej należy odwoływać się do następującego adresu URL: http://www.doi.org/10.1002/ISBNJ0-471-58064-3 gdzie ”www.doi.org” jest adresem jedynego jak na razie administratora katalogów identyfikacyjnych. Użytkownik klikając na tym odnośniku zostanie połączony ze stroną katalogową, która z kolei zlokalizuje i zwróci adres URL związany z konkretnym identyfikatorem DOI. Przy założeniu, że katalog jest aktualny, zarówno właściciel strony jak i użytkownik mogą mieć pewność, że zwrócony zostanie adres najświeższej strony. Architektura systemu odwołań do obiektu cyfrowego przedstawiona jest na Rys. 1. Użytkownik klikając na odsyłacz DOI na stronie internetowej nie musi wiedzieć gdzie znajduje się szukany obiekt, jego przeglądarka łączy się z serwerem DOI, uzyskuje adres internetowy skojarzony z identyfikatorem i następnie łączy się ze wskazanym adresem. 1. Wysłanie zapytania DOI Komputer użytkownika z przeglądarką 3. Uzyskanie informacji o obiekcie 2. Przekierowanie Biblioteka lub wydawca zapytania do biblioteki /brama lub dostawcy Serwer DOI Rejestr Identyfikatorów DOI Informacja o obiekcie Rys. 1. Architektura systemu odwołań do obiektu cyfrowego INFORMACJE STANDARYZACYJNE Składnia DOI jest opisywana przez standard NISO (National Information Standards Organisation USA) w dokumencie: ANSI/NISO Z39.84-2000 Syntax for the Digital Object Identifier, gdzie ANSI oznacza American National Standards Institute. W opracowywanym przez CNRI Handle System do opisu identyfikatorów zamiast określenia handle używane jest DOI. Obydwa te terminy są zgodne z dokumentem IETF RFC 1737 Functional Requirements for Uniform Resource Names. Handle System jest otwartą specyfikacją opisywaną przez następujące dokumenty: → Internet Draft -- "Handle System Overview" zgłoszony do IETF w czerwcu 1999 zaktualizowany w lutym 2000, → Internet Draft -- "Handle System Namespace and Service Definition" zgłoszony do IETF w lipcu 1999, zaktualizowany w lutym 2000. Dokumenty te są zgodne z RFC 2026 - Internet Standards Process, rozdział 10, „Intellectual property rights”. System DOI jest oparty na Handle System i używa go do przechowywania i zarządzania cyfrowymi identyfikatorami obiektów. Handle System zapewnia globalny system nazewnictwa, który umożliwia każdej lokalnej przestrzeni nazw na przyłączenie się do globalnego i wspólnego systemu nadawania nazw przez uzyskanie unikatowego znacznika (ang. handle). Lokalne nazwy i ich powiązania pozostają nienaruszone po dołączeniu się do globalnego Handle System. Każde odwołanie do lokalnego zasobu może być obsłużone przez interfejs (proxy) komunikujący się z Handle System, który potrafi zidentyfikować nazwy lokalne. Handle System definiuje hierarchiczny model usługi. Najwyższy poziom zawiera pojedynczą globalną usługę znaną jako Global Handle Registry [6] pozwalającą na zarządzanie przestrzeniami nazw znaczników, natomiast niższe poziomy zawierają wszystkie pozostałe usługi handle (usługi lokalne). Warto porównać Handle System z innymi usługami internetowymi realizującymi identyfikację obiektów: → DNS (Domain Name System) jest chyba najbardziej popularnym systemem nadawania nazw zasobom internetowym. Zapewnia on mechanizm nazywania zasobów w taki sposób, że ich nazwy są mapowane na adresy IP i dostępne przez różne komputery, sieci i rodziny protokołów w Internecie. System jednak ten nie nadaje się do zaimplementowania w nim globalnego systemu nazewnictwa z powodu zbyt dużego znaczenia nazw dla rutingu w sieciach lokalnych, oraz sposobu zarządzania. Jest to system nieskalowalny i nie jest możliwe przypisanie kilku zasobów do jednej nazwy. Nazwy DNS są zwykle przydzielane przez administratorów sieci lokalnych bez żadnego zabezpieczenia nazw, oraz bez żadnych udogodnień do przydzielania tych nazw dla innych osób. Handle System posiada rozproszoną architekturę, usługi i zarządzanie. Handle System został od początku zaprojektowany do obsłużenia systemu nadawania nazw dla wielkiej ilości elementów i zarządzania nimi przez nazwy. Model danych Handle System pozwala kontrolować dostęp na każdym z poziomów danych. Każdy handle może mieć dodatkowo zdefiniowanego administratora, który będzie zarządzał danymi przez protokół uwierzytelniający. → Usługi katalogowe X.500/LDAP (Lightweight Directory Access Protocol). X.500 jest protokołem zdefiniowanym do zapewniania usług typu “white pages” i służy głównie do szukania danych osobowych. Zapewnia hierarchiczną strukturę danych i mechanizmy do wyszukiwania. Protokół LDAP jest klientem X.500 możliwym do zaimplementowania na prostszym sprzęcie nie wymagającym znacznej ilości zasobów i mocy obliczeniowej. Podstawową różnicą między usługami katalogowymi, a Handle System jest możliwość przeszukiwania danych i przez to większa złożoność w usługach katalogowych. → URN (Uniform Resource Names). Standard ten definiuje składnie, mechanizmy identyfikacji, oraz procedury rejestracji przestrzeni nazw dla identyfikatorów. Jest on przeznaczony głównie do obsługi wielokrotnych identyfikatorów oraz systemów identyfikacji i dostępu do danych. Handle System jest wersją URN, przeznaczoną dla bardzo specyficznych danych i modelu usług oraz protokołem zapewniającym identyfikację nazw oraz administrację. DZIAŁANIE SYSTEMU IDENTYFIKATORÓW CYFROWYCH Aby móc korzystać z globalnego systemu identyfikacji wystarczy zainstalować plug-in do przeglądarki, dzięki któremu, przeglądarka będzie identyfikowała adresy DOI zgodnie z protokołem Handler. Dostępny obecnie plug-in obsługuje jedynie przeglądarki Netscape i Microsoft Internet Explorer. Do tworzenia własnych bibliotek elementów, opisywanych przez identyfikatory cyfrowe należy zainstalować Java Development Kit konieczny do działania platformy Java, Handle Server oraz Handle System Client Library. W trakcie instalacji konieczne okaże się uzyskanie własnego numeru identyfikacyjnego, który zostanie przydzielony po przesłaniu pod odpowiedni adres, pliku wynikowego jednego z kroków konfiguracji. Po zainstalowaniu pełnej wersji serwera użytkownik uzyska możliwość tworzenia własnych znaczników (handle) do usług (WWW, FTP czy poczta elektroniczna). Zasada działania systemu: 1. Użytkownik uzyskuje identyfikator żądanego elementu ze strony internetowej, CD-ROMu lub dowolnych materiałów reklamowych, wpisuje go w przeglądarce internetowej (lub innym dedykowanym programie) i wysyła do odpowiedniego serwera. 2. Serwer wyszukuje identyfikator DOI w tablicy gromadzącej identyfikatory, odczytuje skojarzony adres internetowy i wysyła go do użytkownika. 3. Przeglądarka użytkownika wysyła zapytanie pod adres otrzymany od serwera DOI. W większości przypadków DOI będzie odnośnikiem na stronie HTML zachowującym się tak samo jak tradycyjny odsyłacz internetowy. Każdy klient zna lokalizację lub ma kopię globalnego systemu rejestracji, który przechowuje globalne informacje na temat kluczy publicznych. Na rysunku 2 pokazano przykładową stronę internetową wykorzystującą znaczniki DOI, strzałkami zaznaczono odsyłacz DOI na stronie oraz obiekt docelowy na pasku statusu przeglądarki. Rys. 2. Odsyłacz DOI (strzałka) na stronie HTML Sposób identyfikacji i dostępu do obiektów cyfrowych pokazany jest na rysunku 3. Klient (np. przeglądarka internetowa) wysyła żądanie adresu związanego z identyfikatorem do serwera proxy w swojej sieci lokalnej. Serwer proxy najpierw sprawdza czy identyfikator nie odnosi się do zasobów lokalnych, a następnie przesyła żądanie do systemu rejestracji i przetwarzania znaczników. System ten odpowiada wysyłając przez serwer proxy do klienta odpowiedni adres Internetowy. Po uzyskaniu adresu klient łączy się z nim bezpośrednio i uzyskuje żądany zasób. Globalny system rejestracji i rozpoznawania znaczników handle DOI: 10.789/abc 10.123/789=http://local/abc.html Sieć lokalna Zasoby lokalne Proxy http://www.pub.com/abc.html DOI: 10.789/abc http://www.pub.com/abc.html www.pub.com DOI: 10.789/abc abc.html Klient lokalny Rys. 3. Sposób identyfikacji i dostępu do obiektów cyfrowych Rysunek 4 przedstawia sposób interpretacji znacznika handle. Znacznik może być skojarzony z kilkoma adresami URL (wybór któregoś z nich będzie odbywał się według zdefiniowanego sposobu np. odległość serwera ). Może być również powiązany z systemem DLS (Digital Library System) lub z dowolną zestandaryzowaną usługą, co otwiera możliwości w korzystaniu z nowych usług internetowych. Handle Typ danych 10.1004/abcde123456 Dane handle URL http://www.pub1.com URL http://www.pub2.com DLS loc/repository Rozszerzalne typy danych Identyfikator zawartości (nazwa) XYZ 1010101011000 Usługi cyfrowe Rys.4. Sposób interpretacji znaczników ZASADY TWORZENIA METADANYCH W DOI Metadane [3] (wg definicji Duane Harbin art. http://www.atla.com/refdes/diktuon/dikt0299.html) są to uporządkowane, strukturalne dane opisujące inne dane. Wszelkiego rodzaju indeksy czy katalogi są doskonałym przykładem metadanych. Podstawowym ich przeznaczeniem jest przekierowywanie użytkownika do danych właściwych. Jednak znaczenie metadanych może być daleko szersze i na przykład opisywać one mogą pewien specyficzny format pliku – wskazując na przeznaczenie każdego bitu danych w pliku oraz jego kontekst. Tak więc w ogólności metadane należy uznać jako zbiór informacji określających zawartość. Grupowanie obiektów czy informacji jako spełniających te same kryteria może być przeprowadzane w różny sposób, zależnie od potrzeb. Dla przykładu jedno wydrukowane wydanie czasopisma (wielotysięczny nakład) może być w pewnych przypadkach traktowane jako pojedynczy egzemplarz. Odwoływanie się do konkretnego zdjęcia na określonej stronie czasopisma, traktowane będzie tak samo jak odwołanie do całego wydania, natomiast aby przeczytać czasopismo trzeba sięgnąć po ściśle określoną kopię wersji drukowanej. Tak więc jeden identyfikator nie może obsłużyć wszystkich zastosowań chociażby z tego względu, że grupowanie może następowac po różnych elementach (raz identyfikować klasę a raz określony element klasy). Do tego potrzebna jest cała sieć identyfikatorów, a związki pomiędzy nimi wyrażone muszą być poprzez odsyłacze. Metadane określają właśnie element w wymagany sposób. Nie wystarczy więc przypisać identyfikatora do obiektu bez określenia czym jest ten obiekt i jakiego jest on typu, lecz wskazać te informacje w elemencie stowarzyszonym – jako metadane. Metadane powinny być utworzone w sposób nieskomplikowany (pozwalający na łatwe odczytywanie i operowanie poszczególnymi elementami) oraz zgodny z przyjętym modelem, aby zapewnić poprawne wyrażanie związków pomiędzy poszczególnymi elementami metadanych. Każdy schemat metadanych posiadać musi określoną liczbę elementów, określone z góry nazwy elementów oraz znaczenia poszczególnych elementów. Typowo semantyka opisuje rodzaj zawartości i kontekst, fizyczne atrybuty, typy (np. tekst lub obraz, mapa lub model), formy (np. kopia drukowana, plik w wersji elektronicznej) itp. Niektóre popularne schematy metadanych to np.: → Dublin Core, → AACR2 (Anglo-American Cataloging Rules), → GILS (Government Information Locator Service). Kiedy używany będzie odpowiedni identyfikator obiektu cyfrowego, stowarzyszone z nim metadane będą włączane do informacji o zasobach. Kluczowym zastosowaniem metadanych jest wskazywanie, czy określony element spełnia warunki poszukiwania poprzez udostępnienie w formie łatwej do odczytania podstawowych informacji o elemencie. Informacje opisowe nie mogą być przenoszone poprzez sam identyfikator, natomiast są właśnie zawarte w stowarzyszonymi z nim metadanymi. Pozwala to na sprawdzenie czy wybrany element jest żądanym bez potrzeby wchodzenia w bezpośrednią zawartość. Dla przykładu przy wyszukiwaniu książek poprzez numery ISBN przydatne będą stowarzyszone dane jak np. tytuł czy nazwisko autora. Pomimo istnienia standardów identyfikatorów stowarzyszonych z metadanymi, nie zawsze zapewniają one strukturę wymaganą dla potrzeb systemu i trwają jeszcze dyskusje nad koniecznością wyspecyfikowania nowych standardów zapewniających prawidłowe rozpoznawnie i identyfikację metadanych. Identyfikator musi deklarować metadane, które w sposób nieskomplikowany będą definiowały identyfikowany element, a z drugiej strony aby element mógł być rozpoznany na podstawie opisujących go metadanych. Nie jest wymagane aby przechowywać metadane wewnątrz systemu DOI; wystarczy, że poprzez DOI określony zostanie wskaźnik do deklaracji metadanych. Jest jeszcze wiele innych zastosowań metadanych. Mogą one dla przykładu zawierać małą część informacji (np. abstrakt), dostepną za darmo, przeznaczoną jako reklama kompletnego elementu o dostępie chronionym (cały artykuł). Poza tym posługiwanie się metadanymi pozwala użytkownikowi bardziej precyzyjnie określić rodzaj zawartości, której poszukuje. Metadane pozwalają również zidentyfikować, czym jest to co użytkownik wyszukał w sieci oraz określić związki pomiędzy poszczególnymi częściami zawartości. Wprowadzenie metadanych do systemu DOI ma na celu m.in.: → ochronę praw autorskich, → rozpropagowanie systemu, → budowanie usług dodanych opartych o DOI, → wprowadzenie pętli zwrotnej do systemu DOI pozwalającej odszukać określony DOI, → uzupełnianie istniejących usług wyszukiwania i indeksowania (A&I – Abstracting and Indexing). Wykorzystanie metadanych w systemie pozwoli także na kontrolę efektywności wykorzystania identyfikatorów oraz wprowadzenie zarządzania jakością w przyszłości. Na rysunku 5 pokazano sposób gromadzenia i przepływ metadanych. DOI i Metadane Lista prefixów Nośniki CD Metadane Rejestracja Rejestracja usług usług DOI DOI Dane handle Metadane DOI Inne serwisy danych Dodatkowe indeksy, filtry, zapytania Handle System Rys. 5. Gromadzenie i przepływ metadanych PODSUMOWANIE Internet w większości zawiera nieuporządkowaną informację. Dostęp poprzez URL nie spełnia wymagań korzystania z bibliotek cyfrowych. System DOI (Handle System) posiada wiele przydatnych cech zwiększających funkcjonalność Internetu. Można mieć nadzieję, że stanie się internetowym ISBN XXI wieku. W pierwszej kolejności z systemu identyfikatorów obiektów cyfrowych korzystają największe oficyny wydawnicze, które wymagają śledzenia położenia tysięcy dokumentów, w tym wielu osiągalnych poprzez sieć. Zmiana położenia plików, przy tak wielkiej liczbie dokumentów powodowałaby konieczność ciągłej zmiany odnośników na stronach internetowych danego wydawnictwa lub wielokrotne wyświetlanie strony informującej o przekierowaniu w przeglądarce użytkownika. Wykorzystanie systemu DOI pozwala aktualizować jedynie centralny katalog i nie stwarza konieczności dokonywania jakichkolwiek zmian na stronach internetowych w związku ze zmianą położenia plików docelowych. „Handle System” ułatwi wprowadzenie wielu usług np. globalnego cache’u, typu zaimplementowanego przez firmę Akamai. Będzie on miał duże znaczenie dla trybu korzystania z baz danych. Niestety Handle System rozwija się niezależnie od systemów typu Akamai, jak również systemów, zarządzania archiwizacji i indeksowania danych multimedialnych MPEG-7. Implementacja systemu DOI pociągnie za sobą pewne koszty: → rozwój i standaryzacja systemu, → utrzymanie infrastruktury systemu rejestracji i identyfikacji zasobów, rejestracji metadanych. Koszt ten powinien być ponoszony przez wydawców a nie przez użytkowników końcowych, chociaż może być na nich przenoszony w postaci opłat za korzystanie z treści. BIBLIOGRAFIA [1] Ford&Harter College and Research Libraries, lipiec 1998 [2] Norman Paskin „Slide presentation: Digital Object Identifier”, http://www.doi.org/about_doi/index.htm, luty 1999 [3] Norman Paskin "Digital Object Identifier: implementing a standard digital identifier as the key to effective digital rights management", http://www.doi.org/doi_presentations/aprilpaper.pdf, kwiecień 2000 [4] Norman Paskin "The DOI Handbook Version 0.4.1” , http://www.doi.org/handbook_2000/index.html, czerwiec 2000 [5] Sam X. Sun, Larry Lannon: “Handle System Overview”, http://www.ietf.org/internetdrafts/draft-sun-handle-system-04.txt, luty 2000 [6] Sam X. Sun, Larry Lannon: “Handle System Namespace and Service Definition”, http://www.ietf.org/internet-drafts/draft-sun-handle-system-02.txt , luty 2000