Push Access Protocol

Technology
12 hours ago
8
4
2
Avatar
Author
Albert Flores

Zpracování WAP push požadavku Push Access Protocol (PAP) je protokol sloužící pro doručení obsahu z Push Iniciátora (PI) na Push proxy bránu , která je obvykle součástí WAP brány. PPG následně zprávu doručí na mobilní zařízení, např. mobilní telefon nebo pager. Zpráva může obsahovat zpravodajství, kurzy akcií, předpověď počasí, informace o dopravě nebo oznámení určité události, jako například příchod e-mailu. Push funkcionalita umožňuje doručovat uživatelům informace bez jejich aktivního přispění, z čehož je odvozeno i její jméno ( = tlačit). Často je důležité, aby informace byla doručena uživateli co nejdříve. PAP je definovaný v dokumentu WAP-164 ze sady vydané Open Mobile Alliance pro Wireless Application Protocol (WAP).

PAP byl navržen tak, aby byl nezávislý na podkladovém transportním protokolu a není určen pro použití na bezdrátovém rozhraní.

PAP definuje následující operace mezi Push Iniciátorem a Push proxy bránou:

* Odeslání push zprávy * Zrušení push zprávy * Dotaz na status push zprávy * Dotaz na funkcionalitu bezdrátového zařízení * Notifikace o výsledku

Interakce mezi Push Iniciátorem a Push proxy branami má formát XML.

...

Operace

Odeslání push zprávy

Účelem Odeslání push zprávy je doručit push zprávu z Push Iniciátoru na Push proxy bránu, která pak musí zprávu doručit uživatelskému agentu v mobilním zařízení v bezdrátové síti. Push zpráva obsahuje řídicí entitu a obsahovou entitu a MŮŽE obsahovat entitu funkcionality. +more Řídicí entita je XML dokument s řídicími informacemi (push-zprávou), kterou PPG použije pro zpracování a doručení zprávy. Obsahová entita reprezentuje obsah, který má být odeslán na bezdrátové zařízení. Entity se schopnostmi obsahuje schopnosti, které Push Iniciátor předpokládá, že klient má, a má formát RDF definovaný v User Agent Profile (UAProf). PPG MŮŽE používat informace o funkcionalitě pro validaci, že zpráva je zobrazitelná na mobilním zařízení. Odezva na push požadavek je XML dokument (push-odezva, část 9. 3), který indikuje počáteční přijetí nebo selhání. PPG MUSÍ přinejmenším XML řídicí entity ve zprávě validovat podle DTD a oznámit výsledek v odezvě. PPG MŮŽE indikovat pomocí oznámení o průběhu zpracování (jestliže ji požaduje Push iniciátor atributem progress-notes-requested), které další validace byly dokončeny. Obsah a počet progress-notes závisí na implementaci. Typická odezva může obsahovat progress notes pro každou fázi interního zpracování. Použité fáze zpracování závisí na implementaci. Push zpráva může být určena více příjemcům. Odezva na takovou zprávu odpovídá původní zprávě, takže se posílá jedna odezva pro každou push zprávu, bez ohledu na to, kolik adresy příjemců obsahuje. Pokud si Push Iniciátor přeje dostat informace o výsledku doručení, pak MUSÍ požádat o notifikaci o výsledku v push zprávě a poskytnout adresu (například URL), kam má být notifikace poslána.

Notifikace o výsledku

Tuto operaci používá PPG pro informování iniciátora o konečném výsledku doručení push zprávy, pokud to Push Iniciátor požadoval. Tato notifikace oznamuje Push Iniciátorovi, že odeslaná zpráva byla doručena (potvrzení bylo přijato z bezdrátového zařízení), vypršela doba její platnosti (expirovala), byla zrušena nebo při jejím zpracování a doručování došlo k chybě. +more Pokud došlo k chybě při zpracování zprávy, Push Iniciátor by MĚL být okamžitě informován o chybě vrácením notifikace a zpráva nesmí být doručována příjemcům. Jinak notifikace MUSÍ být poslána, až když je proces doručování zprávy dokončen. Proces doručování je považován za dokončený, pokud zpráva už nebude doručována, pokud například expirovala. Pokud je odeslání push zprávy indikováno jako zamítnuté, pak notifikace o výsledku nebude poslána. Push Iniciátor MUSÍ při push operaci uvést adresu (například URL), na kterou má být notifikace zaslána.

