WSPÓŁPRACA ZAUTOMATYZOWANEGO SYSTEMU ROZPOZNAWCZO-ZAKŁÓCAJĄCEGO KAKTUS Z SYSTEMAMI ZEWNĘTRZNYMI

Transkrypt

1 SYSTEMY ROZPOZNANIA I WALKI ELEKTRONICZNEJ PISZ LISTOPADA 2010 KNTWE 10 WSPÓŁPRACA ZAUTOMATYWANEGO SYSTEMU ROZPOZNAWC-ZAKŁÓCAJĄCEGO KAKTUS Z SYSTEMAMI ZEWNĘTRZNYMI Paweł KANIEWSKI, Jan LATEK, Tomasz SZYMCZYK, Tomasz ZYCH Zakład Radiokomunikacji i Walki Elektronicznej Wojskowy Instytut Łączności Zegrze, ul. Warszawska 22 A Streszczenie W niniejszym artykule przedstawiono ogólny zarys architektury i przeznaczenia Zautomatyzowanego Systemu Rozpoznawczo-Zakłócającego KAKTUS (ZSR-Z KAKTUS). Opisano koncepcję jego współpracy z zautomatyzowanymi systemami dowodzenia oraz systemami walki elektronicznej. Przewiduje się, że współdziałanie to będzie realizowane na dwa sposoby. Po pierwsze, przy wykorzystaniu systemu SZAFRAN, po drugie poprzez bezpośrednią współpracę modułu taktycznego z systemami dowodzenia NATO. Przewiduje się, że współpraca systemu KAKTUS z systemami dowodzenia NATO odbywać się będzie w oparciu o zalecenia programu MIP. Wykorzystane będą dwa mechanizmy zalecane przez MIP. Wymiana wiadomości odbywać się będzie z wykorzystaniem mechanizmu MEM, natomiast wymianę danych zapewni stosowanie mechanizmu DEM. Jako wspólny interfejs fizyczny przyjęto specyfikowany w MIP Ethernet LAN, który może być zapewniony poprzez różne rozwiązania sprzętowe. Biorąc pod uwagę, że w perspektywie najbliższych kilku lat współpraca międzysystemowa będzie odbywać się w oparciu o zalecenia programu MIP, zaproponowana koncepcja wydaje się przyszłościowym optymalnym rozwiązaniem problemu zapewnienia interoperacyjności systemu KAKTUS z wymienionymi systemami. 1. WSTĘP Zautomatyzowany system rozpoznawczo-zakłócający (ZSR-Z) KAKTUS jest przeznaczony do prowadzenia walki elektronicznej w zakresie rozpoznania elektronicznego (ESM ang. Electronic Warfare Support Measures / Electronic Surveillance Measures) i obezwładniania (przeciwdziałania) elektronicznego (ECM ang. Electronic Countermeasures). Zadania rozpoznawcze systemu KAKTUS obejmują pozyskiwanie informacji o składzie i dyslokacji elementów ugrupowania przeciwnika oraz o charakterze jego bieżących działań. W zakresie przeciwdziałania system KAKTUS jest przeznaczony do prowadzenia ofensywnych działań elektronicznych polegających na emitowaniu zakłócającej energii elektromagnetycznej na częstotliwościach pracy urządzeń odbiorczych przeciwnika. System jest przeznaczony do prowadzenia walki elektronicznej na szczeblu operacyjnym w zakresie HF i na szczeblu taktycznym w zakresach HF, VHF, UHF. Przewiduje się również możliwość jego wykorzystania do realizacji zadań w sytuacjach kryzysowych oraz w ramach operacji pokojowych i stabilizacyjnych w całości, jak również z użyciem części obiektów (w tym głównie elementów modułu taktycznego) wydzielanych do zespołów zadaniowych, szczególnie podczas prowadzenia operacji specjalnych [1]. System KAKTUS zapewnia współpracę z Zautomatyzowanym Systemem Dowodzenia WLąd SZAFRAN oraz interoperacyjność z analogicznymi systemami dowodzenia NATO, umożliwiając realizację wykonywanych przez wojska zadań zarówno w kraju jak i za granicą, w tym również działań w sytuacjach kryzysowych oraz w ramach operacji pokojowych i stabilizacyjnych.

