나중에 찾아보기 위해 RFC 4791을 번역된 것 남김.

Calendaring Extensions to WebDAV (CalDAV)

개요

이 문서는 iCalendar 형식을 기반으로 캘린더 및 일정 정보에 액세스, 관리, 공유하는 표준 방법을 지정하기 위해 WebDAV(Web Distributed Authoring and Versioning) 프로토콜의 확장을 정의합니다.  이 문서는 CalDAV의 'calendar-access' 기능을 정의합니다.

1. Introduction

캘린더 액세스 프로토콜의 기반으로 HTTP[RFC2616]와 WebDAV[RFC2518]를 사용하는 개념으로 결코 새로운 개념이 아니며, 1997년 또는 1998년 초에 IETF CALSCH 워킹 그룹에서 논의된 바 있습니다. 여러 회사에서 HTTP를 사용하여 iCalendar[RFC2445] 개체를 업로드 및 다운로드하고 WebDAV를 사용하여 리소스 목록을 가져오는 캘린더 액세스 프로토콜을 구현한 바 있습니다.  그러나 이러한 구현은 상호 운용되지 않는데, 그 이유는 캘린더 데이터를 WebDAV 리소스로 모델링하는 방법과 WebDAV에 아직 포함되지 않은 필수 기능을 구현하는 방법에서 크고 작은 많은 결정을 내려야 하기 때문입니다. 이 문서에서는 상호 운용 가능한 캘린더 액세스 프로토콜을 만들기 위한 추가 기능과 함께 WebDAV에서 캘린더 데이터를 모델링하는 방법을 제안합니다.

1.1. Notational Conventions

본 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMAND권장", "MAY" 및 "OPTIONAL" 키워드는 [RFC2119]에 설명된 대로 해석해야 합니다.


"protected"이라는 용어는 [RFC3253]의 1.4.2절에 정의된 대로 속성 정의의 적합성 필드에 사용됩니다.


본 문서에서 XML 조각의 컨텍스트 외부에서 "DAV:" 및 "urn:ietf:params:xml:ns:caldav" 네임스페이스의 XML 요소 유형을 참조하는 경우, 요소 유형 이름 앞에 각각 "DAV:" 및 "CALDAV:" 문자열이 접두사로 붙게 됩니다.

1.2.  XML Namespaces and Processing

이 문서에서 XML 요소의 정의는 [W3C.REC-xml-20060816]의 3.2절에 설명된 XML 요소 유형 선언(XML 문서 유형 선언에서 찾을 수 있음)을 사용합니다.

네임스페이스 "urn:ietf:params:xml:ns:caldav"는 이 사양, 그 개정판 및 관련 CalDAV 사양에 정의된 XML 요소를 위해 예약되어 있습니다.  개별 구현에 의해 정의된 XML 요소는 "urn:ietf:params:xml:ns:caldav" 네임스페이스를 사용해서는 안 되며, 대신 해당 구현이 제어하는 네임스페이스를 사용해야 합니다.

이 문서에 사용된 XML 선언에는 네임스페이스 정보가 포함되어 있지 않습니다.  따라서 구현자는 이러한 선언을 유효한 CalDAV 프로퍼티를 생성하거나 CalDAV XML 요소 유형의 유효성을 검사하는 유일한 방법으로 사용해서는 안 됩니다.  일부 선언은 "DAV:" 네임스페이스를 사용하는 WebDAV [RFC2518]에 정의된 XML 요소를 참조합니다. 이러한 XML 요소가 나타나는 곳에는 혼동을 피하기 위해 명시적으로 "DAV:"가 접두사로 붙습니다.

1.3.  Method Preconditions and Postconditions

메서드의 "precondition"(전제 조건)은 해당 메서드가 수행되기 위해 참이어야 하는 서버의 상태를 설명합니다.  메서드의 "postcondition"(사후 조건)은 해당 메서드가 완료된 후 참이어야 하는 서버의 상태를 설명합니다.  요청에 대한 메서드 전조건 또는 후조건이 충족되지 않으면 요청이 항상 실패하므로 요청을 반복해서는 안 되는 경우 요청의 응답 상태는 403(Forbidden)이거나 사용자가 충돌을 해결하고 요청을 다시 제출할 수 있을 것으로 예상되는 경우 409(Conflict)여야 합니다.

 

클라이언트가 403 및 409 응답을 더 잘 처리할 수 있도록 요청의 각 메서드 전제 조건 및 후제 조건에 고유한 XML 요소 유형이 연관됩니다.  특정 전제 조건이 충족되지 않거나 특정 후제 조건을 달성할 수 없는 경우, 요청에서 달리 협상하지 않는 한 응답 본문에서 최상위 DAV:error 요소의 하위 요소로 적절한 XML 요소를 반환해야 합니다.

2.  Requirements Overview

