Synkronisering av lagrad kalenderdata

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Synkronisering av lagrad kalenderdata

David Kjellander

LIU-IDA/LITH-EX-G–12/006–SE Linköping 2012 Institutionen för datavetenskap Linköpings universitet 581 83 Linköping

(2)

(3)

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Synkronisering av lagrad kalenderdata

David Kjellander

LIU-IDA/LITH-EX-G–12/006–SE Linköping 2012

Handledare: Daniel Arthursson

Xcerion

Examinator: Anders Fröberg

ida, Linköpings universitet

Institutionen för datavetenskap Linköpings universitet

(4)

(5)

Avdelning, Institution Division, Department

Institutionen för dataveteskap

Department of Computer and Information Science SE-581 83 Linköping Datum Date 2012-12-11 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport

URL för elektronisk version

ISBN — ISRN

LIU-IDA/LITH-EX-G–12/006–SE Serietitel och serienummer

Title of series, numbering

ISSN —

Titel Title

Synkronisering av lagrad kalenderdata Synchronization of stored calendar data

Författare Author

David Kjellander

Sammanfattning Abstract

I det här arbetet har jag undersökt möjligheten att synkronisera lagrad kalenderdata mellan två olika system.

Mitt arbete beskriver ett API, som i ena änden kommunicerar med Xcerion Baxide-Web Ser-vices, och i den andra änden med en mobil enhet med implementerat stöd för Exchange ActiveSync (t.ex. en iPhone eller Android).

Med hjälp av Exchange ActiveSync-protokollet kan man synkronisera bland annat kalender, kontakter, e-post, anteckningar och påminnelser mellan flera klienter genom en Exchange Server. Dock hamnade all implementation utöver kalendersynkronisationen av Exchange ActiveSync redan från början utanför examensarbetets ramar.

Microsoft tillhandahåller en mycket detaljerad dokumentation över Exchange ActiveSync-protokollet. Dessutom, bland annat med hjälp av Microsoft Exchange Server 2010 och pro-grammet WireShark kunde trafiken från en redan fungerande implementation av protokollet avlyssnas.

Kommunikationen mellan en klient och en Exchange Server kan antingen ske över HTTP eller HTTPS där data transporteras kodat i WBXML. Av säkerhetsskäl är det dock rekom-menderat att en Exchange Server inte tillåter trafik över HTTP.

Innan själva implementationen analyserades protokollets struktur samt vilka nödvändiga metoder som behövdes för kalendersynkronisationen. För varje unik klient lagras en synkro-niseringsfil, innehållandes information om synkroniserad data, samt en cachefil med specifik data som en Exchange Server förväntas cachelagra.

De mest tidskrävande problemen, att till exempel sätta upp testmiljö och att få implemen-tationen att avkoda WBXML data, uppstod innan själva implemenimplemen-tationen av Exchange ActiveSync-protokollet. Själva protokollet bestod av problem som möjligheter till alterna-tiva implementationer och en stor mängd detaljarbete.

Nyckelord

(6)

(7)

Sammanfattning

I det här arbetet har jag undersökt möjligheten att synkronisera lagrad kalender-data mellan två olika system.

Mitt arbete beskriver ett API, som i ena änden kommunicerar med Xcerion Baxide-Web Services, och i den andra änden med en mobil enhet med implementerat stöd

för Exchange ActiveSync (t.ex. en iPhone eller Android).

Med hjälp av Exchange ActiveSync-protokollet kan man synkronisera bland an-nat kalender, kontakter, e-post, anteckningar och påminnelser mellan flera klien-ter genom en Exchange Server. Dock hamnade all implementation utöver kalen-dersynkronisationen av Exchange ActiveSync redan från början utanför examens-arbetets ramar.

Microsoft tillhandahåller en mycket detaljerad dokumentation över Exchange ActiveSync-protokollet. Dessutom, bland annat med hjälp av Microsoft Exchange Server 2010 och programmet WireShark kunde trafiken från en redan fungeran-de implementation av protokollet avlyssnas.

Kommunikationen mellan en klient och en Exchange Server kan antingen ske över HTTP eller HTTPS där data transporteras kodat i WBXML. Av säkerhetsskäl är det dock rekommenderat att en Exchange Server inte tillåter trafik över HTTP. Innan själva implementationen analyserades protokollets struktur samt vilka nöd-vändiga metoder som behövdes för kalendersynkronisationen. För varje unik kli-ent lagras en synkroniseringsfil, innehållandes information om synkroniserad da-ta, samt en cachefil med specifik data som en Exchange Server förväntas cache-lagra.

De mest tidskrävande problemen, att till exempel sätta upp testmiljö och att få implementationen att avkoda WBXML data, uppstod innan själva implementa-tionen av Exchange ActiveSync-protokollet. Själva protokollet bestod av problem som möjligheter till alternativa implementationer och en stor mängd detaljarbete.

(8)

(9)

Innehåll

Figurer vi Tabeller vii 1 Introduktion 1 1.1 Bakgrund . . . 1 1.2 Syfte . . . 2 1.3 Avgränsning . . . 2 1.4 Metodik . . . 3 1.4.1 Reverse engineeing . . . 3 1.4.2 Dokumentation . . . 4 2 Analys 5 2.1 Kravspecifikation . . . 5 2.2 Om Exchange ActiveSync . . . 6 2.2.1 Översikt . . . 6

2.2.2 Program och Bibliotek . . . 7

3 Exchange ActiveSync-protokollet 11 3.1 Grunder . . . 11

4 Implementation 15 4.1 Förberedelser . . . 15

4.2 Implementation av Exchange ActiveSync . . . 15

4.2.1 Provision . . . 18 4.2.2 Mappsynkronisering . . . 19 4.2.3 Kalendersynkronisering . . . 19 4.2.4 Ping . . . 20 4.2.5 Övriga kommandon . . . 20 5 Diskussion 21 5.1 Testning . . . 21 5.2 Problem . . . 22 v

(10)