2 Konieczność współpracy z innymi systemami łączności wymusza zastosowanie w systemie KAKTUS środków łączności zapewniających kompatybilność pracy z elementami eksploatowanych i wdrażanych systemów łączności (rodzaj sprzętu, interfejsy). W perspektywie najbliższych kilku lat współpraca międzysystemowa będzie odbywać się w oparciu o zalecenia programu MIP (ang. Multilateral Interoperability Program). Nabiera to szczególnego znaczenia w świetle podniesienia tych zaleceń do rangi standardu w systemach NATO. Współpraca z systemami dowodzenia państw sojuszniczych dotyczy w największym stopniu modułu taktycznego systemu KAKTUS, który będzie m. in. przeznaczony do działań w ramach zespołów zadaniowych sił narodowych wydzielonych do działań koalicyjnych. 2. ARCHITEKTURA ZSR-Z KAKTUS System KAKTUS jest zautomatyzowanym systemem walki elektronicznej do wykorzystania na szczeblu taktycznym i operacyjnym. Składa się z modułu operacyjnego, w sile kompanii i dwóch modułów taktycznych, każdy w sile plutonu (Rys. 1). W obu modułach systemu KAKTUS punktami centralnymi, w których zbiegają się wszystkie powiązania informacyjne, są: Wóz Dowodzenia Walką Elektroniczną modułu operacyjnego (WD WE ) i Wóz Dowodzenia Walką Elektroniczną modułu taktycznego (WD WE ZT). Znajdują się w nich stanowiska kierowania centrum odbiorczym, kierowania systemem namierzania, kierowanie systemem zakłócania oraz stanowisko dowodzenia walką radioelektroniczną. Wymiana informacji z systemami zewnętrznymi będzie odbywała się przy wykorzystaniu wozów dowodzenia [2]. SZ HF ZT SZ VHF/ UHF ZT WD WE WA ARO-KU WD WE ZT/ TAKTYCZNY OPERACYJNY SZ HF ZT SZ VHF/ UHF ZT ARO-KU WD WE ZT/ TAKTYCZNY Rys. 1 Struktura organizacyjna systemu KAKTUS W celu osiągnięcia szeroko rozumianej interoperacyjności oprogramowanie systemu KAKTUS uwzględnia obowiązujące dokumenty regulujące proces dowodzenia przy prowadzeniu działań rozpoznawczo-zakłócających zarówno w układzie narodowym, jak i w ramach struktur NATO, poprzez implementację standardów i zaleceń agencji NATO w zakresie: 2