이 섹션에서는 CalDAV 서버에 필요한 기능을 나열합니다. 서버가 CalDAV 지원을 알리려면 다음과 같이 해야 합니다:

  • (MUST) 캘린더 객체 리소스 형식의 미디어 유형으로 iCalendar[RFC2445]를 지원해야 합니다;
  • (MUST) WebDAV 클래스 1 [RFC2518]을 지원해야 합니다([rfc2518bis]에는 상호 운용성을 지원하는 [RFC2518]에 대한 설명이 나와 있습니다);
  • (MUST) 이 문서의 섹션 6.1에 정의된 추가 권한으로 WebDAV ACL [RFC3744]을 지원해야 합니다;
  • (MUST) [RFC2818]에 정의된 대로 TLS[RFC2246]를 통한 전송을 지원해야 합니다([RFC2246]은 [RFC4346]에 의해 폐기되었음에 유의);
  • (MUST) 이 문서의 섹션 5.3.4에 명시된 추가 요구 사항과 함께 ETag [RFC2616]을 지원해야 합니다;
  • (MUST) 이 문서의 섹션 7에 정의된 모든 calendaring reports를 지원해야 합니다.
  • (MUST) WebDAV[RFC3253] Versioning Extensions에 정의된 대로 모든 캘린더 컬렉션 및 캘린더 객체 리소스에서 calendaring reports에 대한 지원을 DAV:supported- report-set 속성에 공표해야 합니다.

또한 서버:

  • (SHOULD) 이 문서의 5.3.1절에 정의된 MKCALENDAR 메서드를 지원해야 합니다.

3.  Calendaring Data Model

WebDAV를 성공적인 프로토콜로 만든 기능 중 하나는 확고한 데이터 모델입니다. 이는 캘린더와 같은 다른 애플리케이션에 유용한 프레임워크입니다. 이 사양은 잘 설명된 데이터 모델을 기반으로 모든 기능을 개발함으로써 동일한 패턴을 따릅니다.

 

간단히 요약하면, CalDAV 캘린더는 정의된 구조를 가진 WebDAV 컬렉션으로 모델링되며, 각 캘린더 컬렉션에는 직접 하위 리소스로서 캘린더 개체를 나타내는 여러 리소스가 포함되어 있습니다.  캘린더 객체(event, to-do, journal 또는 기타 캘린더 구성요소)를 나타내는 각 리소스를 "calendar object resource"라고 합니다.  각 캘린더 객체 리소스와 각 캘린더 컬렉션은 개별적으로 잠글 수 있으며 개별 WebDAV 속성을 가질 수 있습니다.  이 모델에서 파생된 요구사항은 섹션 4.1과 섹션 4.2에 나와 있습니다.

3.1.  Calendar Server

캘린더 서버는 WebDAV 저장소와 결합된 calendaring-aware engine입니다.  WebDAV 리포지토리는 통합 URL 네임스페이스 내에 다른 WebDAV 리소스를 포함하는 WebDAV 컬렉션의 집합입니다. 예를 들어, 리포지토리 "http://www.example.com/webdav/"에는 모두 "http://www.example.com/webdav/"로 시작하는 URL을 가진 WebDAV 컬렉션 및 리소스가 포함될 수 있습니다.  루트 URL인 "http://www.example.com/"는 그 자체로 WebDAV 리포지토리가 아닐 수도 있습니다(예: WebDAV 지원이 서블릿 또는 기타 웹 서버 확장을 통해 구현되는 경우).

 

WebDAV 리포지토리는 URL 네임스페이스의 일부에 캘린더 데이터를 포함하고 다른 부분에는 비캘린더 데이터를 포함할 수 있습니다.

 

WebDAV 리포지토리는 리포지토리 루트 내의 어느 지점에서든 이 사양에 정의된 기능을 지원하는 경우 스스로를 CalDAV 서버로 광고할 수 있습니다.  이는 캘린더 데이터가 리포지토리 전체에 분산되어 있고 인근 컬렉션의 비캘린더 데이터와 혼합되어 있음을 의미할 수 있습니다(예: 캘린더 데이터는 /home/lisa/calendars/와 /home/bernard/calendars/에서 찾을 수 있고, 비캘린더 데이터는 /home/lisa/contacts/에서 찾을 수 있음).  또는 리포지토리의 특정 섹션(예: /calendar/)에서만 캘린더 데이터를 찾을 수 있다는 의미일 수도 있습니다.  캘린더 기능은 캘린더 객체 리소스를 포함하거나 포함하는 리포지토리 섹션에만 필요합니다. 따라서 캘린더 데이터를 /calendar/ 컬렉션에 한정하는 리포지토리는 해당 컬렉션 내에서 CalDAV 필수 기능만 지원하면 됩니다.

