Push Access-protokoll - Push Access Protocol
Push Access Protocol (eller PAP ) er en protokoll definert i WAP-164 i WAP- pakken ( Wireless Application Protocol ) fra Open Mobile Alliance . PAP brukes til å kommunisere med Push Proxy Gateway , som vanligvis er en del av en WAP Gateway .
PAP er beregnet for bruk i levering av innhold fra Push Initiators til Push Proxy Gateways for senere levering til smale båndenheter, inkludert mobiltelefoner og personsøkere . Eksempler på meldinger inkluderer nyheter, aksjekurser, vær, trafikkmeldinger og varsling om hendelser som ankomst på e-post. Med Push-funksjonalitet kan brukere motta informasjon uten å måtte be om det. I mange tilfeller er det viktig for brukeren å få informasjonen så snart den er tilgjengelig.
Push Access-protokollen er ikke beregnet for bruk over luften.
PAP er designet for å være uavhengig av den underliggende transportprotokollen. PAP spesifiserer følgende mulige operasjoner mellom Push Initiator og Push Proxy Gateway:
- Send inn en push
- Avbryt et trykk
- Spørsmål for status for en push
- Spørsmål for funksjoner for trådløse enheter
- Resultatvarsel
Samspillet mellom Push Initiators og Push Proxy Gateways er i form av XML- meldinger.
operasjoner
Trykk innlevering
Hensikten med Push Submission er å levere en Push-melding fra en Push Initiator til en PPG, som deretter skal levere meldingen til en brukeragent i en enhet i det trådløse nettverket. Push-meldingen inneholder en kontrollenhet og en innholdsenhet, og KAN inneholde en funksjonsenhet. Kontrollenheten er et XML-dokument som inneholder kontrollinformasjon (push-melding) for PPG å bruke i behandlingen av meldingen for levering. Innholdsenheten representerer innhold som skal sendes til den trådløse enheten. Funksjonsenheten inneholder klientfunksjoner antatt av Push Initiator og er i RDF [RDF] -formatet som definert i User Agent Profile [UAPROF]. PPG KAN bruke funksjonsinformasjonen for å validere at meldingen passer for klienten. Responsen på push-forespørselen er et XML-dokument (push-response, avsnitt 9.3) som indikerer initial aksept eller fiasko. PPG MÅ i det minste validere mot DTD [XML] kontrollenheten i meldingen og rapportere resultatet i svaret. PPG KAN indikere, ved å bruke fremdriftsnotat (hvis forespørsel fra Push-initiativtakeren i attributtet om fremdriftsnotater-forespurt), at andre valideringer er fullført. Innholdet og antall fremdriftsnotater er implementeringsspesifikt. En typisk svarmelding kan inneholde fremdriftsnotater for hvert trinn i intern prosessering. Behandlingsstadiene som er brukt er implementeringsspesifikke. Det er bestemmelser i Push-meldingen for å spesifisere flere mottakere. Svarmeldingen tilsvarer innsendingsmeldingen, så det er en svarmelding for en pushmelding, uavhengig av antall angitte adresser. Hvis Push Initiator ønsker informasjon relatert til det endelige resultatet av leveransen, MÅ den be om et resultatvarslingsinformasjon i push-innsendelsen og oppgi en returadresse (f.eks. URL).
Resultatvarsel
Denne operasjonen brukes av PPG for å informere initiativtakeren om det endelige resultatet av en push-innsending, hvis Push Initiator ber om det. Denne varslingen (pil 5 nedenfor) forteller Push Initiator at meldingen ble sendt (overført, som i pil 3), levert (bekreftelse mottatt fra trådløs enhet, som i pil 4), den gikk ut, ble kansellert eller at det var en feil. Hvis det oppstod en behandlingsfeil, SKAL varselet sendes umiddelbart etter at feilen ble oppdaget til Push Initiator, og meldingen skal ikke sendes til klienten. Ellers MÅ varselet sendes etter at leveringsprosessen for meldingen er fullført. Leveringsprosessen anses som fullført når meldingen ikke lenger er en kandidat for levering, for eksempel meldingen er utløpt. Hvis push-innleveringen er indikert som avvist i trinn to i figur 3, vil ingen resultatvarsling bli sendt. Push Initiator MÅ ha oppgitt en returadresse (f.eks. URL) under pushoperasjonen for at denne varslingen skal være mulig.
Trykk avbestilling
Hensikten med Push Cancellation er å la Push Initiator prøve å avbryte en tidligere innsendt push-melding. Push Initiator initierer denne operasjonen. PPG svarer med en indikasjon på om forespørselen var vellykket eller ikke.
Statusforespørsel
Med statusforespørselsoperasjonen kan Push Initiator be om gjeldende status for en melding som tidligere er sendt inn. Hvis det blir bedt om status for en melding som er adressert til flere mottakere, MÅ PPG sende ett enkelt svar som inneholder statusforespørselsresultater for hver av mottakerne.
Forespørsel om klientfunksjoner
Denne operasjonen lar Push Initiator spørre PPG om funksjonene til en spesifikk enhet. Responsen er et flerparti / relatert dokument som inneholder ccq-respons (avsnitt 9.11) -elementet i et XML-dokument, og i den andre enheten, den faktiske klientfunksjonsinformasjonen i RDF [RDF] som definert i brukeragentprofilen [UAPROF]. PPG KAN legge til funksjonene som er rapportert hvis PPG er villig til å utføre transformasjoner til formatene som støttes av klienten. For eksempel, hvis en klient har JPG-støtte, men ikke GIF, og en PPG er villig til å konvertere GIF-filer til JPG, kan PPG rapportere at klienten kan støtte JPG- og GIF-filer. Funksjonene som er rapportert kan være de kombinerte PPG- og klientfunksjonene, og de kan ha blitt avledet fra øktfunksjoner eller hentet fra en CC / PP-server. Evner kan også avledes ved bruk av implementeringsavhengige midler.
adressering
Det er tre adresser som Push Initiator skal vurdere: push-proxy-gateway-adressen, den trådløse enhetsadressen og resultatvarslingsadressen. Push-proxy-gateway-adressen må være kjent av Push Initiator. Denne adressen er nødvendig på laget under push access-protokollen. Push-proxy-gatewayen adresseres ved hjelp av en unik adresse som er avhengig av den underliggende protokollen. For eksempel, når den underliggende protokollen er HTTP, brukes en URL [RFC1738]. Enhetsadresseringsinformasjonen er inkludert som en del av meldingens innhold (XML-merket innhold). Ethvert tegn som er tillatt i en RFC822-adresse, kan vises i enhetsadressefeltet. I tillegg kan en "varsling-bedt om" -adresse gis av Push Initiator når det er nødvendig, slik at push-proxy-gatewayen senere kan svare på Push Initiator med resultatvarsel.
Flere mottaker adressering
Det er scenarier der en Push Initiator kan sende identiske meldinger til flere mottakere. I stedet for å sende inn flere identiske push-meldinger, en til hver mottaker, kan Push Initiator sende inn en enkelt push-melding adressert til flere mottakere. Denne delen er ment å tydeliggjøre atferd relatert til operasjoner på flere mottakere. Når PPG returnerer push-svar-meldingen, svarer svaret etter meldingen til flere mottakere, uavhengig av antall mottakere som er spesifisert i push-innsendelsen (det er ett svar for hver push-innsending). Når en Push Initiator ber om status (avsnitt 9.8) med flere adresser angitt, MÅ PPG svare med et enkelt status-spørsmål-svar (avsnitt 9.9) som inneholder de individuelle statusene. Det samme er tilfelle når bare en push-id er spesifisert (ingen adresse oppgitt) i spørringen for status for en melding om flere mottakere. Resultatvarsler (avsnitt 9.6) MÅ sendes av PPG for hver enkelt mottaker, hvis resultatvarsling blir bedt om av Push Initiator under innsending av en melding til flere mottakere. I tilfeller der en melding sendes til flere mottakere og senere blir bedt om en avbrytelse av initiativtakeren, vil PPG KAN sende tilbake individuelle svar relatert til hver av de flere mottakerne, eller den KAN sende svar relatert til mange eller alle mottakerne. Støtte for flere adresser er VALGFRITT i en PPG.
Multicast / Broadcast-adresser
Det er scenarier der en enkelt adresse sendt inn av en PI kan utvides med en PPG til flere adresser for levering. I tillegg kan en enkelt adresse overført i et trådløst nettverk mottas av flere enheter (f.eks. Kringkasting). Denne typen tjenester forventes for distribusjon av informasjon av interesse til en bred befolkning (f.eks. Nyheter, vær og trafikk). Denne delen er ment å tydeliggjøre atferd relatert til operasjoner som involverer multicast- og kringkastingsadresser. Siden adresseutvidelsen gjøres i PPG eller i det trådløse nettverket, er oppførselen mellom PI og PPG identisk med atferd som om adressen ikke ble utvidet. Svaret inneholder den individuelle adressen som sendt inn av PI.
Meldingsformat
Trykktilgangsprotokollen er uavhengig av transporten som brukes. PAP-meldinger har kontrollinformasjon, og i tilfelle push-innsending, også informasjon om og informasjon om klientfunksjoner. Kontrollinformasjon inkluderer kommando- / svarmeldinger mellom PPG og Push Initiator, og parametere som er sendt til PPG for bruk ved sending av innhold til den trådløse enheten. Eksempler på denne type informasjon inkluderer den trådløse enhetsadressen, leveringsprioriteten for meldingen, etc. Denne informasjonen blir normalt ikke levert til den trådløse enheten. Innhold er informasjon som er ment for den trådløse enheten. Denne informasjonen kan være forståelig bare for den trådløse enheten (f.eks. Kan være kryptert av Push Initiator eller kan være applikasjonsdata for en applikasjon som er ukjent for PPG), eller den kan være gjenkjennelig av PPG (f.eks. HTML eller WML). PPG kan være konfigurert til å utføre en viss transformasjon på gjenkjennelig innhold (f.eks. HTML til WML) for visse trådløse enheter. Den andre kategorien av informasjon er informasjon om klientfunksjonalitet som spesifisert i brukeragentprofilen [UAPROF]. Når mer enn kontroll utføres i en melding, er formatet til meldingen et MIME-multipart / relatert [RFC2387] sammensatt objekt. Når bare kontrollinformasjon (f.eks. For meldingssvar) blir ført i en melding, er formatet til meldingen en enkel applikasjon / xml-enhet. All informasjon blir transportert i et enkelt meldingsorgan. I multipart-meldingene inneholder den første enheten all push-relatert kontrollinformasjon i et XML-dokument, den andre enheten inneholder innholdet for den trådløse enheten, den tredje enheten, hvis den er til stede, inneholder UAPROF-klientfunksjoner. Formatet til innholdsenheten er spesifisert i [PushMsg].
Kontroll entitetsformat
Kontrollenheten er en MIME-kroppsdel som inneholder et XML-dokument som inneholder ett pap-element som definert i avsnitt 9.1. Kontrollenheten MÅ inkluderes i hver PAP-forespørsel og svar. Kontrollenheten MÅ være den første enheten i MIME-multipart / relaterte meldingen.
Innholdsenhetsformat
Innholdsenheten er en MIME-kroppsdel som inneholder innholdet som skal sendes til den trådløse enheten. Innholdstypen er ikke definert av PAP, men kan være av enhver type så lenge den er beskrevet av MIME. Innholdsenheten er bare inkludert i push-innsendelsen og er ikke inkludert i noen annen operasjonsforespørsel eller svar. Innholdsenheten MÅ være den andre enheten i MIME-multipart / relaterte meldingen.
Funksjoner Enhetsformat
Funksjonsenheten er en MIME-kroppsdel som inneholder Push Initiators antatte undergruppe av funksjonene til den trådløse enheten / brukeragenten. Funksjonsformatet er spesifisert i User Agent Profile [UAPROF]. Funksjonsenheten, hvis den er til stede, MÅ være den tredje enheten i Push Submission MIME multipart / relatert melding, og MÅ være den andre enheten i et svar om klientfunksjoner.