3 obowiązujących dokumentów (STANAG 2014, STANAG 5500); wiadomości sformalizowanych (AdatP-3); znaków taktycznych (APP6A); map numerycznych (VPF, CADRG); modelu terenu (DTED). System KAKTUS umożliwia za pośrednictwem wozów dowodzenia WD WE i WD WE ZT, automatyczne formowanie meldunków z rozpoznania oraz przeciwdziałania i przekazywanie ich do szczebla nadrzędnego. Jest to jednak tylko część informacji, jakie są przesyłane. Oprócz wymiany informacji specjalistycznej, meldunków i rozkazów dotyczących walki elektronicznej, system jest zdolny do odbierania rozkazów i wysyłania meldunków ogólnowojskowych i logistycznych. Informacje należące do pierwszej z tych kategorii informacji są przekazywane w sposób automatyczny. 3. KONCEPCJA WSPÓŁPRACY ZSR-Z KAKTUS Z SYSTEMAMI DOWODZENIA NATO Podsystem łączności systemu KAKTUS zapewnia autonomiczną pracę systemu oraz dowiązanie jego obiektów do rozwiniętych systemów łączności wojsk lądowych, dlatego obiekty systemu KAKTUS wyposażone są w urządzenia łączności, które pozwolą na realizację obu trybów współpracy. W celu realizacji współpracy bezpośredniej z własnymi obiektami, na wozie dowodzenia przewidziano zastosowanie radiostacji zakresu HF i VHF, podsystem dostępu bezprzewodowego PDB oraz radiolinie R-450A. Współpraca bezpośrednia może odbywać się również poprzez interfejsy technologii Ethernet. Architekturę podsystemu łączności przedstawiono na Rys. 2. PKD Szczebel nadrzędny Współdziałanie (MIP, SWD) PKS PKŚ RL PDB HF RL Szczebel nadrzędny Współdziałanie (MIP, SWD) PKS PKD PKŚ PDB SZ HF ZT SZ VHF/ UHF ZT HF WD WE WA ARO-KU WD WE ZT/ TAKTYCZNY OPERACYJNY Szczebel nadrzędny Współdziałanie (MIP, SWD) PKD RL PKS PKŚ PDB WD WE ZT/ SZ HF ZT SZ VHF/ UHF ZT HF ARO-KU TAKTYCZNY Rys. 2 Architektura podsystemu łączności relacje międzymodułowe oraz zewnętrzne 3

4 Współdziałanie ze zautomatyzowanymi systemami dowodzenia NATO może mieć dwojaki charakter. Po pierwsze, dla dowodzenia systemem KAKTUS, przy wykorzystaniu systemu SZAFRAN. Po drugie, dla potrzeb wymiany informacji pomiędzy systemem KAKTUS i systemami dowodzenia NATO lub systemami walki elektronicznej, wspierającej procesy decyzyjne w tych systemach poprzez bezpośrednią współpracę modułu taktycznego. Przykładem może tu być wykorzystanie obiektów systemu KAKTUS podczas prowadzenia misji pokojowych lub stabilizacyjnych, w celu zapewnienia wymiany informacji umożliwiającej uzyskanie lepszego obrazu sytuacji. Współpraca ta odbywać się będzie w oparciu o zalecenia programu MIP (ang. Multilateral Interoperability Program). Zalecenia programu MIP zostały zaimplementowane w systemie KAKTUS w zakresie umożliwiającym automatyzację przekazywania informacji specjalistycznej, meldunków i rozkazów dotyczących walki elektronicznej. W celu zapewnienia interoperacyjności pomiędzy systemami, MIP zdefiniował mechanizm wymiany informacji (ang. Information Exchange Mechanisms - IEMs) który obejmuje: referencyjny model bazy danych; mechanizm wymiany wiadomości MEM (ang. Message Exchange Mechanizm); mechanizm wymiany danych DEM (ang. Data Exchange Mechanizm). Wyżej wymienione elementy stanowią interfejs programowy do współpracy aplikacji użytkowych rożnych systemów (Rys. 3). Jako interfejs fizyczny MIP specyfikuje Ethernet LAN (ang. Local Area Network). Interfejs programowy i fizyczny określane są jako Wspólny Interfejs MIP - MCI (ang. MIP Common Interface). W punktach 3.1 i 3.2 zamieszczono ogólne informacje dotyczące obu mechanizmów: wymiany wiadomości MEM i wymiany danych DEM. Szczegóły dotyczące wymagań implementacyjnych wymienionych elementów zawiera obszerna dokumentacja MIP [3]. Mapowanie formatów Mapowanie formatów Narodowy C2IS (A) esmtp MIP MTF MEM MESSAGE EXCHANGE MECHANISM MIP MTF esmtp Narodowy C2IS (B) JC3IEDM DEM DATA EXCHANGE MECHANISM JC3IEDM Mapowanie formatów Mapowanie formatów Rys. 3 Model wymiany informacji według zaleceń MIP 4