5.3 Optimering . . . 23 5.4 Framtida arbete . . . 23 6 Ordlista 25 7 Referenser 27 A Skärmdumpar 29 A.1 Android . . . 29 A.2 CloudTop . . . 31

B Exchange ActiveSync protokoll exempel 33 B.1 Synkronisering av en kalenderhändelse skapad på klienten (Andro-id) . . . 33

B.1.1 Data från klient . . . 33

B.1.2 Svar från Exchange Server . . . 34

B.2 Synkronisering av en kalenderhändelse skapad på Exchange Ser-vern . . . 35

B.2.1 Data från klient . . . 35

B.2.2 Svar från Exchange Server . . . 35

B.3 Kalenderhändelse lagrat på CloudMe . . . 36

Figurer

2.1 En överblick av strukturen. . . 7

4.1 Översikt av Exchange ActiveSync-protokollet. . . 17

4.2 Hämtning av en policynyckel. . . 18

A.1 Skapande av ett Exchange ActiveSync konto på en Android klient. 29 A.2 Kalenderapplikationen på en Android klient. . . 30

A.3 Kalenderapplikationen på CloudTop. . . 31

(11)

TABELLER vii

Tabeller

(12)

(13)

1

Introduktion

Ett protokoll är en uppsättning regler för att transportera data på ett standardi-serat sätt mellan olika system. Olika tjänster kan använda olika protokoll för att kommunicera mellan klient och server.

I examensarbetet har jag arbetat med en översättning mellan två olika protokoll: Exchange ActiveSync och CloudMe API. Exchange ActiveSync används normalt sett vid kommunikation mellan en klient och en Microsoft Exchange Server. Med hjälp av Exchange ActiveSync-protokollet kan man synkronisera bland an-nat kalender, e-post och kontakter mellan en klient och en Exchange Server. Ex-amensarbetet skalades ner till att innefatta endast kalenderdelen av Exchange ActiveSync.

För att kunna kommunicera med Baxide-Web Services, genom CloudMe API, an-vänds ett antal SOAP-metoder.

1.1 Bakgrund

Xcerion äger bland annat en lagringstjänst på internet kallat CloudMe, samt ett virtuellt skrivbord vid namn CloudTop. En av applikationerna på CloudTop är en kalender.

CloudMe vill utöka kalenders användbarhet genom att implementera möjlighe-ten att synkronisera kalenderhändelser mellan mobila enheter och kalendern på CloudTop.

(14)

2 1 Introduktion

Implementation av ett stöd på serversidan för Exchange ActiveSync gör det möj-ligt. Protokollet finns redan implementerat på klientsidan i de nyare versionerna av de vanligaste operativsystemen till smarttelefoner (eng. smartphones) samt surfplattor. Syftet är att man ska kunna synkronisera en kalender mellan olika mobila enheter oavsett underliggande operativsystem (t.ex. iOS eller Android). CloudMe önskade att implementationen av Exchange ActiveSync-protokollet skul-le ske genom ett API skilt från Baxide, CloudMe-tjänstens serversida. Alternativa lösningar, till exempel att implementera Exchange ActiveSync genom inköp av en Microsoft Exchange Server 2010 eller genom en öppen källkodslösning (t.ex. Zimbra) var inte heller önskevärda.

1.2 Syfte

Syftet med implementationen är att ge Xcerions användare möjligheten att syn-kronisera kalendrar mellan sina mobila enheter, till exempel mellan en

smarttelefon och en surfplatta.

1.3 Avgränsning

Redan från början avgränsades examensarbetet till att endast innefatta kalender-synkroniseringen av Exchange ActiveSync-protokollet. Det räckte även att de se-naste versionerna av protokollet implementeras (dvs. version 14.0 samt 14.1). Kravspecifikationen byggdes fram under examensarbetets gång. Utgångspunk-ten var, efter den initiala avgränsningen, kalenderdelen av Exchange ActiveSync-protokollet. Sedan efterhand, genom diskussioner med handledaren, togs imple-mentation av viss funktionalitet av Exchange ActiveSync-protokollet bort då det saknades stöd på kalenderapplikationen på CloudTop.

I enstaka fall implementerades inte stöd för viss funktionalitet även om det fanns stöd både i Exchange ActiveSync-protokollet och på CloudTop. I de fallen an-sågs det, för att kunna få en bra implementation, tas mer hänsyn till Exchange ActiveSync-protokollet då kalenderapplikationen på CloudTop lagrade kalender-händelser.

Genom att utgå från kalenderdelen av Exchange ActiveSync-protokollet och sedan skala av funktionalitet, växte kravspecifikationen för examensarbetet fram.

(15)

1.4 Metodik 3

1.4 Metodik

Eftersom det på Xcerion inte fanns någon med tidigare erfarenhet av Exchange ActiveSync-protokollet innebar examensarbetet mycket självständigt arbete. För att kunna, med utgångspunkt för Exchange ActiveSync-protokollets begräns-ningar, eventuellt prioritera bort en viss funktionalitet av protokollet använde jag mig av följande värderingar:

• hur grundläggande funktion (t.ex. lägga till kalenderhändelse kan man se som grundläggande funktionalitet)

• hur viktig funktionaliteten ansågs vara av Xcerion

• hur bra stöd det redan fanns på Xcerion för en eventuell implementation I mitt examensarbete använde jag mig av metoden reverse engineeing samt att läsa tillgänglig dokumentation. Dokumentationen Microsoft tillhandahåller är mer heltäckande därför att den också beskriver alternativa implementationer på klientsidan.

1.4.1 Reverse engineeing

Jag var medveten av att Microsoft, som ensam utvecklar och tillhandahåller do-kumentationen av Exchange ActiveSync-protokollet, använder protokollet i de-ras produkt Microsoft Exchange Server. Jag antog att därmed att en Microsoft Exchange Server därför borde ha en korrekt implementation av protokollet, det vill säga ett svar som en klient förväntar sig, vilket jag kunde utnyttja vid imple-mentation av serversidan av protokollet genom att avlyssna trafiken.