CalDAV 서버 또는 리포지토리는 캘린더 데이터 및 상태 정보를 위한 표준 위치입니다. 클라이언트는 데이터 변경 또는 데이터 다운로드 요청을 제출할 수 있습니다. 클라이언트는 캘린더 개체를 오프라인으로 저장하고 나중에 동기화를 시도할 수 있습니다. 그러나 클라이언트는 여러 클라이언트를 통해 캘린더 컬렉션을 공유하고 액세스할 수 있으므로 마지막 동기화 시점과 업데이트 시도 시점 사이에 서버의 캘린더 데이터가 변경될 수 있으므로 이에 대비해야 합니다.  엔티티 태그 및 기타 기능을 통해 이를 가능하게 합니다.

3.2.  Recurrence and the Data Model

반복은 얼마나 많은 리소스가 존재할 것으로 예상되는지를 관리하기 때문에 데이터 모델에서 중요한 부분입니다.  이 사양에서는 recurring calendar component와 recurrence exception를 단일 리소스로 모델링합니다. 이 모델에서는 반복 규칙, 반복 날짜, 예외 규칙 및 예외 날짜가 모두 단일 캘린더 객체 리소스에 있는 데이터의 일부입니다.  이 모델은 리포지토리에 저장할 반복 인스턴스 수 제한, 반복 인스턴스를 반복 캘린더 구성 요소와 동기화하는 방법, 반복 예외를 반복 캘린더 구성 요소와 연결하는 방법 등의 문제를 피할 수 있습니다.  또한 클라이언트와 서버 간에 동기화할 데이터가 줄어들고 모든 되풀이 인스턴스 또는 되풀이 규칙을 더 쉽게 변경할 수 있습니다.  반복 캘린더 컴포넌트를 더 쉽게 만들고 모든 반복 인스턴스를 삭제할 수 있습니다.

 

클라이언트는 반복 구성 요소의 모든 반복 인스턴스에 대한 정보를 강제로 검색하지 않아도 됩니다.  이 문서에 정의된 CALDAV:calendar-query 및 CALDAV:calendar-multiget 보고서를 사용하면 클라이언트가 지정된 시간 범위와 겹치는 반복 인스턴스만 검색할 수 있습니다.

4. Calendar Resources

4.1. Calendar Object Resources

캘린더 컬렉션에 포함된 캘린더 객체 리소스에는 두 가지 이상의 유형의 캘린더 컴포넌트(예: VEVENT, VTODO, VJOURNAL, VFREEBUSY 등)가 포함되어서는 안 되며, iCalendar 객체에 지정된 각 고유 TZID 파라미터 값에 대해 지정되어야 하는 VTIMEZONE 컴포넌트를 제외하고는 두 가지 이상을 포함할 수 없습니다.  예를 들어, 캘린더 객체 리소스에는 하나의 VEVENT 구성 요소와 하나의 VTIMEZONE 구성 요소가 포함될 수 있지만 하나의 VEVENT 구성 요소와 하나의 VTODO 구성 요소는 포함될 수 없습니다.  대신, VEVENT 구성 요소와 VTODO 구성 요소는 동일한 컬렉션에 있는 별도의 캘린더 객체 리소스에 저장해야 합니다.

 

캘린더 컬렉션에 포함된 캘린더 객체 리소스는 iCalendar METHOD 속성을 지정하지 않아야 합니다.

 

캘린더 객체 리소스에 포함된 캘린더 구성 요소의 UID 속성 값은 해당 구성 요소가 저장된 캘린더 컬렉션의 범위 내서 고유해야 합니다.

캘린더 컬렉션의 캘린더 구성요소 중 UID 속성 값이 다른 구성요소는 별도의 캘린더 객체 리소스에 저장해야 합니다.
특정 캘린더 컬렉션에서 동일한 UID 속성 값을 가진 캘린더 구성요소는 반드시 동일한 캘린더 객체 리소스에 포함되어야 합니다.  이렇게 하면 반복 '세트'의 모든 구성요소가 동일한 캘린더 객체 리소스에 포함될 수 있습니다.  캘린더 객체 리소스에는 "재정의된" 인스턴스(일반 인스턴스의 동작을 수정하는 인스턴스이므로 RECURRENCE-ID 속성을 포함하는 인스턴스)를 나타내는 구성 요소만 포함할 수 있으며, "마스터" 반복 구성 요소(반복 "세트"를 정의하고 RECURRENCE-ID 속성을 포함하지 않는 구성 요소)는 포함하지 않을 수 있습니다.

 

예를 들어, 다음 iCalendar 개체가 있습니다:

   BEGIN:VCALENDAR
   PRODID:-//Example Corp.//CalDAV Client//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:1@example.com
   SUMMARY:One-off Meeting
   DTSTAMP:20041210T183904Z
   DTSTART:20041207T120000Z
   DTEND:20041207T130000Z
   END:VEVENT
   BEGIN:VEVENT
   UID:2@example.com
   SUMMARY:Weekly Meeting
   DTSTAMP:20041210T183838Z
   DTSTART:20041206T120000Z
   DTEND:20041206T130000Z
   RRULE:FREQ=WEEKLY
   END:VEVENT
   BEGIN:VEVENT
   UID:2@example.com
   SUMMARY:Weekly Meeting
   RECURRENCE-ID:20041213T120000Z
   DTSTAMP:20041210T183838Z
   DTSTART:20041213T130000Z
   DTEND:20041213T140000Z
   END:VEVENT
   END:VCALENDAR

 