5 Z powyższego wynika konieczność implementacji w systemie KAKTUS bazy danych zgodnej z referencyjnym modelem bazy danych MIP oraz mechanizmów wymiany wiadomości MEM i danych DEM. Biorąc pod uwagę zalecenia MIP dotyczące warstwy fizycznej interfejsu MCI (Ethernet LAN) oraz z przeprowadzonych analiz systemów łączności, w systemie KAKTUS (na obiektach WD WE i WD WE ZT) przewidziano do współpracy międzysystemowej następujące interfejsy: Fast Ethernet (100BASE-TX oraz 100BASE-FX) interfejsy współpracy ETH (odpowiednio: elektryczne i światłowodowe), połączenia realizowane przy wykorzystaniu kabli odpowiednio: polowego kabla skrętkowego (PKS) oraz polowego kabla światłowodowego (PKŚ); Gigabit Ethernet (1000BASE-SX) światłowodowy interfejs współpracy ETH, połączenia realizowane przy wykorzystaniu kabli PKŚ; STANAG 4206 interfejs elektryczny (256 kbit/s), połączenia realizowane przy wykorzystaniu polowego kabla dalekosiężnego (PKD); STANAG 4578 interfejs elektryczny (256/2048 kbit/s), połączenia realizowane przy wykorzystaniu kabla PKD; STANAG 4210 ST ( sygnalizacja STORCZYK ) interfejs elektryczny ( kbit/s), połączenia realizowane przy wykorzystaniu kabla PKD; ISDN PRI interfejs elektryczny (2048 kbit/s), połączenia realizowane przy wykorzystaniu kabla PKD; STANAG 4210 interfejs radiolinii ( kbit/s); E1 (G.703) interfejs radiolinii (2048 kbit/s); 4 x E1 interfejs radiolinii (8192 kbit/s); b/g (zmodernizowany) interfejs podsystemu PDB (11/54 Mbit/s). Interfejs programowy, zgodny z wymaganiami MIP, stanowi oprogramowanie komunikacyjne systemu KAKTUS. Oprogramowanie to obejmuje implementację bazy danych zgodnej z modelem referencyjnym JC3IEDM (Baseline 3), która pozwala na automatyczną wymianę danych z wykorzystaniem mechanizmu DEM oraz mechanizmu MEM realizującego wymianę wiadomości (formatek ADatP-3). W celu zapewnienia współpracy z systemami poprzedniej generacji (np. Przebiśnieg), oprogramowanie to umożliwia ponadto wymianę formatek ADatP-3 z wykorzystaniem jako medium transmisyjne Sieci Wymiany Danych (SWD). W systemie KAKTUS zaimplementowano obsługę następujących formatek ADatP-3: 1. ENSITREP (ang. ENEMY LAND FORCES SITUATION REPORT) - raport o stanie wojsk przeciwnika; 2. OWNSITREP (ang. OWN LAND FORCES SITUATION REPORT) - raport o stanie wojsk własnych; 3. EWAM (ang. ELECTRONIC WARFARE APPROVAL MESSAGE) - zatwierdzenie walki elektronicznej; 4. EWMSNSUM (ang. ELECTRONIC WARFARE MISSION SUMMARY) - podsumowanie misji walki elektronicznej; 5. EWRTM (ang. ELECTRONIC WARFARE REQUESTING/TASKING MESSAGE) - rozkaz walki elektronicznej; 5

