ICalendar - Définition

Core object

L'objet de plus haut-niveau dans iCalendar est le « Calendaring and Scheduling Core Object ». C'est une collection d'informations sur les calendaring et scheduling. Typiquement, cette information consiste en un unique objet iCalendar. Cependant, plusieurs objets de type iCalendar peuvent séquentiellement être regroupés ensemble. La première ligne doit être "BEGIN: VCALENDAR", et la dernière doit être "END: VCALENDAR"; le contenu qui se trouve entre ces deux lignes est appelé "icalbody". Le corps d'un objet iCalendar (le "icalbody") consiste en une suite de propriétés de calendrier et un ou plusieurs composants de calendrier. Les propriétés du calendrier sont des attributs qui s'appliquent à la totalité du calendrier. Les composants du calendrier sont une collection de propriétés qui suivent une syntaxe particulière. Par exemple, le composant peut spécifier un événement, une tâche, une entrée de journal, une information sur le fuseau horaire, une plage de temps libre ou occupé ou encore une alarme.

Voilà un exemple simple (depuis la RFC 2445) d'un objet iCalendar qui définit un événement "Bastille Day Party" qui se déroule entre le 14 juillet 1997 à 17h00 (UTC) jusqu'au 15 juillet 1997 à 03h59m59s (UTC) :

          BEGIN:VCALENDAR          VERSION:2.0          PRODID:-//hacksw/handcal//NONSGML v1.0//EN          BEGIN:VEVENT          DTSTART:19970714T170000Z          DTEND:19970715T035959Z          SUMMARY:Bastille Day Party          END:VEVENT          END:VCALENDAR      

Il existe différents types de composants définis dans la norme. Ils sont décrits ci-dessous.

Evénements (VEVENT)

Un composant "VEVENT" offre un panel de propriétés qui décrivent un événement comme représentant une quantité de temps planifiée sur un calendrier. En temps normal, un événement valide rendra ce temps occupé, mais il est possible de le configurer en mode "Transparent", pour changer cette interprétation.

Les propriétés classiques d'un composant VEVENT sont :

• DTSTART: Date de début de l'événement
• DTEND: Date de fin de l'événement
• SUMMARY: Titre de l'événement
• LOCATION: Lieu de l'événement
• CATEGORIES: Catégorie de l'événement (ex: Conférence, Fête, ...)
• STATUS: Statut de l'événement (TENTATIVE, CONFIRMED, CANCELLED)
• DESCRIPTION: Description de l'événement
• TRANSP: Définit si la ressource affectée à l'évenement est rendu indisponible (OPAQUE, TRANSPARENT)

Un composant VEVENT peut contenir un composant VALARM pour définir des alarmes. De tels événements ont une propriété DTSTART qui définit sa date et son heure de début, et une propriété DTEND définissant sa date et son heure de fin. Si l'événement est périodique, DTSTART définit le début du premier événement.

Les événements périodiques sans heure spécifique, comme les anniversaires ou les rappels périodiques, sont aussi représentés en utilisant des VEVENT. Ces événements devraient avoir une valeur de type DATE pour la propriété DTSTART à la place d'un type DATE-TIME par défaut, et ne doivent pas inclure une propriété "DTEND".

To-do (VTODO)

Le composant "VTODO" décrit un objet "à faire", c’est-à-dire, un objet-action ou une tâche.

Ce qui suit est un exemple d'un "to-do" dont l'échéance est le 15 avril 1998, selon la RFC 2445. Une alarme sonore a été spécifiée pour avertir l'utilisateur du calendrier à midi, le jour précédent la tâche à effectuer. L'alarme sera répétée 4 fois supplémentaires avec un intervalle d'une heure. La définition du "to-do" a été modifiée deux fois depuis sa création initiale.

          BEGIN:VCALENDAR          VERSION:2.0          PRODID:-//ABC Corporation//NONSGML My Product//EN          BEGIN:VTODO          DTSTAMP:19980130T134500Z          SEQUENCE:2          UID:[email protected]          ORGANIZER:MAILTO:[email protected]          ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:[email protected]          DUE:19980415T235959          STATUS:NEEDS-ACTION          SUMMARY:Submit Income Taxes          BEGIN:VALARM          ACTION:AUDIO          TRIGGER:19980403T120000          ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-           files/ssbanner.aud          REPEAT:4          DURATION:PT1H          END:VALARM          END:VTODO          END:VCALENDAR      

Entrée Journal (VJOURNAL)

Le composant VJOURNAL décrit une entrée journal. Il lie simplement un texte descriptif à une date particulière, et peut être utilisé pour enregistrer l'activité journalière ou l'accomplissement de tâches. Un composant "VJOURNAL", n'occupe pas de temps, il n'a donc aucun effet sur le temps libre ou occupé (comme les entrées "TRANSPARENT"). En pratique, seulement quelques implémentations du format iCalendar supportent les entrées "VJOURNAL".

