Redigerer ICalendar (avsnitt)

== Begrensninger og fremtid ==
iCalendar-formatet er designet for å overføre kalenderbaserte data som for eksempel hendelser, og beskriver med vilje ikke hva som skal gjøres med disse dataene. Dermed kan det være nødvendig med annen programmering for å automatisere hvilke handlinger som skal foretas basert på disse dataene.{{Refn|A companion standard, "iCalendar Transport-Independent Interoperability" ([[iTIP]]) (RFC 2446), defines a protocol for exchanging iCalendar objects for collaborative calendaring and scheduling between "Calendar Users" (CUs) facilitated by an "Organizer" initiating the exchange of data. This standard defines methods such as PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER (to negotiate a change in the entry), and DECLINE-COUNTER (to decline the counter-proposal).

Another companion standard, "iCalendar Message-based Interoperability Protocol ([[iMIP]])" (RFC 2447), defines a standard method for implementing iTIP on standard Internet email-based transports.

The "Guide to Internet Calendaring" (RFC 3283) explains how iCalendar interacts with other calendar computer language (current and future).|group=nb}}

iCalendar er ment å "gi definisjonen av et felles format for åpen deling av kalender- og planleggingsinformasjon over internett".{{Refn|CalConnect, 2004|group=nb}} Mens det er god støtte i iCalendar for for de fleste vanlige funksjonene fører imidlertid noen avanserte funksjoner til problemer. For eksempel støtter de fleste epost- og kalender-leverandørene ikke Journals-funksjonen (VJOURNAL). VTODO har også hatt konverteringsproblemer.{{Refn|CalConnect, 2004|group=nb}}

iCalendar kalender er heller ikke kompatibel med enkelte ikke-[[Den gregorianske kalenderen|gregorianske]] kalendere så som [[Månekalender|månekalenderne]] brukt i [[Israel]] og [[Saudi-Arabia]].{{Refn|Although there exist one-to-one mappings between Gregorian and many other calendar scales, the lack of defined CALSCALE values for those calendars and limitations in various date fields can make native support impossible. For example the [[Hebrew calendar]] year may contain either 12 or 13 months, and the [[Japanese era name|Japanese]] Emperor-based calendar scale contains many eras.|group=nb}}

Notatet "Calendar Access Protocol" ([[Request for comments|RFC]] 4324) var et første forsøk på et universelt system for å lage sanntidskalendere, men ble til slutt forlatt. Istedet fikk iCalendar noen adopsjon for slike formål med ''[[ad hoc]]-''utvidelser som [[Gruppedav|GroupDAV]] og [[CalDAV]] som har stått frem som uformelle standarder har fått noe adopsjon i både klient- og tjener-[[Programvare|programvarepakker]].

I 2011 januar avsluttet [[Internet Engineering Task Force|IETF]] Calendaring and Scheduling Working Group (kalt "ietf-calsify WG") sitt første forsøk på å forenkle iCalendar-standardene uten at resultatenene ble tatt i bruk.<ref>{{Kilde www|url=https://datatracker.ietf.org/wg/calsify/charter/|tittel=Calendaring and Scheduling Standards Simplification (calsify)|besøksdato=2015-04-05|forlag=[[IETF]]}}</ref><ref>{{Kilde www|url=http://lists.osafoundation.org/pipermail/ietf-calsify/2010-December/002272.html|tittel=the end of calsify working group– not the end of the mailing list|besøksdato=2015-04-05|fornavn=Eliot|etternavn=Lear|arkiv-dato=2012-12-09|arkiv-url=https://web.archive.org/web/20121209115511/http://lists.osafoundation.org/pipermail/ietf-calsify/2010-December/002272.html|url-status=yes}}</ref> Arbeidet ble deretter plukket opp og fortsatt av IETF Calendaring ''Extensions'' Working Group" (kalt "ietf-cal''ext'' WG").<ref>{{Kilde www|url=https://datatracker.ietf.org/wg/calext/charter/|tittel=Calendaring Extensions (calext)|besøksdato=2016-12-01|forlag=[[IETF]]}}</ref>