NO323223B1 - Et system, en fremgangsmate og protokoll for mobil e-post-kommunikasjon - Google Patents

Description

Teknisk område

Foreliggende oppfinnelse gjelder feltene mobilkommunikasjon og Internett-post, og spesielt gjelder den en fremgangsmåte og en protokoll for overføring av epostmeldinger til og fra nevnte mobilenhet.

Bakgrunn for oppfinnelsen

Dagens post-kommunikasjonssysterner består av en epost-server for å sende post over internett, og en epostklient for å lese og skrive epostmeldinger. Klienten befinner seg normalt på en personlig datamaskin med rikelig prosesseringskraft og lagringskapasitet. Overføring av post er en komplisert prosess som gjør bruk av flere kommunikasjonsprotokoller. Protokollene er konstruert med tanke på en fast terminal, hvilket skaper problemer når en bruker ønsker å lese eller sende post fra en terminal med mer begrenset kapasitet, f.eks. en mobiltelefon. Eksisterende løs-ninger tar ikke hensyn til begrensningene ved mobiltelefoner, dvs. begrensede prosesserings- og lagringsmuligheter, begrenset navigeringsevne, små tastaturer. Hverken begrensningene i de trådløse nettverkene, dvs. ustabile tilstander og lang ventetid, eller uforutsigbar QoS blir ivaretatt. Nærmere bestemt skyldes problemene som oppstår protokollene som skaper overveldende meldingsutveksling mellom klient og server, og unødig overhead i forskjellige deler av eposten. Dette skaper problemer i en kommunikasjonskanal med begrenset båndbredde. I tillegg vil alt for komplekse fremstil-linger av epostmeldingene skape problemer for visning på en dataskjerm med begrenset størrelse og oppløsning. Andre problemer skyldes presentasjonsformater som ikke er støt-tet. En mobilterminal har vanligvis både begrenset prosesseringskraft og begrenset plass for lagring av programmer. Epostklienter er ofte av kompleks natur, noe som er tungt å implementere på en mobilklient med begrenset yteevne. Endelig vil strenge brannmuroppsett by på problemer for mobil tilgang.

Det har vært gjort forsøk på å skape mer effektive løsning-er for mobiltilgang til post, f.eks. ved å bruke VPN-kanaler mellom server og klient, eller ved å innføre en ekstra web/WAP-postserver til å håndtere trafikken mellom epostserveren og klienten. Disse løsningene skaper imidlertid sine egne problemer.

Sammenfatning av oppfinnelsen

Det er derfor behov for en løsning for mobil tilgang til epostmeldinger som unngår manglene som hefter ved post-kommunikasjonssysterner i tidligere teknikk skissert ovenfor.

Det er en hensikt med foreliggende oppfinnelse å skaffe en fremgangsmåte og protokoll for mobil epostkommunikasjon som er bedre tilpasset til en kommunikasjonskanal med begrenset båndbredde enn tilfellet er med systemer i tidligere teknikk.

En annen hensikt er å skaffe en fremgangsmåte og protokoll som fører til at epostmeldingene kan vises korrekt på en dataskjerm av begrenset størrelse.

En ytterligere hensikt er å skaffe en fremgangsmåte og protokoll som er mindre krevende når det gjelder prosesseringskraft og lagringsmuligheter i mobilklienten.

Hensiktene ovenfor blir oppnådd i en fremgangsmåte for mobil epostkommunikasjon som beskrevet i vedlagte krav 1, samt en protokoll for overføring av epostmeldinger som beskrevet i krav 16. Foretrukne utførelser av oppfinnelsen vil fremgå av de tilsvarende uselvstendige krav.

Nærmere bestemt består oppfinnelsen i en fremgangsmåte for mobil epostkommunikasjon mellom en epost-server med POP/IMAP/SMTP grensesnitt og en mobilterminal med en epostklient med SOAP grensesnitt, via en server for epost-tjenester med POP/IMAP/SMTP grensesnitt så vel som SOAP grensesnitt, idet nevnte fremgangsmåte inkluderer følgende: sending av SOAP-meldingsforespørsler fra mobilterminalen til serveren for epost-tjenester, som inneholder forhånds-definerte metodekall for pålogging og autentifisering av brukeren, for å hente en postkasse fra en konto, for å hente overskriftene fra meldinger i en postkasse, for å hente postmeldingsinnhold som informasjon som beskriver innholdet, for å hente innholdet i et vedlegg, for å slette en melding, for å sende post fra mobilklienten, og som har som parameter en melding i XML-protokollformat,

konvertering av forespørslene i serveren for epost-tjenester til standard epostmeldinger, og sende nevnte standard epostmeldinger til epostserveren, og returnere meldinger til mobilterminalen som SOAP-meldinger med innhold i XML-protokollformat.

Videre består oppfinnelsen av et epost-kommunikasjons-protokollformat for overføring av meldinger til og fra en mobilterminal, inkludert følgende: et <Headers>-element som inneholder et begrenset sett informasjon som er relevant for en bruker av mobilterminalen, et <Flags>-element avbildet direkte fra IMAP-spes i f ikas j onen,

et <Body>-element av type «text/plain»-MIME.

Kort beskrivelse av tegningsfigurene

Oppfinnelsen vil nå bli beskrevet i detalj med henvisning til de vedlagte tegningsfigurene, der: Figur 1 viser arkitekturen for nåværende postsystem (kjent teknikk). Figur 2 viser sammenhengen mellom et SMTP-postobjekt og en melding i Internett meldingsformat (Internet Message Format) (kjent teknikk).

Figur 3 viser en SMTP-konvolutt (kjent teknikk).

Figur 4 viser eksempler på epost-strukturer (kjent teknikk) .

Figur 5 viser en VPN-løsning (kjent teknikk).

Figur 6 viser en Web/WAP-post overordnet arkitektur {kjent teknikk). Figur 7 viser en foreslått ny løsning med endefrem avbildning av SMTP, POP, IMAP til XML-Web-tjeneste. Figur 8 viser en alternativ ny løsning der XML-webtjenesten gjør bruk av XMTP. Figur 9 illustrerer oppfinnelsens løsning ved sending av en epostmelding ved bruk av XMMAP. Figur 10 viser oppfinnelsens webtjeneste-arkitektur for epost med bruk av XMMAP. Figur 11 viser meldingsgangen som forekommer mellom delta-kende komponenter ved sending av en epostmelding ved bruk av XMMAP.

Figur 12 viser grensesnittene for Web-tjeneste.

Figur 13 viser en modell av Web Service Enterprise.

Detaljert beskrivelse

Som vist på figur 1 består nåværende postkommunikasjons-systemer av to hovedkomponenter, nemlig epost Server og epost Klient. Disse er begge satt sammen av flere elementer som nytter flere kommunikasjonsprotokoller, og av interne serviceelementer. Eksempler på protokoller er SMTP (Simple Mail Transfer Protocol) [4], IMAP (Internet Message Access Protocol) [5] og POP (Post Office Protocol) [6].

