Stanowisko ISOC Polska dotyczące projektu Krajowych Ram Interoperacyjności

W odpowiedzi na zaproszenie do konsultacji Stowarzyszenie ISOC Polska przekazało swoje uwagi do przesłanego projektu uchwały Rady Ministrów w sprawie ustanowienia Krajowych Ram Interoperacyjności oraz sugestie do przyszłych prac nad nowymi wersjami rozporządzeń Rady Ministrów: z 11 października 2005 r. w sprawie minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej (Dz.U. nr 214/2005, poz. 1781) oraz z 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. nr 212/2005, poz. 1766)

Warszawa, 1 października 2007 r.

Uwagi dotyczące projektu Krajowych Ram Operacyjności

Ramy prawne KRI
Proponowana treść KRI zawiera elementy zasługujące na uregulowanie ustawowe, ale brak jest ustawowych podstaw dla takiego aktu. Rząd stara się wypełnić tę lukę proponując nadanie KRI rangi uchwały Rady Ministrów. Zawarte w takiej uchwale wytyczne będą jednak obowiązywać jedynie jednostki i instytucje wchodzące w skład lub podległe administracji rządowej. Z zadowoleniem witając przygotowanie przez Rząd projektu KRI sugerujemy wykorzystanie jego treści oraz wyników obecnych konsultacji do przygotowania założeń projektu odpowiedniej ustawy lub nowelizacji istniejących ustaw.

Europejski kontekst KRI
Ogólnoeuropejskim wzorcem dla KRI są zalecenia EIF 1.0. Nie są one obecnie obowiązującą u Unii Europejskiej normą prawną (dyrektywą), ale są podstawą zasad interoperacyjności wprowadzonych w wielu krajach UE oraz są zgodnie zalecane przez Komisję Europejską i Parlament Europejski w uchwale z 24 maja 2007. Słusznie więc projekt polskich KRI nawiązuje do EIF i zaleca stosowanie się do sugerowanych w nich zasad i standardów. W szczególności z zadowoleniem witamy wpisanie w projekt KRI zgodnej z EIF definicji otwartego standardu i cieszy nas, że rząd zdecydował się przedstawić projekt KRI nie czekając na wynik toczonych się w różnych organach Unii debat nad propozycjami rozwinięcia i aktualizacji zaleceń EIF.

Definicja neutralności technologicznej
Proponowana w projekcie KRI definicja neutralności technologicznej zawiera wymogi sformułowane niejasno i niejednoznacznie, a więc trudno zweryfikować ich spełnienie.

Dla przykładu wymóg "ograniczenia możliwości utajniania" nie określa stanu wzorcowego, w stosunku do którego możliwości te mają być ograniczone, ani wymaganego zakresu ograniczenia. Z kolei zakaz "uniemożliwienia powstania konkurencyjnych produktów" może być różnie interpretowany w przypadkach, w których powstanie takich produktów jest teoretycznie możliwe, ale ze względu na uciążliwość, czas i koszty wymagane do pozyskania koniecznych informacji oraz ukryte bariery wejścia na rynek praktycznie niewykonalne. Sytuacje takie dobrze znamy z praktyki.

Zakaz narzucania rozwiązań technologicznych, gdy istnieją rozwiązania konkurencyjne, tylko pozornie jest oczywistym elementem zasady neutralności technologicznej. W polskim i europejskim systemie prawnym można wskazać setki przykładów, w których dla zapewnienia szeroko pojętej interoperacyjności władza państwowa narzuca stosowanie jednego z wielu możliwych rozwiązań. Przykładami mogą być normy regulujące ruch drogowy, lotniczy, morski i kolejowy oraz sieci telekomunikacyjne w obszarze telewizji i telefonii.

Proponowany przez KRI bezwzględny zakaz narzucania rozwiązań technologicznych musiałby więc być stosowany wybiórczo lub pozbawiałby Państwo możliwości narzucania wymaganych standardów nawet w zakresie, w których jest to konieczne ze względów bezpieczeństwa lub stanowi niezbędną przesłankę użyteczności danej usługi - na przykład w obszarze powszechnego podpisu elektronicznego lub numeracji kont bankowych.

