RFC 2446 번역은 나중에 참조할 수 있도록 남겨둡니다.
iCalendar 전송 독립 상호 운용성 프로토콜(iTIP)
일정 이벤트, BusyTime, 할 일 및 저널 항목
2 상호 운용성 모델
상호 운용성과 관련된 프로토콜에는 “응용 프로그램 프로토콜”과 “전송 프로토콜”의 두 가지 유형이 있습니다.
애플리케이션 프로토콜은 위에 나열된 예약 트랜잭션을 수행하기 위해 발신자와 수신자 간에 전송되는 iCalendar 개체의 콘텐츠를 정의합니다.
전송 프로토콜은 iCalendar 개체가 발신자와 수신자 간에 전송되는 방식을 정의합니다.
이 문서는 애플리케이션 프로토콜에 중점을 둡니다.
iMIP와 같은 바인딩 문서는 전송 프로토콜에 중점을 둡니다.
아래 다이어그램에서 발신자와 수신자 간의 연결은 응용 프로토콜을 나타냅니다.
발신자에서 수신자로 전달되는 iCalendar 개체는 섹션 3, “응용 프로그램 프로토콜 요소”에 나와 있습니다.
+----------+ +----------+
| | iTIP | |
| Sender |<-------------------->| Receiver |
| | | |
+----------+ +----------+
발신자와 수신자가 “CUA(Calendar User Agent)” 또는 “CS(Calendar Service)”의 다른 역할을 가정하는 이 다이어그램의 변형이 있습니다.
iTIP의 아키텍처는 아래 그림과 같습니다.
이 사양으로 작성된 응용 프로그램은 저장 후 전달 전송, 실시간 전송 또는 이 둘의 조합과 함께 사용할 수 있습니다.
iTIP은 다른 전송에 바인딩될 수도 있습니다.
+------------------------------------------+
| iTIP |
+------------------------------------------+
|Real-time | Store-and-Fwd | Other |
|Transport | Transport | Transports... |
+------------------------------------------+
2.1 애플리케이션 프로토콜
iTIP 모델에서 캘린더 항목은 “주최자”가 만들고 관리합니다.
“주최자”는 위에 나열된 하나 이상의 iTIP 메시지를 전송하여 다른 CU와 상호 작용합니다.
“대기자”는 “회신” 방법을 사용하여 자신의 상태를 전달합니다.
“대기자”는 기본 일정 항목을 직접 변경할 수 없습니다.
다만, “카운터” 방식을 이용하여 “주최자”에게 변경사항을 제안할 수 있습니다.
두 경우 모두 “주최자”는 기본 캘린더 항목을 완전히 제어할 수 있습니다.
2.1.1 달력 입력 상태
일정 항목과 관련된 두 가지 상태가 있습니다.
항목의 전체 상태와 해당 항목의 참석자와 관련된 상태입니다.
항목의 상태는 “Status” 속성에 의해 정의되고 “Organizer”에 의해 제어됩니다.
“state” 속성에는 기본값이 없습니다.
“Organizer”는 “Status” 속성을 각 일정 항목에 대한 적절한 값으로 설정합니다.
프로젝트와 관련된 특정 “참가자”의 상태는 각 “참가자”의 “참가자” 속성에 있는 “partstat” 매개변수에 의해 정의됩니다.
주최자가 초기 항목을 게시할 때 참석자 상태를 알 수 없습니다.
“Organizer”는 “partstat” 매개변수를 “NEEDS-ACTION”으로 설정하여 이를 지정합니다.
각 “참석자”는 “참석자” 속성의 “partstat” 매개변수를 적절한 값으로 수정하고 이를 “호스트”로 다시 전송되는 “REPLY” 메시지의 일부로 사용합니다.
2.1.2 승인
위임은 “참석자”가 다른 CU(또는 CU)가 자신을 대신하여 참석하도록 승인하는 프로세스로 정의됩니다.
주최자는 위임된 참석자가 주최자에게 알렸기 때문에 이러한 변경 사항을 알고 있습니다.
이러한 단계는 요청 방법 섹션에 자세히 설명되어 있습니다.
2.1.3 다른 캘린더 사용자를 대신하여
많은 조직에서 한 사용자가 다른 사용자를 대신하여 모임 요청을 구성하거나 이에 응답합니다.
ITIP는 이러한 활동을 지원하는 두 가지 메커니즘을 제공합니다.
첫째, “주최자”는 “참석자”와 별개의 특별한 개체로 간주됩니다.
참석자의 모든 회신은 주최자에게 전달되므로 회의를 조직한 캘린더 사용자와 회의에 참석한 사용자를 쉽게 구분할 수 있습니다.
또한 iCalendar는 각 “참석자”에 대한 설명 역할을 제공합니다.
예를 들어, “의장” 역할을 한 명 이상의 “보조자”에게 할당할 수 있습니다.
“의장”과 “주최자”는 동일한 캘린더 사용자일 수도 있고 아닐 수도 있습니다.
이는 어시스턴트가 회의를 주최하는 다른 사람을 위해 회의를 예약할 수 있는 시나리오에 유용합니다.
둘째, “발신자” 매개변수는 “Host” 또는 “Attendee” 속성에서 지정할 수 있습니다.
지정된 경우 “From” 매개변수는 응답 CU가 지정된 “Attendant” 또는 “Host”를 나타냄을 나타냅니다.
2.1.4 구성 요소 개정
“Organizer”는 “SEQUENCE” 속성을 사용하여 달력 구성 요소의 개정판을 표시합니다.
“SEQUENCE” 번호를 증가시키는 규칙은 (iCAL)에 정의되어 있습니다.
명확성을 위해 이러한 규칙은 (iTIP)에 적용되는 방식에 대해 설명되어 있습니다.
일정 구성 요소의 지정된 “UID”에 대해:
. “PUBLISH” 및 “REQUEST” 방법의 경우 “SEQUENCE” 속성 값이 (iCAL)에 정의된 규칙에 따라 증가합니다.
구성자가 Append 또는 Cancel 메서드를 사용할 때마다 Sequence 속성 값을 증가시켜야 합니다.
. ‘응답’, ‘새로 고침’, ‘카운터’, ‘문장 카운터’를 사용하거나 ‘요청’ 대리자를 보낼 때 ‘SEQUENCE’ 속성 값을 증가시키면 안 됩니다(MUST NOT).
경우에 따라 주최자는 보낸 최종 수정본에 대한 회신을 받지 못할 수 있습니다.
이 경우 “호스트”는 업데이트 “REQUEST”를 보내고 모든 “참석자”에 대해 “RSVP=TRUE”를 설정하여 현재 응답을 수집할 수 있습니다.
“Attendant” 응답에 포함된 “SEQUENCE” 속성의 값이 항상 “Host”의 개정과 일치하지 않을 수 있습니다.
구현은 CUA가 수정된 항목에 대한 응답임을 CU에 알리고 CU가 응답 수락 여부를 결정하도록 선택할 수 있습니다.
2.1.5 메시지 정렬
iTIP) 응용 프로그램 프로토콜을 처리하는 CUA는 일반적으로 일정 저장소의 구성 요소를 (iTIP) 메시지로 받은 구성 요소와 연결해야 합니다.
예를 들어 이벤트는 동일한 이벤트의 이후 버전으로 업데이트될 수 있습니다.
이를 위해 CUA는 일정 저장소에 이미 있는 이벤트 버전을 (iTIP) 메시지로 전송된 버전과 연결해야 합니다.
이러한 종속성 외에도 (iTIP) 메시지가 예기치 않은 순서로 도착할 수 있는 몇 가지 요인이 있습니다.
즉, “호스트”는 구성 요소의 이전 버전에 대한 응답을 받은 후 이후 버전에 대한 응답을 받을 수 있습니다.
상호 운용성을 최대화하고 예기치 않은 순서로 도착하는 메시지를 처리하려면 다음 규칙을 사용하십시오.
- 특정 iCalendar 구성요소를 참조하는 기본 키는 “UID” 속성 값입니다.
반복 구성 요소의 인스턴스를 참조하기 위해 기본 키는 “UID” 및 “RECURRENCE-ID” 속성으로 구성됩니다. - 참조된 구성요소의 보조 키는 “SEQUENCE” 속성 값입니다.
동일한 “UID”를 가진 구성 요소의 경우 가장 높은 “SEQUENCE” 속성 값을 가진 구성 요소가 더 낮은 값을 가진 구성 요소의 다른 모든 개정을 재정의합니다. - “Attendant”는 “REPLY” 메시지를 “Host”로 보냅니다.
“UID” 속성 값이 동일한 회신의 경우 “SEQUENCE” 속성 값은 “참석자”가 회신하는 구성 요소의 개정판을 나타냅니다.
“SEQUENCE” 속성에 대한 가장 높은 숫자 값을 가진 회신은 더 낮은 값을 가진 다른 모든 회신보다 우선합니다. - “UID” 및 “SEQUENCE” 속성이 일치하면 “DTSTAMP” 속성이 순위 결정자로 사용됩니다.
최신 “DTSTAMP”가 있는 구성 요소가 다른 모든 구성 요소보다 우선합니다.
마찬가지로 “UID” 속성 값과 “SEQUENCE” 속성 값과 일치하는 “참석자” 응답의 경우 최신 “DTSTAMP” 응답이 다른 모든 응답보다 우선합니다.
따라서 CUA는 “UID”, “RECURRENCE-ID”, “SEQUENCE” 및 “DTSTAMP”와 같은 구성 요소 속성을 유지해야 합니다.
또한 구성 요소의 각 “참석자” 속성에 대해 CUA는 “참석자”의 응답과 연결된 “SEQUENCE” 및 “DTSTAMP” 속성 값을 유지해야 합니다.