For å sende en epostmelding vil brukeren samvirke med bru-kergrensesnittet (User Interface - Ul), som bistår ved opp-setting av en epostmelding. Når brukeren ønsker å sende epostmeldingen, vil Ul overlevere meldingen til MUA (Mail User Agent), som vil opprette en SMTP-økt med den fjerntliggende MSA (Mail Submission Agent) for å ekspedere posten. MSA kan utføre forhåndsspesifiserte tilpasninger av meldingen for å tillempe til SMTP-IMF-standardene [7]. Der-nest leverer den posten enten til en lokal bruker via en LDA (Local Delivery Agent), eller til en MTA (Message Transfer Agent) som videresender posten til dens sluttmot-tager(e).

Et SMTP postobjekt inneholder en konvolutt og innhold. SMTP-konvolutten blir sendt som en rekke SMTP-protokollenheter. Den består av en opprinnelsesadresse (som feilrapporter blir å sende til), en eller flere mottagerad-resser og valgfritt materiale med protokollutvidelse. His-torisk kunne varianter av mottageradressekommandoen {RCPT TO) brukes til å angi alternative leveringsmåter, slik som umiddelbar visning; slike varianter er nå av mindre inter-esse.

SMTP-innholdet blir sendt i protokollenheten SMTP DATA, og har to deler: overskrift og brødtekst. Dersom innholdet er i samsvar med andre gjeldende standarder, danner overskriftene en samling av felt/verdi-par, strukturert i samsvar med Internet Message Format; brødteksten, dersom den er strukturert, er definert i samsvar med MIME (Multipurpose Internet Mail Extensions).

Posten vil så bli sendt fra MTA til MTA og vil til slutt ankomme til den endelige leverings-MTA som legger posten i meldingslageret {Message Store) via en LDA. Dette avslutter SMTP-overføringen av meldingen.

For å sende og/eller videresende post må vi følge protokollen som er beskrevet i RFC2821 [4] . Denne kommandosekvensen blir ofte kalt «SMTP-konvolutten» (SMTP envelope).

SMTP Envelope - overveldende meldingsoverføringer

Dette er et eksempel på en typisk «SMTP Envelope» for sending av en normal epostmelding til to mottagere. Det er verdt å legge merke til de overveldende meldings-overføringene:

220 dusl2.nta.no ESMTP Exim 3.35 #1 Fri, 09 Apr 2004 15:57:01 +0200

BHLO dusl2.nta.no

250-dusl2.nta.no Heilo jonfinng at localhost [127.0.0.1]

250-SIZE

250-PIPELINING

250 HELP

MAIL FROM:<jonfinng@stud.ntnu.no>

250 <jonfinngSstud.ntnu.no> is syntactically correct

RCPT TO:<luser8dusl2.nta.no>

250 <luserGdusl2.nta.no> verified

RCPT TO:<jonfinnglfstud.ntnu.no>

250 <jonfinng8stud.ntnu.no> verified

RCPT TO:<jonfinng@dusl2.nta.no>

250 <jonfinng8dusl2.nta.no> verified

DATA

354 Enter message, ending with "." on a line by itself

X-header: Testmessage

Headers (header part of the message) goes here...

content (body part of the message) goes here...

attachments goes here...

250 OK id=lBBwZ4-0000nZ-0O

QUIT

221 dusl2.nta.no closing connection

Som det fremgår av figur 3, kreves det minst 11 meldings-overføringer mellom klient og server for å sende en enkelt epostmelding. To ekstra overføringer blir innført for hver ekstra mottager. Ved sending av multiple epost-meldinger med bruk av samme forbindelse til postserveren kreves det minst ni meldingsoverføringer. Dette er ikke ønskelig, idet det er et mål å holde antall meldingsoverføringer på et ab-solutt minimum. Grunnen er at meldingsutvekslinger innfører ekstra overhead og forsinkelser som det er spesielt viktig å holde på et minimum når det brukes en trådløs forbindelse med lav båndbredde.

IMF og MIME - unødvendige overskrifter og komplekse brød-teksts truk turer

IMF (Internet Message Format) og MIME (Multipurpose Internet Mail Extensions) [8] er standarder brukt til å representere det egentlige innholdet i epostmeldingen. IMF definerer hvilke overskrifter som er påkrevd og hvordan en standardmelding bør organiseres. MIME er en utvidelse av IMF, som definerer hvordan komplekse epostmeldinger bør re-presenteres. Dette er typisk epostmeldinger som har fil-vedlegg, multiple alternative representasjonsformater eller til og med vedlagte epostmeldinger inne i selve meldingen.

IMF-versjonen av en epostmelding er ganske effektiv, og den innfører ingen overhead av betydning. Dette gjør IMF til et godt utgangspunkt i et forsøk på å representere epost-meldinger som er tilpasset mobilterminaler. Problemet med IMF er ikke selve formatet, men hvordan det brukes. En epostmelding inneholder vanligvis en god del informasjon innenfor overskrifter. Det meste av denne informasjonen er ikke relevant for sluttbrukeren. Denne informasjonen kan omfatte en liste over postservere som meldingen har vært innom på veien til destinasjonen, og flere såkalte «X-headers»"!. Denne informasjonen blir vanligvis ikke presentert i bruker-agentene og innforer en betydelig grad av overhead ved sending av epost-overskrifter til mobil-agénter.

Dette er et eksempel på overskriftene i en typisk epostmelding:

Overskriftene som er markert med fet skrift, er de overskriftene som vanligvis blir presentert i en brukeragent, fordi de inneholder den informasjonen som er mest relevant for sluttbrukeren. Ved å sløyfe alle andre overskrifter vil størrelsen av overskriftelementet i denne epostmeldingen krympe fra 2351 til 323 byte og dermed redusere samlet størrelse på denne epostmeldingen betydelig. Det bør altså bare overføres et minimalt sett av overskrifter når det gjelder mobilterminaler med begrenset båndbredde og klient-funksjonalitet.

innholdet i en MIME-epostmelding er ordnet i to disposisjo-ner: INLINE og VEDLEGG {ATTACHMENT). Delene markert INLINE vil vanligvis bli vist i postklienten når eposten åpnes for lesing. Delene i INLINE-innholdet er omkodet som tekst. Delene markert som VEDLEGG består av binærdata og må åpnes i en ekstern applikasjon eller ved hjelp av en Plug-in i postleseren som kan interpretere dette bestemte vedlegget. De forskjellige delene i meldingen er skilt ved tilpassede «avgrensninger». Når det forekommer en avgrensning i meldingen, markerer denne begynnelsen på en ny del. Hver del må være identifisert ved en parameter med «Content-type»

{innholdstype), som angir av hvilken MIME-type vedkommende del er. Andre parametre for en brødtekst kan være omkodingen og filnavnet på vedlegget.

Her er et utklipp fra en epostmelding som inneholder en normal tekstdel som INLINE og et vedlagt bilde som VEDLEGG. Det første overskriftelementet som er inkludert i dette elementet forteller at dette er en MlME-melding, og at postleseren må støtte MIME for å forstå denne meldingen. Når meldingen inneholder deler med ulike innholdstyper, er ba-sisinnholdstypen markert som «multipart/mixed», som i denne meldingen. Legg også merke til avgrensningene i denne meldingen (—=_NextPart_000_2a6d_- 50cl_182a) som skiller de to delene i denne epostmeldingen.