6 6. EWSTOPJAM (ang. ELECTRONIC WARFARE STOP JAMMING MESSAGE) - rozkaz zakończenia zakłócania; 7. MIJIWARNREP (ang. MIJI WARNING REPORT) - raport/ostrzeżenie o zakłóceniach własnych i celowych oraz zakłóceniach systemów nawigacyjnych; 8. INTREP (ang. INTELLIGENCE REPORT) - raport z rozpoznania; 9. INTSUM (ang. INTELLIGENCE SUMMARY) - podsumowanie rozpoznania; 10. SUPINTREP (ang. SUPPLEMENTARY INTELLIGENCE REPORT) - raport uzupełniający z rozpoznania; 11. MSGCORRCANX (ang. MESSAGE CORRECTION OR CANCELLATION) - wiadomość korygująca lub anulująca; 12. ASSESSREP (ang. COMMANDER'S ASSESSMENT REPORT) - raport oszacowania dowódców; 13. INCSPOTREP (ang. INCIDENT SPOT REPORT) - raport incydentów; 14. FIRST HOSTILE ACT (ang. FIRST HOSTILE ACT REPORT) - raport o pierwszym wrogim akcie; 15. FM.CFF (ang. FIRE MISSION-CALL FOR FIRE) - misja ogniowa, żądanie ognia. Oprogramowanie po wprowadzeniu przez operatora danych konfiguracyjnych, zapewnia automatyczną wymianę zakontraktowanych informacji. Dane konfiguracyjne obejmują: listę abonentów z określeniem medium wykorzystywanym do komunikacji i adresem abonenta właściwym dla danego medium; listę zakontraktowanych do wymiany wiadomości (formatek ADatP-3) powiązaną z określonym abonentem. Dane konfiguracyjne (np. lista zakontraktowanych formatek ADatP-3) mogą być modyfikowane przez operatora w dowolnej chwili, jeżeli zachodzi taka konieczność. Informacje odbierane z systemów zewnętrznych przekazywane są do oprogramowania specjalistycznego, które automatycznie wyświetla je w postaci właściwych znaków taktycznych na mapie lub komunikatów tekstowych gdy nie ma możliwości graficznego zobrazowania. Dane dotyczące aktualnej sytuacji taktycznej pozyskane przez obiekty systemu KAKTUS i umieszczane na mapie są automatycznie mapowane do wymaganego formatu (baza danych MIP lub ADatP-3) i przekazywane do oprogramowania komunikacyjnego, które przesyła je do wskazanego (zakontraktowanego) adresata Mechanizm wymiany wiadomości (Message Exchange Mechanism) Mechanizm wymiany wiadomości przewidziany jest do przesyłania widomości tekstowych niesformatowanych oraz o ustalonym formacie (np. ADatP-3). Zgodnie z założeniami MIP dla mechanizmu wymiany wiadomości MEM, został przewidziany protokół ESMTP (ang. Extended Simple Mail Transfer Protocol). Protokół ten różni się od SMTP dodatkowymi polami umieszczonymi w nagłówku ramki wiadomości. Dokładny opis protokołu znajduje się w dokumentach RFC [6-20]. Wiadomość ESMTP składa się z nagłówka wiadomości, ciała wiadomości i jednego lub wielu załączników. Nagłówek wiadomości składa się z pól zdefiniowanych w RFC 2822 oraz MIME (ang. Multipurpose Internet Mail Extensions) RFC od 2045 do Zgodnie z wymaganiami 6

7 MIP, dodatkowe pola nagłówka wiadomości ESMTP zostają wypełniane wartościami przedstawionymi w tabeli poniżej. Nazwa pola (zgodnie z RFC 2822) X-MIP-SUBMISSIONTIME: X-MIP-PRECEDENCE: X-MIP-SECURITY-PREFIX: Wartość pola Data i czas nadania wiadomości przedstawiona w formacie: ddhhmmzmonyyyy, gdzie: dd dzień, hh godzina, mm minuta, MON miesiąc, yyyy rok. Routine Priority Immediate Flash Wskazuje organizację, która określa reguły polityki bezpieczeństwa X-MIP-CLASSIFICATION: X-MIP-SECURITY-CAVEATS: X-MIP-SIC: UNCLASSIFIED NATO UNCLASSIFIED RESTRICTED NATO RESTRICTED CONFIDENTIAL NATO CONFIDENTIAL SECRET NATO SECRET Parametr określający zakres odbiorców wiadomości z określonym poziomem bezpieczeństwa Kod SIC jest powiązany z wiadomością, określany jest przez trzy znaki alfanumeryczne zgodne z dokumentacją APP-3. W przypadku, gdy kodów jest więcej niż jeden należy je rozdzielać znakiem średnika. Interfejs użytkownika wykorzystujący ESMTP pozwala na ustawienie trzech parametrów: RET, ENVID i NOTIFY, wykorzystywanych przez system potwierdzeń dostarczenia wiadomości. Parametr RET jest opisywany wartością HDRS, która oznacza, że potwierdzenia dostarczenia wiadomości należy przesyłać tylko w nagłówku wiadomości. Taki sposób pozwala ograniczyć zajętość łącza w zewnętrznych sieciach wąskopasmowych. Parametr ENVID jest unikalnym identyfikatorem wiadomości, który jest przypisywany przez nadawcę wiadomości. Ten parametr jest wykorzystywany przez nadawcę wiadomości do identyfikacji odebranego potwierdzenia dostarczenia wiadomości. Parametr NOTIFY służy do przekazania odbiorcy wiadomości zbioru gotowych formatów potwierdzeń dostarczenia wiadomości. Zbiór formatów potwierdzeń ma stałą postać: SUCCESS, FAILURE, DELAY. Nadawca wiadomości musi zawsze otrzymać potwierdzenie dostarczenia wiadomości. Typ danych wypełniających nagłówek i ciało wiadomości powinny być zgodne z MIME Version 1.0, a załączniki binarne przygotowane do wysłania powinny być kodowane zgodnie z typem base-64. Nazwy załączników powinny być tworzone zgodnie z zaleceniami znajdującymi się w dokumentacji MOP (ang. MIP Operating Procedures) Annex C. W przypadku wysyłania załącznika zawierającego formatkę ADatP-3 powinien być wysyłany jeden taki załącznik w jednej wiadomości. Załącznik typu ADatP-3 nie może być kompresowany. Szczegółowe informacje dotyczące tworzenia wiadomości ESMTP znajdują się w dokumencie [4]. 7

8 3.2. Mechanizm wymiany danych (Data Exchange Mechanism) Mechanizm wymiany danych (DEM) definiuje sposób wymiany i replikacji danych w oparciu o referencyjny model bazy danych MIP. W celu wymiany danych niezbędne jest określenie zbioru wymienianych danych OIG (ang. Operational Information Group) oraz wskazanie abonenta, z którym wymiana ma być realizowana. Zgodnie z specyfikacją MIP, wykorzystuje się interfejs fizyczny Ethernet LAN oraz protokoły TCP/IP. Interfejs programowy stanowią dwie kolejne warstwy określone w specyfikacji MIP jako: Transport Manager (TMAN) i Data Manager (DATAMGR). TMAN jest odpowiedzialny za zestawianie połączenia pomiędzy dwoma węzłami wymieniającymi dane. DATAMGR jest odpowiedzialny za wymianę i replikację danych (Rys. 4). W warstwie DATAMGR format przesyłanych danych zarówno po stronie nadawcy jak i po stronie odbiorcy musi być zgodny z formatem zdefiniowanym w referencyjnym modelu bazy danych MIP. Dokładna specyfikacja metod wykorzystywanych do replikacji danych oraz ich formatu i struktury znajduje się w dokumencie [5]. WĘZEŁ A Aplikacja użytkownika oferującego dane Żądanie przesłania danych wywołane zmianą wartości rekordu w bazie danych MIP DEM Reference Model Application WĘZEŁ B Aplikacja użytkownika odbierającego dane Aktualizacja rekordu w bazie danych Odbiór danych z DATAMGR Mapowanie żądania przesłania danych do instancji zdefiniowanej w DATAMGR Sprawdzenie czy przesyłane dane znajdują się na liście danych zakontraktowanych do wymiany Wybór metody do przesłania danych i stworzenie wiadomości określającej parametry transakcji Data Manager (DATAMGR) Mapowanie odebranych danych na format danych aplikacji użytkownika Przygotowanie wiadomości zawierającej parametry połączenia Lokalizacja adresu odbiorcy w sieci Przekazanie wiadomości do gniazda (ang. socket) TCP/IP Transport Manager (TMAN) Przekazanie datagramu z danymi do DATAMGR Odbiór wiadomości TMAN z gniazda (ang. socket) TCP/IP Transmisja danych TCP/IP TCP/IP Odbiór danych TCP/IP Rys. 4 Model wymiany danych z wykorzystaniem TMAN i DATAMGR 8

9 4. PODSUMOWANIE W artykule przedstawiono koncepcję współpracy systemu KAKTUS z zautomatyzowanymi systemami dowodzenia NATO. Współdziałanie to może być realizowane na dwa sposoby. Po pierwsze, przy wykorzystaniu systemu SZAFRAN, po drugie poprzez bezpośrednią współpracę modułu taktycznego z systemami dowodzenia NATO lub systemami walki elektronicznej. Współpraca systemu KAKTUS, z systemami dowodzenia NATO odbywa się w oparciu o zalecenia programu MIP. W celu zapewnienia współpracy z systemami poprzedniej generacji (np. Przebiśnieg), zaimplementowano wymianę formatek ADatP-3 z wykorzystaniem Sieci Wymiany Danych (SWD) jako medium transmisyjne. Oprogramowanie komunikacyjne systemu KAKTUS po wprowadzeniu przez operatora niezbędnych danych konfiguracyjnych, zapewnia automatyczną wymianę zakontraktowanych informacji dotyczących walki elektronicznej. 5. LITERATURA 1. PROJEKT WSTĘPNY Zautomatyzowanego Systemu Rozpoznawczo-Zakłócającego kryptonim KAKTUS tom1. Nr arch. WIŁ Z-396/II/07; 2. PROJEKT WSTĘPNY Zautomatyzowanego Systemu Rozpoznawczo-Zakłócającego kryptonim KAKTUS tom2. Nr arch. WIŁ Z-397/II/07; 3. MIP Technical Interface Design Plan - DNK SEAWG 1 JUN 2007 Edition: 3.3; 4. MTIDP - DNK SEAWG 1 JUN 2007 Edition: 3.3 ANNEX B MIP ESMTP SPECIFICATION; 5. MTIDP - DNK SEAWG 1 JUN 2007 Edition: 3.3 ANNEX A MIP DEM SPECIFICATION; 6. RFC 2045 Multipurpose Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies November 1996; 7. RFC 2046 Multipurpose Internet Mail Extensions (MIME), Part Two: Media Types November 1996; 8. RFC 2047 Multipurpose Internet Mail Extensions (MIME), Part Three: MessageHeader Extensions for Non-ASCII Text November 1996; 9. RFC 2048 Multipurpose Internet Mail Extensions (MIME), Part Four: Registration Procedures November 1996; 10. RFC 2049 Multipurpose Internet Mail Extensions (MIME), Part Five: Conformance Criteria and Examples November 1996; 11. RFC 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field August 1997; 12. RFC 2197 SMTP Service Extension for Command Pipelining September 1997; 13. RFC 2387 The MIME Multipart/Related Content-type. Internet Assigned Numbering Authority (IANA) Official Media Types August 1998; 14. RFC 2821 Simple Mail Transfer Protocol [SMTP] April 2001; 15. RFC 2822 Internet Message Format April 2001; 16. RFC 3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) January 2003; 17. RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages January 2003; 18. RFC 3463 Enhanced Mail System Status Codes January 2003; 19. RFC 3464 An Extensible Message Format for Delivery Status Notifications January 2003; 20. RFC 3798 Message Disposition Notification May