Sądzimy, że w definicji neutralności zakaz ten powinien mieć charakter zalecenia: "unikanie narzucania określonych rozwiązań technologicznych w sytuacji, gdy istnieją rozwiązania konkurencyjne, a narzucenie jednego rozwiązania lub normy nie jest niezbędne ze względów bezpieczeństwa lub nie jest niezbędnym warunkiem efektywnego stosowania któregokolwiek z konkurujących rozwiązań". W tym miejscu widzimy rolę otwartych standardów, które projekt KRI definiuje bez wskazania obszaru, w którym standardy takie muszą być stosowane. W naszym przekonaniu w każdym przypadku, w którym Państwo uznaje za nieuniknione wybranie i narzucenie jakiejś normy, powinna ona być opracowana i dostępna jako otwarty standard zgodny z definicją EIF.

Rola neutralności technologicznej i otwartych standardów
Na tym tle dziwi ostatni akapit drugiej części KRI, w którym z jednej strony zawarta jest słuszna prognoza, że otwarte standardy są przyszłością rozwiązań informatycznych administracji publicznej, ale w bezpośrednio następujących po tej prognozie zdaniu sformułowana jest opinia, że obecnie stosowanie otwartych standardów wiąże się z „zagrożeniem znaczącego spowolnienia lub zablokowania procesu udostępniania usług publicznych” i na tej podstawie dopuszcza się współistnienie w warunkach konkurencji wielu standardów, w tym zamkniętych oraz określonych jako „częściowo otwarte” - to pojęcie wydaje się wewnętrznie sprzeczne i przypomina opisywanego przez Bułhakowa "jesiotra drugiej świeżości" lub pamiętane przez wielu z nas standardy "demokracji ludowej".

Prosimy o usunięcie tego zdania z KRI i nadanie wymogowi stosowania otwartych standardów takiej samej rangi, jak wymogowi przestrzegania neutralności technologicznej. Wymogi te bowiem w istocie wzajemnie uzupełniają się i nie mogą istnieć niezależnie. Stosowanie otwartych standardów jest warunkiem dla praktycznego wdrożenia neutralności technologicznej, a z drugiej strony neutralność pozwala na pełne wykorzystanie możliwości stwarzanych przez otwarte standardy.

Otwarte standardy a ryzyko opóźnień
W szczególności uważamy za bezpodstawną zawartą w pierwszej części omawianego zdania tezę, że „wymóg stosowania otwartych standardów stwarza zagrożenie spowolnienia udostępniania usług publicznych”. Trudno bowiem nazwać udostępnioną usługę publiczną, skorzystanie z której możliwe jest tylko za pomocą zamkniętego standardu. Usługa taka może być określona jedynie jako „dostępna dla uprzywilejowanych”, co zaprzecza całej idei KRI. Praktyka dowodzi, że znacznie łatwiej jest wprowadzić niezbędne do pełnego udostępniania każdej usługi zmiany na etapie jej projektowania niż po jej uruchomieniu, podobnie jak łatwiej jest zaprojektować obiekt architektoniczny dostępny dla niepełnosprawnych niż dobudować odpowiednie ułatwienia do gotowej budowli. Jeśli więc nawet wymóg stosowania otwartych standardów opóźniłby wdrożenie jakichś źle zaprojektowanych usług, to w sumie przyspieszyłoby udostępnienie usługi dobrze zaprojektowanej i rzeczywiście powszechnie dostępnej.

Poziomy interoperacyjności
W trzeciej części projektu KRI zdefiniowano różne poziomy interoperacyjności. Znamy wiele podobnych klasyfikacji i łatwo podać zarówno przykłady uzasadniające wybrany podział na poziomy, jak i przykłady usług, które w wybrany podział jest bardzo trudno wpisać. Ogólnie uważamy za pożyteczne objaśnienie modelu, będące podstawą rozważań autorów KRI, choć nie jesteśmy pewni, czy tego rodzaju klasyfikacja wymaga wprowadzenia w dokumencie o randze uchwały Rady Ministrów lub ustawy.