Den første brødtekstdelen er av type «text/plain» og representerer teksten i denne meldingen. Parametre sier oss at brødteksten har tegnsettet iso-8859. Den andre delen av meldingen er et vedlagt bilde med innholdstype «ima-ge/pjpeg». I denne delen er filnavnet og omkodingen tilføyd som parametre.

Dette eksempelet på hvordan innholdet i en epostmelding kan organiseres er bare én måte blant mange mulige måter å strukturere en melding på. MIME-meldinger støtter også nes-tet innhold og såkalte «multipart/alternative» brødtekstde-ler (blant mange andre innholdstyper). En «multi-part /altemative»-melding inneholder ulike presentasjoner av de samme data i forskjellige formater, slik at klienten kan velge hvilket format som passer best for presentering. Figur 4 viser noen eksempler på hvordan epostmeldinger kan organiseres i ulike brødtekstdeler.

MIME er en god og høyst tiltrengt utvidelse av vanlig post. Epost-representasjonene kan imidlertid bli meget komplekse, og kan kreve tid for prosessering på terminaler med begrenset prosesseringskapasitet. MIME krever at sluttklientene har støtte for visning eller åpning av vedleggene som er sendt. I tillegg har det ingen hensikt å sende multiple representasjoner av selve meldingen {multipart/alternative) dersom klienten ikke kan presentere den for brukeren. I slike tilfeller vil MlME-brødtekstdeler ende som unødig overhead.

Tilgangsagenter og brannmurer

Tilgangen og behandlingen av epostmeldinger lagret i meldingslageret åpnet av en Tilgangsagent {Access Agent) som implementerer protokoller slik som IMAP {Internet Message Access Protocol) eller POP {Post Office Protocol). Klien-tens applikasjon vil inneholde enten en IMAP-klient eller en POP-klient (eller begge deler) for henting av epost og postkasseoperasjoner, Dette kommer selvsagt i tillegg til programvaren som kreves for å sende post ved bruk av SMTP.

I mange tilfeller vil klientene og serveren befinne seg på et intranett beskyttet av bedriftens brannmur, som hindrer adgang til epostserveren fra utsiden av dette nettet. Dette gjøres for å beskytte serveren fra eksterne angrep og hack-ingsforsøk, samt for å stoppe uønsket videresendingsaktivi-tet, som kan inkludere spamming. På den annen side blir brukerne stadig mer mobile og ønsker tilgang til sine epostkontoer også når de befinner seg utenfor bedriftens intranett. Dette medfører en interessekonflikt mellom sik-kerhet og tilgjengelighet.

Problemene med dagens postsystemer når tilgangen skjer fra mobile terminaler kan sammenfattes som følger:

Overveldende meldingsutveks1ing.

Unødig overhead i forskjellige deler av epostmeldingen.

For komplekse representasjoner av epostmeldingene.

Presentasjonsformater som ikke er støttet.

Kompleks implementering av epostklienter. Ulike protokoll-utførelser kreves for sending og henting av epost.

Problemer i samband med mobil tilgang, som følge av strenge brannmurinns tillinger.

Aktuelle alternativløsninger og deres begrensninger.

Mye. arbeid er nedlagt for å løse problemet som gjelder brannmurinnstiIlinger, som ofte sperrer tilgang til post-operasjoner utenfor bedriftens intranett. Flere mer eller mindre vellykkede forsøk er fremkommet. Løsningene kunne virke bra med bærbare eller stasjonære datamaskiner, men til nå har løsningene sterke bergrensninger når de brukes til å sende epost til mobiltelefoner.

Virtuelt privatnett

I denne løsningen, vist på figur 5, oppretter en VPN-klient en sikker kanal fra den fjerne datamaskinen via Internett og gjennom brannmuren til bedriftens intranett. Klienten er altså logisk tilkoblet til intranettet, og brukeren kan bruke en normal epostklient til å få tilgang til sin epost ved hjelp av standard protokoller.

Denne løsningen passer meget bra for en PC med tilstrekkelig prosesseringskraft og lagringsmuligheter samt en noen-lunde stabil forbindelse med en betraktelig overføringshas-tighet. Denne løsningen passer ikke for mobiltelefonapparater av flere grunner, nemlig: De fleste mobiltelefonapparat er ikke utstyrt med en VPN-klient.

Mobiltelefonapparater har ikke tilstrekkelig prosesseringsevne til & oppveie overhead som følger av krypteringen og dekrypteringen.

Den ustabile trådløsforbindelsen kan innføre problemer under VPN-økten.

Sporadisk posttilgang for mobilbrukeren er ikke praktisk på grunn av lang oppsettingstid og eventuelt tidsutløp for VPN-forbindelsen.

Mobiltelefonapparater har neppe tilstrekkelig lagringsplass for alle epostmeldingene.

Mobiltelefonapparater har neppe tilstrekkelig prosesseringsevne og lagringsevne til å huse både en SMTP-klient og en IMAP/POP-klient.

Mobiltelefonapparater har meget mer begrensede evner når det gjelder brukergrensesnitt, nemlig liten skjerm, begrensede navigeringsmidler samt et lite og begrenset tastatur.

Mobiltelefonapparater finnes i en rekke ulike typer, noe som vanskeliggjør konstruksjon av grensesnitt.

Web/WAP-post

Som vist på figur 6, introduseres det nå en Web/WAP-postserver. Den er vanligvis plassert i DMZ {De-Militarised Zone - «demilitarisert område»} mellom Internett og bedriftens intranett. Web-applikasjonsserveren synkroniserer med bedriftens postserver innenfor brannmuren når det gjelder henting og sending av post. Denne serveren inneholder faktisk en Web-applikasjon med samme kjerneelementer som en epostklient. Begge utførelser bruker SMTP og IMAP/POP til å kommunisere med epostserveren. Brukeren har tilgang til sin post ved hjelp av en WWW-nettleser.

Hovedfordelen ved denne løsningen er at en bruker av mobiltelefon ikke trenger annet enn en WWW-nettleser for å få tilgang til posten. Det kreves ingen annen funksjonalitet i mobiltelefonapparatet. Mobiltelefonapparatet kan gå inn på brukerens epostkonto på webpostserveren enten direkte ved bruk av en HTML/xHTML-nettleser eller via WAP ved bruk av en WML-nettleser. Det er verd å merke seg at dette alterna-tivet også gjelder rene webposttjenester som Hotmail, Ya-hoo, Online osv.

Manglene er:

Postmeldingene blir ikke lagret i mobiltelefonapparatet, men på Web/WAP-postserveren. For å lese samme post to gang-er må brukeren gå inn på Web/WAP-serveren på nytt. Dette skyldes den relakserte html/WML-standarden der det er vanskelig å skille ut det virkelige informasjonsinnholdet fra presentas j onsinnpakkingen.

Lesing av posten kan være tidkrevende og mindre fleksibelt fordi web/WAP-sidene blir generert dynamisk i farten for hver tilgang. Mellomlagring på mobiltelefonapparatet er vanskelig og krever mye lagringskapasitet, igjen takket være den overveldende mengden av presentasjonsdata som føl-ger sammen med informasjonsinnholdet.

Postmeldingene er ikke tilpasset visning på små skjermer.