UID 값이 "1@example.com"인 VEVENT 컴포넌트는 자체 캘린더 객체 리소스에 저장됩니다.  하나의 반복 인스턴스가 재정의된 반복 이벤트를 나타내는 UID 값이 "2@example.com"인 두 개의 VEVENT 구성 요소는 동일한 캘린더 객체 리소스에 저장됩니다.

4.2. Calendar Collection

캘린더 컬렉션에는 캘린더 내의 캘린더 구성요소를 나타내는 캘린더 객체 리소스가 포함되어 있습니다.  캘린더 컬렉션은 URL로 식별되는 WebDAV 리소스 컬렉션으로 클라이언트에게 표시됩니다.  캘린더 컬렉션은 DAV: 자원 유형 속성 값에 DAV: 컬렉션 및 CALDAV:calendar XML 요소를 보고해야 합니다.  CALDAV: calendar에 대한 요소 유형 선언은 다음과 같습니다:

<!ELEMENT calendar EMPTY>

캘린더 컬렉션은 프로비저닝을 통해 만들거나(즉, 사용자 계정이 프로비저닝될 때 자동으로 만들어짐), MKCALENDAR 메서드를 사용하여 만들 수 있습니다(5.3.1절 참조).  이 방법은 사용자가 추가 캘린더(예: 축구 일정)를 만들거나 사용자가 캘린더(예: 팀 이벤트 또는 회의실)를 공유할 때 유용할 수 있습니다.  하지만 이 문서에서는 추가 캘린더 컬렉션의 용도를 정의하고 있지 않다는 점에 유의하세요.  사용자는 비표준 단서에 의존하여 캘린더 컬렉션의 용도를 찾거나 섹션 5.2.1에 정의된 CALDAV:calendar-description 속성을 사용하여 그러한 단서를 제공해야 합니다.

 

캘린더 컬렉션 내의 리소스에는 다음과 같은 제한이 적용됩니다:

  1. 캘린더 컬렉션에는 캘린더 객체 리소스와 캘린더 컬렉션이 아닌 컬렉션만 포함되어야 합니다. 즉, 캘린더 컬렉션에서 허용되는 유일한 "최상위" 비컬렉션 리소스는 캘린더 객체 리소스입니다.  따라서 캘린더 클라이언트는 캘린더 컬렉션에서 캘린더 이외의 데이터를 처리할 필요가 없지만, 표준 WebDAV 기술을 사용하여 컬렉션의 콘텐츠를 검사할 때는 캘린더 객체 리소스와 컬렉션을 구분해야 합니다.
  2. 캘린더 컬렉션에 포함된 컬렉션은 어떤 깊이의 캘린더 컬렉션도 포함해서는 안 됩니다. 즉, 어떤 깊이의 다른 캘린더 컬렉션 내에 캘린더 컬렉션을 "중첩"하는 것은 허용되지 않습니다.  이 사양은 캘린더 컬렉션에 포함된 컬렉션의 사용 방법이나 캘린더 컬렉션에 포함된 캘린더 객체 리소스와 관련된 방법을 정의하지 않습니다.

여러 캘린더 컬렉션은 동일한 컬렉션의 하위 컬렉션일 수 있습니다.

'calendar' 카테고리의 다른 글

CalDAV - Calendar Access Feature,  (0) 2023.04.25
iTIP - Interoperability Models  (1) 2023.04.19
iTIP - Introduction  (0) 2023.04.19

나중에 찾아보기 위해 RFC 2446을 번역된 것 남김.

iCalendar Transport-Independent Interoperability Protocol (iTIP)
Scheduling Events, BusyTime, To-dos and Journal Entries

2 Interoperability Models

상호 운용성과 관련된 프로토콜에는 "응용 프로그램 프로토콜"과 "전송 프로토콜"이라는 두 가지가 있습니다. 애플리케이션 프로토콜은 위에 나열된 스케줄링 트랜잭션을 수행하기 위해 발신자와 수신자 간에 전송되는 iCalendar 개체의 내용을 정의합니다. 전송 프로토콜은 발신자와 수신자 간에 iCalendar 개체를 전송하는 방법을 정의합니다. 이 문서는 애플리케이션 프로토콜에 중점을 둡니다. iMIP]와 같은 바인딩 문서는 전송 프로토콜에 중점을 둡니다.

아래 다이어그램에서 발신자와 수신자 간의 연결은 애플리케이션 프로토콜을 참조합니다. 발신자에서 수신자에게 전달되는 iCalendar 개체는 섹션 3, 애플리케이션 프로토콜 요소에 나와 있습니다.

   +----------+                      +----------+
   |          |        iTIP          |          |
   |  Sender  |<-------------------->| Receiver |
   |          |                      |          |
   +----------+                      +----------+