Dokumentationen Microsoft tillhandahåller är så pass heltäckande att reverse engineering inte egentligen är en nödvändig metod. Att avlyssna trafiken under-lättade dock förståelsen av dokumentationen avsevärt. Framför allt fick jag ge-nom avlyssning en klar bild hur saker och ting hängde ihop och hur själva kärnan av protokollet fungerade.

Att endast använda sig av reverse engineering är praktiskt svårt, då Exchange ActiveSync på klientsidan i vissa fall har stöd för alternativa implementationer. Dessa alternativa implementationer framgår tydligast i dokumentationen.

(16)

4 1 Introduktion

1.4.2 Dokumentation

Dokumentationen, som Microsoft ansvarar för, beskriver mer i detalj hur proto-kollet kan utnyttjas. I flera fall finns det utrymme för alternativa implementatio-ner av Exchange ActiveSync-protokollet som en klientutvecklare skulle kunna ha använt sig av. Därför har inläsning på dokumentationen varit den mest använda metoden.

Alternativa implementationer av protokollet kan till exempel. vara:

• valfria XML-taggar. Exchange Servern förväntas då använda specifika stan-dardvärden

• undantagsfall där klienten kan utelämna annars obligatoriska XML-taggar, Exchange Servern förväntas då ha cache lagrat data

• alternativt sätt att skicka de obligatoriska parametrarna. Alla parametrarna i en HTTP POST förfrågning får, men behöver inte, vara sekventiellt Base64-kodade

(17)

2

Analys

För att uppfylla kravspecifikationen har jag själv varit tvungen att ta reda på hur Exchange ActiveSync-protokollet fungerar. Jag har utnyttjat olika program och bibliotek som på olika sätt har underlättat för mig.

2.1 Kravspecifikation

Mitt examensarbete handlar om att synkronisera kalenderhändelser mellan Cloud-Me och en klient genom Exchange ActiveSync-protokollet.

Jag har band annat varit tvungen att ta reda på hur protokollet fungerar från grunden (hur kommunikation sker osv.) och sedan implementera det. Krav på vad som ska implementeras av Exchange ActiveSync har efterhand dykt upp i samband med diskussioner om protokollets omfattning, samt vilket stöd det finns för implementation på CloudMe.

• Stöd för Android (utöver iPhone/iPad) • Stöd för Unicode

• Stöd för synkronisering av tidigare kalenderhändelser (t.ex. även de som skett under senaste månaden)

• Stöd för heldagsaktiviteter

• Flytta, ändra, lägga till samt ta bort kalenderhändelser • Stöd för flera klientenheter kopplade till Exchange Servern • Autentisering med hjälp av klientcertifikat

(18)

6 2 Analys

Av dessa krav uppfylldes alla utom det sista, det förhandlades dock bort i brist av tid. Klienten ska, enligt Exchange ActiveSync-protokollet, alltid försöka auten-tisera genom HTTP basic authentication, vilket är den metod som används i min implementation tillsammans med HTTPS.

2.2 Om Exchange ActiveSync

Exchange ActiveSync är en metod för att synkronisera data trådlöst mellan mo-bila enheter och en Exchange Server. Exchange ActiveSync-protokollet ägs, ut-vecklas och dokumenteras av Microsoft. Innan 2008 var Exchange ActiveSync ett slutet protokoll därav finns det endast dokumentation tillgänglig för version 12.1, 14.0 samt 14.1 (och ev. senare versioner).

2.2.1 Översikt

I samband med en ny release av en Microsoft Exchange Server kan protokollet uppdateras. Till exempel motsvarar version 12.1 stöd för Microsoft Exchange 2007 SP1 och 14.1 stöd för Microsoft Exchange 2010 SP1. Vilken version av pro-tokollet som kommer användas avgörs genom att klienten väljer det högsta ver-sionsnumret som både Exchange Server och klienten stödjer.

Exchange ActiveSync är ett XML-baserat protokoll. För att minska ner på den trådlösa trafiken utnyttjas Wireless Application Protocol (WAP) Binary XML( WBXML) för att komprimera XML-kommunikation.

Exchange ActiveSync har stöd för att bland annat synkronisera kalender, kontak-ter, e-post, anteckningar och påminnelser mellan en Exchange Server och klient. Med hjälp av Exchange ActiveSync kan man också implementera en policy som kan begränsa vilka funktioner en användare kan utnyttja på sin klient.

WBXML

Wireless Application Protocol (WAP) Binary XML (WBXML) är en standard för att transportera XML dokument i ett mer kompakt format.

En algoritm som använder sig av WBXML bygger på att varje XML element är mappade till ett specifikt token. Även namnrymder mappas också till ett specifikt token.

Metoden, som används i Exchange ActiveSync-protokollet för att komprimera data, heter ActiveSync WAP Binary XML Algorithm.

(19)

2.2 Om Exchange ActiveSync 7

2.2.2 Program och Bibliotek

Minimal-SOAP-Server

Minimal-SOAP-Server är, som namnet anger, en minimal server som kan ta emot och skicka SOAP-meddelanden. Minimal-SOAP-serven är skriven i C++ av Xceri-on och tänkt att fungera i Ubuntu-miljö.

En klient kommunicerar endast med minimal-SOAP-servern, vilken i sin tur kom-municerar med Baxide-WS genom CloudMe API. Eftersom Exchange ActiveSync använder sig av WBXML vid kommunikation så fick jag konfigurera om servern, och med hjälp av libWBXML, avkoda inkommande data från WBXML. Utgående data till klienten kodas som WBXML.

SOAP-meddelanden används nu endast vid kommunikation med Baxide-WS (ge-nom CloudMe API).

CloudMe Filsystem

CloudMe API

CloudMe Exchange ActiveSync Server

Klient

Exchange ActiveSync

Figur 2.1:En överblick av strukturen. Min implementation, här benämnt som

CloudMe Exchange ActiveSync Server, översätter anrop från och till CloudMe Filsystem, internt kallat Baxide.

(20)

8 2 Analys

Microsoft Windows Server 2008

För att kunna installera och köra Microsoft Exchange Server 2010 krävs det en installation av Microsoft Windows Server 2008.

Microsoft Exchange 2010