Problemer med kjente løsninger

.Som gjennomgått tidligere lider de eksisterende løsningene for mobiltilgang til epost under det faktum at de ikke tok hensyn til begrensningene i mobiltelefonapparatene, nemlig begrenset prosesserings- og lagringsevne, liten skjerm, begrenset navigeringsmulighet, lite tastatur. Verken begrens-

ningene i trådløse nett, dvs. ustabile forbindelser og lang ventetid, eller uforutsigbar QoS er riktig hensyntatt.

Oppfinnelsens område

Foreliggende oppfinnelse består av to elementer:

En arkitektur basert på XMMAP som setter mobilbrukeren i stand til å komme til, sende og behandle egen post lagret på en postserver som befinner seg på brukerens bedrifts-intranett.

En protokoll kalt XMMAP (XML Mobile Email Access Protocol) som består av et sett fremgangsmåter og en datamodell som overflødiggjør funksjonskravene til mobiltelefonapparatene og reduserer mengden av data som blir sendt til mobiltelefonapparatet .

Mobil posttiIgang mad SMTP og IMAP/POP-webtjeneste

For å tillate posttilgang fra mobiltelefonapparater har XML-webtjenesten vist seg å være godt tilpasset, takket være allestedsnærværeisen av Internett og evnen til å passere gjennom brannmurer ved hjelp av SOAP (Simple Object Access Protocol) [2]. Den mest direkte løsningen er å eks-ponere hele SMTP og IMAP/POP som webtjenester, som vist på figur 7. Hver SMTP og IMAP/POP-kommando er avbildet til en webtjeneste-metode. Faktisk er hver SMTP eller IMAP/POP-kommando innkapslet i en SOAP-melding og transportert til WS-klienten.

En fordel ved denne løsningen sammenlignet med Web/WAP-løsningene, er at det ikke finnes overhead-data som angir utseendet av innholdet. Sammenlignet med VPN er denne løs-ningen mer robust takket være bruken av SOAP. SOAP har en mer avslappet måte å behandler økter på. Dette omfatter at økter kan overleve selv om forbindelsen blir brutt for et tidsrom.

Mangelen er de mange funksjonskravene som blir satt til mobiltelefonapparatet. For å få tilgang til og for å kunne hente post, må WS-klienten kunne forstå SMTP/IMAP/POP-språkene og kommunisere korrekt med epostserveren. Den må derfor være utstyrt med både en MUA (Mail User Agent) med full SMTP-støtte og en IMAP/POP-klient. Denne funksjonaliteten blir lagt på toppen av SOAP-motoren.

Andre mangler er det store antallet interaksjoner, og også den store mengden nedlastede data som denne løsningen med-fører. Dette passer definitivt ikke i trådløse nett med begrenset båndbredde.

IMAP og SMTP er ikke rene forespørsel-svar-protokoller. De omfatter også muligheten for servergenererte meldinger. Dersom fullt samsvar med SMTP og POP/IMAP skal bli oppnådd, må klientene også være i stand til å lytte etter metodepåkall fra serveren. I dette tilfellet betyr servergenerert metodepåkall en full webtjeneste-implementering på klienten. Dette er upraktisk på grunn av den begrensede prosesserings- og lagringskapasiteten ved mobi1telefonapparater. Disse har ikke en statisk internettadresse, og forbindelsen blir ofte koblet ned. Mobiltelefonapparater er med andre ord konstruert til å virke som servere.

Mobil posttilgang med XMTP

Bruken av Webtjenester i XML er ført litt videre ved innfø-ring av XMTP (XML MIME transformeringsprotokoll) [1]. XMTP er en protokoll for avbildning av IMF- eller MIME-meldinger til en XML-versjon.

Ved bruk av XML er vi i stand til å transportere hele meldingen i XML (se figur 8). Dette gjør det enklere for klienten å syntaksanalysere meldingen. En XDS (XML Definition Schema) kan brukes til å interpretere de ulike feltene i meldingen, hvorved presentering av posten i klienten potensielt blir hurtigere.

XMTP inneholder ingen funksjonalitet bortsett fra IMF-meldingsavbildningen. Dette betyr at ved bruk av XMTP må alle meldingsutvekslinger og overhead forbli som i den foregående fremgangsmåten. XMTP kan i seg selv innføre en viss mengde overhead som følge av XML-merkelapper.

Det er svært lite å vinne på å bruke XMTP i stedet for direkte avbildning, det medfører sogar ytterligere kompleksi-tet på serversiden ved å innføre en konverteringsrutine mellom SMTP og XMTP. En løsning med bruk av XMTP må derfor avvises som passende for bruk med mobi1terminaler.

Mobil posttilgang med XMMAP

Målet med innføringen av XMMAP {XML Mobile Email Access Protocol) er å løse noen av hovedproblemene som gjelder eposttiIgang fra mobiltelefonapparater, og å overvinne begrensningene og manglende tilstrekkelighet ved de tidligere foreslåtte løsningene.

Som det fremgikk av meldingssekvens-kartet på figur 3, kreves det minst 11 meldinger mellom klient og server bare for å sende en epostmelding. Dette er svært lite ønskelig når man bruker et mobiltelefonapparat. Dersom radiolinken fal-ler ut midt i en meldingssekvens, må hele prosedyren gjen-tas. Dessuten vil hver meldingsoverføring innføre unødig overhead fra de underliggende protokoller. På toppen av dette har vi hensynet til overhead i overskrifter og visning som diskutert tidligere.

Ved innføring av XMMAP reduserer vi antallet meldingsover-føringer til to for de fleste IMAP/POP/SMTP-operajoner. Som vist på figur 9, er vi nede på én melding fra mobilklienten til webtjenesten og én melding i retur.

POP og IMAP har ikke så mange meldingsoverføringer som SMTP. Ofte bare én forespørsel og ett svar er krevd per iverksettelse. På den annen side krever disse protokollene at brukeren identifiserer seg før noen operasjon blir igangsatt på kontoen. Dette innfører økt-administrasjon og ekstra forsinkelse og overhead.

