나중에 찾아보기 위해 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 속성을 사용하여 그러한 단서를 제공해야 합니다.
캘린더 컬렉션 내의 리소스에는 다음과 같은 제한이 적용됩니다:
- 캘린더 컬렉션에는 캘린더 객체 리소스와 캘린더 컬렉션이 아닌 컬렉션만 포함되어야 합니다. 즉, 캘린더 컬렉션에서 허용되는 유일한 "최상위" 비컬렉션 리소스는 캘린더 객체 리소스입니다. 따라서 캘린더 클라이언트는 캘린더 컬렉션에서 캘린더 이외의 데이터를 처리할 필요가 없지만, 표준 WebDAV 기술을 사용하여 컬렉션의 콘텐츠를 검사할 때는 캘린더 객체 리소스와 컬렉션을 구분해야 합니다.
- 캘린더 컬렉션에 포함된 컬렉션은 어떤 깊이의 캘린더 컬렉션도 포함해서는 안 됩니다. 즉, 어떤 깊이의 다른 캘린더 컬렉션 내에 캘린더 컬렉션을 "중첩"하는 것은 허용되지 않습니다. 이 사양은 캘린더 컬렉션에 포함된 컬렉션의 사용 방법이나 캘린더 컬렉션에 포함된 캘린더 객체 리소스와 관련된 방법을 정의하지 않습니다.
여러 캘린더 컬렉션은 동일한 컬렉션의 하위 컬렉션일 수 있습니다.
'calendar' 카테고리의 다른 글
CalDAV - Calendar Access Feature, (0) | 2023.04.25 |
---|---|
iTIP - Interoperability Models (1) | 2023.04.19 |
iTIP - Introduction (0) | 2023.04.19 |