För att kunna avlyssna data mellan en klient och en Exchange Server behövdes en egen installation av en Microsoft Exchange Server som inte blockerade trafik över HTTP.

Ett alternativ skulle vara att skriva all inkommande data till en fil. Det var inte möjligt innan Exchange Servern hade konfigurerats så att all inkommande data avkodades från WBXML till XML. Dessutom tyckte jag att man fick en större överblick av trafiken om man kunde använda sig av program som WireShark. WireShark

För att kunna avlyssna trafiken för att få en klarare bild över hur Exchange ActiveSync-protokollet fungerade, samt vid felsökning, använde jag mig av WireS-hark. I WireShark finns det även en inkluderad avkodare för ActiveSync-WBXML. Dock var inte avkodaren uppdaterad och klarade inte av att avkoda vissa ele-ment.

Jag kunde däremot, om det behövdes, kopiera specifik data från WireShark till en fil. Sedan kunde jag från terminalen manuellt avkoda filen med hjälp av libWBXML-biblioteket.

Ibland var det dock mer praktiskt att skriva ut data direkt i terminalen. libWBXML

libWBXML är ett bibliotek som kan koda och avkoda WBXML. Framförallt stöd-jer libWBXML ActiveSync WAP Binary XML (WBXML) Algorithm som används i Exchange ActiveSync.

Anledningen till att jag använde mig av just libWBXML var för att det var kom-patibelt med utvecklingsmiljön samt programmeringsspråket jag använde mig av.

Dessutom hade biblioteket uppdaterats relativt nyligen, vilket indikerar att det fortfarande utvecklas. Det är viktigt också att biblioteket inte är för gammalt till exempel. om senaste uppdateringen av biblioteket är äldre än senaste versionen av Exchange ActiveSync. Då finns det en risk att vissa WBXML-token avkodas fel (eller inte kan avkodas alls).

Att en gammal avkodare skulle kunna innebära problem märktes tydligt när jag avlyssnade trafiken med hjälp av WireShark. Eftersom ett element är mappat till ett specifikt token blir det fel om elementet uppdateras i protokollet men inte avkodaren.

(21)

2.2 Om Exchange ActiveSync 9

Boost

Boost är en stor samling av bibliotek, som fungerar oberoende av plattform, till för att utöka funktionaliteten för C++. Syftet med boost är att utnyttja redan ex-isterande funktionalitet i C++ och öka produktiviteten genom att standardisera metoder för att lösa förekommande problem.

Jag använder mig av boost för att förenkla och förkorta C++ kod. Till exem-pel stöter jag ofta på problemet att jag behöver representera en integer som en std::string. Med hjälp av boost kan jag abstrahera bort en sådan konversation (ge-nom s.k. lexical casting) och på så sätt slipper jag uppfinna hjulet på nytt. Ett exempel på hur boost::lexical_cast förenklar och förkortar C++ koden: #include <boost/lexical_cast.hpp>

#include <sstream> #include <string> int number = 0; std::string str;

// lexical cast int -> string

str = boost::lexical_cast<string>(number); // Konvertera string -> int

number = boost::lexical_cast<int>(str); // int -> string konvertering i C++ std::stringstream ss;

ss << number; str = ss.str();

// Konvertera string -> int ss.clear(); // återställ flaggor ss.str(""); // återställ stringstream ss << str;

ss >> number;

För att lätt kunna konvertera ett datum till olika format, modifiera ett datum eller jämföra olika datum använder jag mig även av datumobjektet ptime i klassen boost::posix_time.

Boost användes även redan innan på Xcerion, därav behövdes inget nytt bibli-otek installeras. Därför behövde jag inte i någon större utsträckning motivera användandet av boost. Boost krävs egentligen inte i min implementation men ut-nyttjandet av biblioteket underlättar mycket (särskilt vid hanteringen av datum).

(22)

(23)

3

Exchange ActiveSync-protokollet

Exchange ActiveSync är detaljerat beskrivet i dokumentationen [1-7], som tillhan-dahålls av Microsoft. I det här kapitlet beskriver jag protokollets grunder [5][7].

3.1 Grunder

Kommunikation mellan klient och Exchange Server sker antingen genom HTTP eller HTTPS, vilket bestäms genom en inställning på klientsidan. Av säkerhets-skäl är det dock rekommenderat att Exchange Servern är konfigurerad att bloc-kera all trafik över HTTP (så att en användare på klientsidan alltid väljer att kommunicera över HTTPS).

Exchange ActiveSync använder sig av HTTP basis authentication där inloggnings-uppgifterna skickas Base64-kodade. Därför bör all kommunikation mellan klient och Exchange Server ske över HTTPS.

Exchange ActiveSync bygger på förfrågningar samt svarsmeddelanden där klien-ten alltid initierar kommunikationen. Tillåtna metoder är HTTP POST och HTTP OPTIONS där eventuell innehåll är UTF-8-kodat.

En förfrågning till Exchange Servern består av en metod, URI sedan HTTP ver-sion:

POST <URI> HTTP/1.1 eller

OPTIONS <URI> HTTP/1.1

(24)

12 3 Exchange ActiveSync-protokollet

Exchange ActiveSync använder sig av en hårdkodad sökväg: det vill säga en kli-ent kommer alltid skicka förfrågningar till:

http(s)://...Exchange_Server_Website.../Microsoft-Server-ActiveSync HTTP OPTIONS

Genom en HTTP OPTIONS förfrågning får klienten svar på hur kapabel Ex-change Servern är. Klienten får som svar dels vilka kommandon samt vilka ver-sioner av Exchange ActiveSync som Exchange Servern stödjer. Därefter väljer kli-enten den högsta versionen som både klient och Exchange Servern stödjer. Ett exempel på HTTP OPTIONS förfrågning:

OPTIONS /Microsoft-Server-ActiveSync? HTTP/1.1

Headers som finns med i svarsmeddelandet från en HTTP OPTIONS förfrågning: Allow: OPTIONS,POST

MS-ASProtocolVersions: 14.0,14.1

