Cesko.wiki CalDAV
Author
Albert FloresProtokol CalDAV je rozšíření standardu WebDAV, definovaný IETF v roce 2007 (RFC 4791). Jeho cílem je umožnit klientům přístup ke kalendářním informacím uložených na vzdáleném serveru.
Architektura CalDAV organizuje data (události, úkoly, poznámky atd. ) do kolekcí. +more Zdroje a kolekce mohou být přístupné jednomu nebo i více uživatelům pomocí protokolu WebDAV, který poskytuje možnost uzamčení vybraných dat a kolekcí. Pro řízení přístupu k datům je použit koncept ACL (seznam oprávnění připojený k objektu). To znamená, že jakákoliv operace klienta nad daty může být serverem odmítnuta. Aby toho mohlo být dosáhnuto CalDAV server musí podporovat WebDAV Access Control Protocol definovaný RFC 3744. Kalendářní zdroje jsou reprezentovány ve formátu iCalendar, to umožňuje u více serverových a klientských aplikací vzájemné sdílení dat.
Datový model
CalDAV kalendář je definován jako WebDAV kolekce s danou strukturou. Kalendářní kolekce může obsahovat několik zdrojů, nazývající se „objekty kalendářních zdrojů“, jako přímé potomky. +more Každá kolekce a objekt kalendářních zdrojů mohou být uzamčeny nebo obsahovat individuální WebDAV vlastnosti.
CalDAV server je tvořen kombinací kalendářních funkcí a WebDAV úložištěm, které obsahuje kolekce s kalendářními objekty, nacházejícími se v rámci jednotného (URL) jmenného prostoru. WebDAV úložiště může být prohlášeno za CalDAV server, pokud splňuje funkcionalitu, která je zadaná v dokumentu RFC 4791. +more Server musí dokázat reagovat na dotazy od klienta, např. na požadavek na změnu dat, zaslání dat nebo synchronizaci, v případě, že si klient uchovává data na svém úložišti.
Objekty kalendářních zdrojů
Objekty kalendářních zdrojů obsažené v kolekci nesmí obsahovat více než jeden typ komponenty (VEVENT, VTODO, VJOURNAL, atd. ), s výjimkou komponenty VTIMEZONE, která je specifikována pro každý jedinečný parametr TZID v objektu iCalendar. +more Hodnota vlastnosti UID komponenty v kalendářním objektu musí být unikátní v rámci kolekce, ve které je uložena. Pokud existují komponenty se stejnými UID vlastnostmi, značí to komponentu, opakující se v určitém intervalu. Všechny instance opakující se komponenty musí být uloženy v jednom objektu kalendářních zdrojů a zároveň v něm nesmí být komponenta s jinou hodnotou UID vlastnosti. Následuje příklad objektu iCalendar:.
BEGIN:VCALENDAR PRODID:-//Example Corp. //CalDAV Client//EN VERSION:2. +more0 BEGIN:VEVENT UID:1@example. com SUMMARY:One-off Meeting DTSTAMP:20041210T183904Z DTSTART:20041207T120000Z DTEND:20041207T130000Z END:VEVENT BEGIN:VEVENT UID:2@example. com SUMMARY:Weekly Meeting DTSTAMP:20041210T183838Z DTSTART:20041206T120000Z DTEND:20041206T130000Z RRULE:FREQ=WEEKLY END:VEVENT END:VCALENDAR.
Kalendářní kolekce
Kalendářní kolekce obsahuje objekty kalendářních zdrojů, které reprezentují komponenty obsažené v rámci kalendáře. Může být vytvořena automaticky při vytvoření účtu nebo pomocí metody MKCALENDAR. +more Kalendářní kolekce se klientovi jeví WebDAV kolekce definovaní pomocí URL. Kalendářní kolekce musí splňovat následující dvě podmínky: * Kalendářní kolekce mohou obsahovat pouze objekty kalendářních zdrojů nebo nekalendářní kolekce (to zajišťuje, že se klient nemusí zabývat nekalendářními daty v kalendářní kolekci). * Kolekce v kalendářní kolekci nesmí obsahovat kalendářní kolekci v jakékoliv hloubce.
Vybrané vlastnosti CalDAV protokolu
Podpora serveru
Server s podporou kalendářních funkcí musí mít v odpovědi na dotaz s metodou OPTIONS zahrnuto pole „calendar-access“ v DAV hlavičce (pokud je dotaz směřován na zdroj, který podporuje kalendářní vlastnosti, metody, atd. ). +more Odpověď serveru na dotaz klienta s metodou OPTIONS:.
HTTP/1.1 200 OK Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL DAV: 1, 2, access-control, calendar-access Date: Sat, 11 Nov 2006 09:32:12 GMT Content-Length: 0
Vlastnosti kalendářní kolekce
Kalendářní kolekce má oproti specifikaci kolekce u standardu WebDAV přidáno několik následujících vlastností, které jsou definovány ve jmenném prostoru urn:ietf:params:xml:ns:caldav. Jsou to: popis kalendáře, časová zóna kalendáře, podporované komponenty, typ kalendářních dat, maximální velikost objektu kalendářních zdrojů (v bajtech), minimální akceptovatelné datum, maximální akceptovatelné datum, maximální počet instancí opakované komponenty, maximální počet vlastností komponenty.
Kontrola přístupu
CalDAV server musí podporovat a dodržovat požadavky na standard WebDAV ACL, definovaný RFC 3744, a tím poskytovat rámec pro rozšiřitelnou sadu oprávnění, která mohou být použita na kolekce nebo pouze zdroje v ní obsažené. Díky těmto oprávněním může být klientům omezen přístup ke zdrojům.
Kromě tohoto standardu je protokol CalDAV rozšířen o možnost poskytnout uživatelům (pomocí oprávnění CALDAV:read-free-busy) náhled pouze na obsazený čas v cizím kalendáři, bez zobrazení dalších detailů kalendářních komponent. Oprávnění může být použito na kalendářní kolekce, běžné kolekce nebo objekty kalendářních zdrojů a musí být vnořené do DAV:read oprávnění.
Vytváření zdrojů
Zaslání dotazu na server s metodou MKCALENDAR vytvoří novou kalendářní kolekci. Při použití metody MKCALENDAR nesmí vytvářená kalendářní kolekce již existovat a umístěna musí být v povolené oblasti. +more Protože některé úložiště mohou podporovat pro jednoho uživatele pouze jeden kalendář, který je většinou předem vytvořen. Proto je podpora metody MKCALENDAR na serveru pouze doporučena. Pro přehlednost by měl klient používat vlastnost DAV:displayname pro zadání jména kalendáře. Dále je uveden příklad dotazu pro vytvoření kalendářní kolekce:.
MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1 Host: cal.example.com Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
Lisa's Events
Calendar restricted to events.
Do vytvořených kalendářních kolekcí nahrává klient své objekty kalendářních zdrojů. Při jejich nahrání pomocí metody PUT může být URL zadáno zcela nezávisle na vztahu k obsahujícím datům, avšak dané URL nesmí být již využíváno. +more Pokud by tomu tak nebylo, nejednalo by se o vytvoření, ale o aktualizaci.
Pro servery není obtížné zajistit, aby měl vytvořený zdroj zatím neexistující URL, ale pro klienta to jednoduchá záležitost není. Musí prozkoumat URL všech zdrojů a uzamknout kalendářní kolekci, aby nedošlo ke kolizi. +more Až poté si může být klient jist jedinečností URL ve jmenném prostoru. Následuje kód pro vytvoření objektu kalendářních dat:.
PUT /home/lisa/calendars/events/qwue23489. ics HTTP/1. +more1 Host: cal. example. com Content-Type: text/calendar Content-Length: xxxx BEGIN:VCALENDAR VERSION:2. 0 PRODID:-//Example Corp. //CalDAV Client//EN BEGIN:VEVENT UID:20010712T182145Z-123401@example. com DTSTAMP:20060712T182145Z DTSTART:20060714T170000Z DTEND:20060715T040000Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR.
Vlastnost Entity Tag
Vlastnost DAV:getetag, sloužící pro synchronizaci dat, musí být podporována CalDAV serverem a nastavena ve všech objektech kalendářních zdrojů.
Pokud po odeslání PUT dotazu server navrátí hodnotu entity tagu v hlavičce ETag, znamená to, že akce byla správně provedena a klient může hodnotu uložit a dále s ní pracovat. V případě, že je klient schopen provést dotaz PROPFIND na objekt kalendářních zdrojů, může navrácenou hodnotu vlastnosti DAV:gatetag porovnat s hodnotou entity tagu, doručenou v PUT odpovědi. +more Pokud si jsou obě hodnoty rovny, objekty se v danou chvíli nemusí synchronizovat.
Odpověď serveru na GET požadavek, mířený na objekt kalendářního zdroje, musí také obsahovat ETag hlavičku s aktuální hodnotou. Příklad odpovědi serveru na dotaz PUT:
HTTP/1.1 201 Created Content-Length: 0 Date: Sat, 11 Nov 2006 09:32:12 GMT ETag: "123456789-000-111"
Metoda REPORT
Metoda REPORT musí být CalDAV serverem podporována a musí být proveditelná nad všemi kalendářními kolekcemi a objekty kalendářních zdrojů. Metoda poskytuje mechanismus pro získávání informací o komponentách, objektech kalendářních zdrojů a kalendářních kolekcí. +more Pomocí metody se mohou získávat zdroje pouze s určitými vlastnostmi, které se definují v těle dotazu. Je také možné definovat časový rozsah zdrojů, které se mají vyskytovat v odpovědi.
Metoda REPORT s kořenovým elementem CALDAV:calendar-query v těle dotazu slouží pro vyhledávání všech objektů kalendářních zdrojů, které vyhovují zadanému filtru. Odpověď bude obsahovat všechny [url=/1. +more1 Host: cal. example. com Content-Type: application/xml; charset="utf-8" Content-Length: xxxx.
... definice vlastností
Další kořenový [[Extensible Markup Language|XML]url=/1.1 Host: cal.example.com Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
/bernard/work/abcd1.ics /bernard/work/mtg1.ics
Metoda REPORT ještě může obsahovat jako kořenový [[Extensible Markup Language|XML][WebDAV]] vlastnosti a data objektů kalendářních zdrojů vyhovující dotazu. Formát specifikace vlastností v těle dotazu je založen na stejných XML elementech jako metoda PROPFIND. +more Následuje příklad dotazu s metodou REPORT:.
REPORT /bernard/work/[/url]] element v dotazu může být CALDAV:calendar-multiget, pomocí kterého se v odpovědi navrací specifikovaný objekt kalendářních dat pomocí seznamu elementů DAV:href, ve kterém je hodnota s umístěním objektu. Dále je uveden kód popsaného dotazu:
REPORT /bernard/work/[/url]] element CALDAV:free-busy-query, který navrací VREEBUSY komponenty pro všechny objekty kalendářních zdrojů kalendáře.
REPORT /bernard/work/ HTTP/1.1 Host: cal.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx
Synchronizace
Pokud uživatel vyžaduje od kalendářové aplikace (klienta), aby byla data dostupná i v offline režimu, je vhodné zavést u klienta podporu synchronizace dat. CalDAV protokol využívá pro synchronizaci vlastnosti ETagu, který obsahuje každý objekt kalendářních zdrojů.
Klient musí společně s daty ukládat i URI a ETagy všech objektů kalendářních zdrojů. Vzhledem k tomu, že URI se (většinou) nemění a ETag se mění s každou úspěšně provedenou změnou objektu kalendářních zdrojů, může klient pomocí URI načíst ETagy a porovnat je s ETagy uloženými u klienta. +more Jakékoliv lišící se ETag páry značí, že objekt kalendářních zdrojů musí být obnoven.
Aby synchronizace byla kompletní, musí si klient vést záznamy o prováděných akcích v offline režimu. V online režimu pak klient zaznamenané akce realizuje tak, aby se projevily i na vzdáleném serveru.
Literatura
[url=https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0ByK8l8T2eCiWZjM5ZjA2N2QtNWFkZC00MTgyLWFmYjAtZmJkOGVhZTRhYjM1&hl=cs]bakalářská práce[/url]