이 다이어그램에는 발신자와 수신자가 'Calendar User Agent(CUA)' 또는 'Calendar Service(CS)'의 다양한 역할을 맡는 여러 가지 변형이 있습니다.

iTIP의 아키텍처는 아래 다이어그램에 나와 있습니다. 이 사양에 따라 작성된 애플리케이션은 저장 후 전달 전송, 실시간 전송 또는 둘 다에 대한 바인딩과 함께 작동할 수 있습니다. 또한 iTIP는 다른 전송에 바인딩될 수도 있습니다.

   +------------------------------------------+
   |                   iTIP                   |
   +------------------------------------------+
   |Real-time | Store-and-Fwd | Other         |
   |Transport | Transport     | Transports... |
   +------------------------------------------+

2.1 Application Protocol

iTIP 모델에서 캘린더 항목은 "주최자"가 생성하고 관리합니다. "주최자"는 위에 나열된 iTIP 메시지 중 하나 이상을 전송하여 다른 CU와 상호 작용합니다. "참석자"는 "회신" 방법을 사용하여 자신의 상태를 전달합니다. "참석자"는 마스터 캘린더 항목을 직접 변경할 수 없습니다. 그러나 "카운터" 방법을 사용하여 "주최자"에게 변경 사항을 제안할 수 있습니다. 어떤 경우든 "주최자"는 마스터 캘린더 항목을 완전히 제어할 수 있습니다.

2.1.1 Calendar Entry State

캘린더 항목과 관련된 상태에는 항목의 전체 상태와 해당 항목의 '참석자'와 관련된 상태라는 두 가지가 있습니다.

항목의 상태는 "상태" 속성에 의해 정의되며 "주최자"에 의해 제어됩니다. "상태" 속성에는 기본값이 없습니다. "주최자"는 "상태" 속성을 각 일정관리 항목에 적합한 값으로 설정합니다.

항목과 관련된 특정 "참석자"의 상태는 각 "참석자"의 "참석자" 속성에 있는 "partstat" 매개변수에 의해 정의됩니다.  "주최자"가 초기 항목을 발행하면 "참석자" 상태를 알 수 없습니다. "주최자"는 "partstat" 매개변수를 "NEEDS-ACTION"으로 설정하여 이를 지정합니다. 각 "참석자"는 "참석자" 속성의 "partstat" 매개변수를 적절한 값으로 수정하여 "주최자"에게 다시 보내는 "REPLY" 메시지의 일부로 사용합니다.

2.1.2 Delegation

위임은 "참석자"가 다른 CU(또는 여러 CU)에 자신을 대신하여 참석할 수 있는 권한을 부여하는 절차로 정의됩니다. "주최자"는 위임하는 "참석자"가 "주최자"에게 알리기 때문에 이러한 변경 사항을 알게 됩니다. 이러한 단계는 요청 방법 섹션에 자세히 설명되어 있습니다.

2.1.3 Acting on Behalf of other Calendar Users

많은 조직에서 한 사용자가 다른 사용자를 대신하여 미팅 요청을 조직하거나 응답합니다. ITIP는 이러한 활동을 지원하는 두 가지 메커니즘을 제공합니다.

첫째, '주최자'는 '참석자'와는 별개의 특수한 개체로 취급됩니다. '참석자'의 모든 응답은 '주최자'에게 전달되므로 미팅을 조직하는 캘린더 사용자와 미팅에 참석하는 캘린더 사용자를 쉽게 구분할 수 있습니다. 또한, iCalendar는 각 "참석자"에 대해 설명적인 역할을 제공합니다. 예를 들어, '의장'이라는 역할은 한 명 이상의 '참석자'에게 할당될 수 있습니다. "의장"과 "주최자"는 동일한 캘린더 사용자일 수도 있고 아닐 수도 있습니다. 이는 어시스턴트가 회의의 의장을 맡은 다른 사람을 위해 회의 일정을 관리할 수 있는 시나리오에 잘 부합합니다.

둘째, '보낸 사람' 매개변수는 '주최자' 또는 '참석자' 속성 중 하나에 지정할 수 있습니다. 지정된 경우, "보낸 사람" 매개변수는 응답하는 CU가 지정된 "참석자" 또는 "주최자"를 대신하여 작업했음을 나타냅니다.

2.1.4 Component Revisions

"SEQUENCE" 속성은 "주최자"가 캘린더 구성 요소의 수정본을 표시하는 데 사용됩니다. "SEQUENCE" 숫자를 증가시키는 규칙은 [iCAL]에 정의되어 있습니다. 명확성을 위해 여기서는 이러한 규칙을 [iTIP]에서 적용되는 방식에 따라 의역했습니다. 캘린더 컴포넌트에서 주어진 "UID"에 대해:

. "PUBLISH" 및 "REQUEST" 메서드의 경우, [iCAL]에 정의된 규칙에 따라 "SEQUENCE" 속성 값이 증가합니다.
. "주최자"가 "추가" 또는 "취소" 메서드를 사용할 때마다 "SEQUENCE" 속성 값은 반드시 증가해야 합니다.
. "응답", "새로고침", "카운터", "선언 카운터"를 사용하거나 "요청" 위임을 보낼 때 "SEQUENCE" 속성 값을 증가시키면 안됩니다.

경우에 따라 "주최자"는 발송된 최종 수정본에 대한 응답을 받지 못할 수도 있습니다. 이 경우 "주최자"는 업데이트 "REQUEST"를 보내고 모든 "참석자"에 대해 "RSVP=TRUE"를 설정하여 현재 응답을 수집할 수 있도록 할 수 있습니다.

 

"참석자"의 응답에 포함된 "SEQUENCE" 속성 값은 "주최자"의 수정본과 항상 일치하지 않을 수 있습니다. 구현은 CUA가 CU에 응답이 수정된 항목에 대한 것임을 표시하고 CU가 응답을 수락할지 여부를 결정하도록 선택할 수 있습니다.

2.1.5 Message Sequencing

iTIP] 애플리케이션 프로토콜을 처리하는 CUA는 종종 캘린더 저장소의 구성 요소와 [iTIP] 메시지로 수신된 구성 요소를 연관시켜야 합니다. 예를 들어, 이벤트가 동일한 이벤트의 이후 개정판으로 업데이트될 수 있습니다. 이를 위해 CUA는 캘린더 저장소에 이미 있는 이벤트의 버전과 [iTIP] 메시지로 전송된 버전을 상호 연관시켜야 합니다. 이러한 상관관계 외에도 [iTIP] 메시지가 예기치 않은 순서로 도착하는 원인이 될 수 있는 몇 가지 요인이 있습니다.  즉, '주최자'가 구성 요소의 이전 버전에 대한 회신을 받은 후에 이후 버전에 대한 회신을 받을 수 있습니다.

상호 운용성을 극대화하고 예기치 않은 순서로 도착하는 메시지를 처리하려면 다음 규칙을 사용하세요:

 

  1. 특정 iCalendar 구성 요소를 참조하기 위한 기본 키는 "UID" 속성 값입니다. 반복 구성 요소의 인스턴스를 참조하기 위해 기본 키는 "UID" 및 "RECURRENCE-ID" 속성으로 구성됩니다.
  2. 컴포넌트를 참조하기 위한 보조 키는 "SEQUENCE" 속성 값입니다.  "UID"가 동일한 컴포넌트의 경우, "SEQUENCE" 속성 값이 가장 높은 컴포넌트가 낮은 값을 가진 컴포넌트의 다른 모든 리비전을 무시합니다.
  3. "참석자"는 "주최자"에게 "REPLY" 메시지를 보냅니다.  "UID" 속성 값이 동일한 답장의 경우, "SEQUENCE" 속성 값은 "참석자"가 답장하는 구성 요소의 리비전을 나타냅니다.  "SEQUENCE" 속성의 가장 높은 숫자 값을 가진 회신은 낮은 값을 가진 다른 모든 회신을 무시합니다.
  4. "UID" 및 "SEQUENCE" 속성이 일치하는 경우, "DTSTAMP" 속성이 동점자로 사용됩니다. 가장 최근의 "DTSTAMP"를 가진 구성 요소가 다른 모든 구성 요소보다 우선합니다. 마찬가지로 "UID" 속성 값이 일치하고 "SEQUENCE" 속성 값이 일치하는 "참석자" 응답의 경우 가장 최근의 "DTSTAMP"가 있는 응답이 다른 모든 응답보다 우선합니다.

따라서 CUA는 다음 구성 요소 속성을 유지해야 합니다: "UID", "RECURRENCE-ID", "SEQUENCE" 및 "DTSTAMP".  또한 구성 요소의 각 "참석자" 속성에 대해 CUA는 "참석자"의 응답과 관련된 "SEQUENCE" 및 "DTSTAMP" 속성 값을 유지해야 합니다.

나중에 찾아보기 위해 RFC 2446을 번역된 것 남김.

iCalendar Transport-Independent Interoperability Protocol (iTIP)
Scheduling Events, BusyTime, To-dos and Journal Entries

개요

이 문서는 캘린더 시스템이 iCalendar 객체를 사용하여 다른 캘린더 시스템과 상호 운용하는 방법을 지정합니다. 이는 시스템 간의 다양한 통신 방법을 허용하기 위해 일반적인 방식으로 수행됩니다. 후속 문서에서는 이 프로토콜을 사용하는 시스템 간의 상호 운용 가능한 통신 방법을 지정합니다.