MS-ASProtocolCommands: Sync, MoveItems, FolderSync, FolderCreate,FolderDelete,FolderUpdate,Ping,Provision

Svaret visar vilka versioner av protokollet samt vilka metoder som är imple-menterade. Denna implementation stödjer Exchange ActiveSync version 14.0 och 14.1. Headern MS-ASProtocolCommands visar vilka kommandon som är imple-menterade.

HTTP POST

Vid en HTTP POST förfrågning medföljer det ett anrop innehållandes alla para-metervärden. Dessa parametrar kan antingen skickas i klartext eller sekventiellt kodat med Base64. Vilken metod som används spelar ingen roll så länge det är konsekvent. Eftersom jag under utvecklingen inte stötte på någon klient som an-vände Base64-metoden så saknas det stöd för sådana parametrar i min implemen-tation.

Ett exempel på en HTTP POST förfrågning (med parametrar i klartext):

POST /Microsoft-Server-ActiveSync?Cmd=FolderSync&User=NN&DeviceId=ID&DeviceType=Type

Content-Length: 13

Content-Type: application/vnd.ms-sync.wbxml MS-ASProtocolVersion 14.1

(25)

3.1 Grunder 13

X-MS-PolicyKey: 0

Authorization: Basic QmFzaWM= 03 01 6A 00 00 07 56 52 03 30 00 01 01 Parametrarna

Parametrarna, som förklaras nedanför, måste skickas med i varje HTTP POST för-frågning och alla fyra parametrarna ska alltid förekomma:

• Cmd - Vilket kommando som ska köras. Tillåtna kommandon är de som specificerats i headern MS-ASProtocolCommands genom en HTTP OPTIONS förfrågning

• User - Angett användarnamn

• DeviceId - En permanent och unik sträng som representerar en klient • DeviceType - En permanent sträng som representerar vilken typ av klient

(t.ex. Android, iPad eller iPhone) Header

Observera att förekommande headers från en klient kan variera beroende på kli-ent och kommando. Endast Authorization som ska innehålla Base64 kodade in-loggningsuppgifter med hjälp av HTTP basic authentication, är enligt Exchange ActiveSync-protokollet alltid nödvändig.

Content-Typebeskriver innehållet. MIME-typen för WBXML data är: application/vnd.ms-sync.wbxml alternativt kan den kortare formen application/vnd.ms-sync

före-komma.

Normalt sett innehåller data alltid WBXML. Exchange ActiveSync har dock, vid särskilda tillfällen i specifika kommandon, stöd för att skicka HTTP POST för-frågningar utan innehåll. I dessa fall saknas denna header.

Följande headers förekommer endast om klienten skickar parametrar i klartext: Annars inkluderas värdet från dessa headers i det sekventiellt Base64-kodade parametervärdet:

MS-ASProtocolVersion specificerar vilken version av Exchange ActiveSync kli-enten använder sig av.

X-MS-PolicyKeyär en nyckel för att identifiera att klienten har uppfyllt en viss policy satt på Exchange Servern. I min implementation finns ingen policy. Då klienten aldrig kommer få någon ny nyckel än standardvärdet, kommer X-MS-PolicyKey alltid vara satt till 0.

(26)

14 3 Exchange ActiveSync-protokollet

Body

Innehållet i HTTP POST förfrågningen kommer avkodas på följande sätt:

Byte Förklaring

03 WAP Binary XML: Version: 1.3

01 Public ID: "Unknown Public Identifier” 6A Charset = UTF-8

00 String table: 0 bytes 00 07 Byt till kodsida 0x07

56 (0x40 + 0x16) enkelt element, läs token 0x16 52 (0x40 + 0x12) läs token 0x12.

03 sträng med data börjar 30 00 ’0’

01 </SyncKey> 01 </FolderSync>

Tabell 3.1:Avkodning av WBXML data. Data som skickades i exemplet kan översättas till:

<?xml version= "1.0"encoding="utf-8"?> <FolderSync xmlns=”FolderHierarchy:"> <SyncKey>0</SyncKey>

(27)

4

Implementation

I examensarbetet började jag med att sätta upp en testmiljö. Efter att ha fått en övergripande bild över Exchange ActiveSync-protokollets struktur, genom att tillämpa reverse engineering tillsammans med detaljerad dokumentation [3], implementerades de nödvändiga metoderna.

4.1 Förberedelser

Arbetet började med en installation av en Microsoft Exchange Server 2010. Detta gjordes för att kunna avlyssna kommunikationen över HTTP. Grundinställning-en på Grundinställning-en Microsoft Exchange Server är att blockera all HTTP trafik till och från klienten.

När trafiken väl gick över HTTP kunde trafiken sedan avlyssnas med hjälp av WireShark. Observera att inställningar på klientsidan bestämmer om kommuni-kationen till en Exchange Server ska ske genom HTTP eller HTTPS.

Innan implementation av själva Exchange ActiveSync-protokollet kunde imple-menteras konfigurerades minimal-SOAP-servern, som som standard endast kun-de skicka och ta emot SOAP-medkun-delankun-den, till att kunna skicka och ta emot data i WBXML-format.

4.2 Implementation av Exchange ActiveSync

Efter en inledande HTTP OPTIONS förfrågning, för att få reda på vilken version av protokollet samt vilka kommandon Exchange Servern stödjer, inleds synkro-niseringen med att ladda ner alla mappar från servern.

(28)

16 4 Implementation

Saknas det en synkroniseringsfil, där information om vad som har synkroniserats med klienten finns lagrad, returneras ett statusmeddelande som klienten tolkar som att nästa kommando bör vara en så kallad provision.

Synkroniseringsfilen lagras på användares konto på CloudMe, och kommer där-för att hämtas till Exchange Servern i varje där-förfrågning. För att minska ner på data som hämtas till Exchange Servern skapas en ny synkroniseringsfil per unik klient.

Synkroniseringsfilen innehåller:

• Information om klientens operativsystem

• Information om synkroniserade kalendrar som mapp id och namn • Information om när varje kalender senast har synkroniserats