Nie całkiem rozumiemy jednak uwagę, że KRI zasadniczo dotyczą poziomu zadaniowego. Trudno sobie bowiem wyobrazić, by na poziomach określonych jako technologiczny i systemowy można było zrezygnować ze stosowania zasad neutralności technologicznej i wymogu stosowania otwartych standardów.

Klasyfikacja usług publicznych
Nie mamy żadnych zastrzeżeń do przedstawionej w części 4.1 projektu KRI klasyfikacji usług publicznych. Uważamy za potrzebne i celowe uzgodnienie pojęć, stosowanych w tym obszarze, a zaproponowany podział usług na podstawowe i złożone wydaje się zrozumiały i uzasadniony.

Certyfikacja usług podstawowych
Rozumiemy przesłanki, które prowadzą do opisanego w części 4.2 zalecenia stworzenia systemu certyfikacji usług podstawowych, nie rozumiemy jednak celu ogólnikowego wpisywania tego postulatu w dokumencie o randze uchwały Rady Ministrów. Skoro zdaniem Rady Ministrów konieczne jest powołanie organu certyfikującego i nadanie mu odpowiednich uprawnień władczych, to można to osiągnąć jedynie przez odpowiednią inicjatywę ustawodawczą, a nie przez uchwalanie postulatów i zaleceń, których adresatem jest sam wydający te zalecenia organ.

Od strony merytorycznej widoczne jest, że trudno będzie pogodzić rolę i uprawnienia organu certyfikacyjnego z praktycznym stosowaniem zasady neutralności technologicznej, zwłaszcza wobec rozwiązań opartych na zasadach wolnego i otwartego oprogramowania, które mogą natrafić na barierę kosztów procesu certyfikacji.

Uwagi dotyczące rozporządzenia Rady Ministrów z 11 października 2005 r. w sprawie minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej (Dz.U. nr 214/2005, poz. 1781)

Rozporządzenie to w ciągu 2 lat swego obowiązywania nie budziło sporów ani poważniejszych problemów w jego stosowaniu, a więc można powiedzieć, że w zakresie zawartej w nim treści sprawdziło się. Trudno jednak nie zauważyć, że jest ono bardzo lakoniczne i istotnie - zgodnie z tytułem - określa jedynie zupełnie minimalny zakres wymagań.

Spotkaliśmy się z sugestiami, aby obecną treść rozporządzenia, definiującą pola w formie struktur danych typowych dla wymiany informacji między bazami danych, uzupełnić równoległym opisem tych samych pól informacyjnych w formie Schemy XML, a więc w formie typowej dla wymiany komunikatów w ramach np. usług sieciowych. Uważamy tę propozycję za interesującą i wartą rozważenia, ale nie jest niezbędne wpisywanie jej w tekst rozporządzenia - zupełnie wystarczy opublikowanie odpowiedniej zgodnej z rozporządzeniem schemy przez organ odpowiedzialny za wdrażanie rozporządzenia.

Z naszej praktyki wdrażania usług publicznych znamy drobne problemy z opisanym w rozporządzeniu formatem adresu, dostosowanym do praktyki budowy adresów w miastach. W obszarach wiejskich typowa tradycyjne forma adresu zawiera w polu "miejscowość" nazwę miejscowości, w której ulokowany jest najbliższy urząd pocztowy, a właściwa nazwa miejscowości lub jej części (przysiółka lub osiedla) umieszczana jest w polu "nazwa ulicy". Powszechność tej tradycji powoduje liczne trudności w interpretowaniu adresów zawartych w bazach adresowych. Wydaje się celowe uzupełnienie powszechnie stosowanego formatu adresu o jednoznaczne wyjaśnienie, jak należy stosować go na obszarach wiejskich w przypadku miejscowości nie mających własnej placówki pocztowej i podziału na ulice.

W świetle obecnych prac nad wdrożeniem rejestru PESEL 2 i systemu rejestrów referencyjnych wydaje się celowe ponowne rozważenie zakresu pól opisanych w rozporządzeniu. Dla przykładu mamy wątpliwości, czy do minimalnego zakresu podstawowych identyfikatorów podmiotu gospodarczego należy zaliczać równolegle identyfikatory REGON, NIP i KRS. Przynajmniej jeden z nich wydaje się zbędny.

