iCalendar

iCal

Caractéristiques

Extensions	.ics, .ifb, .iCal, .iFBf, .icalendar
Type MIME	text/calendar
PUID	fmt/388
Type de format	sérialisation d'agenda
Spécification	Format ouvert

iCalendar (aussi abrégé iCal) est un format de données discuté et proposé par la RFC 5545 (et ses révisions ultérieures) pour les échanges de données de calendrier. Il est notamment utilisé pour le partage de calendrier par abonnement via les protocoles CalDAV et Web Calendar Access Protocol.

iCalendar permet aux utilisateurs d'envoyer des demandes de rendez-vous, et de les transmettre à d'autres utilisateurs par courriel. Les destinataires du courriel qui possèdent un logiciel supportant le format iCalendar peuvent facilement répondre à l'expéditeur ou proposer une autre date/heure de rendez-vous.

Il est implémenté/supporté par un grand nombre de logiciels, tels que : iCal d'Apple, Chandler, Lotus Notes, Zimbra, ScheduleWorld, SOGo, KOrganizer, Mozilla Lightning, Evolution, Windows Calendar et, via une extension, Microsoft Outlook. L'application en ligne Google Agenda utilise également cette norme. Les widgets utilisés dans les portails personnalisables tels que Netvibes ou Posh (sous GNU GPL 3) peuvent également supporter ce format.

Les données iCalendar sont typiquement échangées en utilisant le traditionnel courriel, mais le standard proposé a été conçu pour être indépendant du protocole de transport. Par exemple, il peut aussi bien être partagé et édité en utilisant un serveur WebDAV. Les serveurs web simplistes (ne proposant que le protocole HTTP) sont souvent utilisés pour distribuer des données iCalendar concernant un événement et pour publier les temps de travail d'un individu. Les sites d'événements sur le web embarquent souvent des données iCalendar dans leurs pages web en utilisant le protocole hCalendar, une représentation 1:1 d'iCalendar, mais écrit en XHTML.

Spécifications de base

La spécification iCalendar est le résultat du travail de l'Internet Engineering Task Force Calendaring and Scheduling Working Group (présidé par Anik Ganguly de l'Open Text Inc.), et a été écrit par Frank Dawson de Lotus Software et Derik Stenerson de Microsoft. iCalendar est fortement basé sur la récente spécification industrielle vCalendar du Internet Mail Consortium (IMC). Après qu'iCalendar a été publié, IMC a déclaré qu'il « espère que tous les réalisateurs de vCalendar profitent de ces nouveaux standards ouverts et rendent leurs logiciels compatibles avec vCalendar 1.0 et iCalendar. »

Les données iCalendar ont comme type-MIME text/calendar. L'extension « .ics » est utilisée pour désigner un fichier contenant un ensemble arbitraire d'informations de calendrier ou de planification cohérent avec ce type de contenu MIME. L'extension de fichier « .ifb » sert à désigner un fichier contenant des informations de disponibilité cohérentes avec ce type-MIME. Le type de fichier « iCal » est destiné aux systèmes d'exploitation d'Apple Macintosh pour désigner un fichier contenant des informations de date et planification. Le type de fichier « iFBf » est utilisé dans les systèmes d'exploitation d'Apple Macintosh pour désigner un fichier contenant des informations de disponibilité.

Le jeu de caractères utilisé pour l'ensemble des données n'est pas défini par le format lui-même, mais à défaut d'une indication contraire (par un protocole de transport, ou conservée comme métadonnée par un système de fichiers), l'ensemble des données d'un objet iCalendar (y compris sa syntaxe de représentation) est codé en UTF-8.

Le format utilisé est similaire au format des entêtes MIME (utilisé par le protocole SMTP pour les courriels, ou par le protocole HTTP et nombre de protocoles dérivés), mais avec quelques différences. Comme pour le codage MIME, chaque propriété est sur une ligne séparée commençant par un identificateur (formé de lettres, chiffres ou signes "-"). Les lignes qui commencent par une espace forme la suite de la propriété commencée à la ligne précédente (les espaces en début de ligne et le saut de ligne qui précède sont ignorés) ; cette continuation des lignes est normalement imposée car le format impose une longueur maximale de 75 caractères par ligne (non compris les caractères de contrôles en fin de ligne). Il n'y a normalement aucune ligne vide, les espaces en fin de ligne sont non significatifs, de même que les espaces qui suivent une autre espace.