• Information om synkroniserade kalenderhändelser, filens id lagras i ett XML element under tillhörande kalender

Det finns även en särskild cachefil. En för varje unik klient. I cachefilen sparas information som en Exchange Server förväntas cachelagra. Det är information om hur länge en klient ska polla efter uppdateringar samt information om vilka kalendrar en klient ska lyssna efter uppdateringar på.

(29)

4.2 Implementation av Exchange ActiveSync 17 Mappsynkronisering krävs provision? Provision begäran Provision bekräftande Synkronisera kalender Ping Uppdatera mapp Skapa mapp Ta bort mapp Giltig mappsynkroniserings nyckel? HTTP OPTIONS Uppdatering? Ändrad mapphierarki? Flytta objekt

Figur 4.1:Översikt av Exchange ActiveSync-protokollet.

Notera att det alltid är klienten som initierar kommunikationen. Min implementation, som består av serversidan av protokollet, påverkar flödet endast genom att ge vägledande svar till klienten i form av framför allt olika statuskoder.

(30)

18 4 Implementation

4.2.1 Provision

En så kallad provision är egentligen till för att synkronisera en policy [6]. Vilket inte används i min implementation. Istället kontrolleras här att alla nödvändiga mappar finns på servern (som skapas annars) samt skapar synkroniseringsfilen. En annan anledning till att metoden är implementerad är att man kan spara lite mer detaljerad information som klienten skickar i samband med provisionen. Till exempel version av klientens operativsystem.

Klient Server

Be om Policy

Presentera Policy

Bekräfta accepterande av Policy

Returnera PolicyKey

Figur 4.2:Hämtning av en policynyckel.

En provision går till så att klienten begär att få tillgång till Exchange Serverns policy. Exchange Servern returnerar sedan eventuell policy (eller meddelar att det saknas policy på Exchange Servern). Därefter skickar klienten information till Exchange Servern om policyn uppfylldes eller inte.

Till sist svarar Exchange Servern med en bekräftelse, och om det finns, en perma-nent policynyckel som klienten ska använda sig av i framtida förfrågningar.

(31)

4.2 Implementation av Exchange ActiveSync 19

4.2.2 Mappsynkronisering

Om provisionen lyckas görs ett nytt försöka att ladda ner mappar från Exchange Servern. Det sker genom att klienten hämtar mappens unika id på servern, vilken sedan alltid används för att referera till en specifik mapp.

En mappsynkronisering kommer ske varje gång en kalender läggs till, ändras el-ler tas bort. För att avgöra om en mappsynkronisering ska ske kontrolel-leras det regelbundet, i samband med kalendersynkronisering och ping, om det är någon skillnad mellan synkroniserade kalendrar i synkroniseringsfilen jämfört med ex-isterande kalendrar på CloudMe.

4.2.3 Kalendersynkronisering

Nästa steg är att synkronisera kalenderhändelser i en specifika kalendrar. Klien-ten kommer meddela Exchange Servern om vilka kalendrar som önskas synkro-niseras. Samtidigt som klienten begär uppdateringar av kalenderhändelser från Exchange Servern kan ett meddelande om uppdateringar av kalenderhändelser gjorda på klienten skickas med.

I synkroniseringsfilen finns information om vilka kalenderhändelser som har syn-kroniserats och en tidsstämpel då en viss kalender senast synkroniserades. Implementationen använder sig av tidsobjektet boost::posix_time::ptime för att lätt kunna jämföra två tidsstämplar med normala jämförelseoperander i C++. För att hämta ut information ur den inkommande XML-datan använder jag mig av paketet libxml2. Genom en wrapper skriven i C++ kallar jag på metoder som bland annat skapar ett XML-objekt, som kan användas för tolka XML-dokumentet, i libxml2. Därefter hämtar jag genom olika metoder ut innehållet i till exempel. ett XML-element eller ett XML-attribut.

En annat metod, som Xcerion senare valde att fortsätta med, är att använda XSLT för att transformera data mellan klient och Exchange Server samt vice versa. Be-roende från vilket håll datan kommer (dvs. klient eller Exchange Server) behövs det ett eget XSLT schema.

Fördelen med XSLT att det går att skapa dynamiska regler för XML dokument samt ger ökad läsbarhet då det blir mindre C++ kod. Anledningen till att jag använde libxml2 var dock att jag inte hade något större problem med att använda biblioteket.

(32)

20 4 Implementation

4.2.4 Ping

Sedan kommer klienten att pinga Exchange Servern. Klienten meddelar vilka mappar som är aktuella ifall någon förändring har skett. När en viss tid har gått, som klienten har skickat med i förfrågningen, förväntar klienten ett svar från Exchange Servern även om ingen förändring i någon mapp har skett.

Sker en förändring i någon mapp som är aktuell för klienten kommer Exchange Servern returnera de aktuella mapp id. Klienten kommer därefter begära att syn-kronisera innehållet i den mapp som förändring skedde i. Sedan återgår klienten till att begära att få lyssna på förändringar i mappar.

4.2.5 Övriga kommandon

Om en kalender har lagts till, tagits bort eller bytt namn på klienten kommer klienten att meddela Exchange Servern om detta. Det finns även ett kommando som meddelar att en kalenderhändelse har flyttats från en kalender till en annan.

(33)

5

Diskussion

Implementationen skulle kunna ha testats mer grundligt med flera olika klienter. Det utfördes inte på grund av brist på tid samt tillgång på olika klienter. De flesta problem, och mest tid, har lagts ner innan på att förstå samt lägga upp grunden för implementation av Exchange ActiveSync-protokollet.

Det finns fortfarande möjligheter att implementera större delar av Exchange ActiveSync-protokollet men även CloudTop skulle kunna anpassas för bättre stöd för Ex-change ActiveSync.

5.1 Testning

Vid testning av implementationen användes Android SDK samt en iPhone och en iPad. Testning utfördes genom att utföra olika moment till exempel lägga till, ta bort samt ändra en kalenderhändelse på både klient och på kalenderapplika-tionen i CloudTop.

