Jedna kalendářová služba – jde to i jinak?
Chcete uspořádat nějakou událost, například obchodní jednání, zasedání orgánu firmy, politickou schůzi, setkání kamarádů apod. Jak nejlépe zajistit, aby měli všichni zúčastnění přesné informace o čase, místě a případně dalších důležitých skutečnostech?
Mají-li všichni účet u stejné služby, například Google, je to jednoduché. Prostě se vytvoří událost, do ní se přidají účastníci a je hotovo. Služba se postará o to, aby byli všichni informováni a mohli si událost přidat do svého kalendáře. Další možností je založit společný, sdílený kalendář – to je vhodné hlavně v případech, kdy skupina lidí často něco řeší společně.
Ale co v případě, kdy někdo stejnou službu nevyužívá? Jednou možností je ho k užívání služby přesvědčit, třeba aspoň částečně, například formou využívání sdíleného kalendáře. Ne vždy je to ale vyhovující, protože někdo nemusí souhlasit s podmínkami služby, nechce využívat více kalendářů (a mít v nich jistý nepořádek) atd.
Proto v roce 1998 vznikl protokol iTIP – iCalendar Transport-Independent Interoperability Protocol (RFC 2446; aktuální podoba je upravena novějším dokumentem RFC 5546 z roku 2009). Ten říká, jak probíhá přenos dat iCalendar (což je textový formát kalendářových dat; vznikl rovněž v roce 1998, původně ho specifikoval dokument RFC 2445, aktuální podoba je v RFC 5545).
Protokol iTIP je, jak už název napovídá, nezávislý na způsobu transportu. Může tedy fungovat nad různými transportními vrstvami. Jednou takovou vrstvou, a to vrstvou široce dostupnou, je e-mail. Proto bylo už v roce 1998 (RFC 2447) vytvořeno rozšíření iTIP nazvané iMIP – iCalendar Message-Based Interoperability Protocol. Nynější podoba je popsána v RFC 6047.
Co iMIP umí a jak funguje?
Následující popis bude především popisem protokolu iTIP, protože iMIP řeší jen záležitosti specifické pro přenos v e-mailových zprávách. To ale není na závadu, můžete iMIP vnímat jako úplné řešení a nezabývat se tím, že je v něm ještě iTIP.
Máme nějaký kalendář, například doplněk Lightning v poštovním klientu Mozilla Thunderbird. V něm vytvoříme událost. To jsme zatím ještě v režimu samostatného kalendáře. Zajímavé to začne být až v okamžiku, kdy do události přidáme účastníky.
Událost vytvořená v doplňku Lightning programu Mozilla Thunderbird
Účast konkrétního člověka může povinná či nepovinná, účastník může být předsedající nebo i „nezúčastněný“ (událost se mu jen dává na vědomí, ale s jeho osobní účastí se nepočítá).
Každá událost má svého organizátora, což je standardně ten, kdo ji vytvořil. Pak jsou tu další (přidaní) účastníci – ti se uloží do kalendáře, ale ještě nevědí o tom, že by se měli události zúčastnit (pokud se jim tato informace nepředá jinak nebo událost nebyla dohodnuta předem). Proto je potřeba jim tuto informaci předat.
Přidání účastníků do události
Nyní nastoupí protokol iMIP. Při ukládání události aplikace vytvoří speciální e-mailovou zprávu, která obsahuje kalendářová data, a tu pošle všem účastníkům (samozřejmě kromě organizátora, protože to by nemělo smysl – organizátor ovšem nemusí být nutně účastníkem události).
Dotaz na odeslání kalendářových dat (pokud se nepošlou, účastníci se o události nedozvědí)
Posílat událost lze jak společnou zprávou, tak i zprávami samostatnými pro jednotlivé účastníky. Ve druhém případě se musí odeslat více zpráv, ale není všem odhaleno, kdo všechno je pozván.
Když zpráva přijde účastníkovi, záleží na tom, zda jeho poštovní klient umí s kalendářovými daty správně naložit. Pokud neumí, zobrazí jen textovou zprávu, ale kalendářová data lze uložit do souboru. Potom je lze načíst do kalendářové aplikace, ta už si s nimi poradí – tedy se například zeptá, zda se člověk zúčastní, uloží událost do kalendáře atd.
Pozvánka na událost zobrazená ve webovém klientu služby GMail
Umí-li s kalendářovými daty pracovat přímo poštovní klient (např. zmíněný Thunderbird s Lightningem, Microsoft Outlook, Lotus Notes atd.), je to ještě jednodušší, protože hned nabídne možnosti, co s událostí udělat. Přijde-li vám takto pozvánka na událost a vyžaduje odpověď (není jen informativní), můžete účast potvrdit nebo odmítnout, případně ji ponechat jako nejistou.
Odpověď na pozvánku na událost
Odpověď se odešle organizátorovi, takže se může stav účastníka u události aktualizovat. Podobně se odešle zpráva i při změnách události (posunu v čase, změně názvu či popisu apod.), změnách účasti jednotlivých lidí nebo zrušení události.
Událost vložená do kalendáře Google účastníka
Pokud to klientská aplikace podporuje, lze při přijetí pozvánky navrhnout jiný termín události. Organizátor může návrh přijmout (změna se pak rozešle účastníkům) nebo ponechat termín původní. Možnost navrhnout změnu může organizátor předem zakázat.
Další možnosti iMIP
Využití možností protokolu samozřejmě závisí na podpoře v klientském softwaru. Ne každý program musí podporovat úplně vše.
V rámci iMIP lze řešit také delegace účasti – tedy že některý z účastníků za sebe pošle někoho jiného. Podobně jako události lze sdílet také úkoly (s prakticky totožnými možnostmi jako události), deníkové položky (ty jsou samozřejmě jen informativní, neexistuje u nich potvrzování účasti) a informace o volném a obsazeném čase (lze buď poslat informace o svém čase nebo si vyžádat informace od někoho jiného – hodí se při plánování událostí).