Zrušení push zprávy

Push Iniciátor může zrušit push zprávu odeslanou na PPG před jejím konečným doručením. PPG odpoví indikací, zda požadavek byl úspěšný nebo ne.

Dotaz na stav zprávy

Operace dotaz na stav zprávy umožňuje, aby si Push Iniciátor vyžádal aktuální status dříve odeslané zprávy. Pokud je status požadován pro zprávu adresovanou více příjemcům, MUSÍ PPG vrátit jednu odezvu obsahující výsledky dotazu na stav pro všechny příjemce.

Dotaz na funkcionalitu bezdrátového zařízení

Tato operace umožňuje, aby se Push Iniciátor dotázal PPG na funkcionalitu mobilního zařízení. Odezva je vícedílný MIME multipart/related dokument obsahující ccq-response (část 9. +more11) element v XML dokumentu a jako druhou entitu, skutečné informace o funkcionalitě klienta v RDF definované v User Agent Profile UAProf. PPG MŮŽE přidat další schopnosti ke schopnostem oznámeným mobilním zařízením, pokud bude provádět transformace zprávy na formát podporovaný klientem. Jestliže například klient podporuje obrazový formát JPEG, ale ne GIF, a PPG bude konvertovat GIF soubory na JPEG, pak PPG může oznámit na PI, že klient podporuje JPEG i GIF soubory. Oznámené schopnosti mohou být kombinací schopností PPG a klienta a mohou být odvozené ze schopností sdělených v rámci relace nebo zjištěné z CC/PP serveru. Schopnosti mohou být zjištěny i implementačně závislými prostředky.

Adresování