Z drugiej strony rozporządzenie obejmuje tylko jeden identyfikator obywatela, czyli PESEL (oraz NIP w zakresie, w których obywatel jest zarazem podmiotem gospodarczym), a równocześnie powszechna jest praktyka równoległego żądania podania numeru dowodu osobistego, imion rodziców i miejsca urodzenia, często uzupełniana przez wymóg podania numerów z innych rejestrów (numer prawa jazdy, identyfikatory ZUS i NFZ, nuemru legitymacji studenckiej lub służbowej itp) oraz nazwiska panieńskiego matki. Sądzimy, że rozporządzenie powinno jednoznacznie określać minimalny zestaw danych koniecznych do identyfikacji obywatela i zakazywać gromadzenia i przetwarzania dodatkowych identyfikatorów, jeśli nie są one niezbędne do realizacji odpowiedniej usługi lub procedury administracyjnej.

W ostatnich miesiącach z inicjatywy Instytutu Sobieskiego trwała debata publiczna na temat zakresu ingerencji w prywatność nieuniknionego dla stworzenia spójnego i sprawnego systemu rejestrów. Uważamy, że wiele uwag Instytutu zasługuje na rozważenie i w związku z tym może być celowe jasne zapisanie w rozporządzeniu, że żądanie od obywatela lub przetwarzanie jakichkolwiek danych osobowych wykraczających poza określony w rozporządzeniu zakres minimalny wymaga akceptacji organu odpowiedzialnego za ochronę prywatności i danych osobowych.

Uwagi dotyczące rozporządzenia Rady Ministrów z 11 października 2005 r. w sprawie w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. nr 214/2005, poz. 1781)

