Protokół dostępu push
Push Access Protocol (lub PAP ) to protokół zdefiniowany w WAP-164 pakietu Wireless Application Protocol (WAP) z Open Mobile Alliance . PAP jest używany do komunikacji z bramką Push Proxy , która zwykle jest częścią bramki WAP .
PAP jest przeznaczony do dostarczania treści z inicjatorów Push do bram proxy Push w celu późniejszego dostarczenia do urządzeń wąskopasmowych, w tym telefonów komórkowych i pagerów . Przykładowe wiadomości obejmują wiadomości, notowania giełdowe, pogodę, informacje o ruchu drogowym oraz powiadomienia o zdarzeniach, takich jak nadejście wiadomości e-mail. Dzięki funkcji Push użytkownicy mogą otrzymywać informacje bez konieczności proszenia o nie. W wielu przypadkach ważne jest, aby użytkownik otrzymał informacje, gdy tylko będą one dostępne.
Protokół Push Access Protocol nie jest przeznaczony do użytku drogą radiową.
PAP jest zaprojektowany tak, aby był niezależny od podstawowego protokołu transportowego. PAP określa następujące możliwe operacje pomiędzy Push Initiator a Push Proxy Gateway:
- Prześlij push
- Anuluj Push
- Zapytanie o status Push
- Zapytanie o możliwości urządzenia bezprzewodowego
- Powiadomienie o wynikach
Interakcja między inicjatorami wypychania a bramkami proxy wypychania odbywa się w formie komunikatów XML .
Operacje
Przesyłanie push
Celem Push Submission jest dostarczenie wiadomości Push od Inicjatora Push do PPG, który następnie powinien dostarczyć wiadomość do agenta użytkownika w urządzeniu w sieci bezprzewodowej. Wiadomość Push zawiera jednostkę kontrolną i jednostkę treści i MOŻE zawierać jednostkę możliwości. Jednostką kontrolną jest dokument XML, który zawiera informacje kontrolne (wiadomość push), które PPG może wykorzystać podczas przetwarzania wiadomości w celu jej dostarczenia. Jednostka treści reprezentuje treść, która ma zostać wysłana do urządzenia bezprzewodowego. Jednostka możliwości zawiera możliwości klienta przyjęte przez inicjatora wypychania i jest w formacie RDF [RDF], jak zdefiniowano w profilu agenta użytkownika [UAPROF]. PPG MOŻE wykorzystać informacje o możliwościach do sprawdzenia, czy wiadomość jest odpowiednia dla klienta. Odpowiedzią na żądanie push jest dokument XML (odpowiedź push, sekcja 9.3), który wskazuje wstępną akceptację lub niepowodzenie. PPG MUSI co najmniej zweryfikować DTD [XML] jednostki sterującej w komunikacie i zgłosić wynik w odpowiedzi. PPG MOŻE wskazać, używając informacji o postępach (jeśli zażąda tego inicjator Push w atrybucie progress-notes-requested), że inne walidacje zostały zakończone. Treść i liczba notatek o postępie zależy od implementacji. Typowa wiadomość zwrotna może zawierać uwagi dotyczące postępu dla każdego etapu przetwarzania wewnętrznego. Stosowane etapy przetwarzania są specyficzne dla implementacji. W wiadomości Push znajdują się przepisy określające wielu odbiorców. Komunikat odpowiedzi odpowiada komunikatowi wysyłania, więc istnieje jeden komunikat odpowiedzi dla jednego komunikatu push, niezależnie od podanej liczby adresów. Jeśli Inicjator Push chce uzyskać informacje związane z końcowym wynikiem dostawy, MUSI zażądać informacji o wyniku powiadomienia w zgłoszeniu push i podać adres zwrotny (np. URL).
Powiadomienie o wyniku
Ta operacja jest używana przez PPG do poinformowania inicjatora o ostatecznym wyniku przesłania wypychania, jeśli zażąda tego inicjator wypychania. To powiadomienie (strzałka 5 poniżej) informuje inicjatora wypychania, że wiadomość została wysłana (przesłana, jak na strzałce 3), dostarczona (potwierdzenie otrzymane z urządzenia bezprzewodowego, jak na strzałce 4), wygasła, została anulowana lub nastąpiła błąd. Jeśli wystąpił błąd przetwarzania, powiadomienie POWINNO zostać wysłane natychmiast po wykryciu błędu do Inicjatora Push i nie należy wysyłać komunikatu do klienta. W przeciwnym razie powiadomienie MUSI zostać wysłane po zakończeniu procesu dostarczania wiadomości. Proces dostarczania uważa się za zakończony, gdy wiadomość nie nadaje się już do dostarczenia, np. wiadomość utraciła ważność. Jeśli zgłoszenie push zostanie wskazane jako odrzucone w kroku drugim na rysunku 3, powiadomienie o wyniku nie zostanie wysłane. Inicjator Push MUSI podać adres zwrotny (np. URL) podczas operacji push, aby to powiadomienie było możliwe.
Naciśnij anulowanie
Celem anulowania wypychania jest umożliwienie inicjatorowi wypychania próby anulowania wcześniej przesłanej wiadomości wypychanej. Inicjator wypychania inicjuje tę operację. PPG odpowiada ze wskazaniem, czy żądanie powiodło się, czy nie.
Zapytanie o stan
Operacja zapytania o stan umożliwia inicjatorowi wypychania zażądanie bieżącego stanu wiadomości, która została wcześniej przesłana. Jeśli status jest wymagany dla wiadomości adresowanej do wielu odbiorców, PPG MUSI odesłać pojedynczą odpowiedź zawierającą wyniki zapytania o status dla każdego z odbiorców.
Zapytanie o możliwości klienta
Ta operacja umożliwia inicjatorowi wypychania wysłanie zapytania do PPG o możliwości określonego urządzenia. Odpowiedź jest wieloczęściowym/powiązanym dokumentem zawierającym element ccq-response (sekcja 9.11) w dokumencie XML oraz, w drugiej encji, rzeczywiste informacje o możliwościach klienta w RDF [RDF], jak zdefiniowano w profilu agenta użytkownika [UAPROF]. PPG MOŻE dodać do zgłoszonych możliwości, jeśli PPG jest chętny do wykonania transformacji do formatów obsługiwanych przez klienta. Na przykład, jeśli klient obsługuje pliki JPG, ale nie obsługuje formatu GIF, a firma PPG chce przekonwertować pliki GIF na JPG, firma PPG może zgłosić, że klient obsługuje pliki JPG i GIF. Zgłoszone możliwości mogą być połączonymi możliwościami PPG i klienta i mogły pochodzić z możliwości sesji lub zostać pobrane z serwera CC/PP. Możliwości można również wyprowadzić za pomocą środków zależnych od implementacji.
Adresowanie
Inicjator wypychania bierze pod uwagę trzy adresy: adres bramy proxy wypychania, adres urządzenia bezprzewodowego i adres powiadomienia o wynikach. Adres bramy proxy wypychania musi być znany inicjatorowi wypychania. Ten adres jest potrzebny w warstwie poniżej protokołu dostępu push. Brama proxy typu push jest adresowana przy użyciu unikalnego adresu, który zależy od bazowego protokołu. Na przykład, gdy podstawowym protokołem jest HTTP, używany jest adres URL [RFC1738]. Informacje o adresie urządzenia są zawarte w treści wiadomości (treść ze znacznikami XML). W polu adresu urządzenia może pojawić się dowolny znak dozwolony w adresie RFC822. Ponadto w razie potrzeby inicjator wypychania może dostarczyć adres „żądania powiadomienia”, aby brama proxy wypychania mogła później odpowiedzieć inicjatorowi wypychania z powiadomieniem o wyniku.
Adresowanie wielu odbiorców
Istnieją scenariusze, w których inicjator wypychania może chcieć wysłać identyczne wiadomości do wielu odbiorców. Zamiast przesyłać wiele identycznych wiadomości push, po jednej do każdego odbiorcy, Inicjator Push może przesłać jedną wiadomość push zaadresowaną do wielu odbiorców. Ta sekcja ma na celu wyjaśnienie zachowania związanego z operacjami na wielu odbiorcach. Gdy PPG zwraca wiadomość typu push-response, po przesłaniu push do wielu odbiorców, odpowiedź odpowiada wiadomości, niezależnie od liczby odbiorców określonej w przesłaniu push (jest jedna odpowiedź na każde przesłanie push). Kiedy inicjator wypychania żąda statusu (sekcja 9.8) z określonymi wieloma adresami, PPG MUSI odpowiedzieć jedną odpowiedzią na zapytanie o status (sekcja 9.9) zawierającą poszczególne statusy. To samo dotyczy sytuacji, gdy w zapytaniu o status wiadomości dla wielu odbiorców określono tylko identyfikator wypychania (nie podano adresu). Powiadomienia o wynikach (sekcja 9.6) MUSZĄ być wysyłane przez PPG dla każdego indywidualnego odbiorcy, jeśli powiadomienie o wynikach jest wymagane przez inicjatora push podczas przesyłania wiadomości do wielu odbiorców. W przypadkach, gdy wiadomość jest wysyłana do wielu odbiorców, a następnie inicjator żąda anulowania, PPG MOŻE odesłać indywidualne odpowiedzi dotyczące każdego z wielu odbiorców lub MOŻE wysłać odpowiedzi dotyczące wielu lub wszystkich odbiorców. Obsługa wielu adresów jest OPCJONALNA w PPG.
Adresy multiemisji/rozgłaszania
Istnieją scenariusze, w których pojedynczy adres przesłany przez PI może zostać rozszerzony przez PPG na wiele adresów doręczeń. Ponadto pojedynczy adres przesyłany w sieci bezprzewodowej może być odbierany przez wiele urządzeń (np. rozgłoszenie). Ten typ usług jest przeznaczony do dystrybucji informacji interesujących szerokie grono odbiorców (np. wiadomości, pogoda i ruch uliczny). Ta sekcja ma na celu wyjaśnienie zachowania związanego z operacjami obejmującymi multiemisję i adresy rozgłoszeniowe. Ponieważ rozszerzenie adresu odbywa się w PPG lub w sieci bezprzewodowej, zachowanie między PI i PPG jest identyczne jak w przypadku braku rozszerzenia adresu. Odpowiedź zawiera indywidualny adres podany przez IP.
Format wiadomości
Protokół dostępu push jest niezależny od używanego transportu. Komunikaty PAP zawierają informacje kontrolne, aw przypadku przesyłania push również informacje o treści i opcjonalnie o możliwościach klienta. Informacje kontrolne obejmują komunikaty polecenia/odpowiedzi między PPG a inicjatorem wypychania oraz parametry przekazywane do PPG w celu wykorzystania przy wysyłaniu treści do urządzenia bezprzewodowego. Przykłady tego typu informacji obejmują adres urządzenia bezprzewodowego, priorytet dostarczenia wiadomości itp. Informacje te zwykle nie są dostarczane do urządzenia bezprzewodowego. Treść to informacje przeznaczone dla urządzenia bezprzewodowego. Informacje te mogą być zrozumiałe tylko dla urządzenia bezprzewodowego (np. mogą być zaszyfrowane przez Push Initiator lub mogą to być dane aplikacji dla aplikacji nieznanej PPG) lub mogą być rozpoznawane przez PPG (np. HTML lub WML). PPG może być skonfigurowany do przeprowadzania pewnej transformacji rozpoznawalnej treści (np. HTML do WML) dla niektórych urządzeń bezprzewodowych. Inną kategorią informacji są informacje o możliwościach klienta określone w profilu User Agent [UAPROF]. Gdy wiadomość zawiera więcej niż kontrolę, format wiadomości to wieloczęściowy/powiązany z MIME obiekt złożony [RFC2387]. Gdy w komunikacie przenoszona jest tylko informacja kontrolna (np. dla odpowiedzi na komunikat), format komunikatu to prosta jednostka aplikacja/xml. Wszystkie informacje są przesyłane w ramach jednej treści wiadomości. W wiadomościach wieloczęściowych pierwsza jednostka zawiera wszystkie informacje kontrolne związane z wypychaniem w dokumencie XML, druga jednostka zawiera treść dla urządzenia bezprzewodowego, trzecia jednostka, jeśli jest obecna, zawiera możliwości klienta UAPROF. Format encji treści jest określony w [PushMsg].
Format jednostki kontrolnej
Jednostką kontrolną jest część ciała MIME, która przechowuje dokument XML zawierający jeden element pap, jak zdefiniowano w sekcji 9.1. Jednostka kontrolna MUSI być uwzględniona w każdym żądaniu i odpowiedzi PAP. Jednostka kontrolna MUSI być pierwszą jednostką w wieloczęściowym/powiązanym komunikacie MIME.
Format jednostki treści
Jednostka zawartości jest częścią ciała MIME zawierającą treść, która ma zostać wysłana do urządzenia bezprzewodowego. Typ zawartości nie jest zdefiniowany przez PAP, ale może być dowolny, o ile jest opisany przez MIME. Jednostka zawartości jest uwzględniana tylko w przesyłaniu wypychanym i nie jest uwzględniana w żadnym innym żądaniu operacji ani odpowiedzi. Jednostka treści MUSI być drugą jednostką w wiadomości wieloczęściowej/powiązanej MIME.
Format jednostki zdolności
Jednostka możliwości jest częścią treści MIME zawierającą zakładany przez inicjatora wypychania podzbiór możliwości urządzenia bezprzewodowego/agenta użytkownika. Format możliwości jest określony w profilu User Agent [UAPROF]. Jednostka możliwości, jeśli jest obecna, MUSI być trzecią jednostką w wieloczęściowym/powiązanym komunikacie Push Submission MIME i MUSI być drugą jednostką w odpowiedzi na zapytanie o możliwości klienta.