Push Iniciátor může pracovat se třemi adresami: adresa PPG, adresa bezdrátového zařízení a adresa pro notifikaci o výsledku. Push Iniciátor musí znát adresu PPG, protože ji potřebuje vrstva pod protokolem pro push přístup. +more [url=, používá se [[Uniform Resource Locator|URL][Push Proxy Gateway|Push proxy brána]] má jednoznačnou adresu, která závisí na podkladovém protokolu. Pokud je například podkladovým protokolem[/url]] podle [url=https://www. ietf. org/rfc/rfc1738. txt]RFC1738[/url]. Informace o adrese zařízení je součástí obsahu zprávy (XML taggovaný obsah). V adresním poli zařízení se může vyskytnout jakýkoli znak povolený v [url=https://www. ietf. org/rfc/rfc822. txt]RFC822[/url] adrese. Navíc může Push Iniciátor použít adresu „notify-requested-to“, takže push proxy brána může později poslat odpověď Push Iniciátoru s notifikací o výsledku.

Adresování více příjemců

Existují scénáře, ve kterých Push Iniciátor může chtít poslat stejnou zprávu více příjemcům. Místo odeslání několika stejných push zpráv různým příjemcům může Push Iniciátor odeslat jedinou push zprávu adresovanou více příjemcům. +more Tato část objasňuje chování při odeslání zprávy více příjemcům. Když PPG vrátí odezvu na push zprávu, po odeslání push zprávy pro více příjemců odpovídá odezva původní zprávě, bez ohledu na počet příjemců zadaný v původní zprávě (vrací se jedna odezva pro každé odeslání push zprávy). Když Push Iniciátor vyžaduje status (část 9. 8) pro zprávu odeslanou s více adresami, MUSÍ PPG odpovědět jedinou statusquery odezvou (část 9. 9) obsahující jednotlivé statusy. Totéž platí, když je v dotazu na status zprávy poslané více příjemcům zadán pouze push-id (bez adresy). Notifikace o výsledku (část 9. 6) MUSÍ být PPG poslat pro každého příjemce, jestliže výsledek notifikace je požadovaný Push Iniciátorem během odeslání zprávy více příjemcům. V případech, kdy se zpráva pošle více příjemcům a později si iniciátor vyžádá zrušení zprávy , PPG MŮŽE poslat zpátky jednotlivé odezvy pro každého z příjemců nebo MŮŽE poslat odezvy pro více nebo všechny příjemců. Podpora více adres v PPG je NEPOVINNÁ.

Multicast a broadcast adresy

Existují scénáře, ve kterých může PPG expandovat jednu adresu použitou PI na více adres pro doručení. Jedna adresa použitá v bezdrátové síti může také adresovat více zařízení (například broadcast). +more Tento typ služby je použitelný pro šíření informací zajímavých pro širokou populaci (například zprávy, počasí a dopravní informace). Tato část vysvětluje chování pro operace obsahující multicast a broadcast adresy. Protože expanze adres se provádí v PPG nebo až v bezdrátové síti, chování mezi PI a PPG se nesmí lišit od chování v případě, že adresa by adresovala jen jedno zařízení. Proto odezva obsahuje jednu adresu, která byla použita v původní zprávě od PI.

Formát zprávy

Push Access Protocol je nezávislý na použitém transportním protokolu. PAP zprávy nesou řídicí informace a v případě odeslání push zprávy také obsah a volitelně i informace o funkcionalitě klienta. +more Řídicí informace zahrnují příkazy a odezvy mezi PPG a Push Iniciátorem a parametry předávané PPG pro použití při posílání obsahu na bezdrátové zařízení. Mezi informace tohoto typu patří adresa bezdrátového zařízení, priorita doručení zprávy, atd. Tyto informace se normálně nedoručují na bezdrátové zařízení. Obsah je informace, která je určena pro bezdrátové zařízení. Tato informace může být srozumitelná pouze tomuto bezdrátovému zařízení (například může být zašifrovaná Push Iniciátorem nebo může obsahovat aplikační data pro aplikaci neznámou pro PPG) nebo může být srozumitelná i pro PPG (například HTML nebo WML). PPG může být nakonfigurována, aby prováděla určité transformace známého obsahu (například převod z HTML na WML) pro určitá bezdrátová zařízení. Další kategorií informací jsou informace o funkčnosti klienta definované v User Agent Profile UAProf. Pokud zpráva nese i jiné než řídicí informace, formát zprávy je MIME složený objekt multipart/related podle RFC2387. Pokud zpráva obsahuje pouze řídicí informace (například pro odezvy), její formát je jednoduchá application/xml entita. Veškerá informace je přenášena v těle této zprávy. V multipart zprávách obsahuje první entita obsahuje všechny řídicí informace týkající se push ve tvaru XML dokumentu, druhá entity obsahuje obsah pro bezdrátové zařízení, a třetí entita, pokud je přítomná, obsahuje UAProf funkcionalitu klienta. Formát obsahu této entity je uveden v PushMsg.

Formát řídicí entity

Řídicí entita je ta část MIME těla, která obsahuje XML dokument obsahující jeden pap element definovaný v části 9. 1. +more Řídicí entita MUSÍ být obsažena v každém PAP požadavku i odezvě. Řídicí entita MUSÍ být první entitou v multipart/related MIME zprávě.

Formát obsahové entity

Obsahová entita je ta část MIME zprávy, která nese obsah, který má být odeslán na bezdrátové zařízení. PAP nestanovuje typ obsahu; může to být libovolný typ popsaný v MIME. +more Obsahová entita se používá pouze při odeslání push zprávy a není přítomná v žádném jiném požadavku nebo odezvě. Obsahová entita MUSÍ být druhou entitou v MIME multipart/related zprávě.

Formát entity popisující schopnosti

Entita popisující schopnosti zařízení je částí MIME těla, která obsahuje podmnožina funkcionalit bezdrátového zařízení/uživatelského agenta očekávanou Push Iniciátorem. Formát popisující schopnosti je uveden v User Agent Profile UAProf. +more Pokud je přítomná, entita popisující schopnosti, MUSÍ být třetí entitou při odeslání Push zprávy MIME multipart/related zprávě a MUSÍ být druhou entitou v odezvě na dotaz na schopnosti klienta.

Odkazy

Reference

Související články

Push Proxy Gateway * Push technologie * WAP brána * Wireless Application Protocol

Externí odkazy

[url=http://www.openmobilealliance.org/tech/affiliates/wap/wap-247-pap-20010429-a.pdf]Push Access Protocol Specification, Version 29-Apr-2001[/url]

Kategorie:Bezdrátové sítě Kategorie:Wireless Application Protocol

5 min read
Share this post:
Like it 8

Leave a Comment

Please, enter your name.
Please, provide a valid email address.
Please, enter your comment.
Enjoy this post? Join Cesko.wiki
Don’t forget to share it
Top