Rozporządzenie to w ciągu 2 lat swego obowiązywania stało się przedmiotem wielu sporów i dyskusji, które między innymi doprowadziły do skierowania do Ministra przez wiodącą branżową izbę gospodarczą prośby o wyjaśnienie znaczenia używanych w nim kluczowych pojęć, a przedstawiona przez Ministra odpowiedź bynajmniej nie zakończyła sporów i nie wyjaśniła wątpliwości
(opis historii sprawy można znaleźć w serwisie VaGli pod adresem http://prawo.vagla.pl/node/5866).

Ograniczony wpływ na praktykę
Równocześnie odnosimy wrażenie, że wpływ rozporządzenia na praktykę administracyjną, gospodarczą i społeczną był co najwyżej marginesowy. Niejasność zawartych w nim zaleceń powodowała, że praktycznie każde proponowane i wdrażane rozwiązanie informatyczne można było opisać jako zgodne z jakąś interpretacją rozporządzenia. Równocześnie resort odpowiedzialny za nadzór nad wykonaniem rozporządzenia w ciągu dwóch lat ani razu nie odwołał się do niego w praktyce administracyjnej, a w debatach nad innymi rozporządzeniami (na przykład nad nową wersją BIP) otwarcie przyznawał, że obowiązującą wersję rozporządzenia uważa za tymczasową i konstrukcyjnie wadliwą (http://meta.bip.gov.pl/forum/) umocniło to opinie, że rozporządzenie to nie ma praktycznego znaczenia i nie wywołuje realnych skutków. W swoim raporcie MSWiA (http://prawo.vagla.pl/node/7406) pisze „obecnie brak jest w aktach prawnych wskazanego organu, którego obowiązkiem i uprawnieniem byłoby nadzorowanie wywiązywania się podmiotów wskazanych w
art. 4 ust. 1 i 2 UDIP z obowiązku prowadzenia stron podmiotowych BIP”.

Warto przypomnieć, że ustawa wprowadziła "system kontroli", który wynika z rozdziału 4 ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne, w szczególności
z art. 25 ust. 1 pkt 3. Do tej pory ten system "kontrolerów wyznaczonych przez organ dokonujący kontroli" nie działa, nie wyznaczono kontrolerów i nie realizują oni celu ustawy.

Na tym tle nie możemy zgodzić się z pojawiającymi się w publicznej debacie postulatami, aby zmiany w treści rozporządzenia odłożyć do czasu, gdy zakończą się obecnie przygotowywane lub realizowane projekty. W każdym momencie będą w realizacji jakieś projekty, przygotowane przed dniem wejścia w życie nowej wersji rozporządzenia. Odpowiednie potraktowanie takich przypadków jest zadaniem przepisów przejściowych, które muszą określić od kiedy zmienione wymagania obowiązują i jakiej fazy projektów dotyczą (definiowanie specyfikacji, formułowania SIWZ, wymagań umownych, obowiązku dostosowania istniejących rozwiązań do czasu upływu określonego okresu przejściowego itp.).

Ogólne problemy
Dostrzegamy trzy podstawowe powody kłopotów z interpretacją i stosowaniem tego rozporządzenia:

1. Niedoskonała i niejasna delegacja ustawowa. Ustawa powołuje się na neutralność technologiczną oraz otwarte standardy jako główne sposoby jej wprowadzenia, a równocześnie nigdzie nie definiuje tych pojęć i nie określa sposobu, w jakim mają być one stosowane. Nie wydaje nam się możliwe przeniesienie tych treści do aktu prawnego niższego rzędu, w tym wydanego na podstawie ustawy rozporządzenia (zresztą delegacja ustawowa nie dopuszcza takiej możliwości) lub samoistnej uchwały Rady Ministrów. Bez sprecyzowania celów delegacji ustawowej oraz podstawowych pojęć używanych w ustawie wydanie dobrze realizującego tę delegację rozporządzenia wydaje się bardzo trudne lub wręcz niemożliwe.

2. Niejasne sformułowania w treści rozporządzenia. Określenia obszarów, usług i działań, w których muszą być stosowane wymienione w nim standardy są nie dość precyzyjne. Nie określono, jak należy rozumieć wymienione w każdym obszarze listy standardów i formatów danych, na przykład czy i w jakim zakresie dopuszczalne jest stosowanie i wymaganie - obok standardów i formatów danych wymienionych w rozporządzeniu - również innych, nie wymienionych w rozporządzeniu?

Innym rodzajem niejasności, często występującym w rozporządzeniu jest brak wskazania wersji lub definicji standardów lub formatów, określanych jedynie przez podanie ich nazwy lub tradycyjnie używanego przez nie rozszerzenia nazwy plików w systemach operacyjnych firmy Microsoft. Równocześnie dla innych wymienionych w rozporządzeniu standardów wskazane jest konkretna ich wersja bez sprecyzowania, czy dopuszczalne jest stosowanie późniejszych, wcześniejszych i specjalizowanych odmian danego standardu lub formatu.

Przykłady i uzasadnienie tej opinii przedstawiamy niżej, omawiając szczegółowo poszczególne sekcje rozporządzenia.

3. Brak odpowiedniego aparatu pojęciowego (którego istotną częścią powinny być treści, które rząd proponuje zawrzeć w projekcie KRI) powoduje powszechne niezrozumienie, do jakich działań należy stosować zawarte w rozporządzeniu normy i jak je wdrażać. Dotyczy to także sposobu postępowania w stosunku do już wdrożonych i stosowanych rozwiązań, które nie są w pełni zgodne z wymaganiami rozporządzenia.

Wiąże się z tym brak precyzyjnego określenia statusu wymienionych formatów. Które z nich rozporządzenie traktuje jako otwarte? Które należą do grupy wychodzących z użycia i dopuszczalnych jedynie przejściowo (do kiedy?), a które będą dopuszczalne lub będą obowiązywać w przyszłości (od kiedy?). Czy są jakieś rozwiązania, których stosowanie nie tylko nie wypełnia wymagań minimalnych, ale jest wręcz niedopuszczalne ze względu na bezpieczeństwo lub dyskryminowanie pewnych kategorii użytkowników? Czy sposób stosowania standardów musi być zgodny z wymogami dostępności dla niepełnosprawnych (WAI)?

Szczegółowe uwagi i postulaty:

1. Załącznik 1 sekcja 1

Z uwagi na powszechne stosowanie standardu IPv4 we wszelkich formach teletransmisji określony w tym punkcie wymóg spełniony jest praktycznie przez każdy możliwy do pomyślenia system. Równocześnie stosowanie pozostałych wymienionych w tej sekcji protokołów i standardów (TCP, UDP, IMCP i HTTP 1.1) nie jest w praktyce możliwe bez równoczesnego użycia protokołu IP, a więc w świetle warunku "co najmniej jeden z wymienionych" wymienianie ich jest działaniem nadmiarowym.

Równocześnie treść tej sekcji pozostawia bez odpowiedzi istotne pytanie o dopuszczalność i przyszłą wymagalność stosowania protokołu IPv6. Wydaje się niemożliwe powszechne wdrożenie tego standardu bez inicjatywy i interwencji regulacyjnej Państwa. Równoczesne stosowanie w sieciach teletransmisyjnych standardu IP w wersji 4 i 6 jest możliwe, ale na tyle kłopotliwe, że wdrażanie wersji 6 w w praktyce nie postępuje.

Proponujemy wydzielenie protokołu będącego podstawą transmisji pakietowej w osobną sekcję i określenie jako minimalnego wymogu stosowania protokołu IP w wersji 4 lub 6 z dodaniem wymogu, by wszystkie nowo wdrażane usługi były przygotowane do pracy z protokołem IP w obu wersjach, co oznacza wykluczenie uzależniania działania usług od treści elementów formatu adresu IPv4 oraz od powszechnie stosowanych rozwiązań translacji adresów IPv4 w sieciach lokalnych (NAT).

Podobna uwaga w mniejszym stopniu dotyczy protokołu HTTP. Czy stosowanie go w wersji HTTP 1.0 oznacza niezgodność z minimalnymi wymaganiami? Wersja ta jest już rzadko spotykana, ale zupełnie wystarcza do poprawnego wdrożenia wielu usług, a równoległe obsługiwanie obu wersji nie powoduje żadnych problemów ani po stronie serwerów, ani powszechnie używanych klientów (przeglądarek). Proponujemy zapis „"HTTP 1.0 lub nowszy".

W punkcie tym nie wymieniono żadnego protokołu routingu (BGP) i wymiany danych między operatorami sieci szkieletowych - dla przykładu nie zawiera ono żadnej wskazówki dla operatora, który musi wybrać standard MPLS w wersji opracowanej przez IETF lub ITU, aby przytoczyć tylko przykład ostatnich debat w tym zakresie.

2. Załącznik 1 sekcja 2

Odbieranie i wysyłanie poczty są osobnymi operacjami – istnieją systemy, które służą tylko do wysyłania poczty lub tylko do odbierania. Jeśli więc już definiujemy listę standardów, z których co najmniej jeden musi być obsługiwany, to warto rozdzielić ją na osobną listę metod wysyłania poczty oraz jej odbierania. W przypadku SMTP warto określić, jakie konkretnie warianty i rozszerzenia tego protokołu są wymagane (ESMTP?).

W praktyce wielu użytkowników ma ograniczoną możliwość wyboru pomiędzy korzystaniem z POP3 i IMAP, a więc zasadne wydaje się wprowadzenie wymogu, aby w wymianie poczty operator serwera dopuszczał stosowanie obu rozwiązań.

Równocześnie rozporządzenie całkowicie pomija powszechną obecnie praktykę udostępniania i obsługiwania poczty wyłącznie lub głównie przez przeglądarkę WWW. Czy taka praktyka jest i powinna być dopuszczalna w świetle rozporządzenia?

3. Załącznik 1 sekcja 3

Obok wymienionych w tej sekcji protokołów powszechnie stosuje się inne protokoły bezpiecznego uwierzytelniania i wymiany szyfrowanych danych, a najpopularniejszym z nich wydaje się SSH i oparte na nim protokoły wymiany plików takie jak SFTP. Czy wymaganie ich jest zabronione? W praktyce oznaczałoby to odrzucenie powszechnie stosowanego sposobu bezpiecznego dostępu do serwerów.

Powszechnie stosowane są także różne sposoby udostępniania bezpiecznych kanałów VPN oraz bezpiecznego transferu informacji pomiędzy bazami danych, które nie są oparte na SSL i S/MIME.

4. Załącznik 1 sekcja 4

Wymieniona w tej sekcji usługa DNS należy do zupełnie innej kategorii niż pozostałe wymienione w niej standardy. Co prawda technicznie możliwe jest używanie pozostałych wymienionych w tej sekcji protokołów z zastosowaniem wyłącznie adresowania przez numery IP, ale w praktyce rozwiązanie takie jest kłopotliwe i stosowane jedynie w wyjątkowych przypadkach.

Proponujemy więc wydzielenie protokołów używanych do identyfikacji sieciowej w osobną sekcję i wymienienie w niej - obok DNS - standardu stosowania znaków narodowych w nazwach internetowych IDN wraz z określeniem, jakie usługi i od kiedy muszą dopuszczać stosowanie znaków narodowych w nazwach internetowych.

Podobnie jak przypadku sekcji 1, wymienienie w tej sekcji usługi DNS powoduje, że wymóg stosowania co najmniej jednego z opisanych w niej standardów jest zawsze spełniony, warto jednak zauważyć, że do tranferu plików obok FTP powszechnie stosowane są inne protokoły, takie jak bezpieczny protokół SFTP i jego odmiany. Powszechnie także używa się w tym celu innych usług, w tym protokołu HTTP oraz różnych wersji komunikatorów. Nie potrafimy więc odczytać intencji autorów rozporządzenia: czy instytucja umożliwiająca pobieranie lub przekazywanie plików za pomocą protokołu HTTP musi równolegle udostępniać możliwość ich transferu przez FTP? Czy dopuszczalne jest udostępnianie plików przez komunikatory? Czy jest wreszcie dopuszczalne wskazywanie adresów usług P2P, na przykład w systemie Torrent?

5. Załącznik 1 - brakujące sekcje

W rozporządzeniu nie da się wymienić minimalnych wymagań dla wszelkich możliwych i używanych usług. Niektóre z pominiętych usług są jednak na tyle powszechne, a zarazem dotknięte problemami wynikającymi z braku jednolitego standardu, że zasługują na wzmiankę w rozporządzeniu. Należą do nich:

a. komunikatory. W Polsce dominuje zamknięta aplikacja Gadu-Gadu, a otwarty standard XMPP (Jabber) upowszechnia się bardzo powoli

b. udostępnianie plików multimedialnych. Znana jest rywalizacja różnych standardów, między innymi firm Real Networks, Apple i Microsoft. W tym obszarze istnieją też standardy otwarte, na przykład Ogg Vorbis (kodek audio). Otwartą specyfikację mają zarówno kontenery (MPEG, MP4/MOV, matroska), jak i kodeki (wideo: MPEG-1/2, XviD/Divx, H.264 i audio: AAC, MPEG-1 Layer 2/3 (mp2/3), AC3). Czy i który z nich jest zalecany lub wymagany?

c. telefonia internetowa. Rywalizuje tu wiele rozwiązań zamkniętych i otwarty standard SIP.

d. uwierzytelnianie. Czy stosowanie standardu OpenID jest dopuszczalne i wymagane?

6. Załącznik 2 sekcja 1

Czy dopuszczalne jest stosowanie Unicode w zapisie innym niż UTF-8, na przykład UTF-16, UTF-32 lub wręcz w pełnej, nie skróconej formie? Czy dopuszczalne jest przejściowe stosowanie formatu zapisu polskich znaków MIME ISO-8859-2 i w jak długim okresie przejściowym?

Prawdopodobnie konieczne jest bardziej precyzyjne zdefiniowanie wymagane formatu podpisu elektronicznego, ale mamy wątpliwości, czy nie jest zadaniem rozporządzeń wykonawczych do ustawy o podpisie elektronicznym.

7. załącznik 2 sekcja 2

Ta sekcja budzi w praktyce najwięcej wątpliwości.

Wśród dopuszczonych standardów wymieniony jest format .txt bez jakiegokolwiek wyjaśnienia, co rozszerzenie to zdaniem autorów rozporządzenia oznacza. Jak wiadomo tak zwane pliki tekstowe w różnych systemach operacyjnych i aplkacjach zapisywane są w wielu istotnie różnych formatach - dotyczy to przede wszystkim sposobu oznaczenia przejścia do nowego wiersza lub akapitu oraz sposobu kodowania polskich znaków, ale nie tylko. Proponujemy usunięcie tego formatu z tej listy.

Dalej na liście tej wymieniony jest format PDF w wersji 1.4. Czy oznacza to, że używając PDF w rozumianej przez przytłaczającą większość aplikacji uproszczonej wersji PDF/A trzeba równolegle udostępniać dokumenty w wersji PDF 1.4? Czy dopuszczalne jest stosowanie wyłącznie aktualnie obowiązujacej wersji 1.7, która została jako otwarty standard przekazana pod opiekę niezależnej organizacji standaryzacyjnej i zgłoszona do standaryzacji przez ISO? Proponujemy zapis „"PDF w wersji co najmniej PDF/A".

Jak należy rozumieć określenie "standard obowiązuje wyłącznie do odczytu dokumentu"? Każdy dokument, który ma zostać odczytany, musiał wcześniej zostać jakoś w danym formacie zapisany. Nie wiadomo, której strony wymiany dokumentów dotyczy to ograniczenie.

Ponadto dostępne są powszechnie i bezpłatnie liczne aplikacje pozwalające na tworzenie i zapis dokumentów w formacie PDF, a więc zasadne staje się pytanie, czy dopuszczalne jest akceptowanie przez organ administracji dokumentów dostarczanych przez obywateli w tym formacie? I czy akceptowanie dokumentów w tym formacie wystarczy, by spełnić wymagania rozporządzenia?

Podobne wątpliwości odnoszą się do następnego z wymienionych formatów, a więc .doc. Również w tym wypadku nie wskazano konkretnej wersji jednego z licznych formatów, które firma Microsoft stosowała z tym rozszerzeniem - na przykład pliki z rozszerzeniem .doc zapisuje dostarczana z systemem Windows 98 aplikacji MS Write. Pliki te nie są odczytywane przez żadną inną aplikację tego producenta. Ze względu na to, że w praktyce nie da się zapewnić możliwości odczytania każdego pliku zapisanego w tym formacie powinien być usunięty z tej listy. Nie wyklucza to akceptowania go równolegle z innymi, lepiej określonymi standardami.

Poważnym brakiem tej listy wydaje się natomiast pominięcie powszechnie używanego w tym celu formatu HTML.

8. załącznik 2 sekcja 3

Dopuszczono w niej tylko jeden format grafiki wektorowej, czyli SVG. Czy intencją prawodawcy było wprowadzenie wymogu, aby w każdej sytuacji, w której przekazywana jest grafika wektorowa, możliwe było jej przekazanie lub pobranie w tym formacie obok takich powszechnie stosowanych formatów, jak TeX lub PostScript?

9. załącznik 2 sekcja 4

Powszechnie krytykowane jest dopuszczenie w tej sekcji stosowanie formatu kompresji rar - format ten nie jest nie tylko zamknięty, ale w dodatku obsługujące go aplikacje są trudno dostępne dla uzytkowników wielu systemów operacyjnych.

10. załącznik 2 sekcja 5

Język opisu stylów CSS nie jest formatem, którego można używać zamiast języka opisu dokumentu (HTML lub XHTML), lecz jest jego uzupełnieniem.

Umieszczenie na tej liście protokołu WAP wydaje się nieporozumieniem, gdyż określa on protokół transmisji danych, a nie format stron WWW. Strona WAP nie jest stroną WWW.

W sekcji tej brakuje wzmianki o powstającym formacie HTML 5.

11. załącznik 2 - brakujące sekcje

Podobnie jak w przypadku załącznika 1, nie jest możliwe wyliczenie w rozporządzeniu wszystkich możliwych klas przekazywanych danych i ich formatów. Nie uzasadnia to jednak pominięcia wielu powszechnie stosowanych klas danych, w których różnorodność używanych formatów sprawia szczególne kłopoty. Należą do nich:

1. formaty plików multimedialnych: dźwięku i ruchomego obrazu
2. formaty animacji i prezentacji
3. formaty danych tabelarycznych i bazodanowych

W imieniu Zarządu ISOC

Władysław Majewski