Implementationen skulle kunna testas med ännu flera olika klienter, dock var aldrig aktuellt att testa på fler än de nödvändiga på grund av den extra tid det skulle ta. Android SDK användes vid testning då jag inte hade tillgång till någon tillräckligt ny Android-klient.

Det är först i Android 4.0 eller senare som det finns ordentligt stöd för Exchange ActiveSync. Tidigare versioner av Android har endast stöd för äldre versioner av protokollet.

(34)

22 5 Diskussion

5.2 Problem

Ett stort problem i början var att hitta utvecklingsverktyg och sätta upp utveck-lingsmiljön och testmiljön. Det fanns väldigt lite information att tillgå, både på internet eller på Xcerion, vad som skulle användas för att implementera en Ex-change Server. Det är, enligt min uppfattning, en väldigt ovanlig implementation. Det vanligaste är att företag köper en licens för en Microsoft Exchange Server eller använder någon öppen källkodslösning med stöd för Exchange ActiveSync-protokollet.

Det tillgängliga öppen källkodslösningarna var inte heller till mycket hjälp då min implementation skiljer sig avsevärt ifrån deras. Implementationen är ett API som ska kommunicera med en klient och sedan direkt med Xcerion Baxide-WS. Någon sådan implementation eller något liknande existerar inte redan, utan det var uppgiften i mitt examensarbete att skapa en sådan Exchange Server.

Ett annat problem var att dokumentationen Microsoft tillhandahåller är riktat till hur det är tänkt att en klientutvecklare ska implementera Exchange ActiveSync-protokollet. Det var ganska irriterande i början men man vande sig snabbt att vända på meningarna. Till exempel om det står att en klient förväntar sig en viss data så bör man anta att Exchange Servern ska ha skickat datan.

Det var också mycket nytt som jag behövde sätta mig in i till exempel WBXML. Dessutom fungerade inte biblioteket från början till Ubuntu. Eftersom Exchange Servern i slutändan skulle köras i Ubuntu-miljö, och därför jag inte hitta något bättre bibliotek, blev jag tvungen att själv fixa så att biblioteket (libWBXML) fun-gerade till Ubuntu då jag behövde komma framåt i examensarbetet.

Att rätta till libWBXML-modulen, tillsammans med att integrera avkodaren samt kodaren av WBXML till Exchange Servern, var den mest tidskrävande delen av examensarbetet.

Själva Exchange ActiveSync-protokollet har varit den lättare biten. Det svåra med implementationen har varit alla detaljer som protokollet innebär till exempel alternativa implementationer och omfattningen av olika element.

Ett annat problem är, om en klient får ogiltig data från Exchange Servern, så presenteras som regel inget fel. Man märker att det har blivit fel genom att inget händer, det är inte heller meningen att klienten ska meddela Exchange Server om att någonting på klienten har blivit fel. Då är det bra att kunna kommunicera med till exempel en Microsoft Exchange Server, som förmodligen har en korrekt implementation redan, och avlyssna den datan för att sedan jämföra med datan där det har blivit fel.

(35)

5.3 Optimering 23

5.3 Optimering

Det finns utrymme för att optimera koden. Till exempel skulle man kunna bygga in Exchange Servern i Xcerion Baxide. Då skulle man slippa all kommunikatio-nen över HTTP mellan Exchange Servern och Baxide-WS. Dock önskas inte någon sådan lösning.

Man skulle också kunna banta ner synkroniseringsfilen genom att spara klien-tens id i metadata, som ändå måste hämtas ner till Exchange Servern, i synkroni-serade kalenderhändelser. Anledningen till att den metoden inte används i min implementation är för att den kräver förändringar på Baxide. Problemet med en sådan lösning är att metadata om synkroniserade klienter försvinner i samband med att en fil tas bort.

Hur kalenderhändelser sparas på Baxide, genom kalenderapplikationen på Cloud-Top, skulle också kunna optimeras för att minska trafiken mellan Exchange Ser-vern och Baxide-WS. Eftersom kalenderapplikationen på CloudTop är skriven utan tanke på Exchange ActiveSync-protokollet behöver den mesta datan, till ex-empel datum, konverteras till rätt format.

Bättre anpassning till Exchange ActiveSync vid lagrandet av kalenderhändelser på Baxide skulle minska behovet att konvertera från och till olika format.

5.4 Framtida arbete

Idag fungerar det att synkronisera kalendern endast genom Exchange ActiveSync. Kalendersynkroniseringen är bara en liten del av protokollets totala omfattning. Andra delar av Exchange ActiveSync protokollet som det finns stöd för på Cloud-Top är kontakter, e-post, anteckningar och påminnelser.

(36)

(37)

6

Ordlista

Base64En metod som vanligtvis används för att koda binär data till skrivbara tecken. Som namnet anger bygger kodningen på en bas av 64 tecken.

BaxideInternt namn på serversidan av CloudMe-tjänsten. En ordlek av termerna XIDE/3 (Xcerion Integrated Development Enviroment 3) och backside.

Baxide-WSBaxide Web Services. Själva kärnan i systemet och en front-end, ge-nom ett API innehållande SOAP- och REST-metoder, gentemot klienter på Inter-net.

CloudMe-APICloudeMe Application Programming Interface. Ett antal metoder (SOAP och REST) som kan användas för att kommunicera med Baxide (genom Baxide-WS).

Exchange ServerOm ingen specifik produkt anges (t.ex. Microsoft Exchange Ser-ver) syftas det på en implementation av serverdelen av Exchange ActiveSync. klientI texten antas en klient vara en enhet som har klientdelen av Exchange ActiveSync implementerad.

SOAPSimple Object Access Protocol. Ett XML-baserat protokoll, som för trans-port är beroende av andra protokoll i applikationslagret (t.ex. HTTP), för att ut-byta information i en strukturerad form.

WBXMLWireless Application Protocol (WAP) Binary XML (WBXML). En stan-dard för att transportera XML dokument i ett mer kompakt format.

(38)

26 6 Ordlista