이 문서에서는 static 및 dynamic event, to-do, journal, free/busy 개체를 모두 정의하는 캘린더 교환 모델을 간략하게 설명합니다. static 객체는 원본 항목과의 연속성이나 참조 무결성을 기대하지 않고 한 개체에서 다른 개체로 정보를 전송하는 데 사용됩니다. dyamic 객체는 정적 객체의 상위 집합이며 static 객체만 지원하는 클라이언트의 경우 static 객체로 자연스럽게 저하됩니다.

이 문서는 서로 다른 캘린더 시스템 간에 일정관리 상호 운용성을 제공하는 iCalendar 객체 사양을 기반으로 하는 인터넷 프로토콜을 지정합니다. 이 인터넷 프로토콜을 "iTIP(iCalendar 전송 독립적 상호 운용성 프로토콜)"이라고 합니다.

iTIP는 현재 캘린더 시스템에서 일반적으로 사용할 수 있는 그룹 스케줄링 메서드에 대한 시맨틱을 추가하여 iCalendar 객체 사양을 보완합니다. 이러한 예약 방법을 사용하면 두 개 이상의 캘린더 시스템이 게시, 예약, 일정 재조정, 예약 요청에 대한 응답, 변경 협상 또는 iCalendar 기반 캘린더 구성 요소 취소와 같은 트랜잭션을 수행할 수 있습니다.

iTIP는 스케줄링 정보를 전송하는 데 사용되는 특정 전송 방식과 무관하게 정의됩니다. iTIP에 대한 동반 메모는 여러 인터넷 프로토콜에 대한 상호 운용성 프로토콜의 바인딩을 제공합니다.

1. Introduction

이 문서는 캘린더 시스템이 iCalendar 개체를 사용하여 다른 캘린더 시스템과 상호 운용하는 방법을 지정합니다. 특히 event, to-do 또는 daily journal 항목을 예약하는 방법을 명시합니다. 또한 사용 가능한 바쁜(busy) 시간 정보를 검색하는 방법을 지정합니다. 이는 시스템 간의 다양한 통신 방법을 허용하기 위해 일반적인 방식으로 수행됩니다. 후속 문서에서는 이 프로토콜을 사용하는 시스템 간의 전송 바인딩을 지정합니다.

이 프로토콜은 발신자(originator)가 한 명 이상의 수신자(recipients)에게 보내는 메시지를 기반으로 합니다. 특정 유형의 메시지에 대해 수신자는 자신의 상태를 업데이트하기 위해 응답할 수 있으며 트랜잭션/요청 상태 정보를 반환할 수도 있습니다. 이 프로토콜은 메시지 발신자가 원래 메시지를 수정하거나 취소할 수 있는 기능을 지원합니다. 또한 프로토콜은 수신자가 메시지 발신자에게 변경 사항을 제안할 수 있는 기능도 지원합니다. 프로토콜의 요소는 트랜잭션에 대한 사용자 역할도 정의합니다.

1.1 Formatting Conventions

캘린더링 및 스케줄링 모델, 핵심 객체 또는 상호 운용성 프로토콜의 요소를 참조하기 위해 [iCAL] 및 [iTIP]에 정의된 몇 가지 형식 규칙이 활용되었습니다.

이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENT", "MAY" 및 "OPTIONAL"이라는 키워드는 [RFC-2119]에 설명된 대로 해석되어야 합니다.

캘린더 및 스케줄링 역할은 각 단어의 첫 글자를 대문자로 따옴표로 묶은 텍스트 문자열로 참조됩니다. 예를 들어, 'Organizer'(주최자)는 [iTIP]에 정의된 스케줄링 프로토콜 내에서 'Calendar User(캘린더 사용자)'(CU)의 역할을 나타냅니다. [iCAL]에 정의된 캘린더 구성 요소는 대문자로 따옴표로 묶인 문자열로 참조됩니다. 모든 캘린더 구성 요소는 문자 "V"로 시작합니다. 예를 들어, "VEVENT"는 이벤트 캘린더 구성 요소, "VTODO"는 할 일 캘린더 구성 요소, "VJOURNAL"은 일일 저널 캘린더 구성 요소를 나타냅니다. [iTIP]에 정의된 스케줄링 메서드는 대문자로 따옴표로 묶인 텍스트로 참조됩니다. 예를 들어, "REQUEST"은 일정관리 캘린더 구성 요소의 생성 또는 수정을 요청하는 메서드를 의미하고, "REPLY"은 요청을 받은 사람이 캘린더 구성 요소의 "Organizer"에게 자신의 상태를 업데이트하는 데 사용하는 메서드를 의미합니다.

