Push Access Protocol - Push Access Protocol
Push Access Protocol (of PAP ) is een protocol gedefinieerd in WAP-164 van het Wireless Application Protocol (WAP) suite van de Open Mobile Alliance . PAP wordt gebruikt voor communicatie met de Push Proxy Gateway , die gewoonlijk deel uitmaakt van een WAP-gateway .
PAP is bedoeld voor gebruik bij het afleveren van de inhoud van Push initiators naar Push Proxy Gateway voor daaropvolgende aflevering aan smalbandige apparaten, zoals mobiele telefoons en pagers . Voorbeeld boodschappen bevatten nieuws, aandelenkoersen, het weer, verkeersinformatie, en de kennisgeving van gebeurtenissen zoals e-mail aankomst. Met Push-functionaliteit, zijn gebruikers in staat om informatie te ontvangen, zonder dat daartoe een verzoek. In veel gevallen is het belangrijk voor de gebruiker om de informatie zodra deze beschikbaar komen.
De Push Access Protocol is niet bedoeld voor gebruik via de ether.
PAP is ontworpen om onafhankelijk van het onderliggende transportprotocol zijn. PAP noemt de volgende mogelijke bewerkingen tussen de Push Initiator en de Push Proxy Gateway:
- Gevraagd Push
- Annuleer een Push
- Query voor de status van een Push
- Query voor mogelijkheden draadloze apparaat
- resultaat kennisgeving
De interactie tussen de Push initiators en Push Proxy Gateway is in de vorm van XML -berichten.
Activiteiten
push Submission
Het doel van de Push Onderwerping is een push bericht op basis van een Push Initiator een PPG, die dan het bericht versturen naar een gebruikersagent in een inrichting voor het draadloze netwerk. De Push bericht bevat een controle entiteit en een content entiteit, en kan een vermogens entiteit bevatten. De stuurentiteit is een XML-document dat besturingsinformatie (push-bericht) van de PPG te gebruiken bij het verwerken van het bericht voor aflevering bevat. De inhoud entiteit weergave van de inhoud met het draadloze apparaat worden verzonden. De mogelijkheden entiteit bevat client mogelijkheden overgenomen door de Push Initiatiefnemer en is in het RDF [RDF] formaat zoals gedefinieerd in de User Agent Profile [UAProf]. De PPG kan de mogelijkheden informatie gebruiken om te bevestigen dat het bericht geschikt is voor de klant is. De reactie op het pushverzoek een XML-document (push-respons, paragraaf 9.3) die eerste aanvaarding of falen aangeeft. Minimaal de PPG MOET valideren tegen de DTD [XML] de controle entiteit in het bericht en meld het resultaat in het antwoord. De PPG kan aangeven, met behulp van de voortgang-note (op verzoek van de Push initiator in de voortgang-notes gevraagde attribuut), die andere validaties zijn afgerond. De inhoud en het aantal van de voortgang-notes zijn implementatie specifiek. Een typische reactie bericht kan opmerkingen over de voortgang bevatten voor elke fase van de interne verwerking. De verwerking fasen gebruikte implementatie specifiek. Er zijn bepalingen in de Push-bericht naar meerdere ontvangers te specificeren. Het antwoordbericht overeen met de boodschap dienen, zodat er een antwoordbericht voor een push-bericht, ongeacht het aantal adressen gespecificeerd. Als de Push Initiator wenst informatie met betrekking tot het uiteindelijke resultaat van de levering, dan moet het verzoek gevolg kennisgeving informatie in de push indiening en een retouradres (bv URL).
resultaat Notification
Deze bewerking wordt gebruikt door de PPG aan de initiatiefnemer van het uiteindelijke resultaat van een push indiening op de hoogte, op verzoek van de Push Initiator. Deze melding (pijl 5, hieronder) geeft de Push Initiator dat het bericht is verzonden (overgebracht, zoals bij pijl 3) geleverd (bevestiging ontvangen van draadloze inrichting, volgens pijl 4) is verstreken, werd geannuleerd of er een fout. Als er een verwerkingsfout MOET de melding direct verstuurd na detectie van de fout op de Push Initiator en de boodschap zal niet de cliënt gestuurd. Anders moet de kennisgeving worden verzonden nadat het bericht delivery-proces is voltooid. De levering proces wordt beschouwd als voltooid wanneer het bericht is niet langer een kandidaat voor de levering, bijvoorbeeld het bericht is verlopen. Als de push middel wordt aangeduid als afgewezen in stap twee in figuur 3, dan is geen resultaat bericht worden verzonden. De Push Initiator MOET een retouradres (bv URL) hebben verstrekt tijdens de push bewerking voor deze melding mogelijk te maken.
push Annulering
Het doel van de Push Annulering is om de Push Initiator om te proberen een eerder ingediend push-bericht te annuleren. De Push Initiator initieert deze operatie. De PPG reageert met een indicatie of het verzoek al dan niet succesvol was.
Status Query
De status querybewerking kan de Push Initiator om de huidige status van een bericht dat al eerder is ingediend vragen. Als de status wordt aangevraagd voor een boodschap die is gericht naar meerdere ontvangers MOET de PPG terugsturen een enkele reactie met de status van query resultaten voor elk van de ontvangers.
Client Capabilities Query
Deze bewerking maakt de Push Initiator de PPG worden gezocht naar de mogelijkheden van een specifiek apparaat. Het antwoord is een multipart / gerelateerde document met de CCQ-respons (paragraaf 9.11) element in een XML-document en in de tweede eenheid, de feitelijke cliëntcapaciteiten informatie RDF [RDF] volgens de User Agent Profile [UAProf]. De PPG KAN toe te voegen aan de mogelijkheden gerapporteerd indien de PPG bereid is om transformaties uit te voeren om de door de klant ondersteund formaten. Bijvoorbeeld, als een klant heeft JPG ondersteunen, maar niet GIF en een PPG is bereid om GIF-bestanden te converteren naar JPG, dan is de PPG kan melden dat de cliënt JPG en GIF-bestanden kan ondersteunen. De mogelijkheden gemeld kan de gecombineerde PPG en client-mogelijkheden en ze kunnen zijn afgeleid van sessie mogelijkheden of opgehaald uit een CC / PP-server. Vermogens kunnen ook worden verkregen middels toepassing afhankelijke wijze.
Het aanpakken
Er zijn drie adressen door de Push Initiator te worden beschouwd: de push proxy gateway-adres, het draadloze apparaat adres, en het resultaat kennisgeving adres. De push proxy gateway-adres moet bekend zijn bij de Push Initiator. Dit adres nodig is op de laag onder de push toegang protocol. De push proxy gateway is gericht met behulp van een uniek adres dat is afhankelijk van de onderliggende protocol. Wanneer bijvoorbeeld het onderliggende protocol HTTP URL [RFC1738] gebruikt. De inrichting adresinformatie is opgenomen als deel van de berichtinhoud (XML gelabeld inhoud). Elk teken toegestaan in een RFC822-mailadres verschijnen in het veld apparaat adres. Daarnaast is er een “notify-verzoek-to” adres kan worden verstrekt door de Push Initiator wanneer dat nodig is, zodat de push proxy gateway later kan reageren op de Push Initiator met kennisgeving resultaat.
Meerdere Ontvanger Aanpak
Er zijn scenario's waarin een Push Initiator zou willen identieke boodschappen naar meerdere ontvangers. In plaats van het indienen van meerdere identieke push-berichten, een aan elke ontvanger, de Push Initiator kan indienen een enkele push-bericht naar meerdere ontvangers aangepakt. Deze sectie is bedoeld om het gedrag van transacties met betrekking tot meerdere ontvangers te verduidelijken. Wanneer de PPG de push-antwoordbericht terug na een push onderwerping aan meerdere ontvangers, de respons overeenkomt met de boodschap, ongeacht het aantal ontvangers die op de push middel (er is een respons voor elke bediening indiening). Wanneer een Push initiator verzoekt verlenen (sectie 9.8) met meerdere adressen opgegeven, moet de PPG antwoorden met een statusquery-respons (paragraaf 9.9) met de enkelvoudige statussen. Hetzelfde geldt wanneer slechts een push-id is opgegeven (geen adres vermeld) in de query voor de status van een meervoudige ontvanger bericht. Resultaat meldingen (paragraaf 9.6) moet door de PPG worden gestuurd voor elke individuele ontvanger, als het resultaat met de kennisgeving door de Push Initiator tijdens de indiening van een bericht naar meerdere ontvangers wordt gevraagd. In gevallen waarin een bericht naar meerdere ontvangers wordt verzonden en later een annuleren wordt aangevraagd door de initiator, kan de PPG terug te sturen individuele antwoorden met betrekking tot elk van de meerdere ontvangers of het kan antwoorden met betrekking tot veel of alle van de ontvangers te sturen. Ondersteuning van meerdere adressen is OPTIONEEL in een PPG.
Multicast / Broadcast Adressen
Er zijn scenario's waarin een enkel adres door een PI ingediend door een PPG kan worden uitgebreid naar meerdere adressen voor levering. Bovendien kan een enkel adres verzonden via een draadloos netwerk door meerdere apparaten (zoals broadcast) worden ontvangen. Dit type service wordt verwacht voor de verspreiding van informatie van belang is voor een brede populatie (bijvoorbeeld nieuws, weer en verkeer). Deze sectie is bedoeld om het gedrag in verband met transacties met verduidelijken multicast en broadcast-adressen. Aangezien het adres expansie gaat op PPG of het draadloze netwerk, het gedrag tussen PI en PPG identiek gedrag als het adres niet uitgebreid. Het antwoord bevat de individuele adres zoals ingediend door de PI.
Message Format
De push toegang protocol onafhankelijk van het vervoermiddel. PAP berichten dragen besturingsinformatie, en bij een push middel, ook de inhoud en eventueel cliëntcapaciteiten informatie. Besturingsinformatie commando / antwoordberichten tussen PPG en de Push Initiator en parameters doorgegeven aan het PPG voor het versturen inhoud naar de draadloze inrichting. Voorbeelden van dergelijke informatie zijn het draadloze apparaatadres, de weergaveprioriteit van het bericht, enz. Deze informatie wordt normaliter naar de draadloze inrichting afgegeven. Content is informatie die bestemd is voor het draadloze apparaat. Deze informatie kan begrijpelijk alleen naar de draadloze inrichting (bijvoorbeeld kan worden gecodeerd door de Push Initiator of kunnen applicatiedata voor een toepassing onbekend bij de PPG) of kan herkennen aan de PPG (bijvoorbeeld HTML of WML) zijn. PPG kan zijn geconfigureerd om een aantal op transformatie herkenbare inhoud (bijvoorbeeld HTML naar WML) bepaalde draadloze apparaten voeren. De andere categorie van informatie is clientfaciliteit informatie zoals gespecificeerd in de User Agent Profile [UAProf]. Wanneer meer dan de controle wordt uitgevoerd in een bericht, het formaat van het bericht een MIME multipart / gerelateerde [RFC2387] samengestelde object. Wanneer alleen informatie (bv antwoordberichten) controle wordt uitgevoerd in een bericht, het formaat van het bericht is een eenvoudige toepassing / xml entiteit. Alle informatie wordt getransporteerd binnen een enkel bericht. In multipart berichten, de eerste entiteit die allemaal push verwante besturingsinformatie in een XML-document, de tweede entiteit bevat de inhoud van de draadloze inrichting, de derde entiteit, indien aanwezig, bevat UAProf cliëntcapaciteiten. Het formaat van de inhoud entiteit is opgegeven in [PushMsg].
Controle Entiteit Format
De stuurentiteit is een MIME lichaamsdeel dat een XML-document met een pap element bevat zoals gedefinieerd in punt 9.1. De controle-eenheid moet worden opgenomen in elk PAP verzoek en reactie. De besturingsentiteit moet de eerste entiteit in de MIME multipart / gerelateerde boodschap.
Content Entiteit Format
Het gegevenselement is een MIME lichaamsdeel met de inhoud naar de draadloze inrichting te verzenden. Het inhoudstype wordt niet bepaald door de PAP, maar kan elk type zijn zolang deze wordt beschreven door MIME. De inhoud entiteit wordt alleen opgenomen in de push indiening en is niet opgenomen in een andere bewerking vraag of reactie. De inhoud entiteit moet het tweede entiteit in de MIME multipart / gerelateerde boodschap.
Mogelijkheden Entiteit Format
De mogelijkheden entiteit MIME lichaamsdeel met de Push Initiator Aangenomen subset van de mogelijkheden van de draadloze inrichting / gebruikersagent. De mogelijkheden van formaat wordt opgegeven in de User Agent Profile [UAProf]. De vermogens eenheid, indien aanwezig, moet de derde entiteit in de Push Submission MIME multipart / gerelateerde boodschap zijn en de tweede entiteit een cliëntcapaciteiten query reactie.