wrapperEn så kallad wrapper kan till exempel vara en klass vars metoder i hu-vudsak kallar på andra funktioner. Syftet med wrappern är att den gör att meto-derna bättre passar in med den övriga koden. Till exempel kan man använda en wrapper för att konvertera kod skriven i C till C++.

XMLExtensible Markup Language. Ett dokument skrivet i ren text. Dokumentet har en viss struktur, där data kan finns lagrat i särskilda element. Dessa element innehåller oftast olika direktiv.

XSLTExtensible Stylesheet Language Transformations. XSLT är ett språk för att till exempel transformera XML-dokument till andra XML-dokument.

(39)

7

Referenser

[1] Microsoft Corporation (2008) [MS-ASAIRS]: ActiveSync AirSyncBase Na-mespace Protocol Specification

Tillgänglig på Internet:

http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-ASAIRS%5D.pdf

[Hämtad 12.10.18]

[2] Microsoft Corporation (2008) [MS-ASCAL]: ActiveSync Calendar Class Pro-tocol Specification

http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-ASCAL%5D.pdf

[Hämtad 12.10.18]

[3] Microsoft Corporation (2008) [MS-ASCMD]: ActiveSync Command Refe-rence Protocol Specification

http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-ASCMD%5D.pdf

[Hämtad 12.10.18]

[4] Microsoft Corporation (2008) [MS-ASDTYPE]: ActiveSync Data Types Tillgänglig på Internet:

http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-ASDTYPE%5D.pdf

[Hämtad 12.10.18]

(40)

28 7 Referenser

[5] Microsoft Corporation (2008) [MS-ASHTTP]: ActiveSync HTTP Protocol Specification

http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-ASHTTP%5D.pdf

[Hämtad 12.10.18]

[6] Microsoft Corporation (2008) [MS-ASPROV]: ActiveSync Provisioning Pro-tocol Specification

http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-ASPROV%5D.pdf

[Hämtad 12.10.18]

[7] Microsoft Corporation (2008) [MS-ASWBXML]: ActiveSync WAP Binary XML (WBXML) Algorithm

http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-ASWBXML%5D.pdf

(41)

A

Skärmdumpar

A.1 Android

Figur A.1:Skapande av ett Exchange ActiveSync konto på en Android klient.

(42)

30 A Skärmdumpar

(43)

A.2 CloudTop 31

A.2 CloudTop

(44)

(45)

B

Exchange ActiveSync protokoll

exempel

B.1 Synkronisering av en kalenderhändelse skapad

på klienten (Android)

B.1.1 Data från klient

<Sync xmlns="AirSync:"> <Collections> <Collection> <SyncKey>1638371711</SyncKey> <CollectionId>562958543800134</CollectionId> <DeletesAsMoves/> <GetChanges/> <WindowSize>4</WindowSize> <Options> <FilterType>4</FilterType> <BodyPreference xmlns="AirSyncBase:"> <Type>1</Type> <TruncationSize>200000</TruncationSize> </BodyPreference> </Options> <Commands> <Add> <ClientId>f6f87b4c-e944-42ef-ab70-32204ffca0b9</ClientId> <ApplicationData> <TimeZone xmlns="Calendar:"> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 33

(46)

34 B Exchange ActiveSync protokoll exempel AAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAAAEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAMAAAAFAAEAAAAAAAAAxP///w==</TimeZone> <AllDayEvent xmlns="Calendar:">0</AllDayEvent> <StartTime xmlns="Calendar:">20121031T170000Z</StartTime> <EndTime xmlns="Calendar:">20121031T180000Z</EndTime> <DTStamp xmlns="Calendar:">20121029T150532Z</DTStamp> <Location xmlns="Calendar:">Xcerion</Location> <Subject xmlns="Calendar:">Example</Subject> <Body xmlns="AirSyncBase:"> <Type>1</Type> <Data/> </Body> <Organizer_Email xmlns="Calendar:">test@192.168.12.132 </Organizer_Email> <Reminder xmlns="Calendar:">10</Reminder> <UID xmlns="Calendar:">f6f87b4c-e944-42ef-ab70-32204ffca0b9 </UID> <BusyStatus xmlns="Calendar:">2</BusyStatus> <MeetingStatus xmlns="Calendar:">3</MeetingStatus> <Sensitivity xmlns="Calendar:">0</Sensitivity> </ApplicationData> </Add> </Commands> </Collection> </Collections> </Sync>

B.1.2 Svar från Exchange Server

(47)

B.2 Synkronisering av en kalenderhändelse skapad på Exchange Servern 35

B.2 Synkronisering av en kalenderhändelse skapad

på Exchange Servern

B.2.1 Data från klient

B.2.2 Svar från Exchange Server

<Sync xmlns="AirSync:"> <Collections> <Collection> <SyncKey>1735707607</SyncKey> <CollectionId>562958543800134</CollectionId> <Status>1</Status> <Commands> <Add> <ServerId>4399115082</ServerId> <ApplicationData> <DTStamp xmlns="Calendar:">20121029T150042Z</DTStamp> <StartTime xmlns="Calendar:">20121101T140000Z</StartTime> <Subject xmlns="Calendar:">Test</Subject> <Location xmlns="Calendar:">Xcerion</Location> <EndTime xmlns="Calendar:">20121101T150000Z</EndTime> <Body xmlns="AirSyncBase:"> <Type>1</Type> <Data /> </Body> <AllDayEvent xmlns="Calendar:">0</AllDayEvent>

(48)

36 B Exchange ActiveSync protokoll exempel </ApplicationData> </Add> </Commands> </Collection> </Collections> </Sync>

B.3 Kalenderhändelse lagrat på CloudMe

Filnamn Example.xml

<vevent autostart="" type="Utbildning"> <subject>Example</subject> <description /> <startDate>2012-10-31</startDate> <startTime>17:00</startTime> <endDate>2012-10-31</endDate> <endTime>18:00</endTime> <location>Xcerion</location> <categories>Utbildning</categories> <allDay>false</allDay> </vevent>

(49)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet — eller dess framtida ersättare — under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för icke-kommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förla-gets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet — or its possi-ble replacement — for a period of 25 years from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for his/her own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be men-tioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/