Hovedgevinsten ved bruk av XMMAP er at den både kombinerer og forenkler funksjonaliteten og informasjonen gitt av MTA {SMTP), aksessagenten (IMAP(POP) og visningsformatet (SMTP-IMF/XMTP). Dette er oppnådd ved å avbilde informasjonen til et XML-format og knytte forskjellige deler av formatet til spesifikke forespørsler og responser til SOAP-metoder.

Som XMTP nytter XMMAP styrken ved XML til å forenkle oppde-ling av den mottatte informasjonen. Terminalen kan bruke en XML-parser til å hente informasjonen fra XMMAP-meldingen samt til å konstruere nye XML-dokumenter. Dette gjør at implementering av en XMMAP-kompatibel postklient er en meget enkel sak, sammenlignet med en fullskala epostklient som støtter SMTP med et stort utvalg av MIME-typer, samt klientimplementeringene av POP og IMAP.

XMMAP innfører et nytt konsept ved meldinger. Mens tradisjonelle protokoller forutsetter hyppige meldingsoverfø-ringer med veldefinerte operasjoner, er XMMAP mer fleksibel og gjør det mulig å utføre de fleste operasjoner i én ut-veksling.

XMMAP er i sin grunnleggende form en representasjon av en hel postkonto, som dekker over alt fra påloggingskreditiver til flagg i en spesifikk melding. Dette gjør det mulig å bruke deler av XMMAP-formatet til å representere ulike deler av en postkonto for ulike formål. Dette er spesielt nyttig når XMMAP brukes til å kalle metoder på postserveren. Ved påkalling av en metode blir bare de relevante delene av formatet sendt, slik at unødig overhead unngås.

XMMAP- dataformat

Som nevnt er XMMAP en representasjon av en hel postkonto. Dette avsnittet inneholder en kort beskrivelse av formatet, inkludert en rekke eksempler, vi går direkte på saken ved å gi et eksempel på hvordan den viktigste delen av en konto, en enkelt melding i seg selv, blir representert i XMMAP:

Formatet er i stor grad selvforklarende, idet det inneholder elementer fra de nevnte kjente protokollene (SMTP, XMTP, P0P3 og IMAP). XMMAP avbilder fortrinnsvis til en standard SMTP-IMF-melding, med eller uten MIME-utvidelser, og motsatt. I tillegg til dette tilfører en XMMAP-melding den nødvendige informasjonen gitt av både POP3 og IMAP posttilgangs-protokoller.

Elementet <Message> er roten i en MIME/RFC2822-me1ding. Et <Message>-element inneholder elementene <BoxNumber>J <Hea-ders>, <Flags>, <Body> og <Attachments>.

Forklaring på elementer i XMMAP

namespaces

«namespace» linker til en datert URI som inneholder relevante XML-opp1egg til å beskrive gjeldende bruk av XMMAP-protokollen.

Attributten web:about

Denne attributten er adoptert fra XMTP-formatet og inneholder meldingsidentifikatoren URI.

Elementet <BoxNumber>

Et <BoxNumber> representerer nummeret på en melding I en postkasse. Den aktuelle postkassen kan være gitt som en parameter når den ikke fremgår av omgivende sammenheng.

Elementet <Headers>

<Headers> inneholder standard RFC 2822-overskrifter med lo-kale navn som representerer overskriftnavnene. Parametre er representert ved barn-elementer.

Et hovedpoeng ved bruk av XMMAP er å unngå å overføre hver eneste overskrift som finnes i den opprinnelige SMTP-IMF-meldingen. I stedet blir det tatt sikte på å bruke bare et begrenset sett med overskrifter som overfører informasjon av betydning for sluttbrukeren. F.eks. inneholder en SMTP-melding ofte flere overskrifter med «Received» og «X». Denne informasjonen kunne være relevant ved bakoversporing av meldingsveier og for oppgaver i samband med systemspesifikk prosessering (slik som brannmur-sperring og spam-filtrering). Denne informasjonen er imidlertid ikke relevant for sluttbrukeren. For å spare lagringsplass og over-føringskapasitet i mobilterminalen bør så mange overskrift-elementer som mulig fjernes fra meldingen. Dette blir ut-ført av SMTP->XMMAP-portalen før meldingen blir levert til mobi1termina1en.

Elementet <Flags>

Elementet <Flags> tilfører gjeldende flagg i en epostmelding som barn-elementer. Ved henting med XMMAP av flagg som er satt tidligere, blir de satte flaggene sendt og taggen innehar verdien «1». Ved setting av flagg betyr verdien «1» at flagget skal settes, og «0» at flagget skal usettes. Flaggene er avbildet direkte fra IMAP-spesifikasjonen.

Elementet <Body>

Elementet <Body> (brødtekst) inneholder brødteksten i epostmeldingen. Gjeldende tegnsett blir gitt som en parameter. Dersom ingen parameter er gitt, blir det antatt «us-ascii» som i SMTP-IMF. Innholdet i elementet <Body> blir alltid representert som type «text/plain»-MIME. Dersom den opprinnelige meldingen tilfører valgfrie måter å representere meldingen på, blir alle alternativene unntatt ett fjernet fra meldingen av SMTP->XMMAP-portalen. Dersom brød-teksten bare er representert i for eksempel «text/html», blir HTML-taggene fjernet. Resultatet etter fjerning blir levert som «text/plain». Dette gjøres for å redusere mengden av data som skal sendes, samt for å levere dataene i et så enkelt format som mulig for bruk i samband med mobilterminaler.

Valgfritt kan representasjonsalternativene tilføres og de tilsvarende MIME-typene gis som parametre til elementet

<Body>. Dersom klienten ikke kan representere en brødtekst-del, vil det bli levert en feilmelding som blir vist for brukeren.

Eksempel på alternative representasjoner av elementet

<Body>:

Elementet <Attachments>

Kun aktuelt dersom meldingen inneholder vedlegg (attachments). Disse blir levert innenfor elementet <Attachments>. MIME-type og omkoding er gitt som attributter. Omkoding kan utelates, i så fall antas base64. I tillegg inneholder et vedlegg-element elementene <Filename>, <Size> og <Content> som inneholder henholdsvis filnavnet, størrelsen, samt innholdet i form av binæromkodede data.

vedlegg kan være store, og i mange tilfeller er brukeren ikke interessert i å laste ned slike, men vil bare motta-me 1 dings teksten og beskrivelsen av vedlegget. I slike tilfeller kan elementet <Content> være tomt (<Content/>). Selv om elementet <Content> er tomt, mottar brukeren informasjon om filtype, filnavn og størrelse på filen. Ut fra disse opplysningene kan brukeren avgjøre hvorvidt han vil laste ned vedleggene senere eller ikke.

De elementene som er beskrevet er tilstrekkelig til å representere en epostmelding. Inkludert elementer både fra representasjonsformat SMTP-IMF og flagginformasjon brukt i tilgangsprotokoller. For å representere en hel konto kreves det imidlertid noen elementer i tillegg. En representasjon på en hel konto med bruk av XMMAP er vist nedenfor.

Kontorepresentasjon med bruk av XMMAP:

Elementet <Account>

Elementet <Account> {konto) representerer en hel epostkonto med all dens meta-informasjon samt innhold. Kontoen inneholder elementer <Mailboxes> (postkasser). Kontoelementer kan også omfatte påloggingsakkreditiver. Dette kan være

<UserName>, <PassWord>, <Protocol> and <Port> (brukernavn, passord, protokoll og port). Elementet <Account> er bare nødvendig ved pålogging til en konto, og ved mottak av en liste over tilgjengelige postkasser fra serveren.

Elementet <Mailboxes>

En konto kan inneholde en eller flere postkasser, disse er listet innen postkasseelement-etiketten som MailBox-elementer.

Elementet <Mailbox>

Informasjon om hvor mange meldinger en postkasse inneholder, og hvor mange av dem som er nye meldinger, er ofte ønskelig. En måte å innhente denne informasjonen på er å laste ned alle meldinger i en postkasse og sjekke hvilken av dem som har de riktige flaggene satt. Dette er ikke smart å gjøre når det gjelder mobilterminaler med begrenset lagrings- og prosesseringsevne. IMAP og POP har funksjoner som gir deg denne informasjonen uten å måtte laste ned alle meldingene.

Mailbox-elementet i XMMAP-formatet gir informasjon som vanligvis leveres av POP og IMAP. Elementet kan også inneholde full gjengivelse av postkasser med innhold. <BoxName>, <Un-read>, <Total>, <Messages> og <Mailboxes> er delelementer av et Mailbox-element. <BoxName>, <Unread> og <Total> inneholder henholdsvis navnet på postkassen, antallet uleste meldinger i den, og samlet antall meldinger.

Elementet <Messages>

Messages-elementet kan inneholde en eller flere av meldingene i denne mappen. Det kan også forbli som en tom etikett dersom denne informasjonen ikke er ønsket i den aktuelle forespørselen. Et Mailboxes-element innen et Mailbox-element inneholder del-postkasser av gjeldende postkasse dersom slike finnes.

XMMAP- definerte metoder

Dataformatet XMMAP er nyttig når det gjelder å representere en konto på en minimalistisk måte, og kan også passe godt for lagringsformål. På den annen side mangler dataformatet koblingen til spesifikke metoder relatert til mobil posttilgang. Denne koblingen oppnås ved å definere SOAP-metoder som bruker XMMAP-meldinger som parametre.

Følgende sett av metoder er implementert hittil:

Metodeliste

loginMobileTarmXMMAP og loginProfileXMMAP

Dette er metoder som brukes for autentifisering. Påkrevd for henting av post, fordi fjerntliggende IMAP- og POP-servere krever autentifisering. Det tilrådes å bruke disse metodene for autentifisering, uansett pågående operasjon. Dette fordi autentifisering av brukere stort sett hindrer misbruk av tjenesten og at den åpner for bedre sporingsmu-ligheter når uønsket bruk oppdages.

Ved påkalling av disse to metodene blir en økt opprettet av webtjenesten. Det anbefales at denne økten er en SOAP-økt, men den kan også være basert på underliggende protokoller slik som HTTP. Webtjenesten administrerer også en forbindelse til postserveren som er relatert til hver økt. Økten henter en tidligere lagret profil eller den danner en ny. Profilen, inneholder blant annen informasjon, spesialtil-pasnings -egenskaper for mobilterminalen som er brukt i denne økten.

Forskjellen mellom disse to metodene er at «loginProfileXMMAP» bruker en forhåndslagret profil, mens «loginMobileTermXMMAP» tar flere innparametre som kreves for å danne en ny profil for bruk fra og med nå. Disse parametrene er typisk relatert til mobilterminalen med støtte for skjermstørrelse og maksimum antall farger. Disse parametrene er ikke en del av selve XMMAP-meldingen.

Responsen på et kall på disse metodene er en økt- og profil-lD i tillegg til XMMAP-meldingen (se eksempel nedenfor) . XMMAP-meldingen er en liste over postkassene i den forespurte kontoen.

Eksempel på forespørselsmelding:

Eksempel på responsmelding:

getMailBoxes

Denne metoden henter postkassene fra en konto når det allerede er pålogget. Meldingsutvekslingen er ganske lik pålog-gingsmetodene. Forespørselen kan imidlertid reduseres til

<Account /> eller helt utelates, siden brukeren allerede er pålogget og kontoinformasjonen er lagret innenfor økten.

getHeadersAsXMMAP og getNewHeadersAsXMMAP

Disse metodene brukes til å hente overskrifter fra meldinger i en postkasse. Det er ofte ønskelig å hente bare informasjon om ulest post, for å unngå å overfylle skjermen på mobilterminalen med informasjon om gammel epost. Derfor bør en metode kalt «getNewHeadersAsXMMAP» iverksettes i tillegg til «getHeadersAsXMMAP». Hvilke overskrifter som skal sendes og hvilke som skal skjæres vekk må være innstilt som en del av brukerprofilen.

Eksempel på forespørselsmelding:

<Mailbox>

<BoxName>INBOX.old</BoxName>

</Mailbox>

Eksempel på responsmelding:

getMessagesAsXMMAP

Som navnet antyder, er dette meldingen for å hente postmel-dings innhold. Forespørselsmeldingen må angi navnet på postkassen og nummeret (numrene) på meldingen(e). Merk at innholdet av de eventuelle vedleggene ikke blir sendt i første omgang, men bare informasjonen som beskriver dem. Brukeren kan så velge om han vil laste dem ned senere ved hjelp av metoden «getAttachmentsAsXMMAP».

Eksempel på forespørselsmelding:

Eksempel på responsmelding:

getAttachmen tAsXMMAP

Denne metoden kan påkalles for å få tak i innholdet av et vedlegg. Klienten vil ha mottatt en beskrivelse av vedlegget {vedleggene) fra et kall på metoden «getMessagesAsXM-MAP», og bruker vedleggnummeret (-numrene) til å identifi-sere hvilke vedlegg til hvilke(n) melding som han vil ha. Bare vedlegg vil bli sendt, brødtekst-innholdet blir ute-latt.

Eksempel på forespørselsmelding:

Eksempel på responsmelding:

setFlags

Denne metoden kan brukes til å sette meldingsflagg på IMAP/POP-serveren. Metoden returnerer ingenting, bortsett fra feilmeldinger dersom noe går galt. Merk: settes flagget DELETE med setFlags, markeres meldingen som slettet, men beholder den i postkassen. Se metoden Delete når det gjelder permanent sletting.

Eksempel på forespørselsmelding:

delete

Denne SOAP-metoden markerer en melding som slettet, eller sletter den permanent (også kalt expunging) fra IMAP/POP-serveren. Hvorvidt expunge skal utføres eller ikke, er gitt som en parameter til metodekallet. Standard er ikke å expunge. Metoden returnerer ingenting bortsett fra feilmeldinger dersom noe går galt.

Eksempel på forespørselsmelding:

sendMail

Dette er metoden som skal brukes til å sende post fra mobilklienten. Det er tilstrekkelig med én melingsutveksling, i motsetning til minimum 11 som SMTP krever. Dersom IMAP-protokollen brukes, vil webtjenesten sende sluttmeldingen til brukerens «Sendt»-kasse og markere meldinger som «Be-svart» i gjeldende postkasse dersom meldingen er et svar (gitt ved et «ReplyNumber»-element sammen med overskriftene) . Innsetting av flere <To>, <Cc> eller <Bcc>-overskrifter i forespørselsmeldingen legger til multiple mottagere i XMMAP. Disse overskriftene blir oppdelt av webtjenesten og konvertert til SMTP på dens utgående grensesnitt. En melding som følger RFC2822 blir også opprettet av webtjenesten ut fra mottatt informasjon, innen den blir sendt til endelig destinasjon av SMTP (se figur 11 som viser meldingsgangen mellom deltagende komponenter ved sending av en epostmelding ved bruk av XMMAP).

Eksempel på forespørselsmelding:

Denne meldingen trenger ikke noen respons dersom webtjenesten lyktes i å sende posten videre til dens endelige destinasjon. En SOAP-feil som beskriver feilen blir returnert dersom eposten av en eller annen grunn ikke kunne leveres.

logout

For å logge ut trenger serveren ikke mer informasjon enn øktens ID. Utloggingskallet er derfor en SOAP-melding med tomt brødtekstfelt.

Dette vil lukke alle forbindelser til brukerens postserver og slette økten på webtjeneste-serveren.

Sammendrag

De metodene som er beskrevet i korthet her, utgjør bare et begrenset delsett av de viktigste metodene som kan implementeres ved å koble sammen SOAP og XMMAP for eposttilgang fra mobilterminaler. I prinsippet finnes det ingen begrensninger for hvilke metoder som kan implementeres i tillegg. XMMAP-formatet er fleksibelt og lar seg utvide med nye elementer i hvilken som helst del av formatet, dersom det finnes å være gunstig. Det er ingen fast rekkefølge for hvordan dagens meldinger blir sendt etter at brukeren er logget på. Ved definering av nye metoder bør dette prinsippet føl-ges for at den enkelte meldingen skal være uavhengig både av foregående og etterfølgende meldinger.

Arkitekturoversikt

Figur 10 viser vår arkitektur og dens ulike programvarelag og grensesnitt. Webtjenestekiienten {Web Service Client - WS Client) trenger støtte for SOAP og J2ME [3] som for de andre foreslåtte løsningene. I tillegg til klient trenger denne løsningen bare en Mail User Agent (MUA) som er i stand til XML-opprettelse og deling, samt for å sende og motta XMMAP-meldinger. Med andre ord: Ingen støtte for noen annen postprotokoll er nødvendig. Dette gjør klientimple-menteringen meget enklere, sammenlignet med tradisjonelle løsninger.

Enhver operasjon på klienten trenger kun én XMMAP-melding sendt til webtjenesten, og én melding i retur, ws-motoren (WS Engine) interpreterer meldingen med klientforespørsel, utfører den nødvendige kommunikasjonen med IMAP/POP/SMTP-serveren, og konverterer resultatet til en XMMAP-melding, sendt tilbake til klienten.

Figur 11 viser samvirket mellom noen av komponentene fra figur 10 når en mobilklient sender en epost ved hjelp av webtjenesten, vi ser hvordan SMTP-samvirket blir redusert til én melding for klienten.

I n ter n web t j ene s te - f uriks j onal i te t

Som nevnt i korthet før, vil webtjenesten tilpasse postmeldingene for mobilterminaler som mobiltelefonapparater og PDA-er. Dette oppnås ved å fjerne unødige meldingsover-skri f ter. Alternative gjengivelser av samme innhold {f.eks. både klartekst og HTML-representasjoner av brødteksten) er redusert til én. Vedlegg blir som standard holdt tilbake inntil brukeren uttrykkelig ber om å få dem. Disse tiltake-ne holder mengden av sendte data og antallet meldingsutvekslinger på et minimum.

Et sammendrag av' den interne funksjonaliteten som XML-webtjenesten gir (se figur 10):

SMTP-IMF til XMMAP-portal og vice versa.

XMMAP til IMAP/POP-portal og vice versa.

Autentifisering av brukere.

Oppbevaring og behandling av brukerprofilene.

Økt håndtering for alle grensesnitt og relaterte aktive forbindelser.

Innholdstilpasning. Dette omfatter alt fra fraskilling av etiketter og vedlegg til størrelsestilpasning av bilder.

Valgfritt: Lokal mellomlagring av meldinger og vedlegg.

Sørge for de nødvendige grensesnitt (se avsnittet om grensesnitt) .

Grensenitt

XML-webtjenesten bør sørge for disse grensesnittene: SMTP-grensesnitt. XML-webtjenesten vil utføre nødvendig kommunikasjon med MSA/MTA ved sending av epost. For å få dette til å virke må den utføre all kommunikasjon med MTA ved bruk av SMTP-protokollen.

POP/IMAP-grensesnitt. Nødvendig for å hente post og behandle postkontoen. Bør også ha TSL/SSL-støtte. SOAP/XMMAP-grensesnitt. Dette grensesnittet brukes til kommunikasjon med klienten og er detaljert beskrevet i foreliggende dokument.

Valgfritt: SOAP-grensesnitt. Ett eller flere grensesnitt for kommunikasjon med andre XML-webtjenester. Eksempler kan være filtreringstjenester for spesielt innhold, slik som spamfiltre og virusfiltre.

XML-webtjenesten bør ha en hurtig forbindelse med alle grensesnitt, slik at det blir minimale forsinkelser i kommunikasjonen webtjeneste til postserver. Alle grensesnitt bør støtte kryptert kommunikasjon ved bruk av SSL/TLS.

Fordeler

Vår løsning gir færre meldingsoverføringer mellom klient og server, og mindre samhandling gir bedre ytelse for utstyr med liten båndbredde.

Fordi bare informasjon som har tilknytning til meldingen blir sendt til klienten, kan meldinger lett lagres i mobil-apparatet. Dette er ikke praktisk når epostkontoen kontak-tes via f.eks. webmail.

Innholdet blir automatisk tilpasset slik at det passer for terminalen, ved å bruke informasjon som er sendt av klient-programvaren om skjermstørrelse og fargestøtte osv. Unødig informasjon blir skåret vekk av webtjenesten før svar går til klienten.

Tidsutløp for økten er et problem ved arbeid med tjenester som krever autentifisering. Spesielt ved tilgang til Internett via et GPRS-nett vil GPRS/Internett-portalene ha en tendens til korte tidsutløps-intervaller. Gjenoppretting etter tidsutløp betyr ofte tilordning av en annen IP-adresse, som gjør hele økten på høyere lag ugyldig. Dette problemet løses når det brukes SOAP-økter, som sikrer økt-mobilitet.

Brannmurer er ikke lenger noe problem, fordi all posttra-fikk kan passere via SOAP-meldinger.

Foreliggende oppfinnelse setter flere krav til mobiltelefonapparater når det gjelder prosesserings- og lagringsevne.

Den er i høy grad på linje med standard teknikker slik som XML-webtjenester, IMAP, POP og SMTP.

Begrensninger og mulige forbedringer

Løsningen slik den nå foreligger, har fortsatt noen begrensninger. Her er noen forslag til hvordan disse kunne løses: SOAP og XML innfører selv overhead, og spiser opp mye av innsparingene som er vunnet ved bruk av XMMAP. For å gjøre datamengden enda mindre kan det være en idé å komprimere innholdet av SOAP-meldingen før overføring og dekomprimere den ved mottaging. Dette vil imidlertid kreve ekstra prosesseringskapasitet hos klienten. Dette kan potensielt bety langsom tilgang for klienter.

XMMAP-forespørselens XML-dokument kan bli unødvendig stort. Når man for eksempel bare har behov for å sende en post-ID, blir ekstra XML-merkelapper også sendt i samsvar med XMMAP-standarden. En god løsning på dette problemet er å tilby multiple SOAP-metoder på webtjenesten med samme funksjonalitet. Like metoder som tar henholdsvis XMMAP- eller enkle SOAP-datatyper som parametre.

Det finnes i øyeblikket ingen klienter som støtter XMMAP, hvilket kan bety en stor arbeidsmengde for pionerer som implementerer de første applikasjonene. Dette gjelder selvsagt for alt som er nytt, men vi tror at enkelheten og fleksibiliteten likevel vil gjøre XMMAP attraktivt.

Henting av post kan være langsom, siden dette i høy grad avhenger av forbindelsen med den fjerntliggende postserveren, som selv kan være langsom. Så lenge forbindelsen med postserveren er hurtigere enn forbindelsen til klienten, er mellomlagring mulig. Dette kan være mellomlagring av meldinger når overskriften hentes, og/eller av vedlegg ved henting av meldingene. Innholdet vil da bli preprosessert og klart for overføring når den potensielle forespørselen etter innholdet ankommer.

Utvidelse

Vår epost-tjeneste kan samvirke med andre webtjenester i et bedriftsnett med samarbeidende webtjenester. Et eksempel på dette er vist på figur 13.

Epost-webtjenesten kan også konfigureres til å virke som en MTA, og tillate å videresende epostmeldinger mellom ulike instanser i webtjenesten.

Konstruksjon av Plug-in-moduler som utnytter denne XML webtjenesten til standard epostbruker-agenter som Microsoft Outlook vil åpne for global epost-tilgang. Denne tjenesten vil være like tilgjengelig som Web/WAP-post er i dag, men tillate brukeren å bruke sin favoritt-brukeragent i stedet for et spesialgrensesnitt via en WWW-nettleser.

Henvisninger

[1] XMTP (XML MIME Transformation Protocol) http://www.openhealth.org/documents/xmtp.htm

[2] SOAP (Simple Object Access Protocol) Specification http://www.w3.org/TR/soap/

[3] Java 2 Platform, Micro Edition http://java.sun.com/j2me/

[4] SMTP (Simple Mail Transfer Protocol) http://www.ietf.org/rfc/rfc2821.txt

[5] IMAP (Internet Message Access Protocol) http://www.ietf.org/rfc/rfc2060.txt

[6] POP (Post Office Protocol)

http://www.ietf.org/rfc/rfcl939.txt

[7] IMF {Internet Message Format) http://www.ietf.org/rfc/rfc2822.txt

[8] MIME (Multipurpose Internet Mail Extensions) http://www.ietf.org/rfc/rfc2045.txt

Claims (18)

1. Fremgangsmåte for mobil epost-kommunikasjon mellom en epostserver med POP/IMAP/SMTP grensesnitt og en mobilterminal med en epostklient med SOAP grensesnitt, via en server for epost-tjenester med POP/IMAP/SMTP grensesnitt så vel som SOAP grensesnitt, idet nevnte fremgangsmåte er karakterisert ved følgende trekk: sending av SOAP-meldingsforespørsler fra mobilterminalen til serveren for epost-tjenester, som inneholder forhånds-definerte metodekall for pålogging og autentifisering av brukeren, for å hente en postkasse fra en konto, for å hente overskriftene fra meldinger i en postkasse, for å hente postmeldingsinnhold som informasjon som beskriver innholdet, for å hente innholdet i et vedlegg, for å slette en melding, for å sende post fra mobilklienten, og som har som parameter en melding i XML-protokollformat, konvertering av forespørslene i serveren for epost-tj enes ter til standard epostmeldinger, og sende nevnte standard epostmeldinger til epostserveren, og returnere meldinger til mobilterminalen som SOAP-meldinger med innhold i XML-protokollformat.

2. Fremgangsmåte i henhold til krav 1, idet metodekallene loginMobileTermXMMAP og loginProfileXMMAP for pålogging og autentifisering av brukeren inkluderer som parametre i XML-meldingen i det minste brukerens navn, passord og adresse, valgfritt også protokollen som skal brukes mot epostserveren og porten på epostserveren.

3. Fremgangsmåte i henhold til krav 1, idet metodekallet getMailBoxes brukes for å hente en postkasse fra en konto når brukeren er blitt pålogget.

4. Fremgangsmåte i henhold til krav 1, idet metodekallene getHeadersAsXMMAP og getNewHeadersASXMMAP som brukes for å hente overskriftene fra meldinger i en postkasse inkluderer navnet på postkassen som inngangsparameter.

5. Fremgangsmåte i henhold til krav 1, idet metodekallet getMessagesAsXMMAP for å hente postmeldingsinnhold som informasjon som beskriver innholdet inkluderer navnet på postkassen og postkassenummeret som inngangsparametre.

6. Fremgangsmåte i henhold til krav 1, idet metodekallet getAttachmentAsXMMAP for å hente innholdet i et vedlegg inkluderer navnet på postkassen, nummeret på postkassen og vedleggsnummeret som inngangsparametre.

7. Fremgangsmåte i henhold til krav 1, idet slette-metodekallet for å markere en melding som slettet eller for å slette meldingen permanent fra epostserveren inkluderer navnet og nummeret på postkassen som inngangsparametre.

8. Fremgangsmåte i henhold til krav 1, idet metodekallet sendMail for å sende post fra mobilklienten inkluderer navn og adresse på senderen, navn og adresse på mottageren, em-net for eposten samt brødtekstinnholdet som inngangsparametre .

9. Fremgangsmåte i henhold til krav 8, idet nevnte fremgangsmåte inkluderer å ta med en beskrivelse av vedleggs-innholdstype, et filnavn på vedlegget, en størrelse på vedlegget samt innholdet i vedlegget som inngangsparametre.

10. Fremgangsmåte i henhold til krav 1, idet nevnte fremgangsmåte inkluderer et metodekall for avlogging, realisert som en melding med tomt brødtekstinnhold.

11. Fremgangsmåte i henhold til hvilket som helst av kra-vene 1-10, inkludert komprimering av meldingene.

12. Fremgangsmåte i henhold til krav 1 eller 5, inkludert å holde tilbake vedlegg til epostmeldinger i epostserveren inntil brukeren av mobilterminalen sender en forespørsel etter dem.

13. Fremgangsmåte i henhold til hvilket som helst av kra-vene 1-10, idet nevnte fremgangsmåte inkluderer mellomlagring av alle meldinger og vedlegg i nevnte server for epost-tjenester.

14. Fremgangsmåte i henhold til krav 1, idet nevnte fremgangsmåte inkluderer fjerning av unødvendige epost-overskrifter.

15. Fremgangsmåte i henhold til hvilket som helst av kra-vene 1-10, idet nevnte fremgangsmåte inkluderer krypte-ring av alle meldinger ved hjelp av SSL/TLS.

16. Kommunikasjonsprotokoll-format for epost for å overfø-re meldinger til og fra en mobilterminal ved bruk av fremgangsmåten ifølge krav 1, karakterisert ved at protokoll-formatet inkluderer følgende elementer: et <Headers>-element som inneholder et brukerbestemt redusert sett med informasjon som er relevant for brukeren av mobi1termina1en, et <Flags>-element avbildet direkte fra IMAP-spesifikasjonen, et <Body>-element av type «text/plain»-MlME.

17. Protokollformat i henhold til krav 16, idet nevnte protokoll omfatter et <BoxNumber>-element som representerer nummeret til en melding i en postkasse i epostserveren.

18. Protokollformat i henhold til krav 16, idet nevnte protokoll omfatter et <Attachment>-element med et delelement <Filename> som inneholder navnet på en vedlagt fil, et delelement <Size> som inneholder størrelsen på en vedlagt fil, et delelement <Content> som er tomt.