Résumé

  • En mode AUTOMATIC-FAILURE, un seul PARTSTAT=FAILED ou une échéance dépassée avant la fin peut changer le VTODO général en FAILED.
  • SERVER confie le choix aux règles métier de l’implémentation; CalDAV permet de vérifier les modes pris en charge et rejette un mode incompatible par HTTP 403.

L’affectation est collective : RFC 10051 prévoit que chaque participant d’une requête iTIP exécute la tâche. Dans AUTOMATIC-FAILURE, la réponse PARTSTAT=FAILED d’une seule personne peut marquer le VTODO entier FAILED. Un outil qui lit l’état de la tâche reçoit alors un échec général, alors que le déclencheur est une réponse individuelle.

Le second déclencheur est l’horloge. Si la tâche reste inachevée après son échéance effective, le serveur devrait également la marquer FAILED. L’échéance vient de DUE ou de DTSTART plus DURATION. VSTATUS peut garder le motif, le sous-état et l’horodatage du changement; l’étiquette seule raconte peu de choses.

Publié en octobre 2026, RFC 10051 met à jour VTODO pour les tâches de projet et les flux de travail, au-delà des rappels personnels. TASK-MODE indique au serveur comment traiter les statuts. En son absence, CLIENT est la valeur par défaut : le serveur reprend le statut envoyé par le client. Les autres modes délèguent certaines décisions au serveur.

AUTOMATIC-COMPLETION demande au serveur de marquer la tâche terminée lorsque tous les participants signalent l’avoir achevée; en cas d’échec dans ce mode, le client intervient. AUTOMATIC réunit les comportements de fin et d’échec.

SERVER ouvre davantage la porte. Le mode demande au serveur de choisir un état adapté lorsque les réponses arrivent ou que les échéances passent, selon des règles métier définies par l’implémentation. RFC 10051 ne fixe aucune politique commune pour les périodes de grâce, l’achèvement partiel, les reprises ou une dépendance non résolue. Deux services peuvent échanger la même tâche tout en appliquant des règles différentes.

Le standard permet au client de découvrir une partie de cette frontière. Un serveur CalDAV peut publier les modes qu’il prend en charge dans CALDAV:supported-task-mode-set. Si le client tente d’enregistrer une tâche avec un mode incompatible, le serveur doit répondre HTTP 403 avec une erreur DAV indiquant les modes acceptés. Un client qui ignore TASK-MODE est censé l’ignorer sans planter.

Cette liste est l’indice dont dispose le client; une réponse actuelle d’un service nommé établirait s’il prend en charge ce comportement.

RFC 10051 distingue aussi l’échéance de l’estimation. DTSTART et DUE, ou DTSTART et DURATION, définissent la fenêtre de travail. Le nouveau ESTIMATED-DURATION indique le temps que la tâche devrait prendre. Une réparation estimée à deux heures peut donc disposer d’une fenêtre de quatre heures sans faire passer le travail pour une tâche de quatre heures.

Pour une équipe opérationnelle, l’enregistrement utile ne se limite pas à l’étiquette FAILED. Il faut aussi le mode qui autorise le changement, le calcul d’échéance, la réponse du participant et le motif, le sous-état ou l’horodatage porté par VSTATUS. L’état circule entre systèmes; la règle qui l’a produit peut rester locale.

Sources