L'exemple suivant est un celui d'une écriture d'un journal, selon la RFC 2445:

          BEGIN:VCALENDAR          VERSION:2.0          PRODID:-//ABC Corporation//NONSGML My Product//EN          BEGIN:VJOURNAL          DTSTAMP:19970324T120000Z          UID:[email protected]          ORGANIZER:MAILTO:[email protected]          STATUS:DRAFT          CLASS:PUBLIC          CATEGORY:Project Report, XYZ, Weekly Meeting          DESCRIPTION:Project xyz Review Meeting Minutes\n           Agenda\n1. Review of project version 1.0 requirements.\n2.          Definition           of project processes.\n3. Review of project schedule.\n           Participants: John Smith, Jane Doe, Jim Dandy\n-It was            decided that the requirements need to be signed off by            product marketing.\n-Project processes were accepted.\n           -Project schedule needs to account for scheduled holidays            and employee vacation time. Check with HR for specific            dates.\n-New schedule will be distributed by Friday.\n-           Next weeks meeting is cancelled. No meeting until 3/23.          END:VJOURNAL          END:VCALENDAR      

Temps libre/occupé (VFREEBUSY)

Un composant "VFREEBUSY" décrit soit une requête concernant du temps libre/occupé, soit une réponse à une requête, ou publie un ensemble de temps occupé.

Comme décrit dans la RFC 2445:

      When used to request free/busy time information, the "ATTENDEE"      property specifies the calendar users whose free/busy time is being      requested; the "ORGANIZER" property specifies the calendar user who      is requesting the free/busy time; the "DTSTART" and "DTEND"      properties specify the window of time for which the free/busy time is      being requested; the "UID" and "DTSTAMP" properties are specified to      assist in proper sequencing of multiple free/busy time requests.      

      When used to reply to a request for free/busy time, the "ATTENDEE"      property specifies the calendar user responding to the free/busy time      request; the "ORGANIZER" property specifies the calendar user that      originally requested the free/busy time; the "FREEBUSY" property      specifies the free/busy time information (if it exists); and the      "UID" and "DTSTAMP" properties are specified to assist in proper      sequencing of multiple free/busy time replies.      

      When used to publish busy time, the "ORGANIZER" property specifies      the calendar user associated with the published busy time; the      "DTSTART" and "DTEND" properties specify an inclusive time window      that surrounds the busy time information; the "FREEBUSY" property      specifies the published busy time information; and the "DTSTAMP"      property specifies the date/time that iCalendar object was created.      

Ce qui suit est un exemple d'une publication de temps occupé selon la RFC 2445. L'objet iCalendar devrait être placé à une certaine URL avec l'extension ".ifb" :

          BEGIN:VCALENDAR          VERSION:2.0          PRODID:-//RDU Software//NONSGML HandCal//EN          BEGIN:VFREEBUSY          ORGANIZER:MAILTO:[email protected]          DTSTART:19980313T141711Z          DTEND:19980410T141711Z          FREEBUSY:19980314T233000Z/19980315T003000Z          FREEBUSY:19980316T153000Z/19980316T163000Z          FREEBUSY:19980318T030000Z/19980318T040000Z          URL:http://www.host.com/calendar/busytime/jsmith.ifb          END:VFREEBUSY          END:VCALENDAR      

Les autres composants

D'autres composants définis dans le standard sont "VTIMEZONE" (pour définir des fuseaux horaires), et "VALARM" (pour définir des alarmes). On peut remarquer que certains composants incluent d'autres composants ("VALARM" est souvent inclus dans d'autres composants), et que certains composants sont définis pour gérer d'autres composants définis après eux ("VTIMEZONE" est souvent utilisé de cette manière).

L'échange de données avec iCalendar

Le format iCalendar est conçu pour décrire des données calendaires (comme des événements), et intentionnellement, ne décrit pas ce qu'il faut faire avec des données "classiques" (textes, etc.).

Un compagnon, "iCalendar Transport-Independent Interoperability" (iTIP) (RFC 2446), définit un protocole pour l'échange d'objet iCalendar dans un but de grouper les informations calendaires et de planification entre les "Calendar Users" (CUs); quiconque débute l'échange de données prend le rôle de "l'organisateur". Ce standard définit des méthodes comme PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER (pour négocier une modification d'une entrée) et DECLINE-COUNTER (pour refuser la contre-proposition).

Un autre compagnon, "iCalendar Message-based Interoperability Protocol (IMIP)" (RFC 2447), définit une méthodologie standard pour implémenter iTIP dans le protocole de transport, comme celui des emails.

Le "Guide to Internet Calendaring" (RFC 3283) décrit la relation entre iCalendar et divers standards apparentés (présents et futurs).

Le format iCalendar a été conçu pour assurer l'interopérabilité des données calendaires ; tandis que les fonctionnalités les plus souvent utilisées par les utilisateurs sont largement supportées par les implémentations d'iCalendar et peuvent communiquer, les opérations entre les implémentations de fonctionnalités plus avancées sont "boiteuses".

"Calendar Access Protocol" (RFC 4324) provides a universal methodology for implementing real-time calendaring.

The IETF Calendaring and Scheduling (calsch) Working Group has in the past worked on various extensions to, and supporting protocols for, iCalendar. Officially the working group has been closed in September 2004 as an IETF working group (so that it can be reorganized); its mailing list continues to be used for calendar-related discussions. [1] [2]