요약

  • AUTOMATIC-FAILURE에서는 참여자 한 명이 실패를 기록하거나 미완료 작업의 기한이 지나면 전체 VTODO가 FAILED로 바뀔 수 있다.
  • SERVER에서는 구현별 업무 규칙이 상태를 정한다. CalDAV 서버는 지원 모드를 알리고 미지원 모드에는 HTTP 403을 반환할 수 있다.

핵심은 개인의 응답과 공동 작업의 결과가 같은 기록이 아니라는 점이다. RFC 10051은 iTIP 요청에 이름이 오른 각 참여자(ATTENDEE)가 작업을 수행한다고 본다. 각자의 응답 상태는 PARTSTAT, 작업 전체 기록은 VTODO다. AUTOMATIC-FAILURE에서는 한 참여자의 FAILED 응답이 전체 작업을 실패 상태로 바꿀 수 있다.

후속 대기열이 작업 상태를 읽으면 실패로 분류되는 것은 개인 응답이 아니라 전체 작업이다. 상태 한 칸이 분류와 전달을 함께 맡는다. 그래서 VSTATUS에 이유와 시각을 남기는 일이 운영상 중요해진다.

기한이 지나도 끝나지 않은 작업은 또 다른 실패 사례다. RFC는 서버가 이를 FAILED로 바꾸도록 권고한다. 마감은 DUE에 직접 적거나, 시작 시각(DTSTART)에 작업 가능 시간(DURATION)을 더해 계산한다. VSTATUS에 이유와 시각을 남기면 다음 팀은 상태표시만 전달받지 않고 왜 실패했는지 확인할 수 있다.

2026년 10월 발행된 RFC 10051은 프로젝트와 업무 흐름의 작업을 위해 VTODO를 확장한다. TASK-MODE를 생략하면 CLIENT가 기본이며 서버는 클라이언트의 상태를 존중한다. 다른 모드에서는 상태를 만드는 판단이 서버로 넘어간다.

AUTOMATIC-COMPLETION에서는 모든 참여자가 완료를 알리면 서버가 작업을 완료 상태로 바꾸는 것이 바람직하다. 이 모드의 실패 처리는 클라이언트가 맡는다. AUTOMATIC은 두 자동 전환을 결합한다.

SERVER는 응답이 도착하거나 기한이 지날 때 어떤 상태를 둘지 구현별 업무 규칙에 맡긴다. RFC 10051은 유예 기간, 부분 완료, 재시도 횟수, 미해결 의존성을 다루는 공통 정책을 정하지 않았다. 같은 작업이 두 서비스에 전달돼도 서로 다른 상태를 받을 수 있다.

CalDAV는 그 경계의 일부를 클라이언트에 보여 준다. 서버는 CALDAV:supported-task-mode-set에 지원 모드를 게시할 수 있다. 클라이언트가 지원되지 않는 모드로 작업을 저장하려 하면 서버는 HTTP 403과 지원 모드를 설명하는 DAV 오류를 반환해야 한다. TASK-MODE를 모르는 클라이언트는 해당 속성을 안전하게 무시한다.

게시된 지원 목록은 클라이언트가 확인할 수 있는 근거다. 특정 서비스의 최신 응답을 보면 그 기능을 지원하는지 알 수 있다.

이번 갱신은 마감과 실제 작업에 들 시간도 구분한다. DTSTART와 DUE 또는 DURATION은 일을 끝낼 수 있는 시간 창을 정한다. ESTIMATED-DURATION은 작업 자체에 걸릴 것으로 예상하는 시간이다. 두 시간짜리 수리에 네 시간의 완료 창을 둘 수 있다. 그래야 일정 여유를 작업시간으로 잘못 적지 않는다.

운영팀이 확인할 기록은 FAILED라는 꼬리표에서 끝나지 않는다. 상태 변경을 허용한 모드, 기한 계산, 참석자 응답, VSTATUS에 남은 사유·하위 상태·시간도 추적해야 한다. 상태는 시스템 사이를 이동하지만 그 상태를 만든 규칙은 구현 안에 남을 수 있다.

출처