요약

  • RFC 2446에 따르면 참석자는 COUNTER에 완전한 대안 VEVENT를 담아 보낼 수 있었지만, 그 개체는 주최자가 관리하는 마스터 항목에 대한 편집이 아니라 여전히 하나의 제안이었다.
  • 주최자의 처리 결정, 수정된 REQUEST, 참석자의 PARTSTAT, 전송 인증, 로컬 캘린더 저장, 알림, 실제 참여는 서로 분리된 상태이자 별개의 근거 계층이었다.

월요일에 잡힌가상의회의를 생각해 보자. 한 참석자는 화요일을 선호하여, 화요일 회의를 기술한 완전한 대안 VEVENT를 담은 메시지를 되돌려 보낸다. 이 개체는 구문적으로 완전하고 운영상으로도 유용할 수 있다. 그럼에도 이것이 화요일을 주최자의 마스터 일정으로 만들지는 않는다.

이 경계는 원래 iCalendar와 iTIP 규격 사이의 분업에서 나온다.RFC 2445는 캘린더 정보를 표현하는 데 쓰이는 구성 요소, 속성, 매개변수로 이루어진 iCalendar 개체 모델을 정의했다.RFC 2446은 그러한 개체로 수행하는 전송 계층 독립적인 일정 조율 트랜잭션을 정의했다. 따라서 완전한 VEVENT는 대안을 표현할 수 있음을 보여줄 뿐, 그 자체로 공유 일정 상태를 대체할 권한을 성립시키지는 않는다.

프로토콜상 역할 구분도 똑같이 중요하다. RFC 2446은 일정 조율 교환을 시작하고 마스터 항목을 통제하는 주최자(Organizer)와, 그 조율에 참여하는 초대받은 참석자(Attendee)를 구분한다. 이 iTIP 역할은ATTENDEE속성에 붙는 서술적인ROLE매개변수가 아니다. chair나 required 주체 같은 값은 참여자의 기능을 기술할 뿐, 주최자 권한을 부여하지 않는다.

RFC 2446은 또한 공유 일정 상태와 개별 참여 상태를 분리한다. 주최자는 마스터 항목과 그 전체STATUS를 통제한다. 참석자의PARTSTAT은 해당 항목에 대해 그 참석자 자신의 참여 상태를 기록한다. 따라서 참석자는 수락, 거절 또는 다른 참여 상태를 보고하면서도 모두를 위한 마스터 일정을 다시 쓸 권리를 얻지는 않는다.

iTIP 메서드는 이러한 경계를 구체화한다.PUBLISH는 상호 응답 없이 캘린더 정보를 배포한다.REQUEST는 수신자에게 일정 개체의 처리를 요구하며 응답을 허용한다.REPLY는 참석자 상태를 보고한다.COUNTER는 변경을 제안한다.DECLINECOUNTER는 주최자가 그 제안된 변경을 거절할 수 있게 한다. 각 메서드는 동일한 상태 전이의 다른 표기가 아니라 서로 다른 트랜잭션을 나타낸다.

가상의 월요일→화요일 사례에서 참석자의 COUNTER는 완전한 대안 VEVENT를 담을 수 있다. 그러나RFC 2446은 여전히 COUNTER를 주최자에 대한 제안으로 취급하며, 주최자 캘린더에 대한 직접 편집으로 취급하지 않는다. 거절은DECLINECOUNTER로 표현된다. 수락은 또 하나의 전이를 필요로 한다. 주최자가 항목을 재조율하고 영향받는 참석자들에게 새REQUEST를 보내는 것이다. RFC 2446을 폐기(obsolete)한 이후의RFC 5546도 이 구분을 유지하며, 대안 제안을 수락한 뒤에는 주최자의 캘린더 사용자 에이전트가 영향받는 참석자들에게 REQUEST를 보내야 한다고 규정한다.

SEQUENCE는 그 협상을 동의로 바꾸지 않는다. RFC 2446은 이를 주최자의 개정(revision) 추적에 사용한다.REPLY,REFRESH,COUNTER,DECLINECOUNTER및 위임을 위한REQUEST는 이 값을 증가시키지 않으며,ADD와CANCEL은 증가시킨다. 따라서 응답이 더 오래된 주최자 개정을 참조하는 것은 정상이다. 더 높은 시퀀스 번호는 개정 이력의 근거이지, 모든 참석자가 동의했거나, 개정을 수신했거나, 동일한 로컬 상태를 커밋했다는 증명이 아니다.

전달(forwarding)은 같은 통제 원리를 보여준다. 참석자가 초대받지 않은 캘린더 사용자에게 초대장을 전달하더라도, 그 전달 메시지는 그 사람을 주최자의 마스터 참석자 목록에 추가하지 않는다. RFC 2446은 그 결정을 주최자에게 남겨두고, 전달하는 참석자는 일정 속성 집합을 변경해서는 안 된다고 규정한다. 메시지의 도달 범위는 주최자 마스터 항목에 대한 권한을 이전하지 않은 채 넓어질 수 있다.

저장 후 전달(store-and-forward) 방식의 전송은 또 하나의 구분을 가져온다. RFC 2446은CANCEL이 원래의REQUEST보다 먼저 도착할 수 있음을 예상한다. 낮은 시퀀스의 메시지를 기다리는 동안 상관관계가 없는 취소 메시지를 시퀀스 번호가 0이 아닌 상태로 보존하고, 대응하는 메시지가 오지 않으면 노화(aging out)하여 폐기할 수 있도록 허용한다. 따라서 전송 도착 순서를 트랜잭션 순서로 자동 취급할 수는 없다.

인증은 또 다른 계층에 놓여 있다. iTIP은 전송 계층 독립적이다.RFC 2447은 이메일 바인딩을 제공했고,RFC 6047이 나중에 그 iMIP 바인딩을 갱신(update)했다. RFC 2446은 주최자 및 참석자 메시지 모두에 대한 스푸핑 위험을 식별하고, 인증·암호화 기능을 전송 바인딩 쪽에 배치한다. 파싱된 COUNTER는 메시지가 자칭하는 바를 보여줄 수 있지만, 그 자체로 실제 발신자가 누구인지, 또 그 발신자가 자칭한 역할로 행동할 권한이 있었는지는 증명하지 않는다.

결과적으로 만들어지는 근거 모델은 의도적으로 계층화되어 있다. 원시 메시지 바이트, 인증된 발신자, 역할 권한, 메서드와 UID, 주최자의SEQUENCE, 개별PARTSTAT, COUNTER 내용, 주최자의 처리 결정, 수정된REQUEST, 전송 수신 증명, 수신 측 커밋, 알림 실행, 관찰된 참여를 하나의 사실로 압축해서는 안 된다. 눈에 보이는 캘린더 행이나 알림은 로컬 소프트웨어 상태를 증명할 수 있지만, 주최자 권한, 전역 수렴, 실제 출석에 대해서는 아무것도 증명하지 않는다.

출처