[iCAL]에 정의된 속성은 대문자로 따옴표로 묶인 텍스트 문자열 뒤에 "property"이라는 단어가 붙어서 참조됩니다. 예를 들어, "ATTENDEE"(참석자) 속성은 "Calendar User"(캘린더 사용자)의 캘린더 주소를 전달하는 데 사용되는 iCalendar 속성을 나타냅니다. 이 메모에 정의된 속성 매개변수는 소문자로 따옴표로 묶인 텍스트 문자열 뒤에 "parameter"라는 단어가 붙어서 참조됩니다. 예를 들어, "value" 매개변수는 속성 값의 기본 데이터 유형을 재정의하는 데 사용되는 iCalendar 속성 매개변수를 나타냅니다. 이 메모에 정의된 열거형 값은 대문자로 된 텍스트를 단독으로 사용하거나 그 뒤에 "value"라는 단어를 사용하여 참조합니다.

테이블에서는 테이블 길이를 최소화하기 위해 따옴표로 묶인 문자열 텍스트가 따옴표 없이 지정됩니다.

 

1.2 Related Documents

구현자는 이 문서와 함께 인터넷 캘린더 및 스케줄링 표준을 설명하는 다른 여러 메모를 숙지하고 있어야 합니다. 이 문서인 [iTIP]는 서로 다른 구현 간의 스케줄링을 위한 상호 운용성 프로토콜을 지정합니다. 관련 문서는 다음과 같습니다:

     [iCAL] - 프로토콜에 사용되는 객체, 데이터 유형, 속성 및 속성 매개변수와 이를 표현하고 인코딩하는 방법을 지정합니다;

     [iMIP] - [iTIP]에 대한 인터넷 이메일 바인딩을 지정합니다.

이 메모에서는 이러한 다른 메모의 개념이나 정의에 대한 사양을 반복하지 않습니다. 가능한 경우 이러한 개념 또는 정의의 사양을 제공하는 메모를 참조합니다.

1.3 ITIP Roles and Transactions

ITIP는 "Calendar User"(CU) 간의 그룹 캘린더링 및 예약을 목적으로 [iCAL] 개체를 교환하는 방법을 정의합니다. CU는 iTIP에서 두 가지 역할 중 하나를 수행합니다. 교환을 시작한 CU는 "Organizer"(주최자) 역할을 맡습니다. 예를 들어, 그룹 모임을 제안한 CU가 "Organizer"입니다. "Organizer"로부터 그룹 미팅에 참여하도록 요청받은 CU는 "Attendee"(참석자) 역할을 맡습니다. "role"은 _ATTENDEE_ 속성에 대한 설명 매개변수이기도 합니다. 이 매개변수는 'chair', 'req-participant' 또는 'non-participant'와 같이 'Attendee'에게 설명적인 컨텍스트를 전달하는 데 사용되며 캘린더 워크플로와는 아무런 관련이 없습니다.

ITIP 메서드는 아래에 나열되어 있으며 그 사용법과 의미는 이 문서의 섹션 3에 정의되어 있습니다.

Method Description
PUBLISH 한 명 이상의 캘린더 사용자에게 캘린더 항목을 게시하는 데 사용됩니다. 게시자와 다른 캘린더 사용자 간에는 상호 작용이 없습니다. 예를 들어 야구 팀이 대중에게 일정을 게시하는 경우를 들 수 있습니다.
REQUEST 다른 캘린더 사용자와 캘린더 항목을 예약하는 데 사용됩니다. 요청은 수신자가 응답 메서드를 사용해 응답해야 한다는 점에서 대화형입니다. 미팅 요청, 바쁨 시간 요청, 다른 캘린더 사용자에게 VTODO 할당 등이 모두 그 예입니다. 요청은 'Organizer'가 캘린더 항목의 상태를 업데이트하는 데에도 사용됩니다.
REPLY Reply은 'Attendee' 상태를 'Organizer'에게 전달해 달라는 요청에 대한 응답으로 사용됩니다. 회신은 일반적으로 미팅 및 작업 요청에 응답하는 데 사용됩니다.
ADD 기존 VEVENT, VTODO 또는 VJOURNAL에 하나 이상의 인스턴스를 추가합니다.
CANCEL 기존 VEVENT, VTODO 또는 VJOURNAL의 인스턴스를 하나 이상 취소합니다.
REFRESH REFRESH 방법은 'Attendee'가 캘린더 항목의 최신 버전을 요청하는 데 사용됩니다.
COUNTER Counter 메서드는 'Attendee'가 캘린더 항목의 변경을 협상하는 데 사용됩니다. 예를 들어, 제안된 이벤트 시간을 변경하거나 VTODO의 마감일을 변경하는 요청이 있습니다.
DECLINE-COUNTER "Organizer"가 제안된 반대 제안을 거부하는 데 사용됩니다.

iTIP에서 그룹 예약은 위에서 설명한 "request" 및 "response" 메서드 세트를 사용하여 수행됩니다. 다음 표는 메서드를 보낼 수 있는 사람에 따라 분류된 메서드를 보여줍니다.

Originator Methods
Organizer PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER
Attendee REPLY, REFRESH, COUNTER
REQUEST only when delegating  

일부 캘린더 컴포넌트 유형의 경우 허용되는 메서드가 위 집합의 하위 집합이라는 점에 유의하세요.

+ Recent posts