Chaque propriété comprend dans l'ordre son nom, un signe deux-points, et sa valeur (ou plusieurs valeurs séparées par des virgules dans un ordre non significatif). Elle peut parfois comprendre un ou plusieurs paramètres facultatifs (permettant d'interpréter plus précisément la valeur donnée, ou de préciser comment elle est codée si ce n'est pas du texte, ou de fournir une représentation alternative, éventuellement externe par référencement avec une URI) sous forme « paramètre=valeur », séparés entre eux et du nom de la propriété par un point-virgule; si une valeur de paramètre inclut une virgule, un point-virgule ou un deux-points (par exemple une URI), elle doit être placée entre « guillemets doubles dactylographiques »).

Certaines propriétés sont définies avec un type imposant un format standard pour leur valeur, notamment les dates et URI. Quand le type d'une propriété permet plusieurs valeurs en nombre indéfini, elles sont séparées par des virgules (sans ordre significatif) : ceci est équivalent à ajouter une autre propriété homonyme séparée pour chaque valeur.

Les propriétés sont normalement non ordonnées, mais contrairement au format MIME, elles peuvent être structurées plus précisément en sous-propriétés,

• soit quand les valeurs de sous-propriétés sont en nombre fini et dans un ordre prédéfini par leur type, en séparant ces sous-valeurs par des points-virgules pour former une valeur unique;
• soit en les encadrant par les pseudo-propriétés « BEGIN » et « END » (dont l'usage est obligatoire pour inclure la totalité des propriétés définissant un objet iCalendar) afin de former un objet complet qui peut être inclus parmi les propriétés d'un autre objet.

Les valeurs de propriétés peuvent également être typées explicitement (sinon leur type par défaut est textuel), et encodées si la représentation textuelle n'est pas suffisante (par exemple pour des données binaires), en utilisant des paramètres après le nom de la propriété.

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. 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 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 « Fête à la Bastille » qui se déroule du 14 juillet 1997 à 17 h 00 UTC au 15 juillet 1997 à 03 h 59 UTC :

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT
DTSTART:19970714T170000Z
DTEND:19970715T035900Z
SUMMARY:Fête à la Bastille
END:VEVENT
END:VCALENDAR

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

Évé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'événement est rendu indisponible (OPAQUE, TRANSPARENT)
• SEQUENCE : Nombre de mises à jour, la première mise à jour est à 1

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:uid4@host1.com
ORGANIZER:MAILTO:unclesam@us.gov
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
DUE:19980415T235959
STATUS:NEEDS-ACTION
SUMMARY:Submit Income Taxes
BEGIN:VALARM
ACTION:AUDIO
TRIGGER:19980414T120000
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:uid5@host1.com
ORGANIZER:MAILTO:jsmith@host.com
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éfini dans la RFC 2445, 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é. 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:jsmith@host.com
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 ». Cette norme 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 courriels.

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) fournit une méthode universelle d'implémentation de calendrier temps-réel.

Le IETF Calendaring and Scheduling (calsch) Working Group a travaillé dans le passé à diverses extensions et protocoles de compatibilité pour iCalendar. Le groupe de travail a officiellement cessé son existence en tant que groupe de travail de l'IETF en septembre 2004, mais sa liste de diffusion continue d'être utilisée pour des discussions sur le thème des calendriers.

Voir aussi

• vCalendar
• vCard
• hCard
• CalDAV
• xCal

Liens externes

• Internet Calendaring and Scheduling Core Object Specification (iCalendar) - RFC 2445 - IETF. Novembre 1998
• University of California at Berkeley July 28-30, 2004. Calconnect IV Interoperability Testing of RFC 2445, RFC 2446 and RFC 2447
• iCalendar DTD Document (xCal)
• Traduction en français de la RFC 2445