Rozszerzenie NASK EPP
|
|
- Lech Włodarczyk
- 9 lat temu
- Przeglądów:
Transkrypt
1 Rozszerzenie NASK EPP Rozszerzenie NASK EPP... 1 Wstęp... 1 Statusy... 1 Operacje na domenach... 1 Operacje na kontaktach... 4 Opcje... 7 Raporty Historia zmian Wstęp Celem niniejszego dokumentu jest skrócony opis rozszerzeń wprowadzonych do protokołu EPP (Extensible Provisioning Protocol) przez NASK. Obowiązująca wersja EPP jest w pełni opisana w dokumentach IETF: Extensible Provisioning Protocol (draft-ietf-provreg-epp-07.txt) Extensible Provisioning Protocol Contact Mapping (draft-ietf-provreg-eppcontact-05.txt) Extensible Provisioning Protocol Domain Name Mapping (draft-ietf-provregepp-domain-05.txt) Extensible Provisioning Protocol Host Mapping (draft-ietf-provreg-epp-host- 05.txt) Statusy clientrenewprohibited ustawiony zapobiega automatycznemu odnowieniu domeny po upływie okresu utrzymywania domeny clienttransferprohibited użycie niedozwolone dla domen Operacje na domenach 1. <domain:create> a. opcjonalny element <reason> zawierający uzasadnienie prawa Registranta do nazwy domeny, b. opcjonalny element <book>, którego podanie oznacza żądanie zarezerwowania domeny, c. opcjonalny element <taste>, którego podanie oznacza żądanie stworzenia testów domeny (usługa Domain Name Tasting). Przykład komendy <domain:create> z elementem <book>: <create> NASK 2013 Strona 1
2 <domain:create xmlns:domain=" xsi:schemalocation=" domain-2.0.xsd"> <domain:name>example.pl</domain:name> <domain:period unit="y">1</domain:period> <domain:ns>ns1.example.pl</domain:ns> <domain:ns>ns1.example2.pl</domain:ns> <domain:registrant>nsk1234</domain:registrant> <domain:contact type="tech">nsk5678</domain:contact> <domain:authinfo> <domain:pw>2foobar</domain:pw> </domain:authinfo> </domain:create> </create> <extdom:create xmlns:extdom=" xsi:schemalocation=" extdom-2.0.xsd"> <extdom:reason>nice name</extdom:reason> <extdom:book/> </extdom:create> Przykład komendy <domain:create> z elementem <taste>: <create> <domain:create xmlns:domain=" xsi:schemalocation=" domain-2.0.xsd"> <domain:name>example.pl</domain:name> <domain:ns>ns1.example.pl</domain:ns> <domain:ns>ns1.example2.pl</domain:ns> <domain:registrant>nsk1234</domain:registrant> <domain:contact type="tech">nsk5678</domain:contact> <domain:authinfo> <domain:pw>2foobar</domain:pw> </domain:authinfo> </domain:create> </create> <extdom:create xmlns:extdom=" xsi:schemalocation=" extdom-2.0.xsd"> <extdom:reason>nice name</extdom:reason> <extdom:taste/> </extdom:create> 2. <domain:transfer> a. opcjonalny element <resendconfirmationrequest>, którego podanie w zleceniu transferu powoduje powtórne wysłanie prośby o potwierdzenie transferu przez registranta. Przykład komendy <domain:transfer>: NASK 2013 Strona 2
3 <transfer op="request"> <domain:transfer xmlns:domain=" xsi:schemalocation=" domain-2.0.xsd"> <domain:name>example.pl</domain:name> <domain:period unit="y">1</domain:period> <domain:authinfo> <domain:pw>2foobar</domain:pw> </domain:authinfo> </domain:transfer> </transfer> <extdom:transfer xmlns:extdom=" xsi:schemalocation=" extdom-2.0.xsd"> <extdom:resendconfirmationrequest/> </extdom:transfer> 3. <domain:renew> a. opcjonalny element <reactivate>, którego podanie oznacza, iż domena będąca w stanie BLOCKED może być odnowiona. Przykład komendy <domain:renew>: <renew> <domain:renew xmlns:domain=" xsi:schemalocation=" domain-2.0.xsd"> <domain:name>example.pl</domain:name> <domain:curexpdate> </domain:curexpdate> <domain:period unit="y">1</domain:period> </domain:renew> </renew> <extdom:renew xmlns:extdom=" xsi:schemalocation=" extdom-2.0.xsd"> <extdom:reactivate/> </extdom:renew> b. opcjonalny element <renewtodate>, którego podanie umożliwi przesunięcie daty wygaśnięcia domeny. Przykład komendy <domain:renew> z ustawionym elementem <renewtodate>: NASK 2013 Strona 3
4 <renew> <domain:renew xmlns:domain=" xsi:schemalocation=" domain-2.0.xsd"> <domain:name>example.pl</domain:name> <domain:curexpdate> </domain:curexpdate> </domain:renew> </renew> <extdom:renew xmlns:extdom=" xsi:schemalocation=" extdom-2.0.xsd"> <extdom:renewtodate> </extdom:renewtodate > </extdom:renew> Operacje na kontaktach 1. <contact:create> a. element <individual> zawierający informację, czy kontakt reprezentuje osobę fizyczną, b. element <consentforpublishing> zawierający zgodę albo zakaz kontaktu na publikację danych osobowych w przypadku osoby fizycznej. Przykład komendy <contact:create>: <create> <contact:create xmlns:contact=" xsi:schemalocation=" contact-2.0.xsd"> <contact:id>sh8013</contact:id> <contact:postalinfo type="loc"> <contact:name>john Doe</contact:name> <contact:org>acme</contact:org> <contact:addr> <contact:street>123 Example Dr.</contact:street> <contact:street>suite 100</contact:street> <contact:city>dulles</contact:city> <contact:sp>va</contact:sp> <contact:pc> </contact:pc> <contact:cc>us</contact:cc> </contact:addr> </contact:postalinfo> <contact:voice x="1234"> </contact:voice> <contact:fax> </contact:fax> <contact: >jdoe@example.tld</contact: > <contact:authinfo> <contact:pw>secret</contact:pw> </contact:authinfo> </contact:create> NASK 2013 Strona 4
5 </create> <extcon:create xmlns:extcon=" xsi:schemalocation=" extcon-2.0.xsd"> <extcon:individual>1</extcon:individual> <extcon:consentforpublishing>1</extcon:consentforpublishing> </extcon:create> 2. <contact:update> a. opcjonalny element <consentforpublishing> zawierający zgodę albo zakaz kontaktu na publikację danych osobowych w przypadku osoby fizycznej. Przykład komendy <contact:update>: <update> <contact:update xmlns:contact=" xsi:schemalocation=" contact-2.0.xsd"> <contact:id>nsk0001</contact:id> <contact:add> <contact:status s="clientdeleteprohibited"/> </contact:add> <contact:chg> <contact:postalinfo type="int"> <contact:org/> <contact:addr> <contact:street>124 Example Dr.</contact:street> <contact:street>suite 200</contact:street> <contact:city>dulles</contact:city> <contact:sp>va</contact:sp> <contact:pc> </contact:pc> <contact:cc>us</contact:cc> </contact:addr> </contact:postalinfo> <contact:voice> </contact:voice> <contact:fax/> </contact:chg> </contact:update> </update> <extcon:update xmlns:extcon=" xsi:schemalocation=" extcon-2.0.xsd"> <extcon:consentforpublishing>1</extcon:consentforpublishing> </extcon:update> 3. <contact:info> a. opcjonalny atrybut roid w elemencie <authinfo>, który zawiera identyfikator w systemie (Repository Object IDentifier) domeny, dla której kontakt o identyfikatorze <contact:id> jest registrantem, jeśli jej NASK 2013 Strona 5
6 informacje autoryzujące zostały podane w elemencie <contact:authinfo>. Przykład komendy <contact:info>: <info> <contact:info xmlns:contact=" xsi:schemalocation=" contact-2.0.xsd"> <contact:id>666666</contact:id> </contact:info> </info> <extcon:info xmlns:extcon=" xsi:schemalocation=" extcon-2.0.xsd"> <extcon:authinfo> <extcon:pw roid="1234-nask">2foobar</extcon:pw> </extcon:authinfo> </extcon:info> 4. <contact:infdata> (odpowiedź na komendę <contact:info>) a. element <individual> zawierający informację, czy kontakt reprezentuje osobę fizyczną, b. element <consentforpublishing> zawierający zgodę albo zakaz kontaktu na publikację danych osobowych w przypadku osoby fizycznej. Przykład odpowiedzi na <contact:info>: <result code="1000"> <msg lang="en">command completed successfully</msg> <msgq count="1" id="2649" /> <resdata> <contact:infdata xmlns:contact=" xsi:schemalocation=" contact-2.0.xsd"> <contact:id>nsk002</contact:id> <contact:roid>27200-nask</contact:roid> <contact:status s="ok" lang="en" /> <contact:postalinfo type="loc"> <contact:name>john Doe</contact:name> <contact:org>organizacja</contact:org> <contact:addr> <contact:street>street 23/22</contact:street> <contact:street /> <contact:street /> <contact:city>city</contact:city> <contact:pc>01-012</contact:pc> <contact:cc>pl</contact:cc> NASK 2013 Strona 6
7 </contact:addr> </contact:postalinfo> <contact:voice> </contact:voice> <contact:fax> </contact:fax> <contact:clid>nask</contact:clid> <contact:crid>nask</contact:crid> <contact:crdate> t17:59:48.0z</contact:crdate> <contact:authinfo> <contact:pw> </contact:pw> </contact:authinfo> </contact:infdata> </resdata> <extcon:infdata xmlns:extcon=" xsi:schemalocation=" extcon-2.0.xsd"> <extcon:individual>true</extcon:individual> <extcon:consentforpublishing>false</extcon:consentforpublishing> </extcon:infdata> <svtrid>ja </svtrid> Opcje Opcja na rejestrację nazwy domeny zapewnia możliwość rejestracji tej nazwy domeny, gdy będzie ona wolna do rejestracji (np. zakończy się jej okres utrzymywania bez uprzedniego przedłużenia lub zostanie usunięta). W takiej sytuacji domena zostanie automatycznie zarezerwowana dla uprawnionego registrara oraz registranta opcji. Do obsługi opcji dostarczono podzbiór komend wymienionych w Extensible Provisioning Protocol (draft-ietf-provreg-epp-07.txt), który opisano poniżej. 1. <future:check> a. jeden lub więcej elementów <future:name> zawierających nazwę opcji. Przykład komendy <future:check>: <check> <future:check xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:name>przyklad.pl</future:name> <future:name>przyklad1.pl</future:name> <future:name>przyklad2.pl</future:name> </future:check> </check> 2. <future:chkdata> (odpowiedź na komendę <future:check>) NASK 2013 Strona 7
8 Dla każdego podanego w komendzie elementu <future:name> odpowiedź zawiera odpowiadający mu element <future:cd> zawierający: a. element <future:name> zawierający nawę domeny oraz atrybut avail, który określa, czy utworzenie opcji dla danej nazwy domeny w momencie wykonania komendy było możliwe dla zalogowanego registrara (wartość true oznacza, że utworzenie jest możliwe, wartość false oznacza, że utworzenie jest niemożliwe), b. opcjonalny element <future:reason>, występujący, gdy atrybut avail elementu <future:name> ma wartość false, który zawiera numer dodatkowego kodu diagnostycznego opisującego powód, z którego zalogowany registrar nie może utworzyć opcji dla podanej nazwy domeny. Przykład odpowiedzi na <future:check>: <result code="1000"> <msg lang="en">command completed successfully</msg> <msgq count="1" id="2649" /> <resdata> <future:chkdata xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:cd> <future:name avail="false">przyklad.pl</future:name> <future:reason>4002</future:reason> </future:cd> <future:cd> <future:name avail="true">przyklad1.pl</future:name> </future:cd> <future:cd> <future:name avail="false">przyklad2.pl</future:name> <future:reason>4012</future:reason> </future:cd> </future:chkdata> </resdata> <svtrid>ja </svtrid> 3. <future:create> a. element <future:name> zawierający nazwę domeny, dla której ma zostać utworzona opcja, b. element <future:period> zawierający okres, na jaki ma zostać utworzony future, który zawiera atrybut unit o wartości y lub m, określający w jakich jednostkach (odpowiednio: rok lub miesiąc) została podana wartość elementu <future:period>, c. element <future:registrant> zawierający identyfikator kontaktu registranta opcji, d. element <future:authinfo> zawierający informacje autoryzujące opcji. Przykład komendy <future:create>: NASK 2013 Strona 8
9 <create> <future:create xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:name>przyklad.pl</future:name> <future:period unit="y">3</future:period> <future:registrant>nsk001</future:registrant> <future:authinfo> <future:pw>3foobar</future:pw> </future:authinfo> </future:create> </create> 4. <future:credata> (odpowiedź na komendę <future:create>) a. element <future:name> zawierający nazwę domeny, dla której utworzono opcję, b. element <future:crdate> zawierający datę utworzenia opcji, c. element <future:exdate> zawierający datę końca okresu utrzymywania opcji. Przykład odpowiedzi na <future:create>: epp- 2.0.xsd"> <result code="1000"> <msg lang="en">command completed successfully</msg> <msgq count="1" id="2649" /> <resdata> <future:credata xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:name>przyklad.pl</future:name> <future:crdate> t09:01:24.0z</future:crdate> </future:credata> </resdata> <svtrid>ja </svtrid> 5. <future:info> a. element <future:name> zawierający nazwę opcji, b. opcjonalny element <future:authinfo> zawierający informacje autoryzujące opcji lub kontaktu i. opcjonalny atrybut roid, który zawiera identyfikator w systemie (Repository Object IDentifier) kontaktu powiązanego z opcją o nazwie <future:name> jako registrant, jeśli jego informacje autoryzujące zostały podane w elemencie <future:authinfo>. Przykład komendy <future:info>: NASK 2013 Strona 9
10 <info> <future:info xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:name>przyklad.pl</future:name> <future:authinfo> <future:pw>3foobar</future:pw> </future:authinfo> </future:info> </info> 6. <future:infdata> (odpowiedź na komendę <future:info>) a. element <future:name> zawierający nazwę opcji, b. element <future:roid> zawierający identyfikator opcji w systemie (Repository Object IDentifier), c. element <future:registrant> zawierający identyfikator kontaktu registranta opcji, d. element <future:clid> zawierający identyfikator uprawnionego registrara opcji, e. element <future:crid> zawierający identyfikator registrara, który utworzył opcję, f. element <future:crdate> zawierający datę i czas utworzenia opcji w systemie, g. element <future:exdate> zawierający datę i czas końca okresu utrzymywania opcji, h. opcjonalny element <future:upid> zawierający identyfikator registrara, który dokonał ostatniej modyfikacji opcji, i. opcjonalny element <future:update> zawierający datę i czas ostatniej modyfikacji opcji, j. opcjonalny element <future:trdate> zawierający datę i czas ostatniego transferu opcji, k. element <future:authinfo> zawierający informacje autoryzujące opcji, l. element <future:period> zawierający okres utrzymywania opcji. Przykład odpowiedzi na <future:info>: <result code="1000"> <msg lang="en">command completed successfully</msg> <msgq count="1" id="2649" /> <resdata> <future:infdata xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:name>przyklad.pl</future:name> <future:roid>311-nask</future:roid> <future:registrant> </future:registrant> <future:clid>nask</future:clid> <future:crid>nask</future:crid> NASK 2013 Strona 10
11 <future:crdate> t09:01:24.0z</future:crdate> <future:exdate> t09:01:24.0z</future:exdate> <future:authinfo> <future:pw>3foobar</future:pw> </future:authinfo> </future:infdata> </resdata> <svtrid>ja </svtrid> 7. <future:update> a. element <future:name> zawierający nazwę opcji, b. <future:chg> element zawierający następujące elementy: i. opcjonalny element <future:registrant> zawierający identyfikator registranta opcji, ii. opcjonalny element <future:authinfo> zawierający informacje autoryzujące opcji. Przykład komendy <future:update>: <update> <future:update xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:name>przyklad.pl</future:name> <future:chg> <future:registrant>nsk001</future:registrant> <future:authinfo> <future:pw>4foobar</future:pw> </future:authinfo> </future:chg> </future:update> </update> 8. <future:transfer> a. atrybut op o jednej z wartości request, query, approve, reject, cancel, b. element <future:name> zawierający nazwę opcji, c. opcjonalny element <future:period>, który nie jest obsługiwany, d. element <future:authinfo> zawierający informacje autoryzujące opcji lub kontaktu i. opcjonalny atrybut roid, który zawiera identyfikator w systemie (Repository Object IDentifier) kontaktu powiązanego z opcją o nazwie <future:name> jako registrant, jeśli jego informacje autoryzujące zostały podane w elemencie <future:authinfo>, e. opcjonalny element <extfut:resendconfirmationrequest> (bez wartości). Przykład komendy <future:transfer>: NASK 2013 Strona 11
12 <transfer op="query"> <future:transfer xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:name>przyklad.pl</future:name> <future:authinfo> <future:pw>3foobar</future:pw> </future:authinfo> </future:transfer> </transfer> 9. <future:trndata> (odpowiedź na komendę <future:transfer>) a. element <future:name> zawierający nazwę opcji, b. element <future:trstatus> zawierający stan wykonania transferu opcji o jednej z wartości: clientapproved, clientcancelled, pending, serverapproved, servercancelled, c. element <future:reid> zawierający identyfikator registrara zlecającego transfer opcji, d. element <future:redate> zawierający datę zlecenia transferu, e. element <future:acid> zawierający identyfikator kontaktu registranta opcji, który zatwierdza zlecenie transferu, f. element <future:acdate> zawierający datę wygaśnięcia zlecenia transferu opcji, jeśli stan zlecenia transferu to pending albo datę zakończenia przetwarzania zlecenia transferu opcji dla pozostałych stanów zlecenia transferu. Przykład odpowiedzi na <future:transfer>: <result code="1001"> <msg lang="en">command completed successfully; action pending</msg> <msgq count="1" id="2649" /> <resdata> <future:trndata xmlns:future=" xsi:schemalocation=" future-2.0.xsd"> <future:name>przyklad.pl</future:name> <future:trstatus>pending</future:trstatus> <future:reid>nask</future:reid> <future:redate> t09:31:11.0z</future:redate> <future:acid>nsk0001</future:acid> <future:acdate> t09:31:11.0z</future:acdate> </future:trndata> </resdata> <svtrid>ja </svtrid> NASK 2013 Strona 12
13 Raporty Komenda raportów zwraca listę obiektów znajdujących się w systemie, należących do danego użytkownika i spełniających zadane warunki. 1. <extreport:report> a. jeden z następujących elementów, który określa typ raportu: i. <extreport:domain> lista domen, które są w określonym stanie i które wygasną w zadanym terminie, ii. <extreport:contact> lista kontaktów należących do zalogowanego registrara lub jeden określony identyfikatorem, iii. <extreport:host> lista hostów należących do zalogowanego registrara lub jeden określony nazwą, iv. <extreport:future> lista opcji, które wygasną w zadanym terminie, v. <extreport:payment> lista paymentów dla konta podanego typu, vi. <extreport:paymentfunds> sumy środków (początkowych, wydanych, bieżących) dla konta podanego typu, b. opcjonalny element <extreport:offset> określający przesunięcie w zwracanych danych (domyślnie 0), c. opcjonalny element <extreport:limit> określający ilość zwracanych danych. 2. <extreport:reportdata> (odpowiedź na komendę <extreport:report>) a. jeden z następujących elementów, który zawiera listę zwróconych obiektów w zależności od typu raportu, odpowiednio: i. <extreport:domdatarsp>, ii. <extreport:condatarsp>, iii. <extreport:hosdatarsp>, iv. <extreport:futdatarsp>, v. <extreport:paymentdatarsp>, vi. <extreport:paymentfundsdatarsp>, b. element <extreport:offset> zawierający przesunięcie zwracanych obiektów względem wszystkich obiektów spełniających warunki raportu, c. element <extreport:limit> zawierający maksymalną możliwą liczbę zwróconych obiektów w jednym raporcie, d. element <extreport:size> zawierający liczbę obiektów w systemie spełniająca warunki raportu. 3. <extreport:domain> a. opcjonalny element <extreport:state> zawierający jedną z wartości: STATE_REGISTERED, STATE_EXPIRED, STATE_BLOCKED, STATE_RESERVED, STATE_BOOK_BLOCKED, STATE_DELETE_BLOCKED, STATE_TASTED, STATE_TASTED_BLOCKED, określający stan domen (domyślnie STATE_REGISTERED), b. opcjonalny element <extreport:exdate> zawierający datę wygaśnięcia domen; jeśli nie zostanie podany, zwracane są wszystkie domeny zalogowanego registrara, c. opcjonalny element <extreport:statuses> zawierający elementy i. jeden lub więcej elementów <extreport:status> zawierających nazwy statusów domeny, ii. opcjonalny parametr statusesin decydujący czy wyszukiwane domeny mają zawierać podane statusy (domyślnie true) NASK 2013 Strona 13
14 Przykład komendy <extreport:domain>: <extreport:report xmlns:extreport=" xsi:schemalocation=" <extreport:domain> <extreport:state>state_registered</extreport:state> <extreport:exdate> t11:23:00.0z</extreport:exdate> <extreport:statuses statusesin="true"> <extreport:status>serverhold</extreport:status> </extreport:statuses> </extreport:domain> </extreport:report> 4. <extreport:domdatarsp> a. zero lub więcej elementów <extreport:domdata> i. element <extreport:name> zawierający nazwę domeny, ii. iii. iv. element <extreport:roid> zawierający identyfikator domeny w systemie (Repository Object IDentifier), element <extreport:exdate> zawierający datę wygaśnięcia domeny, element <extreport:statuses> zawierający elementy 1. zero lub więcej elementów <extreport:status> zawierających nazwy statusów domeny. Przykład odpowiedzi na <extreport:domain>: <result code="1000"> <msg lang="en">command completed successfully</msg> <msgq count="12" id="469432"/> <extreport:reportdata xmlns:extreport=" xsi:schemalocation=" <extreport:domdatarsp> <extreport:domdata> <extreport:name>example1.pl</extreport:name> <extreport:roid>1234-nask</extreport:roid> <extreport:exdate> t23:00:00.0z</extreport:exdate> <extreport:statuses> <extreport:status>serverhold</extreport:status> </extreport:statuses> </extreport:domdata> <extreport:domdata> <extreport:name>example2.pl</extreport:name> <extreport:roid>1235-nask</extreport:roid> <extreport:exdate> t15:25:31.0z</extreport:exdate> <extreport:statuses> <extreport:status>serverhold</extreport:status> NASK 2013 Strona 14
15 </extreport:statuses> </extreport:domdata> </extreport:domdatarsp> <extreport:size>2</extreport:size> </extreport:reportdata> <svtrid>re </svtrid> 5. <extreport:contact> a. opcjonalny element <extreport:conid> zawierający identyfikator kontaktu; jeśli nie zostanie podany, zwracane są wszystkie kontakty zalogowanego registrara. Przykład komendy <extreport:contact>: <extreport:report xmlns:extreport=" xsi:schemalocation=" <extreport:contact> <extreport:conid>k13</extreport:conid> </extreport:contact> </extreport:report> 6. <extreport:condatarsp> a. zero lub więcej elementów <extreport:condata> i. element <extreport:conid> zawierający identyfikator kontaktu, ii. element <extreport:roid> zawierający identyfikator kontaktu w systemie (Repository Object IDentifier). Przykład odpowiedzi na <extreport:contact>: <result code="1000"> <msg lang="en">command completed successfully</msg> <msgq count="12" id="469432"/> <extreport:reportdata xmlns:extreport=" xsi:schemalocation=" <extreport:condatarsp> <extreport:condata> <extreport:conid>k13</extreport:conid> <extreport:roid> nask</extreport:roid> </extreport:condata> </extreport:condatarsp> NASK 2013 Strona 15
16 <extreport:size>1</extreport:size> </extreport:reportdata> <svtrid>re </svtrid> 7. <extreport:host> a. opcjonalny element <extreport:name> zawierający nazwę hosta; jeśli nie zostanie podany, zwracane są wszystkie hosty zalogowanego registrara. Przykład komendy <extreport:host>: <extreport:report xmlns:extreport=" xsi:schemalocation=" <extreport:host> <extreport:name>ns1.temp.pl</extreport:name> </extreport:host> </extreport:report> 8. <extreport:hosdatarsp> a. zero lub więcej elementów <extreport:hosdata> i. element <extreport:name> zawierający nazwę hosta, ii. element <extreport:roid> zawierający identyfikator hosta w systemie (Repository Object IDentifier). Przykład odpowiedzi na <extreport:host>: <result code="1000"> <msg lang="en">command completed successfully</msg> <msgq count="12" id="469432"/> <extreport:reportdata xmlns:extreport=" xsi:schemalocation=" <extreport:condatarsp> <extreport:condata> <extreport:name>ns1.temp.pl</extreport:name> <extreport:roid> nask</extreport:roid> </extreport:condata> </extreport:condatarsp> <extreport:size>1</extreport:size> </extreport:reportdata> <svtrid>re </svtrid> NASK 2013 Strona 16
17 9. <extreport:future> a. opcjonalny element <extreport:exdate> zawierający datę wygaśnięcia opcji; jeśli nie zostanie podany, zwracane są wszystkie opcje zalogowanego registrara. Przykład komendy <extreport:future>: <extreport:report xmlns:extreport=" xsi:schemalocation=" <extreport:future> <extreport:exdate> t15:22:34.0z</extreport:exdate> </extreport:future> </extreport:report> 10.<extreport:futDataRsp> a. zero lub więcej elementów <extreport:futdata> i. element <extreport:name> zawierający nazwę opcji, ii. iii. element <extreport:roid> zawierający identyfikator opcji w systemie (Repository Object IDentifier), element <exreport:exdate> zawierający datę wygaśnięcia opcji. Przykład odpowiedzi na <extreport:future>: <result code="1000"> <msg lang="en">command completed successfully</msg> <msgq count="12" id="469432"/> <extreport:reportdata xmlns:extreport=" xsi:schemalocation=" <extreport:futdatarsp> <extreport:futdata> <extreport:name>ns1.temp.pl</extreport:name> <extreport:roid> nask</extreport:roid> <extreport:exdate> t15:25:31.0z</extreport:exdate> </extreport:futdata> </extreport:futdatarsp> <extreport:size>1</extreport:size> </extreport:reportdata> <svtrid>re </svtrid> NASK 2013 Strona 17
18 11.<extreport:payment> a. wymagany element <extreport:accounttype> zawierający typ konta, dla którego wyświetlane są paymenty. Przykład komendy <extreport:payment>: <extreport:report xmlns:extreport=" xsi:schemalocation=" <extreport:prepaid> <extreport:payment> <extreport:accounttype>domain</extreport:accounttype> </extreport:payment> </extreport:prepaid> </extreport:report> 12.<extreport:paymentDataRsp> a. zero lub więcej elementów <extreport:paymentdata> i. element <extreport:roid> zawierający identyfikator paymentu w systemie (Repository Object IDentifier), ii. element <exreport:crdate> zawierający datę utworzenia, iii. element <exreport:grossvalue> zawierający wartość brutto, iv. element <exreport:vatpercent> zawierający procent VAT, v. element <exreport:vatvalue> zawierający wartość VAT, vi. element <exreport:initialfunds> zawierający środki początkowe, vii. element <exreport:currentfunds> zawierający środki bieżące. Przykład odpowiedzi na <extreport:payment>: xmlns:xsi= <result code="1000"> <msg lang="pl">komenda wykonana poprawnie</msg> <extreport:reportdata xsi:schemalocation=" <extreport:paymentdatarsp> <extreport:paymentdata> <extreport:roid>14-nask</extreport:roid> <extreport:crdate> T08:08:40.0Z</extreport:crDate> <extreport:grossvalue>1220.0</extreport:grossvalue> <extreport:vatpercent>22</extreport:vatpercent> <extreport:vatvalue>220.0</extreport:vatvalue> <extreport:initialfunds>1000.0</extreport:initialfunds> <extreport:currentfunds>1000.0</extreport:currentfunds> </extreport:paymentdata> </extreport:paymentdatarsp> <extreport:size>1</extreport:size> NASK 2013 Strona 18
19 </extreport:reportdata> <svtrid>re </svtrid> 13.<extreport:paymentFunds> a. wymagany element <extreport:accounttype> zawierający typ konta, dla którego wyświetlane są sumy środków (początkowych, wydanych i bieżących). Przykład komendy <extreport:paymentfunds>: <extreport:report xmlns:extreport=" xsi:schemalocation=" <extreport:prepaid> <extreport:paymentfunds> <extreport:accounttype>domain</extreport:accounttype> </extreport:paymentfunds> </extreport:prepaid> </extreport:report> 14.<extreport:paymentDataRsp> a. element <extreport:paymentfundsdata> i. element <exreport:currentbalance> zawierający sumę środków bieżących. Przykład odpowiedzi na <extreport:paymentfunds>: xmlns:xsi= <result code="1000"> <msg lang="pl">komenda wykonana poprawnie</msg> <extreport:reportdata xsi:schemalocation=" <extreport:paymentfundsdatarsp> <extreport:paymentfundsdata> <extreport:currentbalance>803.86</extreport:currentbalance> </extreport:paymentfundsdata> </extreport:paymentfundsdatarsp> <extreport:size>1</extreport:size> </extreport:reportdata> <svtrid>re </svtrid> NASK 2013 Strona 19
20 Historia zmian Wersja Obowiązuje Wersja Obowiązuje Lista zmian dokumentu od Registry od Dodany opis rozszerzenia <renewtodate> Poprawiony przykład dla <domain:transfer> Aktualizacja przykładu odpowiedzi dla komendy <future:create> Modyfikacja przykładów. Usunięcie <contact:transfer> NASK 2013 Strona 20
Rozszerzenie NASK EPP
Rozszerzenie NASK EPP Rozszerzenie NASK EPP... 1 Wstęp... 1 Statusy... 1 Operacje na domenach... 1 Operacje na kontaktach... 4 Opcje... 8 Raporty... 14 Historia zmian... 23 Wstęp Celem niniejszego dokumentu
Rozszerzenie NASK EPP
Rozszerzenie NASK EPP Rozszerzenie NASK EPP... 1 Wstęp... 1 Operacje na domenach... 1 Operacje na kontaktach... 2 Opcje... 6 Raporty... 6 Wstęp Celem niniejszego dokumentu jest skrócony opis rozszerzeń
Rozszerzenie EPP o DNSSEC
Patrycja Węgrzynowicz, Kierownik Zespołu Projektów Informatycznych NASK Registry Naukowa i Akademicka Sieć Komputerowa Rozszerzenie EPP o DNSSEC Agenda Model NASK-EPP DNSSEC w modelu NASK-EPP Przykłady
AZ.pl 2010 API Strona 1/33. Spis treści
AZ.pl 2010 API Strona 1/33 Spis treści Historia zmian...4 Możliwości API...5 Dostęp do API...6 Ograniczenia...7 Technologia...7 Podłączanie do API...7 Java...7 PHP...8 Opis struktur danych oraz operacji...10
Wdrożenie modułu płatności eservice. dla systemu Zen Cart 1.3.9 1.5
Wdrożenie modułu płatności eservice dla systemu Zen Cart 1.3.9 1.5 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
API transakcyjne BitMarket.pl
API transakcyjne BitMarket.pl Wersja 20140402 1. Sposób łączenia się z API... 2 1.1. Klucze API... 2 1.2. Podpisywanie wiadomości... 2 1.3. Parametr tonce... 2 1.4. Limity zapytań... 3 1.5. Odpowiedzi
.pl API. Dokumentacja techniczna wersja 2.12 z dnia Jacek Partyka, MSERWIS
.pl API Dokumentacja techniczna wersja 2.12 z dnia 31.05.2012 Jacek Partyka, MSERWIS 1 Spis treści I. Dostęp do API...3 II. Katalog komend...4 1. check_domain...4 2. check_multiple...4 3. domain_book...4
Baza numerów Wersja 1.1
Baza numerów Wersja 1.1 SPIS TREŚCI 1. Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją 1.2 Informacje zwrotne wysyłane z API w odpowiedzi na odebrane odwołania I. Zarządzanie grupami Bazy Numerów
Instrukcja instalacji programu MR-Transfer
Strona 1 z 10 Instrukcja instalacji programu MR-Transfer Strona 2 z 10 Instalacja W celu zainstalowania oprogramowania, należy pobrać wersję instalacyjną ze strony https://microres.pl/bin/mrtransfer/mrtransfer.2.3.0.msi
V. Struktury wyrobów. 13.5 Kartoteka struktur produktów. Przykład: Ćwiczenia z użytkowania systemu MFG/PRO 1
Ćwiczenia z użytkowania systemu MFG/PRO 1 V. Struktury wyrobów 13.5 Kartoteka struktur produktów Przykład: Ćwiczenia z użytkowania systemu MFG/PRO 2 indeks nadrzędny identyfikator indeksu, który jest wytwarzany
Wdrożenie modułu płatności eservice. dla systemu oscommerce 2.3.x
Wdrożenie modułu płatności eservice dla systemu oscommerce 2.3.x - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
Dokumentacja modułu integracyjnego WHMCS-HRD
Dokumentacja modułu integracyjnego WHMCS-HRD Dział 1: Wymagania modułu WHMCS-HRD Moduł WHMCS-HRD do poprawnego funkcjonowania wymaga: PHP w wersji 5.3 lub nowszej z zainstalowaną biblioteką Curl, Iconv
Wdrożenie modułu płatności eservice. dla systemu Magento 1.4 1.9
Wdrożenie modułu płatności eservice dla systemu Magento 1.4 1.9 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie do
Certum Certificates For WHMCS. Instalacja, Konfiguracja i Zarządzanie
Instalacja, Konfiguracja i Zarządzanie 1 Spis Treści 1. O Module... 3 2. Instalacja... 4 3. Konfiguracja I Zarządzanie... 6 3.1. Strefa Klienta... 6 3.1.1. Zamówienie I Pierwszy Krok Konfiguracji... 6
KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED
KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED Podręcznik użytkownika Katowice 2010 Producent programu: KAMSOFT S.A. ul. 1 Maja 133 40-235 Katowice Telefon: (0-32) 209-07-05 Fax:
Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do
Sesje i ciasteczka Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do śledzenia użytkownika podczas jednej sesji
Regulamin rejestracji oraz utrzymania nazwy domeny 1. Postanowienia ogólne
Regulamin rejestracji oraz utrzymania nazwy domeny 1. Postanowienia ogólne 1. Niniejszy Regulamin rejestracji oraz utrzymania nazwy domeny, zwany dalej Regulaminem, określa warunki świadczenia usług rejestracji
E-administracja. Korzystanie z Elektronicznej Platformy Usług Administracji Publicznej
Szkolenie komputerowe: E-administracja. Korzystanie z Elektronicznej Platformy Usług Administracji Publicznej W ramach projektu Seniorzy w przestrzeni publicznej (FIO 2014) PROWADZĄCY: ŁUKASZ KUCHA 1 Czym
Poniższy cennik obowiązuje Klientów zarejestrowanych w systemie AZ.pl przed dniem 18.03.2014.
Jeśli nie podano inaczej, prezentowane ceny są cenami netto. Poniższy cennik obowiązuje Klientów zarejestrowanych w systemie AZ.pl przed dniem 18.03.2014. Z dniem 07.04.2014 usługa Hostingu Wieczystego
Instrukcja obsługi aplikacji WIFI AC. SYG01Eng-4
Instrukcja obsługi aplikacji WIFI AC SYG01Eng-4 1. Pobieranie i instalacja aplikacji Zeskanuj kod, aby pobrać i zainstalować aplikację WIFI AC na swoim urządzeniu. 2. Rejestracja użytkownika i logowanie
Specyfikacja HTTP API. Wersja 1.6
Specyfikacja HTTP API Wersja 1.6 1. Wprowadzenie Platforma PlaySMS umożliwia masową rozsyłkę SMS-ów oraz MMS-ów marketingowych. Umożliwiamy integrację naszej platformy z dowolnym systemem komputerowym
Opis zmian w wersji Oprogramowania do Obsługi SR/FA/SW/DM/ST
Opis zmian w wersji 2-5.4 Oprogramowania do Obsługi SR/FA/SW/DM/ST 1. Dostosowanie systemu do generowania i eksportowania miesięcznego sprawozdania z zakresu świadczeń wychowawczych wg nowego wzoru obowiązującego
VirtueMart 3. Instrukcja instalacji modułu płatności
Instrukcja instalacji modułu płatności VirtueMart 3 Wersja 1.0 lipiec 2016 1 Autorzy Rozszerzenie zostało przy współpracy z DodatkiJoomla.pl 2 Wymagania Aby korzystać z modułu płatności tpay.com dla skryptu
Wszystkie ceny podano w złotych z uwzględnieniem podatku od towarów i usług (VAT), o ile nie oznaczono inaczej.
cennik Wszystkie ceny podano w złotych z uwzględnieniem podatku od towarów i usług (VAT), o ile nie oznaczono inaczej. Tabela Opłaty instalacyjne i aktywacyjne. Opłaty instalacyjne i aktywacyjne neostrada
Do użytku z aplikacjami z funkcją skanowania / czytania kodów QR
Aplikacja Xerox QR Code Skrócona instrukcja obsługi 702P03999 Do użytku z aplikacjami z funkcją skanowania / czytania kodów QR Aplikacji QR Code można używać w połączeniu z: aplikacjami do skanowania /
Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do
Sesje i ciasteczka Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do śledzenia użytkownika podczas jednej sesji
ZiMSK. Routing statyczny, ICMP 1
ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Artur Sierszeń, asiersz@kis.p.lodz.pl dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl Routing statyczny, ICMP 1
Aktualizacja SMSFall v. 1.1.5 Data publikacji: 20-05-2013
Aktualizacja SMSFall v. 1.1.5 Data publikacji: 20-05-2013 Wersja Standard i Plus: we właściwościach terminala dodano wskaźnik poziomu sygnału urządzenia GSM wyrażony w dbm. Podstawa teoretyczna: http://pl.wikipedia.org/wiki/dbm.
I. Rejestracja i logowanie
1 Spis treści I. Rejestracja i logowanie...3 Rejestracja...3 Logowanie...4 II. Grupy ćwiczebne...5 Tworzenie nowej grupy ćwiczebnej...5 Dodawanie osób do grupy...5 Przenoszenie uczniów między grupami...7
Adobe Sign. Podręcznik przechowywania danych Adobe Systems Incorporated. All rights reserved. Ostatnia aktualizacja: 13 marca 2017 r.
Podręcznik przechowywania danych 2017 Adobe Systems Incorporated. All rights reserved. Ostatnia aktualizacja: 13 marca 2017 r. Spis treści Przechowywanie danych omówienie... 3 Konfiguracja przechowywania
REGULAMIN DOMEN. Ważny od dnia r.
REGULAMIN DOMEN Ważny od dnia 12.03.2018r. Spis treści I Postanowienia ogólne...2 II Definicje...3 III Rejestracja domen internetowych...4 IV Płatności...6 V Transfer domeny...7 VI Cesja domeny...8 VII
elaborat Podręcznik Użytkownika MARCEL S.A r. INTERNETOWA PLATFORMA PREZENTACJI WYNIKÓW PUBLIKACJA WYNIKÓW DLA PACJENTA INDYWIDUALNEGO
elaborat INTERNETOWA PLATFORMA PREZENTACJI WYNIKÓW PUBLIKACJA WYNIKÓW DLA PACJENTA INDYWIDUALNEGO Podręcznik Użytkownika MARCEL S.A. 2018 r. Spis treści Zasady pracy......3 Logowanie Pacjenta do serwisu......3
Spis treści INTERFEJS (WEBSERVICES) - DOKUMENTACJA TECHNICZNA 1
I N T E R F E J S W E BSERVICES NADAWANIE PAKIETÓW D O S Y S T EMU MKP PRZEZ I N TERNET D O K U M E N T A C J A T E C H N I C Z N A P A Ź D Z I E R N I K 2 0 1 6 Spis treści 1. Wstęp... 2 2. Informacje
Materiał informacyjny schematy przepływów statusów w systemie KDPW_ARM
Materiał informacyjny schematy przepływów statusów w systemie KDPW_ARM 2017-09-28 wersja 1.0 1 / 10 Spis treści Historia zmian... 3 Słownik pojęć... 3 I. Wykaz statusów w usłudze KDPW ARM... 3 II. Cykl
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl wersja.2.9 data 2014-11-21 Opis usług: P24 KOD P24 KLUCZ P24 WAPA SEND SMS Strona 1 z 8 P24 KOD Przebieg transakcji Operacje po stronie Sprzedawcy
Przewodnik użytkownika systemu e-faktur
Przewodnik użytkownika systemu e-faktur Zawartość 1. Rejestracja na portalu... 4 1.1 Email aktywacyjny... 4 1.2 Siła hasła... 4 1.3 Utrata hasła... 5 1.4 Wygaśnięcie ticketu... 5 2. Logowanie do portalu
Ulotka v System Comarch OPT!MA v Comarch SA Kraków, Al. Jana Pawła II 41g tel. (12) , fax (12)
System Comarch OPT!MA v. 2012.6.1 Ulotka v.2012.6.1 Comarch SA 31-864 Kraków, Al. Jana Pawła II 41g tel. (12) 681 43 00, fax (12) 687 71 00 Dział Wsparcia Klienta i Partnera: tel. (12) 681 43 00 www.comarch.pl/erp
INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR
INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR UWAGA Aby zapewnić niezawodną pracę urządzenia, przed przystąpieniem do jego obsługi
Rejestracja w serwisie martwekontabankowe.pl...2 Proces zamawiania usługi w serwisie martwekontabankowe.pl...4
Spis treści Rejestracja w serwisie martwekontabankowe.pl...2 Proces zamawiania usługi w serwisie martwekontabankowe.pl...4 Odnowienie hasła...4 Rejestracja spadkodawcy...4 Płatności...5 Płatność przelewem...5
2008 Nokia. Wszelkie prawa zastrzeżone. Nokia, Nokia Connecting People i Nseries są znakami towarowymi lub zarejestrowanymi znakami towarowymi firmy
Czat Wydanie 1 2008 Nokia. Wszelkie prawa zastrzeżone. Nokia, Nokia Connecting People i Nseries są znakami towarowymi lub zarejestrowanymi znakami towarowymi firmy Nokia Corporation. Sygnał dźwiękowy o
Nowa funkcjonalność umożliwiająca sprawdzenie z systemie ewuś statusu uprawnienia do świadczeń dla wybranego pacjenta.
Raport Nr 44/2012 SYSTEM INFORMATYCZNY KS-SOMED'2012 WERSJA Nr 2012.03.0.05 z dnia 2012-10-23 MODUŁ OPIS ZMIAN, MODYFIKACJI i AKTUALIZACJI M11 TERMINARZ 1. Poprawiono błąd zapytania, który mógł powodować
Application Style G. Pamiętaj, że: REJESTRACJA PRODUKTU KROK PO KROKU
Pamiętaj, że: REJESTRACJA PRODUKTU KROK PO KROKU Aby zarejestrować produkt musisz posiadać konto na stronie https://support.fortinet.com. Jeśli nie posiadasz konta wybierz Podpisz (Sign Up) na stronie
Regulamin usługi Halo Granie Obowiązuje od 01.01.2014
RP441_090511_1_OGSM/PDF01/0511, Strona 1 z 1111 Regulamin usługi Halo Granie Obowiązuje od 01.01.2014 1 Zakres Usługi 1. Usługa Halo Granie na podstawie niniejszego regulaminu jest oferowana od 9.05.2011
III. Dane podstawowe definiowanie organizacji
Ćwiczenia z użytkowania systemu MFG/PRO 1 III. Dane podstawowe definiowanie organizacji 1.1.1 Kartoteka kodów statusów zapasów Kod statusu zapasów określa parametry statusu zapasów w zakresie: Dostępne
Rozszerzenie NASK EPP
Rozszerzenie NASK EPP 1. Wstęp... 2 2. Statusy... 2 3. Operacje na domenach... 2 3.1. ... 2 3.2. ... 3 3.3. ... 3 4. Operacje na kontaktach... 4 4.1. ...
Telefon AT 530 szybki start.
Telefon AT 530 szybki start. Instalacja i dostęp:... 2 Konfiguracja IP 530 do nawiązywania połączeń VoIP.....4 Konfiguracja WAN... 4 Konfiguracja serwera SIP... 5 Konfiguracja IAX... 6 1/6 Instalacja i
Portal zarządzania Version 7.5
Portal zarządzania Version 7.5 PODRĘCZNIK ADMINISTRATORA Wersja: 29.8.2017 Spis treści 1 Informacje na temat niniejszego dokumentu...3 2 Informacje o portalu zarządzania...3 2.1 Konta i jednostki... 3
Moduł kontrakty służy do przechowywania danych o zakontraktowanych cenach zakupu od wybranych kontrahentów.
1. Moduł kontrakty służy do przechowywania danych o zakontraktowanych cenach zakupu od wybranych kontrahentów. Dokument kontraktu określa: asortyment i cenę zakupu określoną w kontrakcie zakres dat w którym
W N I O S E K - O T C
Formularz OTC - Numer. (Wypełnia TGE RRM) Kod ACER. (Wypełnia Wnioskodawca), dnia Do Towarowa Giełda Energii S.A. z siedzibą w Warszawie ul. Poleczki 23 bud. H 02-822 Warszawa KRS 0000030144 W N I O S
Instrukcja logowania do systemu Rejestru Unii
Instrukcja logowania do systemu Rejestru Unii UWAGA Instrukcja jest przeznaczona dla użytkowników, którzy posiadali aktywne konta w Krajowym Rejestrze Uprawnień, a następnie ich dane zostały zmigrowane
Regulamin domen I. Postanowienia ogólne. 1. Regulamin oznacza Regulamin domen oraz dokumenty, do których odsyła ten Regulamin, w szczególności cennik oraz Ogólne Warunki Umów. 2. Domena oznacza unikalny
REGULAMIN*REJESTRACJI*DOMEN*W*SERWISIE* FABRYKANAZW.PL*! I.! Postanowienia!ogólne! II.! Definicje! III.! Obowiązek!przestrzegania!prawa! IV.!
REGULAMIN*REJESTRACJI*DOMEN*W*SERWISIE* FABRYKANAZW.PL* I. Postanowieniaogólne II. Definicje III. Obowiązekprzestrzeganiaprawa IV. ZasadyrejestracjiDomenyglobalnej V. ZasadyrejestracjiDomenypolskiej VI.
Procedura składania wniosku urlopowego z wykorzystaniem Elektronicznego Systemu Obiegu Dokumentów
Załącznik nr 1 do Zarządzenia Nr 10/2014/2015 Rektora UKW z dnia 15 grudnia 2014 r. Procedura składania wniosku urlopowego z wykorzystaniem Elektronicznego Systemu Obiegu Dokumentów Niniejszy dokument
1. Opis ogólny. 2. Opis techniczny. 3. Wymagania techniczne
Dokumentacja programu e Zoz Opis biblioteki PhantomAPI.dll Wersja 1.22.1.5 Zielona Góra 2010-08-26 1. Opis ogólny Biblioteka programistyczna PhantomAPI.dll służy do integracji oprogramowania zewnętrznego
Specyfikacja API 1.0. Specyfikacja kontroli Konta systemu CashBill z wykorzystaniem API opartego na REST
Specyfikacja API 1.0 API REST Specyfikacja kontroli Konta systemu CashBill z wykorzystaniem API opartego na REST CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42
Certyfikat kwalifikowany
Certyfikat kwalifikowany Krok 2 Aktywacja odnowienia certyfikatu kwalifikowanego. Instrukcja uzyskania certyfikatu kwalifikowanego Krok 2 Aktywacja odnowienia certyfikatu kwalifikowanego Wersja 1.8 Spis
Podręcznik Sprzedającego. Portal aukcyjny
Podręcznik Sprzedającego Portal aukcyjny Spis treści 1. Czym jest KupTam.pl?... 3 2. Logowanie do serwisu... 3 3. Rejestracja... 4 4. Tworzenie domeny aukcyjnej... 7 5. Wybór domeny... 9 6. Obsługa portalu...
Instrukcja obsługi: Moduł Reklamacje
Instrukcja obsługi: Moduł Reklamacje Moduł Reklamacje znajdujący się na platformie B2B Ateneum został utworzony w celu usprawnienia procesu wymiany informacji oraz obsługi reklamacji zrealizowanych dostaw
Regulamin rejestracji i utrzymania domen internetowych
9.01.2014 Regulamin rejestracji i utrzymania domen internetowych Niniejszy Regulamin jest podstawą świadczenia przez Grupę Adweb usług rejestracji i utrzymania domen internetowych. Podjęcie współpracy
Minimalna wspierana wersja systemu Android to 2.3.3 zalecana 4.0. Ta dokumentacja została wykonana na telefonie HUAWEI ASCEND P7 z Android 4.
Dokumentacja dla Scandroid. Minimalna wspierana wersja systemu Android to 2.3.3 zalecana 4.0. Ta dokumentacja została wykonana na telefonie HUAWEI ASCEND P7 z Android 4. Scandroid to aplikacja przeznaczona
Krajowy Integrator Płatności Spółka Akcyjna
Instrukcja instalacji modułu płatności VirtueMart 3 Wersja 1.0 marzec 2015 Krajowy Integrator Płatności Spółka Akcyjna z siedzibą w Poznaniu, przy ul. Św. Marcin 73/6, wpisana do rejestru przedsiębiorców
Kalipso wywiady środowiskowe
Kalipso wywiady środowiskowe Instrukcja obsługi INFO-R Spółka Jawna - 2017 43-430 Pogórze, ul. Baziowa 29, tel. (33) 479 93 29, (33) 479 93 89 fax: (33) 853 04 06 e-mail: admin@ops.strefa.pl Spis treści:
Gatesms.eu Mobilne Rozwiązania dla biznesu
Mobilne Rozwiązania dla biznesu SPECYFIKACJA TECHNICZNA WEB API-USSD GATESMS.EU wersja 0.9 Opracował: Gatesms.eu Spis Historia wersji dokumentu...3 Bezpieczeństwo...3 Wymagania ogólne...3 Mechanizm zabezpieczenia
Dokumentacja techniczna asendo APIEmail
asendo.pl tel: 22 211 20 22 Dokumentacja techniczna asendo APIEmail Spis treści 1. Wprowadzenie...2 2. Komunikaty...3 3. Zarządzanie kontaktami...7 4. Szablony email...19 5. Nadawcy email...22 6. Kampanie
Specyfikacja 1.2.1. Płatności CashBill. Instrukcja podłączenia płatności elektronicznych do typowych zastosowań.
Specyfikacja 1.2.1 Płatności CashBill Instrukcja podłączenia płatności elektronicznych do typowych zastosowań. CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax:
neostrada tp aktywacja usługi na łączu TP, na którym jest świadczona usługa telefoniczna w oparciu o dostęp analogowy
cennik usługi neostrada tp Tabela 1 Opłaty instalacyjne i aktywacyjne neostrada tp instalacja i aktywacja usługi neostrada tp aktywacja usługi na łączu TP, na którym jest świadczona usługa telefoniczna
REGULAMIN USŁUGI WŁASNA STRONA FIRMOWA DLA ABONENTÓW PLAY KORZYSTAJĄCYCH Z OFERTY FORMUŁA BIZNES BOX Z NIELIMITOWANYM INTERNETEM DO BIURA
REGULAMIN USŁUGI WŁASNA STRONA FIRMOWA DLA ABONENTÓW PLAY KORZYSTAJĄCYCH Z OFERTY FORMUŁA BIZNES BOX Z NIELIMITOWANYM INTERNETEM DO BIURA ważny od 16 czerwca 2016 r. do odwołania I. DEFINICJE W tym Regulaminie
Instrukcja poruszania się po generatorze
Instrukcja poruszania się po generatorze Spis treści I. Dla nowych oferentów:... 2 Krok I. REJESTRACJA... 2 Krok II. LOGOWANIE... 3 II. Dla Oferentów posiadających już konto w Generatorze:... 3 Krok I.
Połączenie Partnera z serwisem JustPay poprzez - METODĘ 2
Połączenie Partnera z serwisem JustPay poprzez - METODĘ 2 Generowanie kodów: po stronie Partnera Weryfikacja kodów: po stronie Partnera Spis treści 1. Kolejne kroki w stworzeniu własnego serwisu 2. Jak
Akademia Techniczno-Humanistyczna w Bielsku-Białej
Akademia Techniczno-Humanistyczna w Bielsku-Białej Wydział Budowy Maszyn i Informatyki Laboratorium z sieci komputerowych Ćwiczenie numer: 3 Temat ćwiczenia: Narzędzia sieciowe w systemie Windows 1. Wstęp
elektroniczna Platforma Usług Administracji Publicznej
elektroniczna Platforma Usług Administracji Publicznej Instrukcja użytkownika Profil Zaufany wersja 02-02. Ministerstwo Spraw Wewnętrznych i Administracji ul. Batorego 5, 02-591 Warszawa www.epuap.gov.pl
Autoryzacja zleceń kodem SMS. Dodatek do instrukcji głównej
Płońsk 2019 Spis treści Spis treści Oznaczenia...3...4 1.1. Pierwsze logowanie...4 1.2. Logowanie do systemu...6 1.3. Reset hasła dostępu...7 1.4. Zmiana hasła dostępu...7 2. Autoryzacja kodem SMS...9
Konto użytkownika. I. Logowanie
Konto użytkownika I. Logowanie Korzystanie z INTEGRO jest możliwe przez czytelnika niezalogowanego (Przeglądasz, jako GOŚĆ) w ograniczonym zakresie. Tylko osoba zalogowana na swoje konto, ma dostęp do
PROCES AKTUALIZACJI DANYCH PODMIOTU W KRAJOWEJ BAZIE O EMISJACH GAZÓW CIEPLARNIANYCH I INNYCH SUBSTANCJI
PROCES AKTUALIZACJI DANYCH PODMIOTU W KRAJOWEJ BAZIE O EMISJACH GAZÓW CIEPLARNIANYCH I INNYCH SUBSTANCJI Instrukcja wypełniania formularza aktualizacji danych podmiotu w Krajowej bazie o emisjach gazów
Jak zacząć korzystać w HostedExchange.pl ze swojej domeny np. @firma.pl
str. 1 Jak zacząć korzystać w HostedExchange.pl ze swojej domeny np. @firma.pl W tym dokumencie znajdziesz: Krok 1 - Kup domenę u dowolnego dostawcy... 1 Krok 2 - Dodaj domenę do panelu zarządzania HostedExchange.pl...
Programy licencjonowania zbiorczego firmy Adobe
Programy licencjonowania zbiorczego firmy Adobe Podręcznik użytkownika konsoli sprzedawcy programu VIP dla planu Value Incentive Plan (VIP) Wersja 3.5 listopad 21, 2013 Obowiązuje od 1 listopada 2013 Strona
Dokumentacja Użytkownika Systemu. Integracja z Okazje.info, Skąpiec, Sklepy24
Dokumentacja Użytkownika Systemu Integracja z Okazje.info, Skąpiec, Sklepy24 Wersja 2016 Spis treści 1 INTEGRACJA... 3 2 REJESTRACJA... 4 2.1 OKAZJE.INFO... 4 2.2 SKĄPIEC... 4 2.3 SKLEPY24.PL... 4 3 KONFIGURACJA...
Domeny globalne i światowe polityka prywatności i
Portal > Knowledgebase > Domeny > Informacje podstawowe > Domeny globalne i światowe polityka prywatności i zarządzanie domeną Domeny globalne i światowe polityka prywatności i zarządzanie domeną Bartosz
RYNEK NAZW DOMENY.PL
RYNEK NAZW DOMENY.PL SZCZEGÓŁOWY RAPORT NASK ZA trzeci KWARTAŁ 2015 ROKU Q3 2015 Tekst i redakcja: Anna Gniadek, Katarzyna Sobczyk Opracowanie danych z systemu rejestracji nazw domeny.pl: Izabela Domagała,
REGULAMIN PORTALU ROLNICZA CHMURA USŁUG. 1 Definicje
REGULAMIN PORTALU ROLNICZA CHMURA USŁUG Niniejszy regulamin określa zasady korzystania z usług internetowego portalu Rolnicza Chmura Usług świadczonych przez Usługodawców pod adresem www. rolniczachmurauslug.pl
WARUNKI UCZESTNICTWA W KONGRESIE BIZNES TO ROZMOWY
WARUNKI UCZESTNICTWA W KONGRESIE BIZNES TO ROZMOWY I Warunki udziału oraz zasady płatności 1. Organizatorem Kongresu Biznes to Rozmowy (dalej: Kongres) jest Netia SA (dalej: Organizator) oraz Ringier Axel
Wersja z dnia r.
Szczegółowe warunki korzystania z usługi Private Exchange Wersja z dnia 20.11.2015 r. Artykuł 1 Cel Celem niniejszego dokumentu jest określenie szczegółowych warunków technicznych instalacji na Platformie
Sieci komputerowe - Wstęp do intersieci, protokół IPv4
Piotr Kowalski KAiTI Internet a internet - Wstęp do intersieci, protokół IPv Plan wykładu Informacje ogólne 1. Ogólne informacje na temat sieci Internet i protokołu IP (ang. Internet Protocol) w wersji.
Przechwytywanie domen jako istotny element rynku wtórnego domen. Michał Pleban, Dropped.pl
Przechwytywanie domen jako istotny element rynku wtórnego domen Michał Pleban, Dropped.pl Czym jest Dropped.pl? DDD Działając od września 2006 roku, Dropped.pl jest liderem przechwytywania domen w Polsce
Instrukcja dla użytkowników serwisu internetowego
Instrukcja dla użytkowników serwisu internetowego 1 2 Spis treści SPIS TREŚCI... 2 I WSTĘP... 3 II OPIS FUNKCJONALNOŚCI... 3 1. LOGOWANIE DO SERWISU INTERNETOWEGO... 3 1.1 Reguły bezpieczeństwa... 3 2.
Specyfikacja wysyłek marketingowych v1.10
Specyfikacja wysyłek marketingowych v1.10 1 Historia zmian: Al. Jerozolimskie 81 Data Autor Opis 05-07-2013 Olga Krygier-Zawistowska Dodano przykład w PHP 2 Specyfikacja komunikacji Al. Jerozolimskie 81
Instrukcja Użytkownika (Studenta) Systemu Obsługującego Lokalne Archiwum Dokumentów
Instrukcja Użytkownika (Studenta) Systemu Obsługującego Lokalne Archiwum Dokumentów Szkoła Główna Handlowa 1/15 System Obsługujący Lokalne Archiwum Dokumentów (SOLAD) jest programem służącym do wprowadzania,
CitiManager: Krótki przewodnik migracji dla posiadaczy kart
Niniejszy krótki przewodnik pomoże Ci: 1. Zarejestrować się na portalu CitiManager a) Wyłącznie dla obecnych posiadaczy kart korzystających z wyciągów online b) Wyłącznie dla posiadaczy kart korzystających
InPost PACZKOMATY. (Moduł Magento 2) v Strona 1 z 18
InPost PACZKOMATY (Moduł Magento 2) v.1.0.0 Strona 1 z 18 Spis treści Zgodny z Magento... 3 Instalacja... 3 Problem z instalacją... 3 Odinstalowanie modułu:... 3 Konfiguracja cron LINUX... 3 Konfiguracja...
W N I O S E K - O T C
Formularz OTC - Numer. (Wypełnia TGE RRM) Kod ACER. (Wypełnia Wnioskodawca), dnia Do Towarowa Giełda Energii S.A. z siedzibą w Warszawie ul. Poleczki 23 bud. H 02-822 Warszawa KRS 0000030144 Komentarz
API przekazy masowe - Dokumentacja. v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/ Poznań.
API przekazy masowe - Dokumentacja v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/6 61-808 Poznań www.kipsa.pl www.tpay.com 1 Bramka API Dokumentacja opisuje możliwość wykonania przekazów masowych za
Instrukcja logowania do systemu Rejestru Unii sprawdzenie identyfikatora użytkownika - URID
Instrukcja logowania do systemu Rejestru Unii sprawdzenie identyfikatora użytkownika - URID UWAGA Instrukcja jest przeznaczona dla użytkowników, którzy posiadali aktywne konta w Krajowym Rejestrze Uprawnień,
QuickStart. 2012 TechBase S.A. Technical contact - support.techbase.eu 1/8
QuickStart 2012 TechBase S.A. Technical contact - support.techbase.eu 1/8 TECHBASE (C) QuickStart 2/8 Przygotowanie do pierwszego uruchomienia 1. Zasilacz Do podłączenia urządzenia należy przygotować zasilacz
Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko
Podstawowe pojęcia dotyczące relacyjnych baz danych mgr inż. Krzysztof Szałajko Czym jest baza danych? Co rozumiemy przez dane? Czym jest system zarządzania bazą danych? 2 / 25 Baza danych Baza danych
1. Wstęp 2. Adres usługi 3. Konfiguracja 4. Metody 5. Typy danych 6. Przykład wywołania metody przy użyciu php i biblioteki nusoap 7.
1. Wstęp 2. Adres usługi 3. Konfiguracja 4. Metody 5. Typy danych 6. Przykład wywołania metody przy użyciu php i biblioteki nusoap 7. Odpowiedź serwera Wstęp Usługa udostępniona dla klientów serwisu pakka.pl,
W tym poradniku dowiesz się jak zlecać płatności na twój rachunek, jak wykonywać płatności wewnętrzne i jak wypłacać pieniądze.
Z serii: Dla użytkowników systemu For.Direct Poradnik 2: Wpłaty i wypłaty W tym poradniku dowiesz się jak zlecać płatności na twój rachunek, jak wykonywać płatności wewnętrzne i jak wypłacać pieniądze.
REGULAMIN SYSTEMU OBSŁUGI SERWISOWEJ FIRMY SPUTNIK SOFTWARE SP. Z O.O. Obowiązujący od dnia 25 maja 2018 roku
REGULAMIN SYSTEMU OBSŁUGI SERWISOWEJ FIRMY SPUTNIK SOFTWARE SP. Z O.O. Obowiązujący od dnia 25 maja 2018 roku 1 Podstawowe pojęcia użyte w regulaminie a. Administrator będąca również administratorem zbioru
Przewodnik Google Cloud Print
Przewodnik Google Cloud Print Wersja B POL Definicje oznaczeń W tym podręczniku użytkownika zastosowano następujący styl uwag: Uwagi informują o tym, jak należy reagować w danej sytuacji, lub zawierają