RFC2446 日本語訳
2446 iCalendar Transport-Independent Interoperability Protocol (iTIP)Scheduling Events, BusyTime, To-dos and Journal Entries. S.Silverberg, S. Mansour, F. Dawson, R. Hopson. November 1998. (Format: TXT=225964 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Silverberg
Request for Comments: 2446 Microsoft
Category: Standards Track S. Mansour
Netscape
F. Dawson
Lotus
R. Hopson
ON Technologies
November 1998
コメントを求めるワーキンググループS.シルバーバーグの要求をネットワークでつないでください: 2446年のマイクロソフトカテゴリ: 規格は1998年11月に技術でS.マンスール・Netscape F.ドーソン・ロータスR.ホプソンを追跡します。
iCalendar Transport-Independent Interoperability Protocol
(iTIP)
Scheduling Events, BusyTime, To-dos and Journal Entries
出来事、BusyTime、大騒ぎ、および仕訳記入の計画をするiCalendarの輸送から独立している相互運用性プロトコル(iTIP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. Subsequent documents specify interoperable methods of communications between systems that use this protocol.
このドキュメントはcalendaringシステムが他のカレンダーシステムで共同利用するのにどうiCalendar物を使用するかを指定します。それは、システムのコミュニケーションの複数の方法を許容するためにザッとします。その後のドキュメントはこのプロトコルを使用するシステムのコミュニケーションの共同利用できる方法を指定します。
The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects. Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects.
ドキュメントは静的なものと同様にダイナミックな出来事を定義するカレンダー交換、大騒ぎ、ジャーナル、および無料の、または、忙しい物のためにモデルについて概説します。 静的な物は、オリジナルの項目で連続か参考の保全への期待なしで情報を1つの実体から別の実体まで伝えるのに使用されます。 ダイナミックな物は、静的な物のスーパーセットであり、静的な物を支えるだけであるクライアントのために優雅に彼らの静的な対応者へ退行するでしょう。
This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the "iCalendar Transport-Independent Interoperability Protocol (iTIP)".
このドキュメントは異なったカレンダーシステムの間にスケジューリング相互運用性を供給するiCalendar物の仕様に基づくインターネットプロトコルを指定します。インターネットプロトコルは「iCalendarの輸送から独立している相互運用性プロトコル(iTIP)」と呼ばれます。
Silverberg, et. al. Standards Track [Page 1] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[1ページ]。
iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components.
iTIPは、現在のカレンダーシステムで一般的に利用可能なグループスケジューリング方法のために意味論を加えることによって、iCalendar物の仕様の補足となります。これらのスケジューリング法は、発行するような取引を実行するシステム(スケジュール)が時期変更する2以上カレンダーを可能にするか、スケジューリング要求、変化の交渉に応じるか、またはiCalendarベースのカレンダーコンポーネントを取り消します。
iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols.
iTIPはスケジューリング情報を伝えるのに使用される特定の輸送の如何にかかわらず定義されます。 iTIPへの仲間メモは相互運用性プロトコルの結合を多くのインターネットプロトコルに提供します。
Table of Contents
目次
1 INTRODUCTION...................................................5
1.1 FORMATTING CONVENTIONS .....................................5
1.2 RELATED DOCUMENTS ..........................................6
1.3 ITIP ROLES AND TRANSACTIONS ................................6
2 INTEROPERABILITY MODELS........................................8
2.1 APPLICATION PROTOCOL .......................................9
2.1.1 Calendar Entry State ...................................9
2.1.2 Delegation .............................................9
2.1.3 Acting on Behalf of other Calendar Users ..............10
2.1.4 Component Revisions ...................................10
2.1.5 Message Sequencing ....................................11
3 APPLICATION PROTOCOL ELEMENTS.................................12
3.1 COMMON COMPONENT RESTRICTION TABLES .......................13
3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ....................14
3.2.1 PUBLISH ...............................................15
3.2.2 REQUEST ...............................................17
3.2.2.1 Rescheduling an Event..............................19
3.2.2.2 Updating or Reconfirmation of an Event.............19
3.2.2.3 Delegating an Event to another CU..................19
3.2.2.4 Changing the Organizer.............................20
3.2.2.5 Sending on Behalf of the Organizer.................20
3.2.2.6 Forwarding to An Uninvited CU......................20
3.2.2.7 Updating Attendee Status...........................21
3.2.3 REPLY .................................................21
3.2.4 ADD ...................................................23
3.2.5 CANCEL ................................................25
3.2.6 REFRESH ...............................................26
3.2.7 COUNTER ...............................................28
3.2.8 DECLINECOUNTER ........................................29
3.3 METHODS FOR VFREEBUSY COMPONENTS ..........................31
3.3.1 PUBLISH ...............................................32
3.3.2 REQUEST ...............................................33
3.3.3 REPLY .................................................34
3.4 METHODS FOR VTODO COMPONENTS ..............................35
1つの序論…5 1.1 形式コンベンション…5 1.2 ドキュメントについて話します…6 1.3 ITIP役割のAND取引…6 2相互運用性はモデル化されます…8 2.1アプリケーション・プロトコル…9 2.1 .1 カレンダーエントリー州…9 2.1 .2代表団…9 2.1 .3 他のCalendar UsersのBehalfに影響します…10 2.1 .4 コンポーネント改正…10 2.1 .5 メッセージ配列…11 3 アプリケーションプロトコル要素…12 3.1 共通成分制限テーブル…13 VEVENTカレンダーの部品のための3.2の方法…14 3.2 .1 発行してください…15 3.2 .2 要求します。17 3.2 .2 .1 出来事の時期変更します…19 3.2 .2 出来事の.2のアップデートか再確認…19 3.2 .2 .3 別のCUへEventを代表として派遣します…19 3.2 .2 .4 オーガナイザーを変えます…20 3.2 .2 .5 オーガナイザーを代表して、発信します…20 3.2 .2 .6 押しかけのCuに送ります。20 3.2 .2 .7 出席者状態をアップデートします…21 3.2 .3 返答してください…21 3.2 .4 加えてください…23 3.2 .5 取り消してください…25 3.2 .6 リフレッシュしてください…26 3.2 .7 反対してください…28 3.2 .8DECLINECOUNTER…29 VFREEBUSYの部品のための3.3の方法…31 3.3 .1 発行してください…32 3.3 .2 要求します。33 3.3 .3 返答してください…34 VTODOの部品のための3.4の方法…35
Silverberg, et. al. Standards Track [Page 2] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[2ページ]。
3.4.1 PUBLISH ...............................................35
3.4.2 REQUEST ...............................................37
3.4.2.1 REQUEST for Rescheduling a VTODO...................39
3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO....39
3.4.2.3 REQUEST for Delegating a VTODO.....................40
3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User....40
3.4.2.5 REQUEST Updated Attendee Status....................41
3.4.3 REPLY .................................................41
3.4.4 ADD ...................................................43
3.4.5 CANCEL ................................................44
3.4.6 REFRESH ...............................................46
3.4.7 COUNTER ...............................................48
3.4.8 DECLINECOUNTER ........................................49
3.5 METHODS FOR VJOURNAL COMPONENTS ...........................50
3.5.1 PUBLISH ...............................................51
3.5.2 ADD ...................................................52
3.5.3 CANCEL ................................................53
3.6 STATUS REPLIES ............................................55
3.7 IMPLEMENTATION CONSIDERATIONS .............................57
3.7.1 Working With Recurrence Instances .....................57
3.7.2 Attendee Property Considerations ......................58
3.7.3 X-Tokens ..............................................59
4 EXAMPLES......................................................59
4.1 PUBLISHED EVENT EXAMPLES ..................................59
4.1.1 A Minimal Published Event .............................60
4.1.2 Changing A Published Event ............................60
4.1.3 Canceling A Published Event ...........................61
4.1.4 A Rich Published Event ................................62
4.1.5 Anniversaries or Events attached to entire days .......63
4.2 GROUP EVENT EXAMPLES ......................................63
4.2.1 A Group Event Request .................................64
4.2.2 Reply To A Group Event Request ........................65
4.2.3 Update An Event .......................................65
4.2.4 Countering an Event Proposal ..........................66
4.2.5 Delegating an Event ...................................68
4.2.6 Delegate Accepts the Meeting ..........................70
4.2.7 Delegate Declines the Meeting .........................71
4.2.8 Forwarding an Event Request ...........................72
4.2.9 Cancel A Group Event ..................................72
4.2.10 Removing Attendees ...................................74
4.2.11 Replacing the Organizer ..............................75
4.3 BUSY TIME EXAMPLES ........................................76
4.3.1 Request Busy Time .....................................77
4.3.2 Reply To A Busy Time Request ..........................77
4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ....................78
4.4.1 A Recurring Event Spanning Time Zones .................78
4.4.2 Modify A Recurring Instance ...........................79
4.4.3 Cancel an Instance ....................................81
3.4.1 発行してください…35 3.4 .2 要求します。37 3.4 .2 .1 VTODOの時期変更するために、要求します。39 3.4 .2 .2 VTODOのアップデートか再確認のために、要求します。39 3.4 .2 .3 VTODOを代表として派遣するために、要求します。40 3.4 .2 押しかけのカレンダーユーザに転送された.4要求…40 3.4 .2 .5 アップデートされた出席者状態を要求してください…41 3.4 .3 返答してください…41 3.4 .4 加えてください…43 3.4 .5 取り消してください…44 3.4 .6 リフレッシュしてください…46 3.4 .7 反対してください…48 3.4 .8DECLINECOUNTER…49 VJOURNALの部品のための3.5の方法…50 3.5 .1 発行してください…51 3.5 .2 加えてください…52 3.5 .3 取り消してください…53 3.6 状態は返答します…55 3.7 実現問題…57 3.7 .1 再発例で、働いています…57 3.7 .2 出席者特性の問題…58 3.7 .3のX-象徴…59 4つの例…59 4.1はイベントの例を発表しました…59 4.1 .1 最小量の発行された出来事…60 4.1 .2 発行された出来事を変えます…60 4.1 .3 発行された出来事を取り消します…61 4.1 .4 リッシュは出来事を発行しました…62 4.1 .5記念日かEventsが全体の日まで付きました…63 4.2 イベントの例を分類してください…63 4.2 .1 グループイベント要求…64 4.2 .2 グループイベント要求に答えてください…65 4.2 .3 出来事をアップデートしてください…65 4.2 .4 イベント提案に対抗します…66 4.2 .5 出来事を代表として派遣します…68 4.2 .6代表はミーティングを受け入れます…70 4.2 .7代表はミーティングを断ります…71 4.2 .8 イベント要求を転送します…72 4.2 .9 グループイベントを取り消してください…72 4.2 .10 出席者を免職します…74 4.2 .11 オーガナイザーを取り替えます…75 4.3 時間の例と忙しくしてください…76 4.3 .1 繁忙期を要求してください…77 4.3 .2 繁忙期要求に答えてください…77 4.4 繰り返し起こる事柄と時間帯の例…78 4.4 .1 時間帯にわたる繰り返し起こる事柄…78 4.4 .2 再発例を変更してください…79 4.4 .3 例を取り消してください…81
Silverberg, et. al. Standards Track [Page 3] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[3ページ]。
4.4.4 Cancel Recurring Event ................................81
4.4.5 Change All Future Instances ...........................82
4.4.6 Add A New Instance To A Recurring Event ...............82
4.4.7 Add A New Series of Instances To A Recurring Event ....83
4.4.8 Counter An Instance Of A Recurring Event ..............87
4.4.9 Error Reply To A Request ..............................88
4.5 GROUP TO-DO EXAMPLES ......................................89
4.5.1 A VTODO Request .......................................90
4.5.2 A VTODO Reply .........................................90
4.5.3 A VTODO Request for Updated Status ....................91
4.5.4 A Reply: Percent-Complete .............................91
4.5.5 A Reply: Completed ....................................92
4.5.6 An Updated VTODO Request ..............................92
4.5.7 Recurring VTODOs ......................................92
4.5.7.1 Request for a Recurring VTODO......................93
4.5.7.2 Calculating due dates in recurring VTODOs..........93
4.5.7.3 Replying to an instance of a recurring VTODO.......93
4.6 JOURNAL EXAMPLES ..........................................94
4.7 OTHER EXAMPLES ............................................94
4.7.1 Event Refresh .........................................94
4.7.2 Bad RECURRENCE-ID .....................................95
5 APPLICATION PROTOCOL FALLBACKS................................97
5.1 PARTIAL IMPLEMENTATION ....................................97
5.1.1 Event-Related Fallbacks ...............................97
5.1.2 Free/Busy-Related Fallbacks ...........................99
5.1.3 To-Do-Related Fallbacks ...............................99
5.1.4 Journal-Related Fallbacks ............................101
5.2 LATENCY ISSUES ...........................................102
5.2.1 Cancellation of an Unknown Calendar Component. .......102
5.2.2 Unexpected Reply from an Unknown Delegate ............103
5.3 SEQUENCE NUMBER ..........................................103
6 SECURITY CONSIDERATIONS......................................103
6.1 SECURITY THREATS .........................................103
6.1.1 Spoofing the "Organizer" .............................103
6.1.2 Spoofing the "Attendee" ..............................103
6.1.3 Unauthorized Replacement of the Organizer ............104
6.1.4 Eavesdropping ........................................104
6.1.5 Flooding a Calendar ..................................104
6.1.6 Procedural Alarms ....................................104
6.1.7 Unauthorized REFRESH Requests ........................104
6.2 RECOMMENDATIONS ..........................................104
6.2.1 Use of [RFC-1847] to secure iTIP transactions ........105
6.2.2 Implementation Controls ..............................105
7 ACKNOWLEDGMENTS..............................................106
8 BIBLIOGRAPHY.................................................106
9 AUTHORS' ADDRESSES...........................................107
10 FULL COPYRIGHT STATEMENT....................................109
4.4.4 繰り返し起こる事柄を取り消してください…81 4.4 .5 すべての将来の例を変えてください…82 4.4 .6 新しい例を繰り返し起こる事柄に加えてください…82 4.4 .7 新物の例を繰り返し起こる事柄に加えてください…83 4.4 .8 繰り返し起こる事柄の例を打ち返してください…87 4.4 要求への.9エラー応答…88 4.5 大騒ぎの例を分類してください…89 4.5 .1 VTODO要求…90 4.5 .2 VTODO回答…90 4.5 .3 アップデートされた状態を求めるVTODO要求…91 4.5 .4 回答: パーセント完全…91 4.5 .5 回答: 完成されます…92 4.5 .6 アップデートされたVTODO要求…92 4.5 .7再発VTODOs…92 4.5 .7 .1 再発には、VTODOを要求してください…93 4.5 .7 再発VTODOsの.2回の計算の期日…93 4.5 .7 .3 再発VTODOの例に答えます…93 4.6 ジャーナルの例…94 他の4.7の例…94 4.7 .1出来事はリフレッシュします…94 4.7 .2 悪い再発ID…95 5 アプリケーション・プロトコル後退…97 5.1の部分的な実現…97 5.1 .1のイベント関連の後退…97 5.1 .2の自由であるか忙しい関連の後退…99 5.1 .3の大騒ぎ関連の後退…99 5.1 .4のジャーナル関連の後退…101 5.2 潜在問題…102 5.2.1 未知のカレンダーコンポーネントのキャンセル。 .......102 5.2.2 未知の代表からの予期しない返答…103 5.3一連番号…103 6 セキュリティ問題…103 6.1 セキュリティの脅威…103 6.1.1 「オーガナイザー」をだまします…103 6.1.2 「出席者」をだまします…103 6.1.3 オーガナイザーの権限のない交換…104 6.1.4 雨垂れ…104 6.1.5 カレンダーをあふれさせます…104 6.1.6 手続き上のアラーム…104 6.1.7 権限のない、要求をリフレッシュしてください…104 6.2の推薦…104 6.2.1 iTIP取引を保証する[RFC-1847]の使用…105 6.2.2 実現は制御されます…105 7つの承認…106 8図書目録…106 9人の作者のアドレス…107 10 完全な著作権宣言文…109
Silverberg, et. al. Standards Track [Page 4] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[4ページ]。
1 Introduction
1つの序論
This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. In particular, it specifies how to schedule events, to-dos, or daily journal entries. It further specifies how to search for available busy time information. It does so in a general way so as to allow multiple methods of communication between systems. Subsequent documents specify transport bindings between systems that use this protocol.
このドキュメントはcalendaringシステムが他のカレンダーシステムで共同利用するのにどうiCalendar物を使用するかを指定します。特に、それは出来事、大騒ぎ、または日計表エントリーの計画をする方法を指定します。 それはさらに利用可能な繁忙期情報を検索する方法を指定します。 それは、システムのコミュニケーションの複数の方法を許容するためにザッとします。その後のドキュメントはこのプロトコルを使用するシステムの間の輸送結合を指定します。
This protocol is based on messages sent from an originator to one or more recipients. For certain types of messages, a recipient may reply, in order to update their status and may also return transaction/request status information. The protocol supports the ability for the message originator to modify or cancel the original message. The protocol also supports the ability for recipients to suggest changes to the originator of a message. The elements of the protocol also define the user roles for its transactions.
このプロトコルは創始者から1人以上の受取人に送られたメッセージに基づいています。 あるタイプのメッセージに関しては、受取人は、それらの状態をアップデートするために返答して、また、取引/要求状態情報を返すかもしれません。 プロトコルはメッセージ創始者がオリジナルのメッセージを変更するか、または取り消す能力を支持します。 また、プロトコルは受取人がメッセージの創始者への変化を勧める能力を支持します。 また、プロトコルの原理は取引のためにユーザの役割を定義します。
1.1 Formatting Conventions
1.1 形式コンベンション
In order to refer to elements of the calendaring and scheduling model, core object or interoperability protocol defined in [iCAL] and [iTIP] several formatting conventions have been utilized.
[iCAL]と[iTIP]で定義されたcalendaringとスケジューリング・モデルか、コア物か相互運用性プロトコルの原理を示すために、数人の形式コンベンションが利用されました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" (CU) within the scheduling protocol defined by [iTIP]. Calendar components defined by [iCAL] are referred to with capitalized, quoted-strings of text. All calendar components start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to the daily journal calendar component. Scheduling methods defined by [iTIP] are referred to with capitalized, quoted-strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified, "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component.
役割のCalendaringして、計画をするのは大文字における、それぞれの単語の最初のキャラクタと共にテキストに関する引用文字列で言及されます。 例えば、「オーガナイザー」は[iTIP]によって定義されたスケジューリングプロトコルの中に「カレンダーユーザ」(CU)の役割を示します。 [iCAL]によって定義されたカレンダーコンポーネントが大文字で書かれることで言及される、テキストに関する引用文字列。 すべてのカレンダーコンポーネントが文字「V」から始まります。 例えば、"VEVENT"はイベントカレンダーコンポーネントを示します、そして、"VTODO"は大騒ぎカレンダーコンポーネントを示します、そして、"VJOURNAL"は日計表カレンダーコンポーネントを示します。 定義された方法の計画をする[iTIP]が大文字で書かれることで参照されるテキストに関する引用文字列。 例えば、「要求」はスケジューリングカレンダーコンポーネントが作成されるか、または変更されて、「回答」がカレンダーコンポーネントの「オーガナイザー」と共にそれらの状態をアップデートするのに要求用途の方法への受取人を参照するよう要求するための方法を示します。
Properties defined by [iCAL] are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters
[iCAL]によって定義された特性が大文字で書かれることで示される、「特性」という言葉があとに続いたテキストに関する引用文字列。 例えば、「出席者」の特性は「カレンダーユーザ」のカレンダーアドレスを伝えるのに使用されるiCalendarの特性を示します。 特性のパラメタ
Silverberg, et. al. Standards Track [Page 5] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[5ページ]。
defined by this memo are referred to with lower case, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Enumerated values defined by this memo are referred to with capitalized text, either alone or followed by the word "value".
このメモで、小文字、テキストに関する引用文字列で言及されて、「パラメタ」という言葉があとに続いていて、定義されます。 例えば、「値」パラメタは資産価値のためのデフォルトデータ型に優越するのに使用されるiCalendar特性のパラメタを示します。 このメモで定義された列挙された値の、大文字で書かれたテキストで単独で言及されるか、または「値」という言葉はあとに続いています。
In tables, the quoted-string text is specified without quotes in order to minimize the table length.
テーブルでは、引用文字列テキストは、テーブルの長さを最小にするために引用文なしで指定されます。
1.2 Related Documents
1.2 関連ドキュメント
Implementers will need to be familiar with several other memos that, along with this one, describe the Internet calendaring and scheduling standards. This document, [iTIP], specifies an interoperability protocol for scheduling between different implementations. The related documents are:
Implementersは、これと共に規格のcalendaringして、計画をするインターネットについて説明する他のいくつかのメモによく知られる必要があるでしょう。 このドキュメント[iTIP]は異なった実現の間のスケジューリングに相互運用性プロトコルを指定します。 関連するドキュメントは以下の通りです。
[iCAL] - specifies the objects, data types, properties and
property parameters used in the protocols, along with the
methods for representing and encoding them;
[iCAL]--パラメタがそれらを表して、コード化するのに方法と共にプロトコルに使用した物、データ型、特性、および特性を指定します。
[iMIP] specifies an Internet email binding for [iTIP].
[iMIP]は[iTIP]で付くインターネットメールを指定します。
This memo does not attempt to repeat the specification of concepts or definitions from these other memos. Where possible, references are made to the memo that provides for the specification of these concepts or definitions.
このメモは、これらの他のメモから概念か定義の仕様を繰り返すのを試みません。 可能であるところでは、これらの概念か定義の仕様に備えるメモを参照します。
1.3 ITIP Roles and Transactions
1.3 ITIPの役割と取引
ITIP defines methods for exchanging [iCAL] objects for the purposes of group calendaring and scheduling between "Calendar Users" (CUs). CUs take on one of two roles in iTIP. The CU who initiates an exchange takes on the role of "Organizer". For example, the CU who proposes a group meeting is the "Organizer". The CUs asked to participate in the group meeting by the "Organizer" take on the role of "Attendee". Note that "role" is also a descriptive parameter to the _ATTENDEE_ property. Its use is to convey descriptive context to an "Attendee" such as "chair", "req-participant" or "non-participant" and has nothing to do with the calendaring workflow.
ITIPはグループcalendaringと「カレンダーユーザ」の間で(CUs)の計画をする目的と[iCAL]物を交換するための方法を定義します。 CUsはiTIPにおける2つの役割の1つを帯びます。 交換を起こすCUは「オーガナイザー」の役割を引き受けます。 例えば、グループ会議を提案するCUは「オーガナイザー」です。 「オーガナイザー」によるグループ会議に参加するように頼まれるCUsは「出席者」の役割を引き受けます。 また、「役割」が_のATTENDEE_特性への描写的であるパラメタであることに注意してください。 使用がある、「いす」、「req関係者」または「非関係者」などの「出席者」に描写的である文脈を伝えて、calendaring作業フローと関係ありません。
Silverberg, et. al. Standards Track [Page 6] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[6ページ]。
The ITIP methods are listed below and their usage and semantics are defined in section 3 of this document.
ITIP方法は以下に記載されています、そして、それらの用法と意味論はこのドキュメントのセクション3で定義されます。
+================+==================================================+ | Method | Description | |================+==================================================| | PUBLISH | Used to publish a calendar entry to one or more | | | Calendar Users. There is no interactivity | | | between the publisher and any other calendar | | | user. An example might include a baseball team | | | publishing its schedule to the public. | | | | | REQUEST | Used to schedule a calendar entry with other | | | Calendar Users. Requests are interactive in that | | | they require the receiver to respond using | | | the Reply methods. Meeting Requests, Busy | | | Time requests and the assignment of VTODOs to | | | other Calendar Users are all examples. | | | Requests are also used by the "Organizer" to | | | update the status of a calendar entry. | | | | | REPLY | A Reply is used in response to a Request to | | | convey "Attendee" status to the "Organizer". | | | Replies are commonly used to respond to meeting | | | and task requests. | | | | | ADD | Add one or more instances to an existing | | | VEVENT, VTODO, or VJOURNAL. | | | | | CANCEL | Cancel one or more instances of an existing | | | VEVENT, VTODO, or VJOURNAL. | | | | | REFRESH | The Refresh method is used by an "Attendee" to | | | request the latest version of a calendar entry. | | | | | COUNTER | The Counter method is used by an "Attendee" to | | | negotiate a change in the calendar entry. | | | Examples include the request to change a | | | proposed Event time or change the due date for a | | | VTODO. | | | | | DECLINE- | Used by the "Organizer" to decline the proposed | | COUNTER | counter-proprosal. | +================+==================================================+
+================+==================================================+ | 方法| 記述| |================+==================================================| | 発行してください。| カレンダーエントリーを1つ以上に発行するために、使用されます。| | | カレンダーユーザ。 対話性が全くありません。| | | 出版社といかなる他のカレンダーの間でも| | | ユーザ。 例は野球チームを含むかもしれません。| | | スケジュールを公衆に発表します。 | | | | | 要求| 他でカレンダーエントリーの計画をするように、使用されます。| | | カレンダーユーザ。 要求はそれで対話的です。| | | 彼らは、受信機が使用を反応させるのを必要とします。| | | Reply方法。 要求で、忙しい状態で会うこと。| | | VTODOsの要求と課題を調節します。| | | 他のCalendar Usersはすべて例です。 | | | また、要求は「オーガナイザー」によって使用されます。| | | カレンダーエントリーの状態をアップデートしてください。 | | | | | 返信| ReplyはRequestに対応して使用されます。| | | 「出席者」状態を「オーガナイザー」に伝えてください。 | | | 回答は、ミーティングに応じるのに一般的に使用されます。| | | そして、要求に仕事を課してください。 | | | | | 加えてください。| 1つ以上の例を存在に加えてください。| | | VEVENT、VTODO、またはVJOURNAL。 | | | | | キャンセル| 存在のより多くのキャンセル1例| | | VEVENT、VTODO、またはVJOURNAL。 | | | | | リフレッシュしてください。| Refresh方法は「出席者」によって使用されます。| | | カレンダーエントリーの最新版を要求してください。 | | | | | カウンタ| Counter方法は「出席者」によって使用されます。| | | カレンダーエントリーにおける変化を交渉してください。 | | | 例はaを変えるという要求を含んでいます。| | | 提案されたEventはaのために期日を調節するか、または変えます。| | | VTODO。 | | | | | 衰退| 提案を傾けるのに「オーガナイザー」によって使用されます。| | カウンタ| カウンタ-proprosal。 | +================+==================================================+
Silverberg, et. al. Standards Track [Page 7] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[7ページ]。
Group scheduling in iTIP is accomplished using the set of "request" and "response" methods described above. The following table shows the methods broken down by who can send them.
iTIPのグループスケジューリングは上で説明された「要求」と「応答」方法のセットを使用するのに優れています。 以下のテーブルはだれがそれらを送ることができるかが砕けている方法を示しています。
+================+==================================================+ | Originator | Methods | |================+==================================================| | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | | | | | Attendee | REPLY, REFRESH, COUNTER | | | REQUEST only when delegating | +================+==================================================+
+================+==================================================+ | 創始者| 方法| |================+==================================================| | オーガナイザー| 発行してください、そして、DECLINECOUNTER、加えて、取り消すよう要求してください。| | | | | 出席者| 返答してください、そして、リフレッシュしてください、そして、反対してください。| | | REQUEST、単に、代表として派遣します。| +================+==================================================+
Note that for some calendar component types, the allowable methods are a subset of the above set.
許容できる方法がいくつかのカレンダーコンポーネント型のための、上のセットの部分集合であることに注意してください。
2 Interoperability Models
2 相互運用性モデル
There are two distinct protocols relevant to interoperability: an "Application Protocol" and a "Transport Protocol". The Application Protocol defines the content of the iCalendar objects sent between sender and receiver to accomplish the scheduling transactions listed above. The Transport Protocol defines how the iCalendar objects are sent between the sender and receiver. This document focuses on the Application Protocol. Binding documents such as [iMIP] focus on the Transport Protocol.
相互運用性に関連している2つの異なったプロトコルがあります: 「アプリケーション・プロトコル」と「トランスポート・プロトコル。」 Applicationプロトコルは上に記載されたスケジューリング取引を実行するために送付者と受信機の間に送られたiCalendar物の内容を定義します。 Transportプロトコルはどう送付者と受信機の間にiCalendar物を送るかを定義します。このドキュメントはApplicationプロトコルに焦点を合わせます。 [iMIP]などの拘束力があるドキュメントはTransportプロトコルに焦点を合わせます。
The connection between Sender and Receiver in the diagram below refers to the Application Protocol. The iCalendar objects passed from the Sender to the Receiver are presented in Section 3, Application Protocol Elements.
以下のダイヤグラムによるSenderとReceiverとの接続はApplicationプロトコルを示します。 Application Protocol Elements、SenderからReceiverまで渡されたiCalendar物はセクション3に提示されます。
+----------+ +----------+ | | iTIP | | | Sender |<-------------------->| Receiver | | | | | +----------+ +----------+
+----------+ +----------+ | | iTIP| | | 送付者| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 受信機| | | | | +----------+ +----------+
There are several variations of this diagram in which the Sender and Receiver take on various roles of a "Calendar User Agent" (CUA) or a "Calendar Service" (CS).
SenderとReceiverが「カレンダーユーザエージェント」(CUA)か「カレンダーサービス」(CS)の様々な役割を引き受けるこのダイヤグラムの数回の変化があります。
The architecture of iTIP is depicted in the diagram below. An application written to this specification may work with bindings for the store-and-forward transport, the real time transport, or both. Also note that iTIP could be bound to other transports.
iTIPの構造は以下のダイヤグラムで表現されます。 この仕様に書かれたアプリケーションは店とフォワード輸送、リアルタイムの輸送、または両方のための結合で動作するかもしれません。 また、他の輸送にiTIPを縛ることができたことに注意してください。
Silverberg, et. al. Standards Track [Page 8] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[8ページ]。
+------------------------------------------+ | iTIP | +------------------------------------------+ |Real-time | Store-and-Fwd | Other | |Transport | Transport | Transports... | +------------------------------------------+
+------------------------------------------+ | iTIP| +------------------------------------------+ |リアルタイムで| ストアとFwd| 他| |輸送| 輸送| 輸送します。 | +------------------------------------------+
2.1 Application Protocol
2.1 アプリケーション・プロトコル
In the iTIP model, a calendar entry is created and managed by an "Organizer". The "Organizer" interacts with other CUs by sending one or more of the iTIP messages listed above. "Attendees" use the "REPLY" method to communicate their status. "Attendees" do not make direct changes to the master calendar entry. They can, however, use the "COUNTER" method to suggest changes to the "Organizer". In any case, the "Organizer" has complete control over the master calendar entry.
iTIPモデルでは、カレンダーエントリーは、「オーガナイザー」によって作成されて、管理されます。 「オーガナイザー」は発信するのによる他の上にリストアップされたiTIPメッセージの1つ以上のCUsと対話します。 「出席者」は彼らの状態を伝える「回答」方法を使用します。 「出席者」はマスターへの変更をカレンダーエントリーにダイレクトにしません。 しかしながら、彼らは「オーガナイザー」への変化を示す「カウンタ」方法を使用できます。 どのような場合でも、「オーガナイザー」には、マスターカレンダーエントリーの完全なコントロールがあります。
2.1.1 Calendar Entry State
2.1.1 カレンダーエントリー州
There are two distinct states relevant to calendar entries: the overall state of the entry and the state associated with an "Attendee" to that entry.
カレンダーエントリーに関連している2つの異なった州があります: エントリーの総合的な州と状態はそのエントリーへの「出席者」と交際しました。
The state of an entry is defined by the "STATUS" property and is controlled by the "Organizer." There is no default value for the "STATUS" property. The "Organizer" sets the "STATUS" property to the appropriate value for each calendar entry.
エントリーの状態は、「状態」の特性によって定義されて、「オーガナイザー」によって制御されます。 「状態」の特性のためのデフォルト値が全くありません。 「オーガナイザー」は適切な値への「状態」の特性をそれぞれのカレンダーエントリーに設定します。
The state of a particular "Attendee" relative to an entry is defined by the "partstat" parameter in the "ATTENDEE" property for each "Attendee". When an "Organizer" issues the initial entry, "Attendee" status is unknown. The "Organizer" specifies this by setting the "partstat" parameter to "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property "partstat" parameter to an appropriate value as part of a "REPLY" message sent back to the "Organizer".
エントリーに比例した特定の「出席者」の状態は各「出席者」のために"partstat"パラメタによって「出席者」の特性で定義されます。 「オーガナイザー」が初期のエントリーを発行するとき、「出席者」状態は未知です。 「オーガナイザー」は、「必要性動作」に"partstat"パラメタを設定することによって、これを指定します。 「回答」メッセージの一部が「オーガナイザー」を送り返したので、各「出席者」はそれらの「出席者」特性の"partstat"パラメタを適切な値に変更します。
2.1.2 Delegation
2.1.2 代表団
Delegation is defined as the process by which an "Attendee" grants another CU (or several CUs) the right to attend on their behalf. The "Organizer" is made aware of this change because the delegating "Attendee" informs the "Organizer". These steps are detailed in the REQUEST method section.
代表団は「出席者」が別のCU(または、数個のCUs)に彼らに代わって出席する権利を与える過程と定義されます。 代表として派遣する「出席者」が「オーガナイザー」を知らせるので、「オーガナイザー」をこの変化を意識するようにします。 これらのステップはREQUEST方法部で詳細です。
Silverberg, et. al. Standards Track [Page 9] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[9ページ]。
2.1.3 Acting on Behalf of other Calendar Users
2.1.3 他のCalendar UsersのBehalfに影響すること。
In many organizations one user will act on behalf of another to organize and/or respond to meeting requests. ITIP provides two mechanisms that support these activities.
多くの組織では、別のものを代表して1人のユーザが、ミーティング要求に結団する、そして/または、応じるために行動するでしょう。 ITIPはこれらの活動を支持する2つのメカニズムを提供します。
First, the "Organizer" is treated as a special entity, separate from "Attendees". All responses from "Attendees" flow to the "Organizer", making it easy to separate a calendar user organizing a meeting from calendar users attending the meeting. Additionally, iCalendar provides descriptive roles for each "Attendee". For instance, a role of "chair" may be ascribed to one or more "Attendees". The "chair" and the "Organizer" may or may not be the same calendar user. This maps well to scenarios where an assistant may manage meeting logistics for another individual who chairs a meeting.
まず最初に、「オーガナイザー」は「出席者」から別々の特別な実体として扱われます。 「出席者」からのすべての応答が「オーガナイザー」に注ぎます、ミーティングに出席するカレンダーユーザから会を組織するカレンダーユーザを切り離すのを簡単にして。 さらに、iCalendarは各「出席者」に記述的役割を提供します。 例えば、「いす」の役割は1「出席者」までせいにされるかもしれません。 「いす」と「オーガナイザー」は同じカレンダーユーザであるかもしれません。 これはアシスタントがミーティングの議長を務める別の個人のためにミーティングロジスティクスを管理するかもしれないシナリオに井戸を写像します。
Second, a "sent-by" parameter may be specified in either the "Organizer" or "Attendee" properties. When specified, the "sent-by" parameter indicates that the responding CU acted on behalf of the specified "Attendee" or "Organizer".
2番目に、aが「発信した」というパラメタは「オーガナイザー」か「出席者」所有地で指定されるかもしれません。 指定されると、「送って」パラメタは、応じているCUが指定された「出席者」か「オーガナイザー」を代表して行動したのを示します。
2.1.4 Component Revisions
2.1.4 コンポーネント改正
The "SEQUENCE" property is used by the "Organizer" to indicate revisions to the calendar component. The rules for incrementing the "SEQUENCE" number are defined in [iCAL]. For clarity, these rules are paraphrased here in terms of how they are applied in [iTIP]. For a given "UID" in a calendar component:
「系列」の特性は、カレンダーコンポーネントに改正を示すのに「オーガナイザー」によって使用されます。 「系列」番号を増加するための規則は[iCAL]で定義されます。 明快において、それらが[iTIP]でどう適用されるかに関してこれらの規則はここで言い換えられます。 カレンダーコンポーネントの与えられた"UID"のために:
. For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
value is incremented according to the rules defined in [iCAL].
. 「発行してください」と「要求」方法において、[iCAL]で定義された規則に従って、「系列」資産価値は増加されます。
. The "SEQUENCE" property value MUST be incremented each time the
"Organizer" uses the "ADD" or "CANCEL" methods.
. 「オーガナイザー」が「加えてください」か「キャンセル」方法を使用するたびに「系列」資産価値を増加しなければなりません。
. The "SEQUENCE" property value MUST NOT be incremented when using
"REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
delegation "REQUEST".
. 代表団「要求」を送りながら「回答」、「リフレッシュしてください」、「カウンタ」、"DECLINECOUNTER"、またはいつを使用するかとき、「系列」資産価値を増加してはいけません。
In some circumstances the "Organizer" may not have received responses to the final revision sent out. In this situation, the "Organizer" may wish to send an update "REQUEST", and set "RSVP=TRUE" for all "Attendees", so that current responses can be collected.
いくつかの事情では、「オーガナイザー」は出された最終的な改正への応答を受けていないかもしれません。 「オーガナイザー」がアップデート「要求」を送って、この状況で、セットしたがっているかもしれない、「RSVPが本当に等しい、」 したがって、すべての「出席者」に関しては、そんなに現在の応答を集めることができます。
Silverberg, et. al. Standards Track [Page 10] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[10ページ]。
The value of the "SEQUENCE" property contained in a response from an "Attendee" may not always match the "Organizer's" revision. Implementations may choose to have the CUA indicate to the CU that the response is to an entry that has been revised and allow the CU to decide whether or not to accept the response.
「」 特性が応答で含んだ系列は「出席者」から「にオーガナイザーいつも合うかもしれないというわけではなく」改正の値。 実現は、CUAが、改訂されたエントリーには応答があるのをCUに示して、CUが、応答を受け入れるかどうか決めるのを許容するのを持っているのを選ぶかもしれません。
2.1.5 Message Sequencing
2.1.5 メッセージ配列
CUAs that handle the [iTIP] application protocol must often correlate a component in a calendar store with a component received in the [iTIP] message. For example, an event may be updated with a later revision of the same event. To accomplish this, a CUA must correlate the version of the event already in its calendar store with the version sent in the [iTIP] message. In addition to this correlation, there are several factors that can cause [iTIP] messages to arrive in an unexpected order. That is, an "Organizer" could receive a reply to an earlier revision of a component AFTER receiving a reply to a later revision.
[iTIP]アプリケーション・プロトコルを扱うCUAsはカレンダー店で[iTIP]メッセージにコンポーネントを受け取っていてコンポーネントをしばしば関連させなければなりません。 例えば、同じ出来事の後の改正で出来事をアップデートするかもしれません。 これを達成するために、CUAは[iTIP]メッセージでバージョンを送って既にカレンダー店の出来事のバージョンを関連させなければなりません。 この相関関係に加えて、予期していなかったオーダーに到達する[iTIP]メッセージを引き起こす場合があるいくつかの要素があります。 すなわち、「オーガナイザー」は、後の改正に回答を受け取りながら、コンポーネントAFTERの以前の改正に回答を受け取るかもしれません。
To maximize interoperability and to handle messages that arrive in an unexpected order, use the following rules:
相互運用性を最大にして、予期していなかったオーダーに到達するメッセージを扱うには、以下の規則を使用してください:
1. The primary key for referencing a particular iCalendar component
is the "UID" property value. To reference an instance of a
recurring component, the primary key is composed of the "UID" and
the "RECURRENCE-ID" properties.
1. 特定のiCalendarの部品に参照をつけるための主キーは"UID"資産価値です。 参照に、再発コンポーネントの例であり、主キーは"UID"と「RECURRENCE ID」の特性で構成されます。
2. The secondary key for referencing a component is the "SEQUENCE"
property value. For components where the "UID" is the same, the
component with the highest numeric value for the "SEQUENCE"
property obsoletes all other revisions of the component with
lower values.
2. コンポーネントに参照をつけるための二次キーは「系列」資産価値です。 "UID"が同じであるコンポーネントのために、「系列」の特性のための最も高い数値があるコンポーネントは下側の値でコンポーネントの他のすべての改正を時代遅れにします。
3. "Attendees" send "REPLY" messages to the "Organizer". For
replies where the "UID" property value is the same, the value of
the "SEQUENCE" property indicates the revision of the component
to which the "Attendee" is replying. The reply with the highest
numeric value for the "SEQUENCE" property obsoletes all other
replies with lower values.
3. 「出席者」は「回答」メッセージを「オーガナイザー」に送ります。 回答のために、"UID"資産価値が同じであるところで「系列」属性の価値は「出席者」が返答しているコンポーネントの改正を示します。 「系列」の特性のための最も高い数値がある回答は下側の値で他のすべての回答を時代遅れにします。
4. In situations where the "UID" and "SEQUENCE" properties match,
the "DTSTAMP" property is used as the tie-breaker. The component
with the latest "DTSTAMP" overrides all others. Similarly, for
"Attendee" responses where the "UID" property values match and
the "SEQUENCE" property values match, the response with the
latest "DTSTAMP" overrides all others.
4. "UID"と「系列」の特性が合っている状況で、"DTSTAMP"の特性はタイブレークとして使用されます。 最新の"DTSTAMP"があるコンポーネントはすべての他のものをくつがえします。 同様に、「出席者」応答のために、"UID"特性の値が合っていて、「系列」特性の値が合っているところで最新の"DTSTAMP"との応答はすべての他のものをくつがえします。
Silverberg, et. al. Standards Track [Page 11] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[11ページ]。
Hence, CUAs must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response.
したがって、CUAsは以下のコンポーネントの特性を固持しなければなりません: "UID"、「RECURRENCE ID」、「系列」、および"DTSTAMP"。 その上、コンポーネントのそれぞれの「出席者」の特性のために、CUAsは「「に出席者関連している系列」 "DTSTAMP"特性の値」応答を固持しなければなりません。
3 Application Protocol Elements
3 アプリケーションプロトコル要素
ITIP messages are "text/calendar" MIME entities that contain calendaring and scheduling information. The particular type of [iCAL] message is referred to as the "method type". Each method type is identified by a "METHOD" property specified as part of the "text/calendar" content type. The table below shows various combinations of calendar components and the method types that this memo supports.
ITIPメッセージは、calendaringを含む「テキスト/カレンダー」MIME存在と情報の計画することです。 特定のタイプに関する[iCAL]メッセージは「方法タイプ」と呼ばれます。 それぞれの方法タイプは「テキスト/カレンダー」満足しているタイプの一部として指定された「方法」の特性によって特定されます。 以下のテーブルはこのメモが支えるカレンダーコンポーネントと方法タイプの様々な組み合わせを示しています。
+=================================================+ | | VEVENT | VTODO | VJOURNAL | VFREEBUSY | |=================================================| |Publish | Yes | Yes | Yes | Yes | |Request | Yes | Yes | No | Yes | |Refresh | Yes | Yes | No | No | |Cancel | Yes | Yes | Yes | No | |Add | Yes | Yes | Yes | No | |Reply | Yes | Yes | No | Yes | |Counter | Yes | Yes | No | No | |Decline- | | | | | |Counter | Yes | Yes | No | No | +=================================================+
+=================================================+ | | VEVENT| VTODO| VJOURNAL| VFREEBUSY| |=================================================| |発行してください。| はい| はい| はい| はい| |要求| はい| はい| いいえ| はい| |リフレッシュしてください。| はい| はい| いいえ| いいえ| |キャンセル| はい| はい| はい| いいえ| |加えてください。| はい| はい| はい| いいえ| |返信| はい| はい| いいえ| はい| |カウンタ| はい| はい| いいえ| いいえ| |衰退| | | | | |カウンタ| はい| はい| いいえ| いいえ| +=================================================+
Each method type is defined in terms of its associated components and properties. Some components and properties are required, some are optional and others are excluded. The restrictions are expressed in this document using a simple "restriction table". The first column indicates the name of a component or property. Properties of the iCalendar object are not indented. Properties of a component are indented. The second column contains "MUST" if the component or property must be present, "MAY" if the component or property is optional, and "NOT" if the component or property must not be present. Entries in the second column sometimes contain comments for further clarification.
それぞれの方法タイプはその関連コンポーネントと特性で定義されます。 いくつかのコンポーネントと特性が必要です、そして、或るものは任意です、そして、他のものは除かれます。 制限は、本書では簡単な「制限テーブル」を使用することで表されます。 最初のコラムはコンポーネントか特性の名前を示します。 iCalendar物の特性はギザギザを付けられません。 コンポーネントの特性はギザギザを付けられます。 コンポーネントか特性が存在していなければならないなら、第2コラムは“MUST"を含んでいます、そして、「5月」はコンポーネントか特性であるなら任意です、そして、「NOT」はコンポーネントか特性であるなら存在しているはずがありません。 第2コラムにおけるエントリーは時々さらなる明確化のためのコメントを含んでいます。
Silverberg, et. al. Standards Track [Page 12] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[12ページ]。
3.1 Common Component Restriction Tables
3.1 共通成分制限テーブル
The restriction table below applies to properties of the iCalendar object. That is, the properties at the outermost scope. The presence column uses the following values to assert whether a property is required, is optional and the number of times it may appear in the iCalendar object.
以下の制限テーブルはiCalendar物の特性に適用されます。 すなわち、一番はずれの範囲の特性。 存在コラムは特性が必要であり、任意であるか否かに関係なく、断言する以下の値とそれがiCalendar物で見えるかもしれない回数を使用します。
Presence Value Description -------------------------------------------------------------- 1 One instance MUST be present 1+ At least one instance MUST be present 0 Instances of this property Must NOT be present 0+ Multiple instances MAY be present 0 or 1 Up to 1 instance of this property MAY be present ---------------------------------------------------------------
存在値の記述-------------------------------------------------------------- 1 + この特性の現在の0InstancesがMustであったに違いなく、プレゼントが0であったかもしれなく、現在の0が複数の例でなかったなら、1つの例が現在の少なくとも1+1つの例であるに違いありませんかこの特性の1つの例への1Upが存在しているかもしれません。---------------------------------------------------------------
The tables also call out "X-PROPERTY" and "X-COMPONENT" to show where vendor-specific properties and components can appear. The tables do not lay out the restrictions of property parameters. Those restrictions are defined in [iCAL].
また、テーブルは、業者特有の性質とコンポーネントがどこに見えることができるかを示すために「X-特性」と「X-コンポーネント」を大声で叫びます。 テーブルは特性のパラメタの制限を広げません。 それらの制限は[iCAL]で定義されます。
Component/Property Presence ------------------- ---------------------------------------------- CALSCALE 0 or 1 PRODID 1 VERSION 1 Value MUST be "2.0" X-PROPERTY 0+
コンポーネント/特性の存在------------------- ---------------------------------------------- CALSCALE0か1PRODID1バージョン1Valueは「2インチXの特性0の+」であるに違いありません。
DateTime values MAY refer to a "VTIMEZONE" component. The property restrictions in the table below apply to any "VTIMEZONE" component in an ITIP message.
DateTime値は"VTIMEZONE"コンポーネントについて言及するかもしれません。 以下のテーブルでの特性の制限はITIPメッセージのどんな"VTIMEZONE"コンポーネントにも適用されます。
Component/Property Presence
------------------- ----------------------------------------------
VTIMEZONE 0+ MUST be present if any date/time refers
to timezone
DAYLIGHT 0+ MUST be one or more of either STANDARD or
DAYLIGHT
COMMENT 0 or 1
DTSTART 1 MUST be local time format
RDATE 0+ if present RRULE MUST NOT be present
RRULE 0+ if present RDATE MUST NOT be present
TZNAME 0 or 1
TZOFFSET 1
TZOFFSETFROM 1
TZOFFSETTO 1
コンポーネント/特性の存在------------------- ---------------------------------------------- 時間がDAYLIGHT0+がどちらかの1つ以上がSTANDARDであったならそうしなければならないタイムゾーンを示すか、またはDAYLIGHT COMMENT0か1DTSTART1が現地時間でなければならない何か日付/が現在のRDATE MUST NOTが現在のTZNAME0か1TZOFFSET1TZOFFSETFROM1TZOFFSETTO1であるなら現在のRRULE MUST NOTが現在のRRULE0+であるならRDATE0+をフォーマットするなら、VTIMEZONE0+は存在していなければなりません。
Silverberg, et. al. Standards Track [Page 13] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[13ページ]。
X-PROPERTY 0+
LAST-MODIFIED 0 or 1
STANDARD 0+ MUST be one or more of either STANDARD or
DAYLIGHT
COMMENT 0 or 1
DTSTART 1 MUST be local time format
RDATE 0+ if present RRULE MUST NOT be present
RRULE 0+ if present RDATE MUST NOT be present
TZNAME 0 or 1
TZOFFSETFROM 1
TZOFFSETTO 1
X-PROPERTY 0+
TZID 1
TZURL 0 or 1
X-PROPERTY 0+
X-PROPERTY0+LAST-MODIFIED0か1STANDARD0+は1であるに違いありませんか現在のRDATE MUST NOTが現在のTZNAME0であるなら現在のRRULE MUST NOTが現在のRRULE0+であるなら、STANDARDかDAYLIGHT COMMENT0か1DTSTART1のどちらかの以上が現地時間の形式RDATE0+であるに違いありませんか1TZOFFSETFROM1のTZOFFSETTO1X-PROPERTY0+TZID1TZURL0か1X-PROPERTY0は+です。
The property restrictions in the table below apply to any "VALARM" component in an ITIP message.
以下のテーブルでの特性の制限はITIPメッセージのどんな"VALARM"コンポーネントにも適用されます。
Component/Property Presence
------------------- ----------------------------------------------
VALARM 0+
ACTION 1
ATTACH 0+
DESCRIPTION 0 or 1
DURATION 0 or 1 if present REPEAT MUST be present
REPEAT 0 or 1 if present DURATION MUST be present
SUMMARY 0 or 1
TRIGGER 1
X-PROPERTY 0+
コンポーネント/特性の存在------------------- ---------------------------------------------- VALARM0+ACTION1ATTACH0+記述0か1DURATION0か1、現在のDURATION MUSTが現在のSUMMARY0か1TRIGGER1X-PROPERTY0+であるなら、現在のREPEAT MUSTは現在のREPEAT0か1です。
3.2 Methods for VEVENT Calendar Components
VEVENTカレンダーの部品のための3.2の方法
This section defines the property set restrictions for the method types that are applicable to the "VEVENT" calendar component. Each method is defined using a table that clarifies the property constraints that define the particular method.
このセクションは"VEVENT"カレンダーコンポーネントに適切な方法タイプのために特性のセット制限を定義します。 各方法は、特定の方法を定義する特性の規制をはっきりさせるテーブルを使用することで定義されます。
Silverberg, et. al. Standards Track [Page 14] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[14ページ]。
The following summarizes the methods that are defined for the "VEVENT" calendar component.
以下は"VEVENT"カレンダーコンポーネントのために定義される方法をまとめます。
+================+==================================================+
| Method | Description |
|================+==================================================|
| PUBLISH | Post notification of an event. Used primarily as |
| | a method of advertising the existence of an |
| | event. |
| | |
| REQUEST | Make a request for an event. This is an explicit |
| | invitation to one or more "Attendees". Event |
| | Requests are also used to update or change an |
| | existing event. Clients that cannot handle |
| | REQUEST may degrade the event to view it as an |
| | PUBLISH. |
| | |
| REPLY | Reply to an event request. Clients may set their |
| | status ("partstat") to ACCEPTED, DECLINED, |
| | TENTATIVE, or DELEGATED. |
| | |
| ADD | Add one or more instances to an existing event. |
| | |
| CANCEL | Cancel one or more instances of an existing |
| | event. |
| | |
| REFRESH | A request is sent to an "Organizer" by an |
| | "Attendee" asking for the latest version of an |
| | event to be resent to the requester. |
| | |
| COUNTER | Counter a REQUEST with an alternative proposal, |
| | Sent by an "Attendee" to the "Organizer". |
| | |
| DECLINECOUNTER | Decline a counter proposal. Sent to an |
| | "Attendee" by the "Organizer". |
+================+==================================================+
+================+==================================================+ | 方法| 記述| |================+==================================================| | 発行してください。| 出来事の通知を掲示してください。 主として使用されます。| | | 存在の広告を出す方法| | | 出来事。 | | | | | 要求| 出来事を求める要求をしてください。 これがそうである、明白| | | 1「出席者」への招待。 出来事| | | また、要求もアップデートするか、または変えるのにおいて使用されています。| | | 既存の出来事。 それが扱うことができないクライアント| | | REQUESTは、それを見るために出来事を下げるかもしれません。| | | 発行してください。 | | | | | 返信| イベント要求に答えてください。 クライアントがセットするかもしれない、彼ら| | | ACCEPTED、DECLINEDへの状態("partstat")| | | 一時的であるか、または代表として派遣します。 | | | | | 加えてください。| 既存の出来事に1つ以上の例を加えてください。 | | | | | キャンセル| 存在のより多くのキャンセル1例| | | 出来事。 | | | | | リフレッシュしてください。| 「オーガナイザー」に要求を送ります。| | | 最新版を求める「出席者」| | | リクエスタに再送される出来事。 | | | | | カウンタ| 代案でREQUESTを打ち返してください。| | | 「出席者」で、「オーガナイザー」に発信しました。 | | | | | DECLINECOUNTER| 対案を傾けてください。 発信します。| | | 「オーガナイザー」による「出席者。」 | +================+==================================================+
3.2.1 PUBLISH
3.2.1 発行してください。
The "PUBLISH" method in a "VEVENT" calendar component is an unsolicited posting of an iCalendar object. Any CU may add published components to their calendar. The "Organizer" MUST be present in a published iCalendar component. "Attendees" MUST NOT be present. Its expected usage is for encapsulating an arbitrary event as an iCalendar object. The "Organizer" may subsequently update (with another "PUBLISH" method), add instances to (with an "ADD" method), or cancel (with a "CANCEL" method) a previously published "VEVENT" calendar component.
"VEVENT"カレンダーコンポーネントの「発行してください」という方法はiCalendar物の求められていない任命です。 どんなCUも発行されたコンポーネントをそれらのカレンダーに追加するかもしれません。 「オーガナイザー」は発行されたiCalendarの部品に存在していなければなりません。 「出席者」は存在しているはずがありません。 予想された用法は、iCalendar物として任意の出来事を要約するものです。 「オーガナイザー」が次にアップデートして(別の「発行してください」方法で)、例を加えるかもしれない、(「加えてください」という方法がある)、または、キャンセル(「キャンセル」方法がある)以前に発行された"VEVENT"カレンダーコンポーネント。
Silverberg, et. al. Standards Track [Page 15] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[15ページ]。
This method type is an iCalendar object that conforms to the following property constraints:
この方法タイプは以下の特性の規制に一致しているiCalendar物です:
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST equal "PUBLISH"
VEVENT 1+
DTSTAMP 1
DTSTART 1
ORGANIZER 1
SUMMARY 1 Can be null.
UID 1
RECURRENCE-ID 0 or 1 only if referring to an instance of a
recurring calendar component. Otherwise
it MUST NOT be present.
SEQUENCE 0 or 1 MUST be present if value is greater than
0, MAY be present if 0
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of
values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RELATED-TO 0+
RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
コンポーネント/特性の存在------------------- ---------------------------------------------- オーガナイザー1つの同輩が「発行しなければならない」というMETHOD1VEVENT1+DTSTAMP1DTSTART1概要1がヌルである場合があります。 または、UID1RECURRENCE-ID0、1 再発カレンダーコンポーネントの例を示す場合にだけ。 さもなければ、それは存在しているはずがありません。 SEQUENCE0か1は値が0以上であるなら存在していなければなりません; プレゼントが0ATTACH0+CATEGORIES0か1つのThisの特性が値CLASS0か1COMMENT0か1CONTACT0+CREATED0のリストを含むかもしれないか、そして、1つの記述0か1のCanであったかもしれないなら、ヌルがDTEND0か1であったなら現在のDTEND MUST NOTであるなら現在のDURATION MUST NOTが現在のDURATION0か1であるならいてください; 0+RESOURCES0か1つの関連現在のEXDATE0+EXRULE0+GEO0か1LAST-MODIFIED0か1のLOCATION0か1PRIORITY0か1RDATE0+TOのThisの特性がTENTATIVE/CONFIRMED/CANCELLED TRANSP0か1URL0か1 X-PROPERTY0の1つが+であったなら5月0日か1日に値のRRULE0+STATUSのリストを含むかもしれません。
ATTENDEE 0
REQUEST-STATUS 0
出席者0要求状態0
VALARM 0+ VFREEBUSY 0 VJOURNAL 0
VALARM0+VFREEBUSY0VJOURNAL0
Silverberg, et. al. Standards Track [Page 16] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[16ページ]。
VTODO 0
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
日付/何時でもタイムゾーンX-COMPONENT0+について言及するなら、VTODO0VTIMEZONE0+は存在していなければなりません。
3.2.2 REQUEST
3.2.2 要求
The "REQUEST" method in a "VEVENT" component provides the following scheduling functions:
"VEVENT"コンポーネントの「要求」方法は以下のスケジューリング機能を提供します:
. Invite "Attendees" to an event;
. Reschedule an existing event;
. Response to a REFRESH request;
. Update the details of an existing event, without rescheduling it;
. Update the status of "Attendees" of an existing event, without
rescheduling it;
. Reconfirm an existing event, without rescheduling it;
. Forward a "VEVENT" to another uninvited CU.
. For an existing "VEVENT" calendar component, delegate the role of
"Attendee" to another CU;
. For an existing "VEVENT" calendar component, changing the role of
"Organizer" to another CU.
. 「出席者」を出来事に招待してください。 . 既存の出来事の時期変更してください。 . REFRESH要求への応答。 . それの時期変更しないで、既存の出来事の詳細をアップデートしてください。 . それの時期変更しないで、既存の出来事の「出席者」の状態をアップデートしてください。 . それの時期変更しないで、既存の出来事を再確認してください。 . "VEVENT"を別の押しかけのCuに送ってください。 . 既存の"VEVENT"カレンダーコンポーネントには、「出席者」の役割を別のCuへ代表として派遣してください。 . 「オーガナイザー」の役割を別のCuに変える既存の"VEVENT"カレンダーコンポーネントのために。
The "Organizer" originates the "REQUEST". The recipients of the "REQUEST" method are the CUs invited to the event, the "Attendees". "Attendees" use the "REPLY" method to convey attendance status to the "Organizer".
「オーガナイザー」は「要求」を溯源します。 「要求」方法の受取人は出来事に招待されたCu、「出席者」です。 「出席者」は「オーガナイザー」に出席状態を伝える「回答」方法を使用します。
The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new "VEVENT" calendar component. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is for a rescheduling, an update, or a reconfirm of the "VEVENT" calendar component.
"UID"と「系列」の特性は、「要求」方法の様々な用途を区別するのに使用されます。 「要求」における"UID"資産価値が受取人のカレンダーで見つけられないなら、「要求」は新しい"VEVENT"カレンダーコンポーネントのためのものです。 "UID"資産価値が受取人のカレンダーで見つけられるなら「要求」はa時期変更、アップデート、またはaが"VEVENT"カレンダーコンポーネントをリコンファームさせるからです。
For the "REQUEST" method, multiple "VEVENT" components in a single iCalendar object are only permitted when for components with the same "UID" property. That is, a series of recurring events may have instance-specific information. In this case, multiple "VEVENT" components are needed to express the entire series.
同じ"UID"の特性があるコンポーネントのために受入れるときだけ、「要求」方法において、単一のiCalendar物の複数の"VEVENT"コンポーネントが受入れられます。 すなわち一連の繰り返し起こる事柄には、例特殊情報があるかもしれません。 この場合、複数の"VEVENT"コンポーネントが、シリーズもの全巻を言い表すのに必要です。
Silverberg, et. al. Standards Track [Page 17] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[17ページ]。
This method type is an iCalendar object that conforms to the following property constraints:
この方法タイプは以下の特性の規制に一致しているiCalendar物です:
Component/Property Presence
-----------------------------------------------------------------
METHOD 1 MUST be "REQUEST"
VEVENT 1+ All components MUST have the same UID
ATTENDEE 1+
DTSTAMP 1
DTSTART 1
ORGANIZER 1
SEQUENCE 0 or 1 MUST be present if value is greater than 0,
MAY be present if 0
SUMMARY 1 Can be null
UID 1
コンポーネント/特性の存在----------------------------------------------------------------- 1は値が0以上であるなら存在していなければなりません、そして、METHOD1がすべてのコンポーネントが持たなければならない「要求」VEVENT1+が同じ1DTSTART1のUID出席者の1+DTSTAMPオーガナイザー1系列0であったなら存在しなければなりませんか、または0概要1がヌルUID1であるかもしれないなら存在しているかもしれません。
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 only if referring to an instance of a
recurring calendar component. Otherwise it
MUST NOT be present.
RELATED-TO 0+
REQUEST-STATUS 0+
RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
現在のDTEND MUST NOTが再発カレンダーコンポーネントの例を示す場合にだけEXDATE0+EXRULE0+GEO0か1LAST-MODIFIED0か1のLOCATION0か1PRIORITY0か1RDATE0に+ 0か1のRECURRENCE-IDを提示することであるなら、ATTACH0+CATEGORIES0か1つのThisの特性がヌルがDTEND0か1であったなら現在のDURATION MUST NOTが現在のDURATION0か1であるなら値CLASS0か1COMMENT0か1CONTACT0+CREATED0か1つの記述0か1のCanのリストを含むかもしれません。 さもなければ、それは存在しているはずがありません。 0+RESOURCES0か1つの関連TO0+REQUEST-STATUS Thisの特性がTENTATIVE/CONFIRMED TRANSP0か1URL0か1 X-PROPERTY0の1つが+であったなら5月0日か1日に値のRRULE0+STATUSのリストを含むかもしれません。
VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
日付/何時でもタイムゾーンX-COMPONENT0+について言及するなら、VALARM0+VTIMEZONE0+は存在していなければなりません。
Silverberg, et. al. Standards Track [Page 18] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[18ページ]。
VFREEBUSY 0 VJOURNAL 0 VTODO 0
VFREEBUSY0VJOURNAL0VTODO0
3.2.2.1 Rescheduling an Event
3.2.2.1 出来事の時期変更すること。
The "REQUEST" method may be used to reschedule an event. A rescheduled event involves a change to the existing event in terms of its time or recurrence intervals and possibly the location or description. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar, but that the "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is greater than the value for the existing event, then the "REQUEST" method describes a rescheduling of the event.
「要求」方法は、出来事の時期変更するのに使用されるかもしれません。 ことによると時間か再発間隔と位置か記述で時期変更している出来事は既存の出来事への変化にかかわります。 「要求」方法の受取人CUAが、"UID"資産価値がカレンダーに既に存在していますが、「要求」方法による「系列」(または、"DTSTAMP")資産価値が値より既存の出来事にすばらしいのがわかるなら、「要求」方法は出来事の時期変更について説明します。
3.2.2.2 Updating or Reconfirmation of an Event
3.2.2.2 出来事のアップデートか再確認
The "REQUEST" method may be used to update or reconfirm an event. An update to an existing event does not involve changes to the time or recurrence intervals, and might not involve a change to the location or description for the event. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar and that the "SEQUENCE" property value in the "REQUEST" is the same as the value for the existing event, then the "REQUEST" method describes an update of the event details, but no rescheduling of the event.
「要求」方法は、出来事をアップデートするか、または再確認するのに使用されるかもしれません。 既存の出来事へのアップデートは、時間か再発間隔への変化にかかわらないで、また位置への変化か出来事のための記述にかかわらないかもしれません。 「要求」方法の受取人CUAが"UID"資産価値がカレンダーに既に存在していて、「要求」における「系列」資産価値が既存の出来事のための値と同じであることがわかるなら、「要求」方法はイベントの詳細のアップデートにもかかわらず、出来事の時期変更について説明しません。
The update "REQUEST" method is the appropriate response to a "REFRESH" method sent from an "Attendee" to the "Organizer" of an event.
アップデート「要求」方法は方法が「出席者」から出来事の「オーガナイザー」に送った「リフレッシュしてください」への適切な応答です。
The "Organizer" of an event may also send unsolicited "REQUEST" methods. The unsolicited "REQUEST" methods may be used to update the details of the event without rescheduling it, to update the "partstat" parameter of "Attendees", or to reconfirm the event.
また、出来事の「オーガナイザー」は求められていない「要求」方法を送るかもしれません。 求められていない「要求」方法は、それの時期変更しないで出来事の詳細をアップデートするか、「出席者」の"partstat"パラメタをアップデートするか、または出来事を再確認するのに使用されるかもしれません。
3.2.2.3 Delegating an Event to another CU
3.2.2.3 Delegating an Event to another CU
Some calendar and scheduling systems allow "Attendees" to delegate their presence at an event to another calendar user. ITIP supports this concept using the following workflow. Any "Attendee" may delegate their right to participate in a calendar VEVENT to another CU. The implication is that the delegate participates in lieu of the original "Attendee"; NOT in addition to the "Attendee". The delegator MUST notify the "Organizer" of this action using the steps outlined below. Implementations may support or restrict delegation as they see fit. For instance, some implementations may restrict a delegate from delegating a "REQUEST" to another CU.
Some calendar and scheduling systems allow "Attendees" to delegate their presence at an event to another calendar user. ITIP supports this concept using the following workflow. Any "Attendee" may delegate their right to participate in a calendar VEVENT to another CU. The implication is that the delegate participates in lieu of the original "Attendee"; NOT in addition to the "Attendee". The delegator MUST notify the "Organizer" of this action using the steps outlined below. Implementations may support or restrict delegation as they see fit. For instance, some implementations may restrict a delegate from delegating a "REQUEST" to another CU.
Silverberg, et. al. Standards Track [Page 19] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 19] RFC 2446 iTIP November 1998
The "Delegator" of an event forwards the existing "REQUEST" to the "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property with the calendar address of the "Delegate". The "Delegator" MUST also send a "REPLY" method to the "Organizer" with the "Delegator's" "ATTENDEE" property "partstat" parameter value set to "delegated". In addition, the "delegated-to" parameter MUST be included with the calendar address of the "Delegate".
The "Delegator" of an event forwards the existing "REQUEST" to the "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property with the calendar address of the "Delegate". The "Delegator" MUST also send a "REPLY" method to the "Organizer" with the "Delegator's" "ATTENDEE" property "partstat" parameter value set to "delegated". In addition, the "delegated-to" parameter MUST be included with the calendar address of the "Delegate".
In response to the request, the "Delegate" MUST send a "REPLY" method to the "Organizer" and optionally, to the "Delegator". The "REPLY" method " SHOULD include the "ATTENDEE" property with the "delegated- from" parameter value of the "Delegator's" calendar address.
In response to the request, the "Delegate" MUST send a "REPLY" method to the "Organizer" and optionally, to the "Delegator". The "REPLY" method " SHOULD include the "ATTENDEE" property with the "delegated- from" parameter value of the "Delegator's" calendar address.
The "Delegator" may continue to receive updates to the event even though they will not be attending. This is accomplished by the "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in the "REPLY" to the "Organizer"
The "Delegator" may continue to receive updates to the event even though they will not be attending. This is accomplished by the "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in the "REPLY" to the "Organizer"
3.2.2.4 Changing the Organizer
3.2.2.4 Changing the Organizer
The situation may arise where the "Organizer" of a VEVENT is no longer able to perform the "Organizer" role and abdicates without passing on the "Organizer" role to someone else. When this occurs the "Attendees" of the VEVENT may use out-of-band mechanisms to communicate the situation and agree upon a new "Organizer". The new "Organizer" should then send out a new "REQUEST" with a modified version of the VEVENT in which the "SEQUENCE" number has been incremented and value of the "ORGANIZER" property has been changed to the calendar address of the new "Organizer".
The situation may arise where the "Organizer" of a VEVENT is no longer able to perform the "Organizer" role and abdicates without passing on the "Organizer" role to someone else. When this occurs the "Attendees" of the VEVENT may use out-of-band mechanisms to communicate the situation and agree upon a new "Organizer". The new "Organizer" should then send out a new "REQUEST" with a modified version of the VEVENT in which the "SEQUENCE" number has been incremented and value of the "ORGANIZER" property has been changed to the calendar address of the new "Organizer".
3.2.2.5 Sending on Behalf of the Organizer
3.2.2.5 Sending on Behalf of the Organizer
There are a number of scenarios that support the need for a calendar user to act on behalf of the "Organizer" without explicit role changing. This might be the case if the CU designated as "Organizer" was sick or unable to perform duties associated with that function. In these cases iTIP supports the notion of one CU acting on behalf of another. Using the "sent-by" parameter, a calendar user could send an updated "VEVENT" REQUEST. In the case where one CU sends on behalf of another CU, the "Attendee" responses are still directed back towards the CU designated as "Organizer".
There are a number of scenarios that support the need for a calendar user to act on behalf of the "Organizer" without explicit role changing. This might be the case if the CU designated as "Organizer" was sick or unable to perform duties associated with that function. In these cases iTIP supports the notion of one CU acting on behalf of another. Using the "sent-by" parameter, a calendar user could send an updated "VEVENT" REQUEST. In the case where one CU sends on behalf of another CU, the "Attendee" responses are still directed back towards the CU designated as "Organizer".
3.2.2.6 Forwarding to An Uninvited CU
3.2.2.6 Forwarding to An Uninvited CU
An "Attendee" invited to an event may invite another uninvited CU to the event. The invited "Attendee" accomplishes this by forwarding the original "REQUEST" method to the uninvited CU. The "Organizer" decides whether or not the uninvited CU is added to the attendee
An "Attendee" invited to an event may invite another uninvited CU to the event. The invited "Attendee" accomplishes this by forwarding the original "REQUEST" method to the uninvited CU. The "Organizer" decides whether or not the uninvited CU is added to the attendee
Silverberg, et. al. Standards Track [Page 20] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 20] RFC 2446 iTIP November 1998
list. If the "Organizer" decides not to add the uninvited CU no further action is required, however the "Organizer" MAY send the uninvited CU a "CANCEL" message. If the "Organizer" decides to add an uninvited CU, a new "ATTENDEE" property is added for the uninvited CU with its property parameters set as the "Organizer" deems appropriate. When forwarding a "REQUEST" to another CU, the forwarding "Attendee" MUST NOT make changes to the VEVENT property set.
list. If the "Organizer" decides not to add the uninvited CU no further action is required, however the "Organizer" MAY send the uninvited CU a "CANCEL" message. If the "Organizer" decides to add an uninvited CU, a new "ATTENDEE" property is added for the uninvited CU with its property parameters set as the "Organizer" deems appropriate. When forwarding a "REQUEST" to another CU, the forwarding "Attendee" MUST NOT make changes to the VEVENT property set.
3.2.2.7 Updating Attendee Status
3.2.2.7 Updating Attendee Status
The "Organizer" of an event may also request updated status from one or more "Attendees. The "Organizer" sends a "REQUEST" method to the "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The "SEQUENCE" property for the event is not changed from its previous value. A recipient will determine that the only change in the "REQUEST" is that their "RSVP" property parameter indicates a request for updated status. The recipient SHOULD respond with a "REPLY" method indicating their current status with respect to the "REQUEST".
The "Organizer" of an event may also request updated status from one or more "Attendees. The "Organizer" sends a "REQUEST" method to the "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The "SEQUENCE" property for the event is not changed from its previous value. A recipient will determine that the only change in the "REQUEST" is that their "RSVP" property parameter indicates a request for updated status. The recipient SHOULD respond with a "REPLY" method indicating their current status with respect to the "REQUEST".
3.2.3 REPLY
3.2.3 REPLY
The "REPLY" method in a "VEVENT" calendar component is used to respond (e.g., accept or decline) to a "REQUEST" or to reply to a delegation "REQUEST". When used to provide a delegation response, the "Delegator" SHOULD include the calendar address of the "Delegate" on the "delegated-to" property parameter of the "Delegator's" "ATTENDEE" property. The "Delegate" SHOULD include the calendar address of the "Delegator" on the "delegated-from" property parameter of the "Delegate's" "ATTENDEE" property.
The "REPLY" method in a "VEVENT" calendar component is used to respond (e.g., accept or decline) to a "REQUEST" or to reply to a delegation "REQUEST". When used to provide a delegation response, the "Delegator" SHOULD include the calendar address of the "Delegate" on the "delegated-to" property parameter of the "Delegator's" "ATTENDEE" property. The "Delegate" SHOULD include the calendar address of the "Delegator" on the "delegated-from" property parameter of the "Delegate's" "ATTENDEE" property.
The "REPLY" method may also be used to respond to an unsuccessful "REQUEST" method. Depending on the value of the "REQUEST-STATUS" property no scheduling action may have been performed.
The "REPLY" method may also be used to respond to an unsuccessful "REQUEST" method. Depending on the value of the "REQUEST-STATUS" property no scheduling action may have been performed.
The "Organizer" of an event may receive the "REPLY" method from a CU not in the original "REQUEST". For example, a "REPLY" may be received from a "Delegate" to an event. In addition, the "REPLY" method may be received from an unknown CU (a "Party Crasher"). This uninvited "Attendee" may be accepted, or the "Organizer" may cancel the event for the uninvited "Attendee" by sending a "CANCEL" method to the uninvited "Attendee".
The "Organizer" of an event may receive the "REPLY" method from a CU not in the original "REQUEST". For example, a "REPLY" may be received from a "Delegate" to an event. In addition, the "REPLY" method may be received from an unknown CU (a "Party Crasher"). This uninvited "Attendee" may be accepted, or the "Organizer" may cancel the event for the uninvited "Attendee" by sending a "CANCEL" method to the uninvited "Attendee".
An "Attendee" can include a message to the "Organizer" using the "COMMENT" property. For example, if the user indicates tentative acceptance and wants to let the "Organizer" know why, the reason can be expressed in the "COMMENT" property value.
An "Attendee" can include a message to the "Organizer" using the "COMMENT" property. For example, if the user indicates tentative acceptance and wants to let the "Organizer" know why, the reason can be expressed in the "COMMENT" property value.
Silverberg, et. al. Standards Track [Page 21] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 21] RFC 2446 iTIP November 1998
The "Organizer" may also receive a "REPLY" from one CU on behalf of another. Like the scenario enumerated above for the "Organizer", "Attendees" may have another CU respond on their behalf. This is done using the "sent-by" parameter.
The "Organizer" may also receive a "REPLY" from one CU on behalf of another. Like the scenario enumerated above for the "Organizer", "Attendees" may have another CU respond on their behalf. This is done using the "sent-by" parameter.
The optional properties listed in the table below (those listed as "0+" or "0 or 1") MUST NOT be changed from those of the original request. If property changes are desired the COUNTER message must be used.
The optional properties listed in the table below (those listed as "0+" or "0 or 1") MUST NOT be changed from those of the original request. If property changes are desired the COUNTER message must be used.
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST be "REPLY"
VEVENT 1+ All components MUST have the same UID
ATTENDEE 1 MUST be the address of the Attendee
replying.
DTSTAMP 1
ORGANIZER 1
RECURRENCE-ID 0 or 1 only if referring to an instance of a
recurring calendar component. Otherwise
it must NOT be present.
UID 1 MUST be the UID of the original REQUEST
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "REPLY" VEVENT 1+ All components MUST have the same UID ATTENDEE 1 MUST be the address of the Attendee replying. DTSTAMP 1 ORGANIZER 1 RECURRENCE-ID 0 or 1 only if referring to an instance of a recurring calendar component. Otherwise it must NOT be present. UID 1 MUST be the UID of the original REQUEST
SEQUENCE 0 or 1 MUST if non-zero, MUST be the sequence
number of the original REQUEST. MAY be
present if 0.
SEQUENCE 0 or 1 MUST if non-zero, MUST be the sequence number of the original REQUEST. MAY be present if 0.
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1
DTEND 0 or 1 if present DURATION MUST NOT be present
DTSTART 0 or 1
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RELATED-TO 0+
ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 DTEND 0 or 1 if present DURATION MUST NOT be present DTSTART 0 or 1 DURATION 0 or 1 if present DTEND MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PRIORITY 0 or 1 RDATE 0+ RELATED-TO 0+
Silverberg, et. al. Standards Track [Page 22] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 22] RFC 2446 iTIP November 1998
RESOURCES 0 or 1 This property MAY contain a list of values
REQUEST-STATUS 0+
RRULE 0+
STATUS 0 or 1
SUMMARY 0 or 1
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
RESOURCES 0 or 1 This property MAY contain a list of values REQUEST-STATUS 0+ RRULE 0+ STATUS 0 or 1 SUMMARY 0 or 1 TRANSP 0 or 1 URL 0 or 1 X-PROPERTY 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers
to a timezone
X-COMPONENT 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VALARM 0 VFREEBUSY 0 VJOURNAL 0 VTODO 0
VALARM 0 VFREEBUSY 0 VJOURNAL 0 VTODO 0
3.2.4 ADD
3.2.4 ADD
The "ADD" method in a "VEVENT" calendar component is used to add one or more instances to an existing "VEVENT". Unlike the "REQUEST" method, when using issuing an "ADD" method, the "Organizer" does not send the full "VEVENT" description; only the new instance(s). The "ADD" method is especially useful if there are instance-specific properties to be preserved in a recurring "VEVENT". For instance, an "Organizer" may have originally scheduled a weekly Thursday meeting. At some point, several instances changed. Location or start time may have changed, or some instances may have unique "DESCRIPTION" properties. The "ADD" method allows the "Organizer" to add new instances to an existing event using a single ITIP message without redefining the entire recurring pattern.
The "ADD" method in a "VEVENT" calendar component is used to add one or more instances to an existing "VEVENT". Unlike the "REQUEST" method, when using issuing an "ADD" method, the "Organizer" does not send the full "VEVENT" description; only the new instance(s). The "ADD" method is especially useful if there are instance-specific properties to be preserved in a recurring "VEVENT". For instance, an "Organizer" may have originally scheduled a weekly Thursday meeting. At some point, several instances changed. Location or start time may have changed, or some instances may have unique "DESCRIPTION" properties. The "ADD" method allows the "Organizer" to add new instances to an existing event using a single ITIP message without redefining the entire recurring pattern.
The "UID" must be that of the existing event. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VEVENT". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
The "UID" must be that of the existing event. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VEVENT". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Silverberg, et. al. Standards Track [Page 23] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 23] RFC 2446 iTIP November 1998
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST be "ADD"
VEVENT 1
DTSTAMP 1
DTSTART 1
ORGANIZER 1
SEQUENCE 1 MUST be greater than 0
SUMMARY 1 Can be null
UID 1 MUST match that of the original event
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "ADD" VEVENT 1 DTSTAMP 1 DTSTART 1 ORGANIZER 1 SEQUENCE 1 MUST be greater than 0 SUMMARY 1 Can be null UID 1 MUST match that of the original event
ATTACH 0+
ATTENDEE 0+
CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RELATED-TO 0+
RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
ATTACH 0+ ATTENDEE 0+ CATEGORIES 0 or 1 This property MAY contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTEND 0 or 1 if present DURATION MUST NOT be present DURATION 0 or 1 if present DTEND MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PRIORITY 0 or 1 RDATE 0+ RELATED-TO 0+ RESOURCES 0 or 1 This property MAY contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of TENTATIVE/CONFIRMED TRANSP 0 or 1 URL 0 or 1 X-PROPERTY 0+
RECURRENCE-ID 0
REQUEST-STATUS 0
RECURRENCE-ID 0 REQUEST-STATUS 0
VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VALARM 0+ VTIMEZONE 0+ MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VFREEBUSY 0 VTODO 0 VJOURNAL 0
VFREEBUSY 0 VTODO 0 VJOURNAL 0
Silverberg, et. al. Standards Track [Page 24] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 24] RFC 2446 iTIP November 1998
3.2.5 CANCEL
3.2.5 CANCEL
The "CANCEL" method in a "VEVENT" calendar component is used to send a cancellation notice of an existing event request to the "Attendees". The message is sent by the "Organizer" of the event. For a recurring event, either the whole event or instances of an event may be cancelled. To cancel the complete range of recurring event, the "UID" property value for the event MUST be specified and a "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In order to cancel an individual instance of the event, the "RECURRENCE-ID" property value for the event MUST be specified in the "CANCEL" method.
The "CANCEL" method in a "VEVENT" calendar component is used to send a cancellation notice of an existing event request to the "Attendees". The message is sent by the "Organizer" of the event. For a recurring event, either the whole event or instances of an event may be cancelled. To cancel the complete range of recurring event, the "UID" property value for the event MUST be specified and a "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In order to cancel an individual instance of the event, the "RECURRENCE-ID" property value for the event MUST be specified in the "CANCEL" method.
There are two options for canceling a sequence of instances of a recurring "VEVENT" calendar component:
There are two options for canceling a sequence of instances of a recurring "VEVENT" calendar component:
(a) the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
specified "VEVENT" calendar component and all instances before
(or after); or
(a) the "RECURRENCE-ID" property for an instance in the sequence MUST be specified with the "RANGE" property parameter value of THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the specified "VEVENT" calendar component and all instances before (or after); or
(b) individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the
instances to be cancelled.
(b) individual recurrence instances may be cancelled by specifying multiple "RECURRENCE-ID" properties corresponding to the instances to be cancelled.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be incremented.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be incremented.
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "CANCEL"
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "CANCEL"
VEVENT 1+ All must have the same UID
ATTENDEE 0+ MUST include all "Attendees" being removed
the event. MUST include all "Attendees" if
the entire event is cancelled.
DTSTAMP 1
ORGANIZER 1
SEQUENCE 1
UID 1 MUST be the UID of the original REQUEST
VEVENT 1+ All must have the same UID ATTENDEE 0+ MUST include all "Attendees" being removed the event. MUST include all "Attendees" if the entire event is cancelled. DTSTAMP 1 ORGANIZER 1 SEQUENCE 1 UID 1 MUST be the UID of the original REQUEST
COMMENT 0 or 1
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values
COMMENT 0 or 1 ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values
Silverberg, et. al. Standards Track [Page 25] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 25] RFC 2446 iTIP November 1998
CLASS 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1
DTEND 0 or 1 if present DURATION MUST NOT be present
DTSTART 0 or 1
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST be present if referring to one or
more or more recurring instances.
Otherwise it MUST NOT be present
RELATED-TO 0+
RESOURCES 0 or 1
RRULE 0+
STATUS 0 or 1 MUST be set to CANCELLED. If uninviting
specific "Attendees" then MUST NOT be
included.
SUMMARY 0 or 1
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
REQUEST-STATUS 0
CLASS 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 DTEND 0 or 1 if present DURATION MUST NOT be present DTSTART 0 or 1 DURATION 0 or 1 if present DTEND MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PRIORITY 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST be present if referring to one or more or more recurring instances. Otherwise it MUST NOT be present RELATED-TO 0+ RESOURCES 0 or 1 RRULE 0+ STATUS 0 or 1 MUST be set to CANCELLED. If uninviting specific "Attendees" then MUST NOT be included. SUMMARY 0 or 1 TRANSP 0 or 1 URL 0 or 1 X-PROPERTY 0+ REQUEST-STATUS 0
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VTIMEZONE 0+ MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VTODO 0 VJOURNAL 0 VFREEBUSY 0 VALARM 0
VTODO 0 VJOURNAL 0 VFREEBUSY 0 VALARM 0
3.2.6 REFRESH
3.2.6 REFRESH
The "REFRESH" method in a "VEVENT" calendar component is used by "Attendees" of an existing event to request an updated description from the event "Organizer". The "REFRESH" method must specify the "UID" property of the event to update. A recurrence instance of an event may be requested by specifying the "RECURRENCE-ID" property corresponding to the associated event. The "Organizer" responds with the latest description and version of the event.
The "REFRESH" method in a "VEVENT" calendar component is used by "Attendees" of an existing event to request an updated description from the event "Organizer". The "REFRESH" method must specify the "UID" property of the event to update. A recurrence instance of an event may be requested by specifying the "RECURRENCE-ID" property corresponding to the associated event. The "Organizer" responds with the latest description and version of the event.
Silverberg, et. al. Standards Track [Page 26] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 26] RFC 2446 iTIP November 1998
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "REFRESH"
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "REFRESH"
VEVENT 1
ATTENDEE 1 MUST be the address of requestor
DTSTAMP 1
ORGANIZER 1
UID 1 MUST be the UID associated with original
REQUEST
COMMENT 0 or 1
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise
it must NOT be present.
X-PROPERTY 0+
VEVENT 1 ATTENDEE 1 MUST be the address of requestor DTSTAMP 1 ORGANIZER 1 UID 1 MUST be the UID associated with original REQUEST COMMENT 0 or 1 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it must NOT be present. X-PROPERTY 0+
ATTACH 0
CATEGORIES 0
CLASS 0
CONTACT 0
CREATED 0
DESCRIPTION 0
DTEND 0
DTSTART 0
DURATION 0
EXDATE 0
EXRULE 0
GEO 0
LAST-MODIFIED 0
LOCATION 0
PRIORITY 0
RDATE 0
RELATED-TO 0
REQUEST-STATUS 0
RESOURCES 0
RRULE 0
SEQUENCE 0
STATUS 0
SUMMARY 0
TRANSP 0
URL 0
ATTACH 0 CATEGORIES 0 CLASS 0 CONTACT 0 CREATED 0 DESCRIPTION 0 DTEND 0 DTSTART 0 DURATION 0 EXDATE 0 EXRULE 0 GEO 0 LAST-MODIFIED 0 LOCATION 0 PRIORITY 0 RDATE 0 RELATED-TO 0 REQUEST-STATUS 0 RESOURCES 0 RRULE 0 SEQUENCE 0 STATUS 0 SUMMARY 0 TRANSP 0 URL 0
X-COMPONENT 0+
X-COMPONENT 0+
VTODO 0
VTODO 0
Silverberg, et. al. Standards Track [Page 27] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 27] RFC 2446 iTIP November 1998
VJOURNAL 0 VFREEBUSY 0 VTIMEZONE 0 VALARM 0
VJOURNAL 0 VFREEBUSY 0 VTIMEZONE 0 VALARM 0
3.2.7 COUNTER
3.2.7 COUNTER
The "COUNTER" method for a "VEVENT" calendar component is used by an "Attendee" of an existing event to submit to the "Organizer" a counter proposal to the event description. The "Attendee" sends this message to the "Organizer" of the event.
The "COUNTER" method for a "VEVENT" calendar component is used by an "Attendee" of an existing event to submit to the "Organizer" a counter proposal to the event description. The "Attendee" sends this message to the "Organizer" of the event.
The counter proposal is an iCalendar object consisting of a VEVENT calendar component describing the complete description of the alternate event.
The counter proposal is an iCalendar object consisting of a VEVENT calendar component describing the complete description of the alternate event.
The "Organizer" rejects the counter proposal by sending the "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts the counter proposal by rescheduling the event as described in section 3.2.2.1 Rescheduling an Event.
The "Organizer" rejects the counter proposal by sending the "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts the counter proposal by rescheduling the event as described in section 3.2.2.1 Rescheduling an Event.
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "COUNTER"
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "COUNTER"
VEVENT 1
DTSTAMP 1
DTSTART 1
ORGANIZER 1 MUST be the "Organizer" of the original
event
SEQUENCE 1 MUST be present if value is greater than 0,
MAY be present if 0
SUMMARY 1 Can be null
UID 1 MUST be the UID associated with the REQUEST
being countered
VEVENT 1 DTSTAMP 1 DTSTART 1 ORGANIZER 1 MUST be the "Organizer" of the original event SEQUENCE 1 MUST be present if value is greater than 0, MAY be present if 0 SUMMARY 1 Can be null UID 1 MUST be the UID associated with the REQUEST being countered
ATTACH 0+
ATTENDEE 0+ Can also be used to propose other
"Attendees"
CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1
ATTACH 0+ ATTENDEE 0+ Can also be used to propose other "Attendees" CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1
Silverberg, et. al. Standards Track [Page 28] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 28] RFC 2446 iTIP November 1998
DTEND 0 or 1 if present DURATION MUST NOT be present
DURATION 0 or 1 if present DTEND MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PRIORITY 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise it
MUST NOT be present.
RELATED-TO 0+
REQUEST-STATUS 0+
RESOURCES 0 or 1 This property may contain a list of values
RRULE 0+
STATUS 0 or 1 Value must be one of CONFIRMED/TENATIVE/
CANCELLED
TRANSP 0 or 1
URL 0 or 1
X-PROPERTY 0+
DTEND 0 or 1 if present DURATION MUST NOT be present DURATION 0 or 1 if present DTEND MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PRIORITY 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUS 0+ RESOURCES 0 or 1 This property may contain a list of values RRULE 0+ STATUS 0 or 1 Value must be one of CONFIRMED/TENATIVE/ CANCELLED TRANSP 0 or 1 URL 0 or 1 X-PROPERTY 0+
VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VALARM 0+ VTIMEZONE 0+ MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VTODO 0 VJOURNAL 0 VFREEBUSY 0
VTODO 0 VJOURNAL 0 VFREEBUSY 0
3.2.8 DECLINECOUNTER
3.2.8 DECLINECOUNTER
The "DECLINECOUNTER" method in a "VEVENT" calendar component is used by the "Organizer" of an event to reject a counter proposal submitted by an "Attendee". The "Organizer" must send the "DECLINECOUNTER" message to the "Attendee" that sent the "COUNTER" method to the "Organizer".
The "DECLINECOUNTER" method in a "VEVENT" calendar component is used by the "Organizer" of an event to reject a counter proposal submitted by an "Attendee". The "Organizer" must send the "DECLINECOUNTER" message to the "Attendee" that sent the "COUNTER" method to the "Organizer".
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Silverberg, et. al. Standards Track [Page 29] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 29] RFC 2446 iTIP November 1998
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "DECLINECOUNTER"
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "DECLINECOUNTER"
VEVENT 1
DTSTAMP 1
ORGANIZER 1
UID 1 MUST, same UID specified in original
REQUEST and subsequent COUNTER
COMMENT 0 or 1
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise it
MUST NOT be present.
REQUEST-STATUS 0+
SEQUENCE 0 OR 1 MUST be present if value is greater than 0,
MAY be present if 0
X-PROPERTY 0+
ATTACH 0
ATTENDEE 0
CATEGORIES 0
CLASS 0
CONTACT 0
CREATED 0
DESCRIPTION 0
DTEND 0
DTSTART 0
DURATION 0
EXDATE 0
EXRULE 0
GEO 0
LAST-MODIFIED 0
LOCATION 0
PRIORITY 0
RDATE 0
RELATED-TO 0
RESOURCES 0
RRULE 0
STATUS 0
SUMMARY 0
TRANSP 0
URL 0
VEVENT 1 DTSTAMP 1 ORGANIZER 1 UID 1 MUST, same UID specified in original REQUEST and subsequent COUNTER COMMENT 0 or 1 RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. REQUEST-STATUS 0+ SEQUENCE 0 OR 1 MUST be present if value is greater than 0, MAY be present if 0 X-PROPERTY 0+ ATTACH 0 ATTENDEE 0 CATEGORIES 0 CLASS 0 CONTACT 0 CREATED 0 DESCRIPTION 0 DTEND 0 DTSTART 0 DURATION 0 EXDATE 0 EXRULE 0 GEO 0 LAST-MODIFIED 0 LOCATION 0 PRIORITY 0 RDATE 0 RELATED-TO 0 RESOURCES 0 RRULE 0 STATUS 0 SUMMARY 0 TRANSP 0 URL 0
X-COMPONENT 0+ VTODO 0 VJOURNAL 0 VFREEBUSY 0 VTIMEZONE 0 VALARM 0
X-COMPONENT 0+ VTODO 0 VJOURNAL 0 VFREEBUSY 0 VTIMEZONE 0 VALARM 0
Silverberg, et. al. Standards Track [Page 30] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 30] RFC 2446 iTIP November 1998
3.3 Methods For VFREEBUSY Components
3.3 Methods For VFREEBUSY Components
This section defines the property set for the methods that are applicable to the "VFREEBUSY" calendar component. Each of the methods is defined using a restriction table.
This section defines the property set for the methods that are applicable to the "VFREEBUSY" calendar component. Each of the methods is defined using a restriction table.
This document only addresses the transfer of busy time information. Applications desiring free time information MUST infer this from available busy time information.
This document only addresses the transfer of busy time information. Applications desiring free time information MUST infer this from available busy time information.
The busy time information within the iCalendar object MAY be grouped into more than one "VFREEBUSY" calendar component. This capability allows busy time periods to be grouped according to some common periodicity, such as a calendar week, month, or year. In this case, each "VFREEBUSY" calendar component MUST include the "ATTENDEE", "DTSTART" and "DTEND" properties in order to specify the source of the busy time information and the date and time interval over which the busy time information covers.
iCalendar物の中の繁忙期情報は1つ以上の"VFREEBUSY"カレンダーコンポーネントに分類されるかもしれません。 この能力は、何らかの一般的な周期性に従って繁忙期の期間が分類されるのを許容します、1暦週、月、または年などのように。 この場合、それぞれの"VFREEBUSY"カレンダーコンポーネントは、繁忙期情報が関するものの上で繁忙期情報の源と日時の間隔を指定するために「出席者」、"DTSTART"、および"DTEND"の特性を含まなければなりません。
The "FREEBUSY" property value MAY include a list of values, separated by the COMMA character ([US-ASCII] decimal 44). Alternately, multiple busy time periods MAY be specified with multiple instances of the "FREEBUSY" property. Both forms MUST be supported by implementations conforming to this document. Duplicate busy time periods SHOULD NOT be specified in an iCalendar object. However, two different busy time periods MAY overlap.
"FREEBUSY"資産価値はコンマキャラクタ([米国のASCII]の10進44)によって切り離された値のリストを含むかもしれません。 交互に、複数の繁忙期の期間が"FREEBUSY"の特性の複数の例で指定されるかもしれません。 このドキュメントに従う実現で両方のフォームを支持しなければなりません。 指定されていて、iCalendar物に繁忙期期間のSHOULD NOTをコピーしてください。 しかしながら、2回の異なった繁忙期の期間が重なるかもしれません。
"FREEBUSY" properties should be sorted such that their values are in ascending order, based on the start time, and then the end time, with the earliest periods first. For example, today's busy time information should appear after yesterday's busy time information. And the busy time for this half-hour should appear after the busy time for earlier today.
"FREEBUSY"の特性が分類されるべきであるので、最初に、それらの値が最も早い期間と共に開始時刻、および次に、終わりの時間に基づいた昇順であります。 例えば、昨日のものが時間情報と忙しくした後に今日の繁忙期情報は現れるべきです。 そして、この30分間の繁忙期は前の今日の繁忙期の後に現れるべきです。
Since events may span a day boundary, free busy time period may also span a day boundary. Individual "A" requests busy time from individuals "B", "C" and "D". Individual "B" and "C" replies with busy time data to individual "A". Individual "D" does not support busy time requests and does not reply with any data. If the transport binding supports exception messages, then individual "D" returns an "unsupported capability" message to individual "A4.34.3".
出来事が日の境界にかかるかもしれないので、自由な繁忙期の期間は長さ1日境界にもかかっています。 個人からの要求繁忙期個々の「B」、「C」、および「D。」 個人「B」と「C」は繁忙期データで個人「A」に返答します。 個人「D」は、繁忙期要求を支持しないで、またどんなデータでも返答しません。 輸送結合が例外メッセージを支持するなら個人「D」が「サポートされない能力」メッセージを個人に返す、「A4.34、0.3インチ」
The following summarizes the methods that are defined for the "VFREEBUSY" calendar component.
以下は"VFREEBUSY"カレンダーコンポーネントのために定義される方法をまとめます。
Silverberg, et. al. Standards Track [Page 31] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[31ページ]。
|================|==================================================| | Method | Description | |================|==================================================| | PUBLISH | Publish unsolicited busy time data. | | REQUEST | Request busy time data. | | REPLY | Reply to a busy time request. | |================|==================================================|
|================|==================================================| | 方法| 記述| |================|==================================================| | 発行してください。| 求められていない繁忙期データを発表してください。 | | 要求| 繁忙期データを要求してください。 | | 返信| 繁忙期要求に答えてください。 | |================|==================================================|
3.3.1 PUBLISH
3.3.1 発行してください。
The "PUBLISH" method in a "VFREEBUSY" calendar component is used to publish busy time data. The method may be sent from one CU to any other. The purpose of the method is to provide a message for sending unsolicited busy time data. That is, the busy time data is not being sent as a "REPLY" to the receipt of a "REQUEST" method.
"VFREEBUSY"カレンダーコンポーネントの「発行してください」という方法は、繁忙期データを発表するのに使用されます。 1CUからいかなる他のも方法を送るかもしれません。 方法の目的は送付の求められていない繁忙期データへのメッセージを提供することです。 すなわち、繁忙期データは「回答」として「要求」方法の領収書に送られません。
The "ATTENDEE" property must be specified in the busy time information. The value is the CU address of the originator of the busy time information.
繁忙期情報で「出席者」の特性を指定しなければなりません。 値は繁忙期情報の創始者のCUアドレスです。
This method type is an iCalendar object that conforms to the following property constraints:
この方法タイプは以下の特性の規制に一致しているiCalendar物です:
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "PUBLISH"
コンポーネント/特性の存在------------------- ---------------------------------------------- METHOD1は「発行してください」であるに違いありません。
VFREEBUSY 1+
DTSTAMP 1
DTSTART 1 DateTime values must be in UTC
DTEND 1 DateTime values must be in UTC
FREEBUSY 1+ MUST be BUSYTIME. Multiple instances are
allowed. Multiple instances must be sorted
in ascending order
ORGANIZER 1 MUST contain the address of originator of
busy time data.
VFREEBUSY1+DTSTAMP1DTSTARTの1DateTime値はDateTimeが評価する1が+がUTC FREEBUSY1では、BUSYTIMEであるに違いないというUTC DTENDでは、ことであるに違いないということでなければなりません。 複数の例が許容されています。 複数の例は昇順に分類されて、ORGANIZER1が繁忙期データの創始者のアドレスを含まなければならないということであるに違いありません。
COMMENT 0 or 1
CONTACT 0+
X-PROPERTY 0+
URL 0 or 1 Specifies busy time URL
COMMENT0か1CONTACT0+X-PROPERTY0+URL0か1つのSpecifies繁忙期URL
ATTENDEE 0
DURATION 0
REQUEST-STATUS 0
UID 0
出席者0持続時間0要求状態0UID0
X-COMPONENT 0+
X-コンポーネント0+
Silverberg, et. al. Standards Track [Page 32] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[32ページ]。
VEVENT 0 VTODO 0 VJOURNAL 0 VTIMEZONE 0 VALARM 0
VEVENT0VTODO0VJOURNAL0VTIMEZONE0VALARM0
3.3.2 REQUEST
3.3.2 要求
The "REQUEST" method in a "VFREEBUSY" calendar component is used to ask a "Calendar User" for their busy time information. The request may be for a busy time information bounded by a specific date and time interval.
"VFREEBUSY"カレンダーコンポーネントの「要求」方法は、「カレンダーユーザ」にそれらの繁忙期情報を求めるのに使用されます。 要求は特定の日時の間隔のそばで境界がある繁忙期情報のためのものであるかもしれません。
This message only permits requests for busy time information. The message is sent from a "Calendar User" requesting the busy time information to one or more intended recipients.
このメッセージは繁忙期情報に関する要求を可能にするだけです。 繁忙期情報を要求する「カレンダーユーザ」から意図している1人以上の受取人にメッセージを送ります。
If the originator of the "REQUEST" method is not authorized to make a busy time request on the recipient's calendar system, then an exception message SHOULD be returned in a "REPLY" method, but no busy time data need be returned.
受取人のカレンダーシステムの上で繁忙期要求をするのに「要求」方法の創始者に権限を与えないなら、「回答」方法で例外メッセージを返すべきですが、繁忙期データは全く返す必要はありません。
This method type is an iCalendar object that conforms to the following property constraints:
この方法タイプは以下の特性の規制に一致しているiCalendar物です:
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "REQUEST"
コンポーネント/特性の存在------------------- ---------------------------------------------- METHOD1は「要求」であるに違いありません。
VFREEBUSY 1
ATTENDEE 1+ contain the address of the calendar store
DTEND 1 DateTime values must be in UTC
DTSTAMP 1
DTSTART 1 DateTime values must be in UTC
ORGANIZER 1 MUST be the request originator's address
UID 1
COMMENT 0 or 1
CONTACT 0+
X-PROPERTY 0+
VFREEBUSY1ATTENDEE1+は要求創始者のアドレスUID1COMMENT0か1CONTACT0+X-PROPERTY0が+であったならDateTimeがDateTimeが評価する1がUTC ORGANIZER1にUTC DTSTAMP1DTSTARTに、あるに違いないということであるに違いないことを評価する1がそうしなければならないカレンダー店DTENDのアドレスを含んでいます。
FREEBUSY 0
DURATION 0
REQUEST-STATUS 0
URL 0
FREEBUSY0持続時間0要求状態0URL0
X-COMPONENT 0+ VALARM 0 VEVENT 0
X-コンポーネント0+VALARM0VEVENT0
Silverberg, et. al. Standards Track [Page 33] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[33ページ]。
VTODO 0 VJOURNAL 0 VTIMEZONE 0
VTODO0VJOURNAL0VTIMEZONE0
3.3.3 REPLY
3.3.3 回答
The "REPLY" method in a "VFREEBUSY" calendar component is used to respond to a busy time request. The method is sent by the recipient of a busy time request to the originator of the request.
"VFREEBUSY"カレンダーコンポーネントの「回答」方法は、繁忙期要求に応じるのに使用されます。 方法は繁忙期要求の受取人によって要求の創始者に送られます。
The "REPLY" method may also be used to respond to an unsuccessful "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy time information may be returned.
また、「回答」方法は、失敗の「要求」方法に応じるのに使用されるかもしれません。 「要求状態」値によって、繁忙期情報を全く返さないかもしれません。
This method type is an iCalendar object that conforms to the following property constraints:
この方法タイプは以下の特性の規制に一致しているiCalendar物です:
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "REPLY"
コンポーネント/特性の存在------------------- ---------------------------------------------- METHOD1は「回答」であるに違いありません。
VFREEBUSY 1
ATTENDEE 1 (address of recipient replying)
DTSTAMP 1
DTEND 1 DateTime values must be in UTC
DTSTART 1 DateTime values must be in UTC
FREEBUSY 1+ (values MUST all be of the same data
type. Multiple instances are allowed.
Multiple instances MUST be sorted in
ascending order. Values MAY NOT overlap)
ORGANIZER 1 MUST be the request originator's address
UID 1
VFREEBUSY1ATTENDEE1(受取人返答のアドレス)DTSTAMP1DTEND1DateTime値はUTC DTSTART1DateTime値には、+がUTC FREEBUSY1にあるに違いないということでなければなりません。(値はすべて、同じデータ型のものであるに違いありません。 複数の例が許容されています。 昇順に複数の例を分類しなければなりません。 値は重ならないかもしれません。) ORGANIZER1は要求創始者のアドレスUID1であるに違いない。
COMMENT 0 or 1
CONTACT 0+
REQUEST-STATUS 0+
URL 0 or 1 (specifies busy time URL)
X-PROPERTY 0+
DURATION 0
SEQUENCE 0
COMMENT0か1CONTACT0+REQUEST-STATUS0+URL0か1(繁忙期URLを指定します) X-PROPERTY0+DURATION0SEQUENCE0
X-COMPONENT 0+ VALARM 0 VEVENT 0 VTODO 0 VJOURNAL 0 VTIMEZONE 0
X-コンポーネント0+VALARM0VEVENT0VTODO0VJOURNAL0VTIMEZONE0
Silverberg, et. al. Standards Track [Page 34] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[34ページ]。
3.4 Methods For VTODO Components
VTODOの部品のための3.4の方法
This section defines the property set for the methods that are applicable to the "VTODO" calendar component. Each of the methods is defined using a restriction table that specifies the property constraints that define the particular method.
このセクションは"VTODO"カレンダーコンポーネントに適切な方法のために特性のセットを定義します。 それぞれの方法は、特定の方法を定義する特性の規制を指定する制限テーブルを使用することで定義されます。
The following summarizes the methods that are defined for the "VTODO" calendar component.
以下は"VTODO"カレンダーコンポーネントのために定義される方法をまとめます。
+================+==================================================+ | Method | Description | |================+==================================================| | PUBLISH | Post notification of a VTODO. Used primarily as | | | a method of advertising the existence of a VTODO.| | | | | REQUEST | Assign a VTODO. This is an explicit assignment to| | | one or more Calendar Users. The REQUEST method | | | is also used to update or change an existing | | | VTODO. Clients that cannot handle REQUEST MAY | | | degrade the method to treat it as a PUBLISH. | | | | | REPLY | Reply to a VTODO request. Attendees MAY set | | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | | | DELEGATED, PARTIAL, and COMPLETED. | | | | | ADD | Add one or more instances to an existing to-do. | | | | | CANCEL | Cancel one or more instances of an existing | | | to-do. | | | | | REFRESH | A request sent to a VTODO Organizer asking for | | | the latest version of a VTODO. | | | | | COUNTER | Counter a REQUEST with an alternative proposal. | | | | | DECLINECOUNTER | Decline a counter proposal by an Attendee. | +================+==================================================+
+================+==================================================+ | 方法| 記述| |================+==================================================| | 発行してください。| VTODOの通知を掲示してください。 主として使用されます。| | | VTODOの存在の広告を出す方法、|| | | | 要求| VTODOを割り当ててください。 これは明白な課題です。| | | 1Calendar Users。 REQUEST方法| | | また、存在をアップデートするか、または変えるために、使用されます。| | | VTODO。 REQUEST MAYを扱うことができないクライアント| | | PUBLISHとしてそれを扱う方法を下がらせてください。 | | | | | 返信| VTODO要求に答えてください。 出席者はセットするかもしれません。| | | 受け入れられることへの傾けられて、一時的なPARTSTAT| | | 代表として派遣されて、部分的であって、完成しています。 | | | | | 加えてください。| 既存の大騒ぎに1つ以上の例を加えてください。 | | | | | キャンセル| 存在のより多くのキャンセル1例| | | 大騒ぎ。 | | | | | リフレッシュしてください。| 要求はVTODO Organizerの尋ねるのに発信しました。| | | VTODOの最新版。 | | | | | カウンタ| 代案でREQUESTを打ち返してください。 | | | | | DECLINECOUNTER| Attendeeで対案を傾けてください。 | +================+==================================================+
3.4.1 PUBLISH
3.4.1 発行してください。
The "PUBLISH" method in a "VTODO" calendar component has no associated response. It is simply a posting of an iCalendar object that maybe added to a calendar. It MUST have an "Organizer". It MUST NOT have "Attendees". Its expected usage is for encapsulating an arbitrary "VTODO" calendar component as an iCalendar object. The "Organizer" MAY subsequently update (with another "PUBLISH" method), add instances to (with an "ADD" method), or cancel (with a "CANCEL"
"VTODO"カレンダーコンポーネントの方法が持っている「発行してください」ノー、は応答を関連づけました。 それは単に多分カレンダーに加えたiCalendar物の任命です。 それには、「オーガナイザー」がなければなりません。 それには、「出席者」があってはいけません。 予想された用法は、iCalendar物として任意の"VTODO"カレンダーコンポーネントを要約するものです。 5月が次にアップデートして(別の「発行してください」方法で)、例を加える「オーガナイザー」(「加えてください」という方法がある)、またはキャンセル、(「キャンセル」
Silverberg, et. al. Standards Track [Page 35] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[35ページ]。
method) a previously published "VTODO" calendar component.
方法) 以前に発行された"VTODO"カレンダーコンポーネント。
This method type is an iCalendar object that conforms to the following property constraints:
この方法タイプは以下の特性の規制に一致しているiCalendar物です:
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST be "PUBLISH"
VTODO 1+
DTSTAMP 1
DTSTART 1
ORGANIZER 1
PRIORITY 1
SEQUENCE 0 or 1 MUST be present if value is greater than
0, MAY be present if 0
SUMMARY 1 Can be null.
UID 1
コンポーネント/特性の存在------------------- ---------------------------------------------- 1は値が0以上であるなら存在していなければなりません、そして、METHOD1は「発行してください」VTODO1+DTSTAMPオーガナイザー1DTSTART1の1つの優先権1系列0であるに違いないか0概要1がヌルである場合があるなら、存在しているかもしれません。 UID1
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise
it MUST NOT be present.
ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PERCENT-COMPLETE 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. さもなければ、それは存在しているはずがありません。
RELATED-TO 0+
RESOURCES 0 or 1 This property may contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS/CANCELLED
URL 0 or 1
X-PROPERTY 0+
0+RESOURCES0か1つの関連TO Thisの特性がCOMPLETED/NEEDS ACTION/IN PROCESS/CANCELLED URL0か1X-PROPERTY0の1つが+であったなら5月0日か1日に値のRRULE0+STATUSのリストを含むかもしれません。
ATTENDEE 0
REQUEST-STATUS 0
出席者0要求状態0
Silverberg, et. al. Standards Track [Page 36] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[36ページ]。
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
VALARM 0+
X-COMPONENT 0+
日付/何時でもタイムゾーンVALARM0+X-COMPONENT0+について言及するなら、VTIMEZONE0+は存在していなければなりません。
VFREEBUSY 0 VEVENT 0 VJOURNAL 0
VFREEBUSY0VEVENT0VJOURNAL0
3.4.2 REQUEST
3.4.2 要求
The "REQUEST" method in a "VTODO" calendar component provides the following scheduling functions:
"VTODO"カレンダーコンポーネントの「要求」方法は以下のスケジューリング機能を提供します:
. Assign a to-do to one or more "Calendar Users";
. Reschedule an existing to-do;
. Update the details of an existing to-do, without rescheduling
it;
. Update the completion status of "Attendees" of an existing
to-do, without rescheduling it;
. Reconfirm an existing to-do, without rescheduling it;
. Delegate/reassign an existing to-do to another "Calendar User".
. 1「カレンダーユーザ」に大騒ぎを割り当ててください。 . 既存の大騒ぎの時期変更してください。 . それの時期変更しないで、既存の大騒ぎの詳細をアップデートしてください。 . それの時期変更しないで、既存の大騒ぎの「出席者」の完成状態をアップデートしてください。 . それの時期変更しないで、既存の大騒ぎを再確認してください。 . 別の「カレンダーユーザ」に既存の大騒ぎを代表として派遣するか、または再選任してください。
The assigned "Calendar Users" are identified in the "VTODO" calendar component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property value sequences.
割り当てられた「カレンダーユーザ」は"VTODO"カレンダーコンポーネントで「出席者; 役割はREQ-関係者と等しい」という個々の資産価値系列によって特定されます。
The originator of a "REQUEST" is the "Organizer" of the to-do. The recipient of a "REQUEST" is the "Calendar User" assigned the to-do. The "Attendee" uses the "REPLY" method to convey their acceptance and completion status to the "Organizer" of the "REQUEST".
「要求」の創始者は大騒ぎの「オーガナイザー」です。 「要求」の受取人は大騒ぎが割り当てられた「カレンダーユーザ」です。 「出席者」は「要求」の「オーガナイザー」にそれらの承認と完成状態を伝える「回答」方法を使用します。
The "UID", "SEQUENCE", and "DTSTAMP" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in the "REQUEST" is not found on the recipient's calendar, then the "REQUEST" is for a new to-do. If the "UID" property value is found on the recipient's calendar, then the "REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO" calendar object.
"UID"、「系列」、および"DTSTAMP"の特性は、「要求」方法の様々な用途を区別するのに使用されます。 「要求」における"UID"資産価値が受取人のカレンダーで見つけられないなら、「要求」は新しい大騒ぎのためのものです。 "UID"資産価値が受取人のカレンダーで見つけられるなら、「要求」はa時期変更、アップデート、またはaが"VTODO"カレンダー物をリコンファームさせるということです。
If the "Organizer" of the "REQUEST" method is not authorized to make a to-do request on the "Attendee's" calendar system, then an exception is returned in the "REQUEST-STATUS" property of a subsequent "REPLY" method, but no scheduling action is performed.
「要求」方法の「オーガナイザー」が「に関する出席者大騒ぎ要求を」 カレンダーシステムにするのが認可されないなら、例外はその後の「回答」方法の「要求状態」所有地で返されますが、スケジューリング動作は全く実行されません。
For the "REQUEST" method, multiple "VTODO" components in a single iCalendar object are only permitted when for components with the same "UID" property. That is, a series of recurring events may have
同じ"UID"の特性があるコンポーネントのために受入れるときだけ、「要求」方法において、単一のiCalendar物の複数の"VTODO"コンポーネントが受入れられます。 すなわち、出来事にはあるかもしれない再発するシリーズ
Silverberg, et. al. Standards Track [Page 37] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[37ページ]。
instance-specific information. In this case, multiple "VTODO" components are needed to express the entire series.
例特殊情報。 この場合、複数の"VTODO"コンポーネントが、シリーズもの全巻を言い表すのに必要です。
This method type is an iCalendar object that conforms to the following property constraints:
この方法タイプは以下の特性の規制に一致しているiCalendar物です:
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST be "REQUEST"
VTODO 1+ All components must have the same UID
ATTENDEE 1+
DTSTAMP 1
DTSTART 1
ORGANIZER 1
PRIORITY 1
SEQUENCE 0 or 1 MUST be present if value is greater than
0, MAY be present if 0
SUMMARY 1 Can be null.
UID 1
コンポーネント/特性の存在------------------- ---------------------------------------------- 1は値が0以上であるなら存在していなければなりません、そして、METHOD1がすべてのコンポーネントが持たなければならない「要求」VTODO1+が同じUID出席者1+DTSTAMPオーガナイザー1DTSTART1の1つの優先権1系列0であったなら存在しなければなりませんか、または0概要1がヌルである場合があるなら、存在しているかもしれません。 UID1
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of
values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 present if referring to an instance of a
recurring calendar component. Otherwise
it MUST NOT be present.
RELATED-TO 0+
RESOURCES 0 or 1 This property may contain a list of
values
RRULE 0+
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS
URL 0 or 1
X-PROPERTY 0+
DUE0か1Ifが+ Ifが+ 現在のEXDATE0+EXRULE0がGEO0か1LAST-MODIFIED0か1LOCATION0か1PERCENT-COMPLETE0か1RDATE0であったならDUE MUST NOTを寄贈する現在のDURATION0か1が0か1のRECURRENCE-IDであったならDURATION MUST NOTを寄贈するヌルが存在していたなら、再発カレンダーコンポーネントの例を示すなら、ATTACH0+CATEGORIES0か1つのThisの特性が値CLASS0か1COMMENT0か1CONTACT0+CREATED0か1つの記述0か1のCanのリストを含むかもしれません。 さもなければ、それは存在しているはずがありません。 0+RESOURCES0か1つの関連TO Thisの特性がCOMPLETED/NEEDS ACTION/IN PROCESS URL0か1X-PROPERTY0の1つが+であったなら5月0日か1日に値のRRULE0+STATUSのリストを含むかもしれません。
Silverberg, et. al. Standards Track [Page 38] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[38ページ]。
REQUEST-STATUS 0
要求状態0
VALARM 0+
VALARM0+
VTIMEZONE 0+ MUST be present if any date/time refers
to a timezone
X-COMPONENT 0+
日付/何時でもタイムゾーンX-COMPONENT0+について言及するなら、VTIMEZONE0+は存在していなければなりません。
VEVENT 0 VFREEBUSY 0 VJOURNAL 0
VEVENT0VFREEBUSY0VJOURNAL0
3.4.2.1 REQUEST for Rescheduling a VTODO
3.4.2.1 VTODOの時期変更するのを求める要求
The "REQUEST" method may be used to reschedule a "VTODO" calendar component.
「要求」方法は、"VTODO"カレンダーコンポーネントの時期変更するのに使用されるかもしれません。
Rescheduling a "VTODO" calendar component involves a change to the existing "VTODO" calendar component in terms of its start or due time or recurrence intervals and possibly the description. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar, but that the "SEQUENCE" property value in the "REQUEST" is greater than the value for the existing VTODO, then the "REQUEST" method describes a rescheduling of the "VTODO" calendar component.
"VTODO"カレンダーコンポーネントの時期変更すると、始めか締切りの時間か再発間隔とことによると記述で既存の"VTODO"カレンダーコンポーネントへの変化はかかわります。 「要求」方法の受取人CUAが、"UID"資産価値がカレンダーに既に存在していますが、「要求」における「系列」資産価値が値より既存のVTODOにすばらしいのがわかるなら、「要求」方法は"VTODO"カレンダーコンポーネントの時期変更について説明します。
3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO
3.4.2.2 VTODOのアップデートか再確認を求める要求
The "REQUEST" method may be used to update or reconfirm a "VTODO" calendar component. Reconfirmation is merely an update of "Attendee" completion status or overall "VTODO" calendar component status.
「要求」方法は、"VTODO"カレンダーコンポーネントをアップデートするか、または再確認するのに使用されるかもしれません。 再確認は単に「出席者」完成状態か総合的な"VTODO"カレンダーコンポーネント状態のアップデートです。
An update to an existing "VTODO" calendar component does not involve changes to the start or due time or recurrence intervals, nor generally to the description for the "VTODO" calendar component. If the recipient CUA of a "REQUEST" method finds that the "UID" property value already exists on the calendar and that the "SEQUENCE" property value in the "REQUEST" is the same as the value for the existing event, then the "REQUEST" method describes an update of the "VTODO" calendar component details, but not a rescheduling of the "VTODO" calendar component.
既存の"VTODO"カレンダーコンポーネントへのアップデートは始め、締切りの時間または再発間隔と、そして、"VTODO"カレンダーコンポーネントのための一般に、記述への変化にかかわりません。 「要求」方法の受取人CUAが"UID"資産価値がカレンダーに既に存在していて、「要求」における「系列」資産価値が既存の出来事のための値と同じであることがわかるなら、「要求」方法は"VTODO"カレンダーコンポーネントの時期変更ではなく、"VTODO"カレンダーコンポーネントの詳細のアップデートについて説明します。
The update "REQUEST" is the appropriate response to a "REFRESH" method sent from an "Attendee" to the "Organizer" of a "VTODO" calendar component.
アップデート「要求」は方法が「出席者」から"VTODO"カレンダーコンポーネントの「オーガナイザー」に送った「リフレッシュしてください」への適切な応答です。
Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a "VTODO" calendar component. The unsolicited "REQUEST" methods are
求められていない「要求」方法は"VTODO"カレンダーコンポーネントの「オーガナイザー」によって送られるかもしれません。 求められていない「要求」方法はそうです。
Silverberg, et. al. Standards Track [Page 39] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[39ページ]。
used to update the details of the "VTODO" (without rescheduling it or updating the completion status of "Attendees") or the "VTODO" calendar component itself (i.e., reconfirm the "VTODO").
"VTODO"(それの時期変更するか、または「出席者」の完成状態をアップデートすることのない)か"VTODO"カレンダーコンポーネント(すなわち、"VTODO"を再確認する)自体の細部をアップデートするのにおいて、使用されています。
3.4.2.3 REQUEST for Delegating a VTODO
3.4.2.3 VTODOを代表として派遣するのを求める要求
The "REQUEST" method is also used to delegate or reassign ownership of a "VTODO" calendar component to another "Calendar User". For example, it may be used to delegate an "Attendee's" role (i.e. "chair", or "participant") for a "VTODO" calendar component. The "REQUEST" method is sent by one of the "Attendees" of an existing
また、「要求」方法も"VTODO"カレンダーコンポーネントの所有権を別の「カレンダーユーザ」に代表として派遣するか、または再選任するのにおいて使用されています。 例えば、それは「を出席者代表として派遣するのが使用されるかもしれません。」 "VTODO"カレンダーコンポーネントのための役割(すなわち、「いす」、または「関係者」)。 「要求」方法は存在の「出席者」の1つによって送られます。
"VTODO" calendar component to some other individual. An "Attendee" of a "VTODO" calendar component MUST NOT delegate to the "Organizer" of the event.
ある他の個人への"VTODO"カレンダーコンポーネント。 "VTODO"カレンダーコンポーネントの「出席者」は出来事の「オーガナイザー」に委任してはいけません。
For the purposes of this description, the "Attendee" delegating the "VTODO" calendar component is referred to as the "Delegator". The "Attendee" receiving the delegation request is referred to as the "Delegate".
この記述の目的のために、"VTODO"カレンダーコンポーネントを代表として派遣する「出席者」は"Delegator"と呼ばれます。 代表団要求を受け取る「出席者」は「代表」と呼ばれます。
The "Delegator" of a "VTODO" calendar component MUST forward the existing "REQUEST" method for a "VTODO" calendar component to the "Delegate". The "VTODO" calendar component description MUST include the "Delegator's" up-to-date "VTODO" calendar component definition. The "REQUEST" method MUST also include an "ATTENDEE" property with the calendar address of the "Delegate". The "Delegator" MUST also send a "REPLY" method back to the "Organizer" with the "Delegator's" "Attendee" property "partstat" parameter value set to "DELEGATED". In addition, the "delegated-to" parameter MUST be included with the calendar address of the "Delegate". A response to the delegation "REQUEST" is sent from the "Delegate" to the "Organizer" and optionally, to the "Delegator". The "REPLY" method from the "Delegate" SHOULD include the "ATTENDEE" property with their calendar address and the "delegated-from" parameter with the value of the "Delegator's" calendar address.
"VTODO"カレンダーコンポーネントの"Delegator"は"VTODO"カレンダーコンポーネントのために既存の「要求」方法を「代表」に送らなければなりません。 "VTODO"カレンダーコンポーネント記述は"Delegator"の最新の"VTODO"カレンダーコンポーネント定義を含まなければなりません。 また、「要求」方法は「代表」のカレンダーアドレスがある「出席者」の特性を含まなければなりません。 また、"Delegator"は「代表として派遣されること」への"Delegator"の「出席者」特性の"partstat"パラメタ選択値群と共に「回答」方法を「オーガナイザー」に送り返さなければなりません。 さらに、「代表」のカレンダーアドレスで「委任されて」パラメタを含まなければなりません。 代表団「要求」への応答を「オーガナイザー」への「代表」から"Delegator"に任意に送ります。 そして、「代表」からの「回答」方法がそれらのカレンダーアドレスがある「出席者」の特性を含むべきである、「代表として派遣する、-、」 "Delegator"のカレンダーアドレスの値があるパラメタ。
The delegation "REQUEST" method MUST assign a value for the "RSVP" property parameter associated with the "Delegator's" "Attendee" property to that of the "Delegate's" "ATTENDEE" property. For example if the "Delegator's" "ATTENDEE" property specifies "RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE".
代表団「要求」方法は」 「の代表「出席者」特性のものへの"Delegator"の「出席者」の特性に関連している"RSVP"特性のパラメタのために値を割り当てなければなりません。 例えば、"Delegator"の「出席者」であるなら、特性は指定します。」 次に、「の代表「出席者」特性は指定しなければなりません。「RSVPは本当に等しい」、「RSVPは本当に等しいです」。
3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User
3.4.2.4 押しかけのカレンダーユーザに転送された要求
An "Attendee" assigned a "VTODO" calendar component may send the "VTODO" calendar component to another new CU, not previously associated with the "VTODO" calendar component. The current
"VTODO"カレンダーコンポーネントが割り当てられた「出席者」は以前に、"VTODO"カレンダーコンポーネントに関連づけられるのではなく、"VTODO"カレンダーコンポーネントを別の新しいCuに送るかもしれません。 電流
Silverberg, et. al. Standards Track [Page 40] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[40ページ]。
"Attendee" assigned the "VTODO" calendar component does this by forwarding the original "REQUEST" method to the new CU. The new CU can send a "REPLY" to the "Organizer" of the "VTODO" calendar component. The reply contains an "ATTENDEE" property for the new CU.
"VTODO"カレンダーコンポーネントが割り当てられた「出席者」は、オリジナルの「要求」方法を新しいCuに送ることによって、これをします。 新しいCUは"VTODO"カレンダーコンポーネントの「オーガナイザー」に「回答」を送ることができます。 回答は新しいCuのための「出席者」の特性を含んでいます。
The "Organizer" ultimately decides whether or not the new CU becomes part of the to-do and is not obligated to do anything with a "REPLY" from a new (uninvited) CU. If the "Organizer" does not want the new CU to be part of the to-do, the new "ATTENDEE" property is not added to the "VTODO" calendar component. The "Organizer" MAY send the CU a "CANCEL" message to indicate that they will not be added to the to- do. If the "Organizer" decides to add the new CU, the new "ATTENDEE" property is added to the "VTODO" calendar component. Furthermore, the "Organizer" is free to change any "ATTENDEE" property parameter from the values supplied by the new CU to something the "Organizer" considers appropriate.
「オーガナイザー」は、結局、新しいCUが大騒ぎの一部になるかどうか決めて、「回答」で新しい(押しかけの)Cuから何もするのが義務付けられません。 「オーガナイザー」が、新しいCUに大騒ぎの一部になって欲しくないなら、新しい「出席者」の特性は"VTODO"カレンダーコンポーネントに加えられません。 「オーガナイザー」がそれらに加えられないのを示す「キャンセル」メッセージをCUに送るかもしれない、-、してください。 「オーガナイザー」が、新しいCUを加えると決めるなら、新しい「出席者」の特性は"VTODO"カレンダーコンポーネントに加えられます。 その上、「オーガナイザー」は自由にどんな「出席者」特性のパラメタも新しいCuによって供給された値から「オーガナイザー」が適切であると考える何かに変えることができます。
3.4.2.5 REQUEST Updated Attendee Status
3.4.2.5 アップデートされた出席者状態を要求してください。
An "Organizer" of a "VTODO" may request an updated status from one or more "Attendees". The "Organizer" sends a "REQUEST" method to the "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The "SEQUENCE" property for the "VTODO" is not changed from its previous value. A recipient determines that the only change in the "REQUEST" is that their "RSVP" property parameter indicates a request for an updated status. The recipient SHOULD respond with a "REPLY" method indicating their current status with respect to the "REQUEST".
An "Organizer" of a "VTODO" may request an updated status from one or more "Attendees". The "Organizer" sends a "REQUEST" method to the "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The "SEQUENCE" property for the "VTODO" is not changed from its previous value. A recipient determines that the only change in the "REQUEST" is that their "RSVP" property parameter indicates a request for an updated status. The recipient SHOULD respond with a "REPLY" method indicating their current status with respect to the "REQUEST".
3.4.3 REPLY
3.4.3 REPLY
The "REPLY" method in a "VTODO" calendar component is used to respond (e.g., accept or decline) to a request or to reply to a delegation request. It is also used by an "Attendee" to update their completion status. When used to provide a delegation response, the "Delegator" MUST include the calendar address of the "Delegate" in the "delegated-to" parameter of the "Delegator's" "ATTENDEE" property. The "Delegate" MUST include the calendar address of the "Delegator" on the "delegated-from" parameter of the "Delegate's" "ATTENDEE" property.
The "REPLY" method in a "VTODO" calendar component is used to respond (e.g., accept or decline) to a request or to reply to a delegation request. It is also used by an "Attendee" to update their completion status. When used to provide a delegation response, the "Delegator" MUST include the calendar address of the "Delegate" in the "delegated-to" parameter of the "Delegator's" "ATTENDEE" property. The "Delegate" MUST include the calendar address of the "Delegator" on the "delegated-from" parameter of the "Delegate's" "ATTENDEE" property.
The "REPLY" method MAY also be used to respond to an unsuccessful "VTODO" calendar component "REQUEST" method. Depending on the "REQUEST-STATUS" value, no scheduling action may have been performed.
The "REPLY" method MAY also be used to respond to an unsuccessful "VTODO" calendar component "REQUEST" method. Depending on the "REQUEST-STATUS" value, no scheduling action may have been performed.
The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" method from a "Calendar User" not in the original "REQUEST". For example, a "REPLY" method MAY be received from a "Delegate" of a "VTODO" calendar component. In addition, the "REPLY" method MAY be
The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" method from a "Calendar User" not in the original "REQUEST". For example, a "REPLY" method MAY be received from a "Delegate" of a "VTODO" calendar component. In addition, the "REPLY" method MAY be
Silverberg, et. al. Standards Track [Page 41] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 41] RFC 2446 iTIP November 1998
received from an unknown "Calendar User", having been forwarded the "REQUEST" by an original "Attendee" of the "VTODO" calendar component. This uninvited "Attendee" MAY be accepted, or the "Organizer" MAY cancel the "VTODO" calendar component for the uninvited "Attendee" by sending them a "CANCEL" method.
received from an unknown "Calendar User", having been forwarded the "REQUEST" by an original "Attendee" of the "VTODO" calendar component. This uninvited "Attendee" MAY be accepted, or the "Organizer" MAY cancel the "VTODO" calendar component for the uninvited "Attendee" by sending them a "CANCEL" method.
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence
------------------- ---------------------------------------------
METHOD 1 MUST be "REPLY"
VTODO 1+ All component MUST have the same UID
ATTENDEE 1+
DTSTAMP 1
ORGANIZER 1
REQUEST-STATUS 1+
UID 1 MUST must be the address of the replying
attendee
Component/Property Presence ------------------- --------------------------------------------- METHOD 1 MUST be "REPLY" VTODO 1+ All component MUST have the same UID ATTENDEE 1+ DTSTAMP 1 ORGANIZER 1 REQUEST-STATUS 1+ UID 1 MUST must be the address of the replying attendee
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1
DTSTART 0 or 1
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
PRIORITY 0 or 1
RDATE 0+
RELATED-TO 0+
RESOURCES 0 or 1 This property may contain a list of values
RRULE 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
Recurring calendar component. Otherwise it
MUST NOT be present
SEQUENCE 0 or 1 MUST be the sequence number of
the original REQUEST if greater than 0.
MAY be present if 0.
STATUS 0 or 1
ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 DTSTART 0 or 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PERCENT-COMPLETE 0 or 1 PRIORITY 0 or 1 RDATE 0+ RELATED-TO 0+ RESOURCES 0 or 1 This property may contain a list of values RRULE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a Recurring calendar component. Otherwise it MUST NOT be present SEQUENCE 0 or 1 MUST be the sequence number of the original REQUEST if greater than 0. MAY be present if 0. STATUS 0 or 1
Silverberg, et. al. Standards Track [Page 42] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 42] RFC 2446 iTIP November 1998
SUMMARY 0 or 1 Can be null
URL 0 or 1
X-PROPERTY 0+
SUMMARY 0 or 1 Can be null URL 0 or 1 X-PROPERTY 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VALARM 0 VEVENT 0 VFREEBUSY 0
VALARM 0 VEVENT 0 VFREEBUSY 0
3.4.4 ADD
3.4.4 ADD
The "ADD" method in a "VTODO" calendar component is used to add one or more instances to an existing to-do.
The "ADD" method in a "VTODO" calendar component is used to add one or more instances to an existing to-do.
If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VTODO". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH".
If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient SHOULD send a "REFRESH" to the "Organizer" in order to be updated with the latest version of the "VTODO". If an "Attendee" implementation does not support the "ADD" method it should respond with a "REQUEST-STATUS" value of 5.3 and ask for a "REFRESH".
The "SEQUENCE" property value is incremented as the sequence of to- dos has changed.
The "SEQUENCE" property value is incremented as the sequence of to- dos has changed.
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST be "ADD"
VTODO 1
DTSTAMP 1
ORGANIZER 1
PRIORITY 1
SEQUENCE 1 MUST be greater than 0
SUMMARY 1 Can be null.
UID 1 MUST match that of the original to-do
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "ADD" VTODO 1 DTSTAMP 1 ORGANIZER 1 PRIORITY 1 SEQUENCE 1 MUST be greater than 0 SUMMARY 1 Can be null. UID 1 MUST match that of the original to-do
ATTACH 0+
ATTENDEE 0+
CATEGORIES 0 or 1 This property may contain a list of
values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
ATTACH 0+ ATTENDEE 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+
Silverberg, et. al. Standards Track [Page 43] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 43] RFC 2446 iTIP November 1998
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DTSTART 0 or 1
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
RDATE 0+
RELATED-TO 0+
RESOURCES 0 or 1 This property may contain a list of
values
RRULE 0+
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS
URL 0 or 1
X-PROPERTY 0+
CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTSTART 0 or 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PERCENT-COMPLETE 0 or 1 RDATE 0+ RELATED-TO 0+ RESOURCES 0 or 1 This property may contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- PROCESS URL 0 or 1 X-PROPERTY 0+
RECURRENCE-ID 0
REQUEST-STATUS 0
RECURRENCE-ID 0 REQUEST-STATUS 0
VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers
to a timezone
X-COMPONENT 0+
VALARM 0+ VTIMEZONE 0+ MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VEVENT 0 VJOURNAL 0 VFREEBUSY 0
VEVENT 0 VJOURNAL 0 VFREEBUSY 0
3.4.5 CANCEL
3.4.5 CANCEL
The "CANCEL" method in a "VTODO" calendar component is used to send a cancellation notice of an existing "VTODO" calendar request to the "Attendees". The message is sent by the "Organizer" of a "VTODO" calendar component to the "Attendees" of the "VTODO" calendar component. For a recurring "VTODO" calendar component, either the whole "VTODO" calendar component or instances of a "VTODO" calendar component may be cancelled. To cancel the complete range of a recurring "VTODO" calendar component, the "UID" property value for the "VTODO" calendar component MUST be specified and a "RECURRENCE- ID" MUST NOT be specified in the "CANCEL" method. In order to cancel an individual instance of a recurring "VTODO" calendar component, the "RECURRENCE-ID" property value for the "VTODO" calendar component MUST be specified in the "CANCEL" method.
The "CANCEL" method in a "VTODO" calendar component is used to send a cancellation notice of an existing "VTODO" calendar request to the "Attendees". The message is sent by the "Organizer" of a "VTODO" calendar component to the "Attendees" of the "VTODO" calendar component. For a recurring "VTODO" calendar component, either the whole "VTODO" calendar component or instances of a "VTODO" calendar component may be cancelled. To cancel the complete range of a recurring "VTODO" calendar component, the "UID" property value for the "VTODO" calendar component MUST be specified and a "RECURRENCE- ID" MUST NOT be specified in the "CANCEL" method. In order to cancel an individual instance of a recurring "VTODO" calendar component, the "RECURRENCE-ID" property value for the "VTODO" calendar component MUST be specified in the "CANCEL" method.
Silverberg, et. al. Standards Track [Page 44] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 44] RFC 2446 iTIP November 1998
There are two options for canceling a sequence of instances of a recurring "VTODO" calendar component:
There are two options for canceling a sequence of instances of a recurring "VTODO" calendar component:
(a) the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
specified "VTODO" calendar component and all instances before (or
after); or
(a) the "RECURRENCE-ID" property for an instance in the sequence MUST be specified with the "RANGE" property parameter value of THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the specified "VTODO" calendar component and all instances before (or after); or
(b) individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the
instances to be cancelled.
(b) individual recurrence instances may be cancelled by specifying multiple "RECURRENCE-ID" properties corresponding to the instances to be cancelled.
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be incremented.
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be incremented.
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence
------------------- ---------------------------------------------
METHOD 1 MUST be "CANCEL"
VTODO 1
ATTENDEE 0+ include all "Attendees" being removed from
the todo. MUST include all "Attendees" if
the entire todo is cancelled.
UID 1 MUST echo original UID
DTSTAMP 1
ORGANIZER 1
SEQUENCE 1
Component/Property Presence ------------------- --------------------------------------------- METHOD 1 MUST be "CANCEL" VTODO 1 ATTENDEE 0+ include all "Attendees" being removed from the todo. MUST include all "Attendees" if the entire todo is cancelled. UID 1 MUST echo original UID DTSTAMP 1 ORGANIZER 1 SEQUENCE 1
ATTACH 0+
CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1
DTSTART 0 or 1
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
RDATE 0+
ATTACH 0+ CATEGORIES 0 or 1 This property MAY contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 DTSTART 0 or 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PERCENT-COMPLETE 0 or 1 RDATE 0+
Silverberg, et. al. Standards Track [Page 45] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 45] RFC 2446 iTIP November 1998
RECURRENCE-ID 0 or 1 MUST only if referring to one or more
instances of a recurring calendar
component. Otherwise it MUST NOT be
present.
RELATED-TO 0+
RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
PRIORITY 0 or 1
STATUS 0 or 1 If present it MUST be set to "CANCELLED".
MUST NOT be used if purpose is to remove
"ATTENDEES" rather than cancel the entire
VTODO.
URL 0 or 1
X-PROPERTY 0+
RECURRENCE-ID 0 or 1 MUST only if referring to one or more instances of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ RESOURCES 0 or 1 This property MAY contain a list of values RRULE 0+ PRIORITY 0 or 1 STATUS 0 or 1 If present it MUST be set to "CANCELLED". MUST NOT be used if purpose is to remove "ATTENDEES" rather than cancel the entire VTODO. URL 0 or 1 X-PROPERTY 0+
REQUEST-STATUS 0
REQUEST-STATUS 0
VTIMEZONE 0 or 1 MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VALARM 0 VEVENT 0 VFREEBUSY 0
VALARM 0 VEVENT 0 VFREEBUSY 0
3.4.6 REFRESH
3.4.6 REFRESH
The "REFRESH" method in a "VTODO" calendar component is used by "Attendees" of an existing "VTODO" calendar component to request an updated description from the "Organizer" of the "VTODO" calendar component. The "Organizer" of the "VTODO" calendar component MAY use this method to request an updated status from the "Attendees". The "REFRESH" method MUST specify the "UID" property corresponding to the "VTODO" calendar component needing update.
The "REFRESH" method in a "VTODO" calendar component is used by "Attendees" of an existing "VTODO" calendar component to request an updated description from the "Organizer" of the "VTODO" calendar component. The "Organizer" of the "VTODO" calendar component MAY use this method to request an updated status from the "Attendees". The "REFRESH" method MUST specify the "UID" property corresponding to the "VTODO" calendar component needing update.
A refresh of a recurrence instance of a "VTODO" calendar component may be requested by specifying the "RECURRENCE-ID" property corresponding to the associated "VTODO" calendar component. The "Organizer" responds with the latest description and rendition of the "VTODO" calendar component. In most cases this will be a REQUEST unless the "VTODO" has been cancelled, in which case the ORGANIZER MUST send a "CANCEL". This method is intended to facilitate machine processing of requests for updates to a "VTODO" calendar component.
A refresh of a recurrence instance of a "VTODO" calendar component may be requested by specifying the "RECURRENCE-ID" property corresponding to the associated "VTODO" calendar component. The "Organizer" responds with the latest description and rendition of the "VTODO" calendar component. In most cases this will be a REQUEST unless the "VTODO" has been cancelled, in which case the ORGANIZER MUST send a "CANCEL". This method is intended to facilitate machine processing of requests for updates to a "VTODO" calendar component.
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Silverberg, et. al. Standards Track [Page 46] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 46] RFC 2446 iTIP November 1998
Component/Property Presence
------------------- ---------------------------------------------
METHOD 1 MUST be "REFRESH"
VTODO 1
ATTENDEE 1
DTSTAMP 1
UID 1 MUST echo original UID
Component/Property Presence ------------------- --------------------------------------------- METHOD 1 MUST be "REFRESH" VTODO 1 ATTENDEE 1 DTSTAMP 1 UID 1 MUST echo original UID
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
Recurring calendar component. Otherwise it
MUST NOT be present
X-PROPERTY 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a Recurring calendar component. Otherwise it MUST NOT be present X-PROPERTY 0+
ATTACH 0
CATEGORIES 0
CLASS 0
COMMENT 0
CONTACT 0
CREATED 0
DESCRIPTION 0
DTSTART 0
DUE 0
DURATION 0
EXDATE 0
EXRULE 0
GEO 0
LAST-MODIFIED 0
LOCATION 0
ORGANIZER 0
PERCENT-COMPLETE 0
PRIORITY 0
RDATE 0
RELATED-TO 0
REQUEST-STATUS 0
RESOURCES 0
RRULE 0
SEQUENCE 0
STATUS 0
URL 0
ATTACH 0 CATEGORIES 0 CLASS 0 COMMENT 0 CONTACT 0 CREATED 0 DESCRIPTION 0 DTSTART 0 DUE 0 DURATION 0 EXDATE 0 EXRULE 0 GEO 0 LAST-MODIFIED 0 LOCATION 0 ORGANIZER 0 PERCENT-COMPLETE 0 PRIORITY 0 RDATE 0 RELATED-TO 0 REQUEST-STATUS 0 RESOURCES 0 RRULE 0 SEQUENCE 0 STATUS 0 URL 0
X-COMPONENT 0+
X-COMPONENT 0+
VALARM 0 VEVENT 0 VFREEBUSY 0 VTIMEZONE 0
VALARM 0 VEVENT 0 VFREEBUSY 0 VTIMEZONE 0
Silverberg, et. al. Standards Track [Page 47] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 47] RFC 2446 iTIP November 1998
3.4.7 COUNTER
3.4.7 COUNTER
The "COUNTER" method in a "VTODO" calendar component is used by an "Attendee" of an existing "VTODO" calendar component to submit to the "Organizer" a counter proposal for the "VTODO" calendar component. The "Attendee" sends the message to the "Organizer" of the "VTODO" calendar component.
The "COUNTER" method in a "VTODO" calendar component is used by an "Attendee" of an existing "VTODO" calendar component to submit to the "Organizer" a counter proposal for the "VTODO" calendar component. The "Attendee" sends the message to the "Organizer" of the "VTODO" calendar component.
The counter proposal is an iCalendar object consisting of a "VTODO" calendar component describing the complete description of the alternate "VTODO" calendar component.
The counter proposal is an iCalendar object consisting of a "VTODO" calendar component describing the complete description of the alternate "VTODO" calendar component.
The "Organizer" rejects the counter proposal by sending the "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the counter proposal by sending all of the "Attendees" of the "VTODO" calendar component a "REQUEST" method rescheduling the "VTODO" calendar component. In the latter case, the "Organizer" SHOULD reset the individual "RSVP" property parameter values to TRUE on each "ATTENDEE" property; in order to force a response by the "Attendees".
The "Organizer" rejects the counter proposal by sending the "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the counter proposal by sending all of the "Attendees" of the "VTODO" calendar component a "REQUEST" method rescheduling the "VTODO" calendar component. In the latter case, the "Organizer" SHOULD reset the individual "RSVP" property parameter values to TRUE on each "ATTENDEE" property; in order to force a response by the "Attendees".
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST be "COUNTER"
VTODO 1
ATTENDEE 1+
DTSTAMP 1
ORGANIZER 1
PRIORITY 1
SUMMARY 1 Can be null
UID 1
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "COUNTER" VTODO 1 ATTENDEE 1+ DTSTAMP 1 ORGANIZER 1 PRIORITY 1 SUMMARY 1 Can be null UID 1
ATTACH 0+
CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1 Can be null
DTSTART 0 or 1
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
ATTACH 0+ CATEGORIES 0 or 1 This property MAY contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 Can be null DTSTART 0 or 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1
Silverberg, et. al. Standards Track [Page 48] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 48] RFC 2446 iTIP November 1998
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST only 3.5if referring to an instance of a
recurring calendar component. Otherwise it
MUST NOT be present.
RELATED-TO 0+
REQUEST-STATUS 0+
RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0 or 1
SEQUENCE 0 or 1 MUST echo the original SEQUENCE number.
MUST be present if non-zero. MAY be present
if zero.
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS/CANCELLED
URL 0 or 1
X-PROPERTY 0+
LOCATION 0 or 1 PERCENT-COMPLETE 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only 3.5if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUS 0+ RESOURCES 0 or 1 This property MAY contain a list of values RRULE 0 or 1 SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. MUST be present if non-zero. MAY be present if zero. STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- PROCESS/CANCELLED URL 0 or 1 X-PROPERTY 0+
VALARM 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VALARM 0+ VTIMEZONE 0 or 1 MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VEVENT 0 VFREEBUSY 0
VEVENT 0 VFREEBUSY 0
3.4.8 DECLINECOUNTER
3.4.8 DECLINECOUNTER
The "DECLINECOUNTER" method in a "VTODO" calendar component is used by an "Organizer" of "VTODO" calendar component to reject a counter proposal offered by one of the "Attendees". The "Organizer" sends the message to the "Attendee" that sent the "COUNTER" method to the "Organizer".
The "DECLINECOUNTER" method in a "VTODO" calendar component is used by an "Organizer" of "VTODO" calendar component to reject a counter proposal offered by one of the "Attendees". The "Organizer" sends the message to the "Attendee" that sent the "COUNTER" method to the "Organizer".
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence ------------------- --------------------------------------------- METHOD 1 MUST be "DECLINECOUNTER"
Component/Property Presence ------------------- --------------------------------------------- METHOD 1 MUST be "DECLINECOUNTER"
VTODO 1
ATTENDEE 1+ MUST for all attendees
DTSTAMP 1
ORGANIZER 1
SEQUENCE 1 MUST echo the original SEQUENCE number
UID 1 MUST echo original UID
VTODO 1 ATTENDEE 1+ MUST for all attendees DTSTAMP 1 ORGANIZER 1 SEQUENCE 1 MUST echo the original SEQUENCE number UID 1 MUST echo original UID
Silverberg, et. al. Standards Track [Page 49] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 49] RFC 2446 iTIP November 1998
ATTACH 0+
CATEGORIES 0 or 1 This property may contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1
DTSTART 0 or 1
DUE 0 or 1 If present DURATION MUST NOT be present
DURATION 0 or 1 If present DUE MUST NOT be present
EXDATE 0+
EXRULE 0+
GEO 0 or 1
LAST-MODIFIED 0 or 1
LOCATION 0 or 1
PERCENT-COMPLETE 0 or 1
PRIORITY 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
recurring calendar component. Otherwise
it MUST NOT be present.
RELATED-TO 0+
REQUEST-STATUS 0+
RESOURCES 0 or 1 This property MAY contain a list of values
RRULE 0+
STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
PROCESS
URL 0 or 1
X-PROPERTY 0+
ATTACH 0+ CATEGORIES 0 or 1 This property may contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 DESCRIPTION 0 or 1 DTSTART 0 or 1 DUE 0 or 1 If present DURATION MUST NOT be present DURATION 0 or 1 If present DUE MUST NOT be present EXDATE 0+ EXRULE 0+ GEO 0 or 1 LAST-MODIFIED 0 or 1 LOCATION 0 or 1 PERCENT-COMPLETE 0 or 1 PRIORITY 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ REQUEST-STATUS 0+ RESOURCES 0 or 1 This property MAY contain a list of values RRULE 0+ STATUS 0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN- PROCESS URL 0 or 1 X-PROPERTY 0+
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VTIMEZONE 0+ MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VALARM 0 VEVENT 0 VFREEBUSY 0
VALARM 0 VEVENT 0 VFREEBUSY 0
3.5 Methods For VJOURNAL Components
3.5 Methods For VJOURNAL Components
This section defines the property set for the methods that are applicable to the "VJOURNAL" calendar component.
This section defines the property set for the methods that are applicable to the "VJOURNAL" calendar component.
The following summarizes the methods that are defined for the "VJOURNAL" calendar component.
The following summarizes the methods that are defined for the "VJOURNAL" calendar component.
Silverberg, et. al. Standards Track [Page 50] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 50] RFC 2446 iTIP November 1998
+================+==================================================+ | Method | Description | |================+==================================================| | PUBLISH | Post a journal entry. Used primarily as a method | | | of advertising the existence of a journal entry. | | | | | ADD | Add one or more instances to an existing journal | | | entry. | | | | | CANCEL | Cancel one or more instances of an existing | | | journal entry. | +================+==================================================+
+================+==================================================+ | Method | Description | |================+==================================================| | PUBLISH | Post a journal entry. Used primarily as a method | | | of advertising the existence of a journal entry. | | | | | ADD | Add one or more instances to an existing journal | | | entry. | | | | | CANCEL | Cancel one or more instances of an existing | | | journal entry. | +================+==================================================+
3.5.1 PUBLISH
3.5.1 PUBLISH
The "PUBLISH" method in a "VJOURNAL" calendar component has no associated response. It is simply a posting of an iCalendar object that may be added to a calendar. It MUST have an "Organizer". It MUST NOT have "Attendees". The expected usage is for encapsulating an
The "PUBLISH" method in a "VJOURNAL" calendar component has no associated response. It is simply a posting of an iCalendar object that may be added to a calendar. It MUST have an "Organizer". It MUST NOT have "Attendees". The expected usage is for encapsulating an
arbitrary journal entry as an iCalendar object. The "Organizer" MAY subsequently update (with another "PUBLISH" method) or cancel (with a "CANCEL" method) a previously published journal entry.
arbitrary journal entry as an iCalendar object. The "Organizer" MAY subsequently update (with another "PUBLISH" method) or cancel (with a "CANCEL" method) a previously published journal entry.
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST be "PUBLISH"
VJOURNAL 1+
DESCRIPTION 1 Can be null.
DTSTAMP 1
DTSTART 1
ORGANIZER 1
UID 1
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "PUBLISH" VJOURNAL 1+ DESCRIPTION 1 Can be null. DTSTAMP 1 DTSTART 1 ORGANIZER 1 UID 1
ATTACH 0+
CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
EXDATE 0+
EXRULE 0+
LAST-MODIFIED 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
ATTACH 0+ CATEGORIES 0 or 1 This property MAY contain a list of values CLASS 0 or 1 COMMENT 0 or 1 CONTACT 0+ CREATED 0 or 1 EXDATE 0+ EXRULE 0+ LAST-MODIFIED 0 or 1 RDATE 0+ RECURRENCE-ID 0 or 1 MUST only if referring to an instance of a
Silverberg, et. al. Standards Track [Page 51] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 51] RFC 2446 iTIP November 1998
recurring calendar component. Otherwise
it MUST NOT be present.
RELATED-TO 0+
RRULE 0+
SEQUENCE 0 or 1 MUST echo the original SEQUENCE number.
MUST be present if non-zero. MAY be
present if zero.
STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED
SUMMARY 0 or 1 Can be null
URL 0 or 1
X-PROPERTY 0+
recurring calendar component. Otherwise it MUST NOT be present. RELATED-TO 0+ RRULE 0+ SEQUENCE 0 or 1 MUST echo the original SEQUENCE number. MUST be present if non-zero. MAY be present if zero. STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED SUMMARY 0 or 1 Can be null URL 0 or 1 X-PROPERTY 0+
ATTENDEE 0
ATTENDEE 0
VALARM 0+
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VALARM 0+ VTIMEZONE 0+ MUST be present if any date/time refers to a timezone X-COMPONENT 0+
VEVENT 0 VFREEBUSY 0 VTODO 0
VEVENT 0 VFREEBUSY 0 VTODO 0
3.5.2 ADD
3.5.2 ADD
The "ADD" method in a "VJOURNAL" calendar component is used to add one or more instances to an existing "VJOURNAL" entry. There is no response to the "Organizer".
The "ADD" method in a "VJOURNAL" calendar component is used to add one or more instances to an existing "VJOURNAL" entry. There is no response to the "Organizer".
If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient MAY treat the "ADD" as a "PUBLISH".
If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient MAY treat the "ADD" as a "PUBLISH".
This method type is an iCalendar object that conforms to the following property constraints:
This method type is an iCalendar object that conforms to the following property constraints:
Component/Property Presence
------------------- ----------------------------------------------
METHOD 1 MUST be "ADD"
VJOURNAL 1
DESCRIPTION 1 Can be null.
DTSTAMP 1
DTSTART 1
ORGANIZER 1
SEQUENCE 1 MUST be greater than 0
UID 1 MUST match that of the original journal
Component/Property Presence ------------------- ---------------------------------------------- METHOD 1 MUST be "ADD" VJOURNAL 1 DESCRIPTION 1 Can be null. DTSTAMP 1 DTSTART 1 ORGANIZER 1 SEQUENCE 1 MUST be greater than 0 UID 1 MUST match that of the original journal
ATTACH 0+
ATTACH 0+
Silverberg, et. al. Standards Track [Page 52] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 52] RFC 2446 iTIP November 1998
CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
EXDATE 0+
EXRULE 0+
LAST-MODIFIED 0 or 1
RDATE 0+
RELATED-TO 0+
RRULE 0+
STATUS 0 or 1 MAY be one of DRAFT/FINAL/CANCELLED
SUMMARY 0 or 1 Can be null
URL 0 or 1
X-PROPERTY 0+
CATEGORIES0か1Thisの特性はヌルURL0か1 X-PROPERTY0が+であったなら0+RRULE CLASS0か1COMMENT0か1CONTACT0関連+ CREATED0か1EXDATE0+EXRULE0+LAST-MODIFIED0か1RDATEの0+TO0+STATUS0か1がDRAFT/FINAL/CANCELLED SUMMARY0か1の1つがCanであったならそうするかもしれない値のリストを含むかもしれません。
ATTENDEE 0
RECURRENCE-ID 0
出席者0RECURRENCE ID0
VALARM 0+
VTIMEZONE 0 or 1 MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
日付/何時でもタイムゾーンX-COMPONENT0+について言及するなら、VALARM0+VTIMEZONE0か1が存在していなければなりません。
VEVENT 0 VFREEBUSY 0 VTODO 0
VEVENT0VFREEBUSY0VTODO0
3.5.3 CANCEL
3.5.3 キャンセル
The "CANCEL" method in a "VJOURNAL" calendar component is used to send a cancellation notice of an existing journal entry. The message is sent by the "Organizer" of a journal entry. For a recurring journal entry, either the whole journal entry or instances of a journal entry may be cancelled. To cancel the complete range of a recurring journal entry, the "UID" property value for the journal entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be specified in the "CANCEL" method. In order to cancel an individual instance of the journal entry, the "RECURRENCE-ID" property value for the journal entry MUST be specified in the "CANCEL" method.
"VJOURNAL"カレンダーコンポーネントの「キャンセル」方法は、既存の仕訳記入に関する解約通知書を送るのに使用されます。 メッセージは仕訳記入の「オーガナイザー」によって送られます。 再発仕訳記入において、仕訳記入の全体の仕訳記入か例が中止されるかもしれません。 再発仕訳記入の全種類を取り消すために、仕訳記入への"UID"資産価値を指定しなければなりません、そして、「RECURRENCE ID」の特性は「キャンセル」方法で指定されてはいけません。 仕訳記入の個々の例を取り消すために、「キャンセル」方法で仕訳記入への「RECURRENCE ID」資産価値を指定しなければなりません。
There are two options for canceling a sequence of instances of a recurring "VJOURNAL" calendar component:
再発"VJOURNAL"カレンダーコンポーネントの例の系列を取り消すための2つのオプションがあります:
Silverberg, et. al. Standards Track [Page 53] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[53ページ]。
(a) the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of
THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the
specified "VTODO" calendar component and all instances before (or
after); or
(a) THISANDPRIOR(または、THISANDFUTURE)の「範囲」特性のパラメタ価値で系列の例のための「RECURRENCE ID」の特性を指定して、指定された"VTODO"カレンダーコンポーネントと(or after)の前のすべての例のキャンセルを示さなければなりません。 または
(b) individual recurrence instances may be cancelled by specifying
multiple "RECURRENCE-ID" properties corresponding to the
instances to be cancelled.
(b) 個々の再発例は、取り消されるために例に対応する複数の「RECURRENCE ID」の特性を指定することによって、取り消されるかもしれません。
When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be incremented.
"VJOURNAL"が取り消されるとき、「系列」資産価値を増加しなければなりません。
This method type is an iCalendar object that conforms to the following property constraints:
この方法タイプは以下の特性の規制に一致しているiCalendar物です:
Component/Property Presence
------------------- ---------------------------------------------
METHOD 1 MUST be "CANCEL"
VJOURNAL 1+ All MUST have the same UID
DTSTAMP 1
ORGANIZER 1
SEQUENCE 1
UID 1 MUST be the UID of the original REQUEST
コンポーネント/特性の存在------------------- --------------------------------------------- METHOD1はすべてが持たなければならない「キャンセル」VJOURNAL1+がオーガナイザー1つの同じUID DTSTAMP1系列1UID1であったならオリジナルのUIDが要求であったに違いないならそうしなければなりません。
ATTACH 0+
ATTENDEE 0+
CATEGORIES 0 or 1 This property MAY contain a list of values
CLASS 0 or 1
COMMENT 0 or 1
CONTACT 0+
CREATED 0 or 1
DESCRIPTION 0 or 1
DTSTART 0 or 1
EXDATE 0+
EXRULE 0+
LAST-MODIFIED 0 or 1
RDATE 0+
RECURRENCE-ID 0 or 1 only if referring to an instance of a
recurring calendar component. Otherwise
it MUST NOT be present.
RELATED-TO 0+
RRULE 0+
STATUS 0 or 1 MAY be present, must be "CANCELLED" if
present
SUMMARY 0 or 1
URL 0 or 1
X-PROPERTY 0+
再発カレンダーコンポーネントの例を示す場合にだけ、0+CATEGORIES0か1つのATTACH0+ATTENDEE Thisの特性が値CLASS0か1COMMENT0か1CONTACT0+ CREATED0か1記述0か1DTSTART0か1EXDATE0+EXRULE0+LAST-MODIFIED0か1RDATEのRECURRENCE0+ID0か1のリストを含むかもしれません。 さもなければ、それは存在しているはずがありません。 0+RRULE関連TO0+STATUS0か1はプレゼントが「取り消されました」が、現在の概要0であるに違いないか1つのURL0か1X-特性の0が+であることであるかもしれません。
Silverberg, et. al. Standards Track [Page 54] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[54ページ]。
REQUEST-STATUS 0
要求状態0
VTIMEZONE 0+ MUST be present if any date/time refers to
a timezone
X-COMPONENT 0+
VALARM 0
VEVENT 0
VFREEBUSY 0
VTODO 0
日付/何時でもタイムゾーンX-COMPONENT0+VALARM0VEVENT0VFREEBUSY0VTODO0について言及するなら、VTIMEZONE0+は存在していなければなりません。
3.6 Status Replies
3.6 状態回答
The "REQUEST-STATUS" property may include the following values:
「要求状態」の特性は以下の値を含むかもしれません:
|==============+============================+=========================| | Short Return | Longer Return Status | Offending Data | | Status Code | Description | | |==============+============================+=========================| | 2.0 | Success. | None. | |==============+============================+=========================| | 2.1 | Success but fallback taken | Property name and value | | | on one or more property | MAY be specified. | | | values. | | |==============+============================+=========================| | 2.2 | Success, invalid property | Property name MAY be | | | ignored. | specified. | |==============+============================+=========================| | 2.3 | Success, invalid property | Property parameter name | | | parameter ignored. | and value MAY be | | | | specified. | |==============+============================+=========================| | 2.4 | Success, unknown non- | Non-standard property | | | standard property ignored. | name MAY be specified. | |==============+============================+=========================| | 2.5 | Success, unknown non | Property and non- | | | standard property value | standard value MAY be | | | ignored. | specified. | |==============+============================+=========================| | 2.6 | Success, invalid calendar | Calendar component | | | component ignored. | sentinel (e.g., BEGIN: | | | | ALARM) MAY be | | | | specified. | |==============+============================+=========================| | 2.7 | Success, request forwarded | Original and forwarded | | | to Calendar User. | caluser addresses MAY | | | | be specified. | |==============+============================+=========================| | 2.8 | Success, repeating event | RRULE or RDATE property |
|==============+============================+=========================| | 短い収益| より長いリターン状態| 怒っているデータ| | ステータスコード| 記述| | |==============+============================+=========================| | 2.0 | 成功。 | なし。 | |==============+============================+=========================| | 2.1 | 成功にもかかわらず、取られた後退| 特性の名と値| | | 1つ以上の所有地に関して| 指定されるかもしれなくなってください。 | | | 値。 | | |==============+============================+=========================| | 2.2 | 成功、無効の特性| 特性の名はそうです。| | | 無視にされる。 | 指定にされる。 | |==============+============================+=========================| | 2.3 | 成功、無効の特性| 特性のパラメタ名| | | 無視されたパラメタ。 | そして、値はそうです。| | | | 指定にされる。 | |==============+============================+=========================| | 2.4 | 成功、未知、非| 標準的でない特性| | | 無視された標準の特性。 | 名前は指定されるかもしれません。 | |==============+============================+=========================| | 2.5 | 成功、未知、非| そして、特性、非| | | 標準の資産価値| 基準値はそうです。| | | 無視にされる。 | 指定にされる。 | |==============+============================+=========================| | 2.6 | 成功、無効のカレンダー| カレンダーコンポーネント| | | 無視されたコンポーネント。 | 歩しょう(例えば、BEGIN: | | | | ALARM)はそうです。| | | | 指定にされる。 | |==============+============================+=========================| | 2.7 | 成功、転送された要求| オリジナルで進めます。| | | カレンダーユーザに。 | caluserは5月を記述します。| | | | 指定されてください。 | |==============+============================+=========================| | 2.8 | 成功、繰り返している出来事| RRULEかRDATEの特性|
Silverberg, et. al. Standards Track [Page 55] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[55ページ]。
| | ignored. Scheduled as a | name and value MAY be | | | single component. | specified. | |==============+============================+=========================| | 2.9 | Success, truncated end date| DTEND property value | | | time to date boundary. | MAY be specified. | |==============+============================+=========================| | 2.10 | Success, repeating VTODO | RRULE or RDATE property | | | ignored. Scheduled as a | name and value MAY be | | | single VTODO. | specified. | |==============+============================+=========================| | 2.11 | Success, unbounded RRULE | RRULE property name and | | | clipped at some finite | value MAY be specified. | | | number of instances | Number of instances MAY | | | | also be specified. | |==============+============================+=========================| | 3.0 | Invalid property name. | Property name MAY be | | | | specified. | |==============+============================+=========================| | 3.1 | Invalid property value. | Property name and value | | | | MAY be specified. | |==============+============================+=========================| | 3.2 | Invalid property parameter.| Property parameter name | | | | and value MAY be | | | | specified. | |==============+============================+=========================| | 3.3 | Invalid property parameter | Property parameter name | | | value. | and value MAY be | | | | specified. | |==============+============================+=========================| | 3.4 | Invalid calendar component | Calendar component | | | sequence. | sentinel MAY be | | | | specified (e.g., BEGIN: | | | | VTIMEZONE). | |==============+============================+=========================| | 3.5 | Invalid date or time. | Date/time value(s) MAY | | | | be specified. | |==============+============================+=========================| | 3.6 | Invalid rule. | Rule value MAY be | | | | specified. | |==============+============================+=========================| | 3.7 | Invalid Calendar User. | Attendee property value | | | |MAY be specified. | |==============+============================+=========================| | 3.8 | No authority. | METHOD and Attendee | | | | property values MAY be | | | | specified. | |==============+============================+=========================|
| | 無視にされる。 aとして、予定されています。| 名前と値はそうです。| | | ただ一つのコンポーネント。 | 指定にされる。 | |==============+============================+=========================| | 2.9 | 成功、端が欠けている終了日| DTEND資産価値| | | 境界の日付を入れる時間。 | 指定されるかもしれなくなってください。 | |==============+============================+=========================| | 2.10 | 成功、繰り返しているVTODO| RRULEかRDATEの特性| | | 無視にされる。 aとして、予定されています。| 名前と値はそうです。| | | VTODOを選抜してください。 | 指定にされる。 | |==============+============================+=========================| | 2.11 | 成功、限りないRRULE| そしてRRULE特性の名。| | | いくつかでは、有限な状態で、切り取られます。| 値は指定されるかもしれません。 | | | 例の数| 例の5月の数| | | | また、指定されてください。 | |==============+============================+=========================| | 3.0 | 無効の特性の名。 | 特性の名はそうです。| | | | 指定にされる。 | |==============+============================+=========================| | 3.1 | 無効の資産価値。 | 特性の名と値| | | | 指定されるかもしれなくなってください。 | |==============+============================+=========================| | 3.2 | 無効の特性のパラメタ| 特性のパラメタ名| | | | そして、値はそうです。| | | | 指定にされる。 | |==============+============================+=========================| | 3.3 | 無効の特性のパラメタ| 特性のパラメタ名| | | 値。 | そして、値はそうです。| | | | 指定にされる。 | |==============+============================+=========================| | 3.4 | 無効のカレンダーコンポーネント| カレンダーコンポーネント| | | 系列。 | 歩しょうはそうです。| | | | 指定されています(例えば、BEGIN: | | | | VTIMEZONE)。 | |==============+============================+=========================| | 3.5 | 無効の期日か時間。 | 日付/時間的価値5月| | | | 指定されてください。 | |==============+============================+=========================| | 3.6 | 無効の規則。 | 規則値はそうです。| | | | 指定にされる。 | |==============+============================+=========================| | 3.7 | 無効のカレンダーユーザ。 | 出席者資産価値| | | |指定されるかもしれなくなってください。 | |==============+============================+=========================| | 3.8 | 権威がありません。 | 方法と出席者| | | | 特性の値はそうです。| | | | 指定にされる。 | |==============+============================+=========================|
Silverberg, et. al. Standards Track [Page 56] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[56ページ]。
| 3.9 | Unsupported version. | VERSION property name | | | | and value MAY be | | | | specified. | |==============+============================+=========================| | 3.10 | Request entity too large. | None. | |==============+============================+=========================| | 3.11 | Required component or | Component or property | | | property missing. | name MAY be specified. | |==============+============================+=========================| | 3.12 | Unknown component or | Component or property | | | property found | name MAY be specified | |==============+============================+=========================| | 3.13 | Unsupported component or | Component or property | | | property found | name MAY be specified | |==============+============================+=========================| | 3.14 | Unsupported capability | Method or action MAY | | | | be specified | |==============+============================+=========================| | 4.0 | Event conflict. Date/time | DTSTART and DTEND | | | is busy. | property name and values| | | | MAY be specified. | |==============+============================+=========================| | 5.0 | Request MAY supported. | Method property value | | | | MAY be specified. | |==============+============================+=========================| | 5.1 | Service unavailable. | ATTENDEE property value | | | | MAY be specified. | |==============+============================+=========================| | 5.2 | Invalid calendar service. | ATTENDEE property value | | | | MAY be specified. | |==============+============================+=========================| | 5.3 | No scheduling support for | ATTENDEE property value | | | user. | MAY be specified. | |==============+============================+=========================|
| 3.9 | サポートされないバージョン。 | バージョン特性の名| | | | そして、値はそうです。| | | | 指定にされる。 | |==============+============================+=========================| | 3.10 | 大き過ぎる状態で実体を要求してください。 | なし。 | |==============+============================+=========================| | 3.11 | または必要なコンポーネント。| コンポーネントか特性| | | 特性の取り逃がすこと。 | 名前は指定されるかもしれません。 | |==============+============================+=========================| | 3.12 | または未知のコンポーネント。| コンポーネントか特性| | | 見つけられた特性| 名前は指定されるかもしれません。| |==============+============================+=========================| | 3.13 | またはサポートされないコンポーネント。| コンポーネントか特性| | | 見つけられた特性| 名前は指定されるかもしれません。| |==============+============================+=========================| | 3.14 | サポートされない能力| 方法か動作はそうするかもしれません。| | | | 指定されてください。| |==============+============================+=========================| | 4.0 | イベント闘争。 日付/時間| DTSTARTとDTEND| | | 忙しい。 | 特性の名と値| | | | 指定されるかもしれなくなってください。 | |==============+============================+=========================| | 5.0 | 5月が支持したよう要求してください。 | 方法資産価値| | | | 指定されるかもしれなくなってください。 | |==============+============================+=========================| | 5.1 | 入手できないサービス。 | ATTENDEE資産価値| | | | 指定されるかもしれなくなってください。 | |==============+============================+=========================| | 5.2 | 無効のカレンダーサービス。 | ATTENDEE資産価値| | | | 指定されるかもしれなくなってください。 | |==============+============================+=========================| | 5.3 | サポートの計画をしません。| ATTENDEE資産価値| | | ユーザ。 | 指定されるかもしれなくなってください。 | |==============+============================+=========================|
3.7 Implementation Considerations
3.7 実現問題
3.7.1 Working With Recurrence Instances
3.7.1 再発例で働いていること。
iCalendar includes a recurrence grammar to represent recurring events. The benefit of such a grammar is the ability to represent a number of events in a single object. However, while this simplifies creation of a recurring event, meeting instances still need to be referenced. For instance, an "Attendee" may decline the third instance of a recurring Friday event. Similarly, the "Organizer" may change the time or location to a single instance of the recurring event.
iCalendarは、繰り返し起こる事柄を表すために再発文法を含んでいます。 そのような文法の利益は単一の物の多くの出来事を表す能力です。 しかしながら、これが繰り返し起こる事柄の創造を簡素化している間、ミーティング例は、まだ参照をつけられる必要があります。 例えば、「出席者」は再発金曜日の出来事の3番目の例を傾けるかもしれません。 同様に、「オーガナイザー」は時間か位置を繰り返し起こる事柄のただ一つの例に変えるかもしれません。
Silverberg, et. al. Standards Track [Page 57] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[57ページ]。
Since implementations may elect to store recurring events as either a single event object or a collection of discreet, related event objects, the protocol is designed so that each recurring instance may be both referenced and versioned. Hence, implementations that choose to maintain per-instance properties (such as "ATTENDEE" property "partstat" parameter) may do so. However, the protocol does not require per-instance recognition unless the instance itself must be renegotiated.
実現が、慎重で、関連するイベント物の単一のイベント物か収集のどちらかとして繰り返し起こる事柄を格納するのを選ぶかもしれないので、プロトコルはそれぞれの再発例に参照をつけて、versionedすることができるように設計されています。 したがって、1例あたりの特性(「出席者」特性の"partstat"パラメタなどの)を維持するのを選ぶ実現はそうするかもしれません。 しかしながら、例自体を再交渉してはいけないなら、プロトコルは1例あたりの認識を必要としません。
The scenarios for recurrence instance referencing are listed below. For purposes of simplification a change to an event refers to a "trigger property." That is, a property that has a substantive effect on the meeting itself such as start time, location, due date (for "VTODO" calendar component components) and possibly description.
再発例の参照箇所のためのシナリオは以下に記載されています。 簡素化の目的について、出来事への変化は「引き金の特性」について言及します。 すなわち、開始時刻や、位置や、期日("VTODO"カレンダーコンポーネントの部品のための)やことによると記述などの実質的な影響をミーティング自体に与える特性。
"Organizer" initiated actions:
「オーガナイザー」は行動を開始しました:
. "Organizer" deletes or changes a single instance of a recurring
event
. "Organizer" makes changes that affect all future instances
. "Organizer" makes changes that affect all previous instances
. "Organizer" deletes or modifies a previously changed instance
「オーガナイザー」は、繰り返し起こる事柄のただ一つの例を削除するか、または変えます。「オーガナイザー」はすべての将来の例に影響する変更を行います。「オーガナイザー」は前のすべての例に影響する変更を行います。. 「オーガナイザー」は、以前に変えられた例を、削除するか、または変更します。
"Attendee" initiated actions:
「出席者」は行動を開始しました:
. "Attendee" changes status for a particular recurrence instance
. "Attendee" sends Event-Counter for a particular recurrence
instance
「出席者」は特定の再発例のために状態を変えます。. 「出席者」は特定の再発例のためにEvent-カウンタを送ります。
An instance of a recurring event is assigned a unique identification, "RECURRENCE-ID" property, when that instance is renegotiated. Negotiation may be necessary when a substantive change to the event or to-do has be made (such as changing the start time, end time, due date or location). The "Organizer" can identify a specific recurrence instance using the "RECURRENCE-ID" property. The property value is equal to the date/time of the instance. If the "Organizer" wishes to change the "DTSTART", the original "DTSTART" value is used for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. Note that after the change has occurred, the "RECURRENCE-ID" has changed to the new "DTSTART" value.
その例が再交渉されるとき、ユニークな識別、「RECURRENCE ID」の特性は繰り返し起こる事柄の例に割り当てられます。 出来事か大騒ぎへの実質的な変更が行われたなら、交渉が必要であるかもしれません(開始時刻、終わりの時間、期日または位置を変えなどなどの)。 「オーガナイザー」は、「RECURRENCE ID」の特性を使用することで特定の再発例を特定できます。 資産価値は例の日付/時間と等しいです。 「オーガナイザー」が"DTSTART"を変えたいなら、元の"DTSTART"値は「RECURRENCE ID」の特性に使用されます、そして、新しい"DTSTART"と"DTEND"値は変化を反映します。 変化が起こった後に「RECURRENCE ID」が新しい"DTSTART"値に変化したことに注意してください。
3.7.2 Attendee Property Considerations
3.7.2 出席者特性の問題
The "ORGANIZER" property is required on published events, to-dos, and journal entries for two reasons. First, only the "Organizer" is allowed to update and redistribute an event or to-do component. It follows that the "ORGANIZER" property MUST be present in the event, to-do, or journal entry component so that the CUA has a basis for
「オーガナイザー」の特性が2つの理由のための発行された出来事、大騒ぎ、および仕訳記入のときに必要です。 まず最初に、出来事か大騒ぎコンポーネントをアップデートして、「オーガナイザー」だけ、が再配付できます。 「オーガナイザー」の特性が出来事、大騒ぎ、またはクーアには基礎がある仕訳記入のコンポーネントのそうに存在していなければならないということになります。
Silverberg, et. al. Standards Track [Page 58] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[58ページ]。
authorizing an update. Second, it is prudent to provide a point of contact for anyone who receives a published component in case of problems.
アップデートを認可します。 2番目に、問題の場合に発行されたコンポーネントを受け取るだれにも連絡先を提供するのは慎重です。
There are valid [RFC-822] addresses that represent groups. Sending email to such an address results in mail being sent to multiple recipients. Such an address may be used as the value of an "ATTENDEE" property. Thus, it is possible that the recipient of a "REQUEST" does not appear explicitly in the list.
グループを代表する有効な[RFC-822]アドレスがあります。 そのようなアドレスにメールを送ると、複数の受取人に送られるメールはもたらされます。 そのようなアドレスは「出席者」属性の価値として使用されるかもしれません。 したがって、「要求」の受取人がリストに明らかに現れないのは、可能です。
It is recommended that the general approach to finding a "Calendar User" in an attendee list be as follows:
出席者リストで「カレンダーユーザ」を見つけることへの一般的方法は以下の通りは、お勧めです:
1. Search for the "Calendar User" in the attendee list where
"TYPE=INDIVIDUAL"
1. 「タイプは個人と等しい」出席者リストの「カレンダーユーザ」の検索
2. Failing (1) look for attendees where "TYPE=GROUP" or
'TYPE=UNKNOWN". The CUA then determines if the "Calendar User"
is a member of one of these groups. If so, the "REPLY" method
sent to the "Organizer" MUST contain a new "ATTENDEE" property in
which:
. the "type" property parameter is set to INDIVIDUAL
. the "member" property parameter is set to the name of the
group
2. 「(1)に失敗して、「タイプ=は分類するところ」で出席者を探しなさいか、'=未知をタイプしてください」。' そして、CUAは、「カレンダーユーザ」がこれらのグループの1つのメンバーであるかどうか決定します。 そうだとすれば、「オーガナイザー」に送られた「回答」方法が中に新しい「出席者」の特性を含まなければならない、どれ、: . 「タイプ」特性のパラメタはINDIVIDUALに設定されます。「メンバー」特性のパラメタはグループの名前に設定されます。
3. Failing (2) the CUA MAY ignore or accept the request as the
"Calendar User" wishes.
3. (2) CUA MAYに失敗して、「カレンダーユーザ」が願っているように、要求を無視するか、または受け入れてください。
3.7.3 X-Tokens
3.7.3 X-象徴
To make iCalendar objects extensible, new property types MAY be inserted into components. These properties are called X-Tokens as they are prefixed with "X-". A client is not required to make sense of X-Tokens. Clients are not required to save X-Tokens or use them in replies.
iCalendar物を広げることができて、新しい特性にするように、タイプはコンポーネントに挿入されるかもしれません。 それらが「X」と共に前に置かれているとき、これらの特性はX-象徴と呼ばれます。 クライアントは、X-象徴を理解できるのに必要ではありません。 クライアントは、X-象徴を取っておくか、または回答にそれらを使用する必要はありません。
4 Examples
4つの例
4.1 Published Event Examples
4.1 発行されたイベントの例
In the calendaring and scheduling context, publication refers to the one way transfer of event information. Consumers of published events simply incorporate the event into a calendar. No reply is expected. Individual "A" publishes an event. Individual "B" reads the event and incorporates it into their calendar. Events are published in several ways including: embedding the event as an object in a web page, e- mailing the event to a distribution list, and posting the event to a newsgroup.
calendaringとスケジューリング文脈では、公表はイベント情報の一方通行の転送について言及します。 発行された出来事の消費者は単に出来事をカレンダーに組み入れます。 回答は全く予想されません。 個人「A」は出来事を発行します。 個人「B」は、出来事を読み込んで、それらのカレンダーにそれを組み入れます。 発行されて、:出来事はいくつかの方法で発行されます。 出来事を埋め込む、aウェブページ、電子郵送で発送先リストに出来事を反対させて、出来事を掲示するのをニュースグループに反対させてください。
Silverberg, et. al. Standards Track [Page 59] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[59ページ]。
The table below illustrates the sequence of events between the publisher and the consumers of a published event.
以下のテーブルは発行された出来事の出版社と消費者の間の出来事の系列を例証します。
+-------------------------------------------------------------------+ | Action | "Organizer" | +---------------------------------+---------------------------------+ | Publish an event | "A" sends or posts a PUBLISH | | | message | +---------------------------------+---------------------------------+ | "B" reads a published event | | +---------------------------------+---------------------------------+ | Publish an updated event | "A" sends or posts a PUBLISH | | | message | +---------------------------------+---------------------------------+ | "B" reads the updated event | | +---------------------------------+---------------------------------+ | Cancel a published event | "A" sends or posts a CANCEL | | | message | +---------------------------------+---------------------------------+ | "B" reads the canceled event | | | publication | | +---------------------------------+---------------------------------+
+-------------------------------------------------------------------+ | 動作| 「オーガナイザー」| +---------------------------------+---------------------------------+ | 出来事を発行してください。| 「A」は、PUBLISHを送るか、または掲示します。| | | メッセージ| +---------------------------------+---------------------------------+ | 「B」は発行された出来事を読みます。| | +---------------------------------+---------------------------------+ | アップデートされた出来事を発行してください。| 「A」は、PUBLISHを送るか、または掲示します。| | | メッセージ| +---------------------------------+---------------------------------+ | 「B」はアップデートされた出来事を読みます。| | +---------------------------------+---------------------------------+ | 発行された出来事を取り消してください。| 「A」は、キャンセルを送るか、または掲示します。| | | メッセージ| +---------------------------------+---------------------------------+ | 「B」は取り消された出来事を読みます。| | | 公表| | +---------------------------------+---------------------------------+
4.1.1 A Minimal Published Event
4.1.1 最小量の発行された出来事
The iCalendar object below describes a single event that begins on July 1, 1997 at 20:00 UTC. This event contains the minimum set of properties for a "PUBLISH" for a "VEVENT" calendar component.
以下のiCalendar物は1997年7月1日協定世界時20時0分に始まる単一の出来事について説明します。 この出来事は"VEVENT"カレンダーコンポーネントのための「発行してください」のための最小の特性を含んでいます。
BEGIN:VCALENDAR METHOD:PUBLISH PRODID:-//ACME/DesktopCalendar//EN VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTART:19970701T200000Z DTSTAMP:19970611T190000Z SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES UID:0981234-1234234-23@example.com END:VEVENT END:VCALENDAR
始まってください: VCALENDAR方法: PRODID: -//ACME/DesktopCalendar//ENバージョンを発行してください: 2.0は始まります: VEVENTオーガナイザー:mailto: a@example.com DTSTART:19970701T200000Z DTSTAMP:19970611T190000Z概要: セントポールセインツダルース-上司はUID: 0981234-1234234-23@example.com エンド: VEVENTエンド: VCALENDARを殴ります。
4.1.2 Changing A Published Event
4.1.2 発行された出来事を変えること。
The iCalendar object below describes an update to the event described in 4.1.1, the time has been changed, an end time has been added, and the sequence number has been adjusted.
以下のiCalendar物が中で説明された出来事にアップデートについて説明する、4.1、.1、時間を変えて、終わりの時間を加えて、一連番号を調整しました。
Silverberg, et. al. Standards Track [Page 60] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[60ページ]。
BEGIN:VCALENDAR METHOD:PUBLISH VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTAMP:19970612T190000Z DTSTART:19970701T210000Z DTEND:19970701T230000Z SEQUENCE:1 UID:0981234-1234234-23@example.com SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES END:VEVENT END:VCALENDAR
始まってください: VCALENDAR方法: バージョン: 2.0PRODIDを発行してください: -//ACME/DesktopCalendar//ENは始まります: VEVENTオーガナイザー:mailto: a@example.com DTSTAMP: 19970612T190000Z DTSTART:19970701T210000Z DTEND:19970701T230000Z系列: 1UID: 0981234-1234234-23@example.com 概要: セントポールセインツダルース-上司は終わり: VEVENTエンド: VCALENDARを殴ります。
The "UID" property is used by the client to identify the event. The "SEQUENCE" property indicates that this is a change to the event. The event with a matching UID and sequence number 0 is superseded by this event.
"UID"の特性は、出来事を特定するのにクライアントによって使用されます。 「系列」の特性は、これが出来事への変化であることを示します。 合っているUIDと一連番号0がある出来事はこの出来事によって取って代わられます。
The "SEQUENCE" property provides a reliable way to distinguish different versions of the same event. Each time an event is published, its sequence number is incremented. If a client receives an event with a sequence number 5 and finds it has the same event with sequence number 2, the event SHOULD be updated. However, if the client received an event with sequence number 2 and finds it already has sequence number 5 of the same event, the event MUST NOT be updated.
「系列」の特性は同じ出来事の異なった見解を区別する信頼できる方法を提供します。 出来事が発行されるたびに一連番号は増加されています。 クライアントが一連番号5で出来事を受けて、それを見つけるなら、一連番号2、イベントSHOULDがある同じ出来事をアップデートしましたか? しかしながら、クライアントが、一連番号2で出来事を受けて、それには同じ出来事の一連番号5が既にあるのがわかるなら、出来事をアップデートしてはいけません。
4.1.3 Canceling A Published Event
4.1.3 発行された出来事を取り消すこと。
The iCalendar object below cancels the event described in 4.1.1. This cancels the event with "SEQUENCE" property of 0, 1, and 2.
出来事が4.1で.1に説明したキャンセルの下におけるiCalendar物 これは0、1、および2の「系列」の特性で出来事を取り消します。
BEGIN:VCALENDAR METHOD:CANCEL VERSION:2.0 PRODID:-//ACME/DesktopCalendar//EN BEGIN:VEVENT ORGANIZER:mailto:a@example.com COMMENT:DUKES forfeit the game SEQUENCE:2 UID:0981234-1234234-23@example.com DTSTAMP:19970613T190000Z END:VEVENT END:VCALENDAR
BEGIN: VCALENDAR METHOD: キャンセルバージョン: 2.0PRODID:-//ACME/DesktopCalendar//EN BEGIN:VEVENT ORGANIZER:mailto: a@example.com COMMENT: DUKESはSEQUENCE: 2UID: 0981234-1234234-23@example.com DTSTAMP: ゲーム19970613T190000Z END:VEVENT END:VCALENDARを没収させます。
Silverberg, et. al. Standards Track [Page 61] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[61ページ]。
4.1.4 A Rich Published Event
4.1.4 豊かな発行された出来事
This example describes the same event as in 4.1.1, but in much greater detail.
この例が4.1で同じ出来事を記述する、.1、はるかにすばらしい詳細
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:PUBLISH
SCALE:GREGORIAN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:America-Chicago
TZURL:http://zones.stds_r_us.net/tz/America-Chicago
BEGIN:STANDARD
DTSTART:19671029T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
TZNAME:CST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870405T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
TZNAME:CDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER:mailto:a@example.com
ATTACH:http://www.dukes.com/
CATEGORIES:SPORTS EVENT,ENTERTAINMENT
CLASS:PRIVATE
DESCRIPTION:MIDWAY STADIUM\n
Big time game. MUST see.\n
Expected duration:2 hours\n
DTEND;TZID=America-Chicago:19970701T180000
DTSTART;TZID=America-Chicago:19970702T160000
DTSTAMP:19970614T190000Z
STATUS:CONFIRMED
LOCATION;VALUE=URI:http://www.midwaystadium.com/
PRIORITY:2
RESOURCES:SCOREBOARD
SEQUENCE:3
SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
UID:0981234-1234234-23@example.com
RELATED-TO:0981234-1234234-14@example.com
BEGIN:VALARM
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: スケール: グレゴリオのバージョンを発行してください: 2.0は始まります: TZURL: VTIMEZONE TZID: アメリカ-シカゴ http://zones.stds_r_us アメリカネット/tz/シカゴBEGIN: STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY; BYDAY=-1SU; BYMONTH=10 TZOFFSETFROM: -0500TZOFFSETTO: -0600TZNAME: CST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY; BYDAY=1SU; BYMONTH=4 TZOFFSETFROM: -0600TZOFFSETTO: -0500TZNAME:CDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER:mailto: a@example.com ATTACH: http://www.dukes.com/ CATEGORIES: SPORTS EVENT、ENTERTAINMENT CLASS: 兵士のDESCRIPTION: ミッドウェイのスタジアム\n Big時間ゲーム。 URI: http://www.midwaystadium.com/ PRIORITY: 2RESOURCES: SCOREBOARD SEQUENCE: 3SUMMARY: セントポールセインツダルース-SUPERIOR DUKES UID: 0981234-1234234-23@example.com の関連TO:0981234-1234234-14@example.com BEGIN: .\n Expected持続時間:2時間\n DTEND; アメリカ-シカゴ: TZID=19970701T180000 DTSTART; アメリカシカゴ: TZID=19970702T160000 DTSTAMP:19970614T190000Z STATUS:CONFIRMED LOCATION; VALUE=VALARMは見なければなりません。
Silverberg, et. al. Standards Track [Page 62] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[62ページ]。
TRIGGER:-PT2H ACTION:DISPLAY DESCRIPTION:You should be leaving for the game now. END:VALARM BEGIN:VALARM TRIGGER:-PT30M ACTION:AUDIO END:VALARM END:VEVENT END:VCALENDAR
TRIGGER:-PT2H ACTION:DISPLAY DESCRIPTION: あなたは今、ゲームに向けて発つべきです。 : VALARMが始まる終わり: 終わり: VALARMエンド: VEVENTエンド: VALARM引き金: -PT30M動作: オーディオVCALENDAR
The "RELATED-TO" field contains the "UID" property of a related calendar event. The "SEQUENCE" property 3 indicates that this event supersedes versions 0, 1, and 2.
「関連された」という分野は関連するカレンダーイベントの"UID"の特性を含んでいます。 「系列」特性3は、この出来事がバージョン0、1、および2に取って代わるのを示します。
4.1.5 Anniversaries or Events attached to entire days
4.1.5 全体の日に取り付けられた記念日かEvents
This example demonstrates the use of the "value" parameter to tie a "VEVENT" to day rather than a specific time.
この例は、特定の時間よりむしろ日に"VEVENT"を結ぶために「値」パラメタの使用を示します。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:PUBLISH VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTAMP:19970614T190000Z UID:0981234-1234234-23@example.com DTSTART;VALUE=DATE:19970714 RRULE:FREQ=YEARLY;INTERVAL=1 SUMMARY: Bastille Day END:VEVENT END:VCALENDAR
2.0は始まります: VEVENTオーガナイザー:mailto: a@example.com DTSTAMP:19970614T190000Z UID: 0981234-1234234-23@example.com DTSTART、始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを発行してください: 値は= 毎年DATE:19970714 RRULE: FREQと等しいです; 間隔は1つの概要と等しいです: 革命記念日の終わり: VEVENTエンド: VCALENDAR
4.2 Group Event Examples
4.2 グループイベントの例
Group events are distinguished from published events in that they have "Attendees" and that there is interaction between the "Attendees" and the "Organizer" with respect to the event. Individual "A" requests a meeting between individuals "A", "B", "C" and "D". Individual "B" confirms attendance to the meeting. Individual "C" declines attendance. Individual "D" tentatively confirms attendance. The following table illustrates the the message flow between these individuals. A, the CU scheduling the meeting, is referenced as the "Organizer".
それらには「出席者」があるので、グループイベントは発行された出来事と区別されます、そして、出来事に関して「出席者」と「オーガナイザー」との相互作用があります。 個人「A」は個人「A」、「B」、「C」、および「D」の間のミーティングを要求します。 個人「B」はミーティングへの出席を確認します。 個人「C」は出席を低下させます。 個人「D」は試験的に出席を確認します。 以下のテーブルはこれらの個人の間のメッセージ流動を例証します。 A(ミーティングの計画をするCU)は「オーガナイザー」として参照をつけられます。
Silverberg, et. al. Standards Track [Page 63] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[63ページ]。
+---------------------------------------------------------------------+ | Action | "Organizer" | Attendee | +---------------------------------------------------------------------+ | Initiate a meeting | "A" sends a REQUEST | | | request | message to "B", "C",| | | | and "D" | | +---------------------------------------------------------------------+ | Accept the meeting | | "B" sends a REPLY | | request | | message to "A" with its | | | | ATTENDEE "partstat" para-| | | | set to "accepted" | +---------------------------------------------------------------------+ | Decline the meeting| | "C" sends a REPLY | | request | | message to "A" with its | | | | ATTENDEE "partstat" para-| | | | set to "declined" | +---------------------------------------------------------------------+ | Tentatively accept | | "D" sends a REPLY | | the meeting request| | message to "A" with its | | | | ATTENDEE "partstat" para-| | | | set to "tentative" | +---------------------------------------------------------------------+ | Confirm meeting | "A" sends a REQUEST | | | status with | message to "B" and | | | attendees | "D" with updated | | | | information. | | +---------------------------------------------------------------------+
+---------------------------------------------------------------------+ | 動作| 「オーガナイザー」| 出席者| +---------------------------------------------------------------------+ | ミーティングを開始してください。| 「A」はREQUESTを送ります。| | | 要求| 「B」、「C」へのメッセージ| | | | そして、「D」| | +---------------------------------------------------------------------+ | ミーティングを受け入れてください。| | 「B」は返信します。| | 要求| | 「A」へ通信する、それ| | | | ATTENDEE"partstat"パラ| | | | 「受け入れられること」に、セットします。| +---------------------------------------------------------------------+ | ミーティングを断ってください。| | 「C」は返信します。| | 要求| | 「A」へ通信する、それ| | | | ATTENDEE"partstat"パラ| | | | 「傾けられること」に、セットします。| +---------------------------------------------------------------------+ | 試験的に受け入れてください。| | 「D」は返信します。| | ミーティング要求| | 「A」へ通信する、それ| | | | ATTENDEE"partstat"パラ| | | | 「一時的に」、セットします。| +---------------------------------------------------------------------+ | ミーティングを確認してください。| 「A」はREQUESTを送ります。| | | 状態| そして「B」へのメッセージ。| | | 出席者| アップデートされるのがある「D」| | | | 情報。 | | +---------------------------------------------------------------------+
4.2.1 A Group Event Request
4.2.1 グループイベント要求
A sample meeting request is sent from "A" to "B", "C", and "D". _E_ is also sent a copy of the request but is not expected to attend and need not reply. "E" illustrates how CUAs might implement an "FYI" type feature. Note the use of the "role" parameter. The default value for the "role" parameter is "req-participant" and it need not be enumerated. In this case we are using the value "non-participant" to indicate "E" is a non-attending CU. The parameter is not needed on other "Attendees" since "participant" is the default value.
「B」、「C」、および「A」から「D」にサンプルミーティング要求を送ります。 _E_はまた、要求のコピーを送りますが、出席しないと予想されて、返答する必要はありません。 「E」はCUAsがどう"FYI"タイプ機能を実行するかもしれないかを例証します。 「役割」パラメタの使用に注意してください。 「役割」パラメタのためのデフォルト値は「req関与しています」、そして、それは列挙される必要はありません。 この場合、私たちは「E」が非出席Cuであることを示すためには「非関係者」の値を使用しています。 パラメタは「関係者」以来他の「出席者」で必要でないのが、デフォルト値であるということです。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを要求してください: 2.0は始まります: VEVENTオーガナイザー:Mailto: A@example.com 出席者; ROLE=議長; PARTSTAT=は、; 大きいA:CN=Mailto: A@example.com 出席者;RSVP=が本当であると受け入れました; = 本当に=個人; CN=B:Mailto: B@example.com 出席者; RSVPをタイプしてください; =個人をタイプしてください; CNはC:Mailto: C@example.com と等しいです。
Silverberg, et. al. Standards Track [Page 64] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[64ページ]。
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T2000000Z SUMMARY:Conference UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR
出席者; RSVP=; タイプ=個人;本当のCN=ハル:Mailto: D@example.com 出席者; RSVPが誤った; 余地: conf_Big@example.com タイプ=出席者;役割=と等しい、非、-、関与、;RSVPは偽:Mailto: E@example.com DTSTAMP: 19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T2000000Z概要: コンファレンスUID: calsrv.example.com-873970198738777@example.com 系列: 0状態と等しいです: 終わり: VEVENTエンド: VCALENDARを確認する
4.2.2 Reply To A Group Event Request
4.2.2 グループイベント要求に答えてください。
Attendee "B" accepts the meeting.
出席者「B」はミーティングを受け入れます。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com ORGANIZER:MAILTO:A@example.com UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 REQUEST-STATUS:2.0;Success DTSTAMP:19970612T190000Z END:VEVENT END:VCALENDAR
VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: 回答バージョン: 2.0は始まります: VEVENT出席者、PARTSTAT=は受け入れました: Mailto: B@example.com オーガナイザー:MAILTO: A@example.com UID: calsrv.example.com-873970198738777@example.com 系列: 0要求状態: 2.0、始まってください: 成功DTSTAMP: 19970612T190000Zは終わります: VEVENTは: VCALENDARを終わらせます。
"B" could have declined the meeting or indicated tentative acceptance by setting the "ATTENDEE" "partstat" parameter to "declined" or "tentative", respectively. Also, "REQUEST-STATUS" is not required in successful transactions.
「B」は、それぞれ「傾けられる」か「一時的である」「出席者」"partstat"パラメタを設定することによって、ミーティングを断ったか、または一時的な承認を示したかもしれません。 また、「要求状態」はうまくいっている取引で必要ではありません。
4.2.3 Update An Event
4.2.3 出来事をアップデートしてください。
The event is moved to a different time. The combination of the "UID" property (unchanged) and the "SEQUENCE" (bumped to 1) properties indicate the update.
出来事はいろいろな時間まで動かされます。 "UID"の特性(変わりのない)と「系列」(1に突き当たられている)の特性の組み合わせはアップデートを示します。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを要求してください: 2.0は: VEVENTオーガナイザー:Mailto: A@example.com を始めます。
Silverberg, et. al. Standards Track [Page 65] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[65ページ]。
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
CUTYPE=ROOM:Mailto:Conf@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
DTSTART:19970701T180000Z
DTEND:19970701T190000Z
SUMMARY:Phone Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1
DTSTAMP:19970613T190000Z
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
役割が= 本当に議長; =が受け入れたPARTSTAT: Mailto: A@example.com 出席者; RSVPと等しいというRSVPが= 本当に; タイプ=個人:Mailto: C@example.com 出席者;本当のRSVPと等しいというタイプ=個人:Mailto: B@example.com 出席者が個人; CN=ハル:Mailto: D@example.com 出席者; 役割=と等しいのをタイプする出席者、非、-、関係者; RSVPは偽と等しいです。 CUTYPEが余地:Mailto: Conf@example.com 出席者; 役割=と等しい、非、-、関与、;RSVPは偽:Mailto: E@example.com DTSTART:19970701T180000Z DTEND:19970701T190000Z概要と等しいです: コンファレンスUID: calsrv.example.com-873970198738777@example.com 系列: 1DTSTAMP: 19970613T190000Z状態: 確認された終わり: VEVENTエンド: VCALENDARに電話をしてください
4.2.4 Countering an Event Proposal
4.2.4 イベント提案に対抗すること。
"A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to "A" to change the time and location.
「A」は「B」と「C」に「要求」を送ります。 「B」は、時間と位置を変えるために対案を「A」にします。
"A" sends the following "REQUEST":
「A」は以下の「要求」を送ります:
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com DTSTART:19970701T190000Z DTEND:19970701T200000Z SUMMARY:Discuss the Merits of the election results LOCATION:Green Conference Room UID:calsrv.example.com-873970198738777a@example.com SEQUENCE:0 DTSTAMP:19970611T190000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
VEVENTオーガナイザー:Mailto: A@example.com 出席者; ROLE=議長; PARTSTAT=は受け入れました: Mailto: A@example.com 出席者、始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを要求してください: 2.0は始まります: RSVPは= 本当に; タイプ=個人:Mailto: B@example.com 出席者;本当のRSVPと等しいです; タイプ=個人:Mailto: C@example com DTSTART:19970701T190000Z DTEND:19970701T200000Z SUMMARY: LOCATION: グリーンコンファレンスRoom UID: calsrv.example.com-873970198738777a@example.com SEQUENCE: 0DTSTAMP: 選挙結果19970611T190000Z STATUSのMerits: CONFIRMED END:VEVENT END:VCALENDARについて議論してください。
"B" sends "COUNTER" to "A", requesting changes to time and place. "B" uses the "COMMENT" property to communicate a rationale for the change. Note that the "SEQUENCE" property is NOT incremented on a "COUNTER".
時間と場所への変化を要求して、「B」は「反対に」「A」に発信します。 「B」は、変化のために原理を伝えるのに「コメント」の特性を使用します。 「系列」の特性が「カウンタ」で増加されないことに注意してください。
Silverberg, et. al. Standards Track [Page 66] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[66ページ]。
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:COUNTER
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
DTSTART:19970701T160000Z
DTEND:19970701T190000Z
DTSTAMP:19970612T190000Z
SUMMARY:Discuss the Merits of the election results
LOCATION:Green Conference Room
COMMENT:This time works much better and I think the big conference
room is too big
UID:calsrv.example.com-873970198738777a@example.com
SEQUENCE:0
DTSTAMP:19970611T190000Z
END:VEVENT
END:VCALENDAR
VEVENTオーガナイザー:Mailto: A@example.com 出席者; ROLE=議長; PARTSTAT=は受け入れました: Mailto: A@example.com 出席者、始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを打ち返してください: 2.0は始まります: RSVPは= 本当に; タイプ=個人:Mailto: B@example.com 出席者;本当のRSVPと等しいです; タイプ=個人:Mailto: C@example com DTSTART:19970701T160000Z DTEND:19970701T190000Z DTSTAMP: 19970612T190000Z SUMMARY: LOCATION:グリーンコンファレンスRoom COMMENT:この時間がたくさんうまくいって、私が、大きい会議室が大き過ぎるUIDであると考えるという選挙結果: calsrv.example.com-873970198738777a@example.com SEQUENCE: 0DTSTAMP: 19970611T190000Z END:VEVENT END:VCALENDARのMeritsについて議論してください。
"A" accepts the changes from "B". To accept a counter-proposal, the "Organizer" sends a new event "REQUEST" with an incremented sequence number.
「A」は「B」からの変化を受け入れます。 対案を受け入れるために、「オーガナイザー」は増加している一連番号と共に新しいイベント「要求」を送ります。
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
DTSTAMP:19970613T190000Z
DTSTART:19970701T160000Z
DTEND:19970701T190000Z
SUMMARY:Discuss the Merits of the election results - changed to
meet B's schedule
LOCATION:Green Conference Room
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:1
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
VEVENTオーガナイザー:Mailto: A@example.com 出席者; ROLE=議長; PARTSTAT=は受け入れました: Mailto: A@example.com 出席者、始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを要求してください: 2.0は始まります: RSVPは= 本当に; タイプ=個人:Mailto: B@example.com 出席者;本当のRSVPと等しいです; タイプ=個人:Mailto: C@example com DTSTAMP:19970613T190000Z DTSTART:19970701T160000Z DTEND: 19970701T190000Z SUMMARY: 選挙結果--変えるMeritsについて議論して、ビーズスケジュールLOCATION: グリーンコンファレンスRoom UID: calsrv.example.com-873970198738777@example.com SEQUENCE: 1STATUS: CONFIRMED END:VEVENT END:VCALENDARに会ってください。
Instead, "A" rejects "B's" counter proposal
代わりに廃棄物「ビーズ」対案
Silverberg, et. al. Standards Track [Page 67] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[67ページ]。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:DECLINECOUNTER VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com COMMENT:Sorry, I cannot change this meeting time UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 DTSTAMP:19970614T190000Z END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD: DECLINECOUNTER VERSION: 2.0 BEGIN:VEVENT ORGANIZER:Mailto: A@example.com ATTENDEE; RSVP=TRUE; TYPE=INDIVIDUAL:Mailto: B@example.com COMMENT: すみません、私はこのミーティング時間にUID: calsrv.example.com-873970198738777@example.com SEQUENCE: 0DTSTAMP:19970614T190000Z END:VEVENT ENDを変えることができません:、VCALENDAR
4.2.5 Delegating an Event
4.2.5 出来事を代表として派遣すること。
When delegating an event request to another "Calendar User", the "Delegator" must both update the "Organizer" with a "REPLY" and send a request to the "Delegate". There is currently no protocol limitation to delegation depth. It is possible for the original
別の「カレンダーユーザ」へイベント要求を代表として派遣するとき、"Delegator"は、「回答」で「オーガナイザー」をアップデートして、「代表」に要求を送らなければなりません。 現在、代表団の深さへのプロトコル制限が全くありません。 オリジナルに、それは可能です。
delegate to delegate the meeting to someone else, and so on. When a request is delegated from one CUA to another there are a number of responsibilities required of the "Delegator". The "Delegator" MUST:
他の誰かなどへミーティングを代表として派遣するのを代表として派遣します。 1CUAから別のCUAまで要求を代表として派遣するとき、"Delegator"について必要である多くの責任があります。 "Delegator"はそうしなければなりません:
. Send a "REPLY" to the "Organizer" with the following updates:
. The "Delegator's" "ATTENDEE" property "partstat" parameter set
to "delegated" and the "delegated-to" parameter is set to the
address of the "Delegate"
. Add an additional "ATTENDEE" property for the "Delegate" with
the "delegated-from" property parameter set to the "Delegator"
. Indicate whether they want to continue to receive updates when
the "Organizer" sends out updated versions of the event.
Setting the "rsvp" property parameter to "TRUE" will cause the
updates to be sent, setting it to "FALSE" causes no further
updates to be sent. Note that in either case, if the "Delegate"
declines the invitation the "Delegator" will be notified.
. The "Delegator" MUST also send a copy of the original "REQUEST"
method to the "Delegate".
. 以下のアップデートと共に「回答」を「オーガナイザー」に送ってください: . "Delegator"の「出席者」特性の"partstat"パラメタは「代表として派遣されること」にセットしました、そして、「委任されて」パラメタは「代表」のアドレスに設定されます。特性のパラメタは"Delegator"にセットしました。「代表」のために追加「出席者」の特性を追加してください、「代表として派遣する、-、」 彼らが、「オーガナイザー」が出すとき、アップデートを受け続けたがっているかどうかが出来事のバージョンをアップデートしたのを示してください。 「本当」のウィルに"rsvp"特性のパラメタを設定して、アップデートが送られることを引き起こしてください、いいえが送るためにさらにアップデートする「誤った」原因にそれを設定して。 「代表」が招待を断つとどちらの場合ではも、"Delegator"に通知することに注意してください。 . また、"Delegator"は謄本「要求」方法を「代表」に送らなければなりません。
It is not required that the "Delegate" include the "Delegator" in their "REPLY" method. However, it is strongly advised since this will inform the "Delegator" whether the "Delegate" plans to attend the meeting. [Editors note: How so?] If the "Delegate" declines the meeting, the "Delegator" may elect to delegate the "REQUEST" to another CUA. The process is the same.
「代表」がそれらの「回答」方法に"Delegator"を含むのが必要ではありません。 しかしながら、これが、「代表」が、ミーティングに出席するのを計画しているかどうかを"Delegator"に知らせるので、それは強くアドバイスされます。 [したがって、エディターズは: その方法に注意します]? 「代表」がミーティングを断つなら、"Delegator"は、「要求」を別のクーアへ代表として派遣するのを選ぶかもしれません。 過程は同じです。
Silverberg, et. al. Standards Track [Page 68] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[68ページ]。
+---------------------------------------------------------------------+ | Action | "Organizer" | Attendee | +---------------------------------------------------------------------+ | Initiate a meeting | "A" sends a REQUEST | | | request | message to "B" and | | | | "C" | | +---------------------------------------------------------------------+ | Delegate: | | "C" sends a REPLY to "A" | | "C" delegates to | | with the ATTENDEE. | | "E" | | "partstat" parameter set | | | | to "delegated" and with a| | | | new "ATTENDEE" property | | | | for "E". "E's" ATTENDEE | | | | "delegated-from" param | | | | is set to "C". "C's" | | | | ATTENDEE "delegated-to" | | | | param is set to "E". | | | | "C" sends REQUEST message| | | | to "E" with the original | | | | meeting request | | | | information. The | | | | "partstat" property | | | | parameter for "C" is set | | | | to "delegated" and the | | | | "delegated-to" | | | | parameter is set to | | | | the address of "E". An | | | | "ATTENDEE" property is | | | | added for "E" and the | | | | "delegated-from" | | | | parameter is set to | | | | the address of "C". | +---------------------------------------------------------------------+ | Confirm meeting | | "E" sends REPLY message | | attendance | | to "A" and optionally "C"| | | | with its "partstat" | | | | property parameter set | | | | to "ACCEPTED" | +---------------------------------------------------------------------+ | Optional: | "A" sends REQUEST | | | Redistribute | message to "B", "C" | | | meeting to | and "E". | | | attendees | | | +---------------------------------------------------------------------+
+---------------------------------------------------------------------+ | 動作| 「オーガナイザー」| 出席者| +---------------------------------------------------------------------+ | ミーティングを開始してください。| 「A」はREQUESTを送ります。| | | 要求| そして「B」へのメッセージ。| | | | 「C」| | +---------------------------------------------------------------------+ | 以下を代表として派遣してください。 | | 「C」は「A」に返信します。| | 「C」は委任します。| | 出席者と共に。 | | 「E」| | "partstat"パラメタセット| | | | 「代表として派遣されること」とa| | | | 新しい「出席者」の特性| | | | 「E」のために。 「E」の出席者| | | | 「代表として派遣する、-、」 param| | | | 「C」に設定されます。 「Cのもの」| | | | 「委任される」出席者| | | | paramは「E」に用意ができています。 | | | | 「C」はREQUESTメッセージを送ります。| | | | オリジナルがある「E」に| | | | ミーティング要求| | | | 情報。 The| | | | "partstat"の特性| | | | 「C」パラメタは設定されます。| | | | そして「代表として派遣される」。| | | | 「委任されます」。| | | | パラメタは設定されます。| | | | 「E」のアドレス。 1| | | | "ATTENDEE"の特性はそうです。| | | | そして「E」で加えられる。| | | | 「代表として派遣する、-、」| | | | パラメタは設定されます。| | | | 「C」のアドレス。 | +---------------------------------------------------------------------+ | ミーティングを確認してください。| | 「E」はREPLYメッセージを送ります。| | 出席| | 「A」と任意に「C」に| | | | "partstat"で| | | | 特性のパラメタセット| | | | 「受け入れたこと」に| +---------------------------------------------------------------------+ | 任意: | 「A」はREQUESTを送ります。| | | 再配付します。| 「B」、「C」へのメッセージ| | | 会います。| そして、「E。」 | | | 出席者| | | +---------------------------------------------------------------------+
Silverberg, et. al. Standards Track [Page 69] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[69ページ]。
"C" responds to the "Organizer".
「C」は「オーガナイザー」に応じます。
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:MAILTO:A@Example.com
ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
TO="Mailto:E@example.com":Mailto:C@example.com
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
REQUEST-STATUS:2.0;Success
DTSTAMP:19970611T190000Z
END:VEVENT
END:VCALENDAR
VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: 回答バージョン: 2.0は始まります: 「Mailto: E@example.com 」と等しいのが代表として派遣されたVEVENTオーガナイザー:MAILTO: A@Example.com 出席者(代表として派遣されたPARTSTAT=): Mailto: C@example.com UID: calsrv.example.com-873970198738777@example.com 系列: 0要求状態: 2.0、始まってください: 成功DTSTAMP: 19970611T190000Zは終わります: VEVENTは: VCALENDARを終わらせます。
Attendee "C" delegates presence at the meeting to "E".
「E」へのミーティングにおける出席者「C」代表存在。
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
TO="Mailto:E@example.com":Mailto:C@example.com
ATTENDEE;RSVP=TRUE;
DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
DTSTART:19970701T180000Z
DTEND:19970701T200000Z
SUMMARY:Phone Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
STATUS:CONFIRMED
DTSTAMP:19970611T190000Z
END:VEVENT
END:VCALENDAR
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: 本当に: 2.0が始めるバージョン: 「Mailto: E@example.com 」と等しいのが代表として派遣されたVEVENTオーガナイザー:Mailto: A@example.com 出席者(代表として派遣されたPARTSTAT=): Mailto: C@example.com 出席者; RSVP=を要求してください。 代表として派遣する、-=「Mailto: C@example.com 」から: Mailto: E@example.com DTSTART:19970701T180000Z DTEND:19970701T200000Z概要: コンファレンスUID: calsrv.example.com-873970198738777@example.com 系列: 0状態: 確認されたDTSTAMP: 19970611T190000Zエンド: VEVENTエンド: VCALENDARに電話をしてください。
4.2.6 Delegate Accepts the Meeting
4.2.6 代表はミーティングを受け入れます。
To accept a delegated meeting, the delegate, "E", sends the following message to "A" and "C":
代表として派遣されたミーティングを受け入れるために、「E」という代表は「A」と「C」に以下のメッセージを送ります:
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0
VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: 回答バージョン: 2.0に以下を始めてください。
Silverberg, et. al. Standards Track [Page 70] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[70ページ]。
BEGIN:VEVENT
ORGANIZER:MAILTO:A@Example.com
ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
FROM="Mailto:C@example.com":Mailto:E@example.com
ATTENDEE;PARTSTAT=DELEGATED;
DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
REQUEST-STATUS:2.0;Success
DTSTAMP:19970614T190000Z
END:VEVENT
END:VCALENDAR
始まってください: PARTSTAT=が受け入れたというVEVENTオーガナイザー:MAILTO: A@Example.com 出席者は=から「Mailto: C@example.com 」を代表として派遣しました: Mailto: E@example.com 出席者; 代表として派遣されたPARTSTAT= : Mailto: C@example.com UID: calsrv.example.com-873970198738777@example.com が: 0要求状態: 2.0に配列する委任している=「Mailto: E@example.com 」 ; DTSTAMP: 19970614T190000Zエンド: VEVENTエンド: 成功VCALENDAR
4.2.7 Delegate Declines the Meeting
4.2.7代表はミーティングを断ります。
In this example the "Delegate" declines the meeting request and sets the "ATTENDEE" property "partstat" parameter to "DECLINED". The "Organizer" SHOULD resend the "REQUEST" to "C" with the "partstat" parameter of the "Delegate" set to "declined". This lets the "Delegator" know that the "Delegate" has declined and provides an opportunity to the "Delegator" to either accept the request or delegate it to another CU.
この例では、「代表」は、ミーティング要求を断って、「出席者」特性の"partstat"パラメタを「傾けられること」に設定します。 「オーガナイザー」SHOULDは「C」に「傾けられること」に設定された「代表」の"partstat"パラメタで「要求」を再送します。 これで、"Delegator"は、「代表」が要請を受け入れるか、または別のCUへそれを代表として派遣するために"Delegator"に減退して、機会を提供するのを知っています。
Response from "E" to "A" and "C". Note the use of the "COMMENT" property "E" uses to indicate why the delegation was declined.
「E」から「A」と「C」までの応答。 特性「E」が代表団がなぜ衰退したかを示すのに使用する「コメント」の使用に注意してください。
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REPLY
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:MAILTO:A@Example.com
ATTENDEE;PARTSTAT=DELEGATED;
DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
ATTENDEE;PARTSTAT=DECLINED;
DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
COMMENT:Sorry, I will be out of town at that time.
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
REQUEST-STATUS:2.0;Success
DTSTAMP:19970614T190000Z
END:VEVENT
END:VCALENDAR
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: 回答バージョン: 2.0は始まります: VEVENTオーガナイザー:MAILTO: A@Example.com 出席者; 代表として派遣されたPARTSTAT= : Mailto: C@example.com 出席者; PARTSTAT=が傾けた委任している=「Mailto: E@example.com 」。 DELEGATED-FROMはその時、: Mailto: E@example.com COMMENT: すみません、Iがある「Mailto: C@example.com 」町と等しいです。 UID: calsrv.example.com-873970198738777@example.com 系列: 0要求状態: 2.0に、成功DTSTAMP: 19970614T190000Zは終わります: VEVENTは: VCALENDARを終わらせます。
"A" resends the "REQUEST" method to "C". "A" may also wish to express the fact that the item was delegated in the "COMMENT" property.
「A」は「要求」方法を「C」に再送します。 また、「A」は「コメント」所有地で商品を代表として派遣したという事実を言い表したがっているかもしれません。
Silverberg, et. al. Standards Track [Page 71] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[71ページ]。
BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:MAILTO:A@Example.com
ATTENDEE;PARTSTAT=DECLINED;
DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
ATTENDEE;RSVP=TRUE:Mailto:C@example.com
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
SUMMARY:Phone Conference
DTSTART:19970701T180000Z
DTEND:19970701T200000Z
DTSTAMP:19970614T200000Z
COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR
INVITATION
END:VEVENT
END:VCALENDAR
2.0は始まります: VEVENTオーガナイザー:MAILTO: A@Example.com 出席者、始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを要求してください: PARTSTAT=は減退しました。 代表として派遣する、-、=「Mailto: C@example.com 」から:、Mailto: E@example.com 出席者;、RSVP、= 0概要: コンファレンスDTSTARTに電話をしてください: 19970701T180000Z DTEND:19970701T200000Z DTSTAMP:19970614T200000Zはコメントします: 本当に、: Mailto: C@example.com UID: calsrv.example.com-873970198738777@example.com は以下を配列して、代表(出席者Mailto: E@example.com )はあなたの招待終わり: VEVENTエンド: VCALENDARを傾けました。
4.2.8 Forwarding an Event Request
4.2.8 イベント要求を転送すること。
The protocol does not prevent an "Attendee" from "forwarding" an "VEVENT" calendar component to other "Calendar Users". Forwarding differs from delegation in that the forwarded "Calendar User" (often referred to as a "Party Crasher") does not replace the forwarding "Calendar User". Implementations are not required to add the "Party Crasher" to the "Attendee" list and hence there is no guarantee that a "Party Crasher" will receive additional updates to the Event. The forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the attendee list. The "Organizer" MAY add the forwarded "Calendar User" to the attendee list.
プロトコルは、「出席者」が"VEVENT"カレンダーコンポーネントを他の「カレンダーユーザ」に「進めること」を防ぎません。 推進は進められた「カレンダーユーザ」(しばしば「パーティに押し掛ける者」と呼ばれる)が推進「カレンダーユーザ」を取り替えないという点において代表団と異なっています。 実現は「出席者」リストに「パーティに押し掛ける者」を追加するのに必要ではありません、そして、したがって、「パーティに押し掛ける者」が追加アップデートをEventに受けるという保証が全くありません。 推進「カレンダーユーザ」SHOULD NOTは「パーティに押し掛ける者」を出席者リストに追加します。 「オーガナイザー」は進められた「カレンダーユーザ」を出席者リストに追加するかもしれません。
4.2.9 Cancel A Group Event
4.2.9 グループイベントを取り消してください。
Individual "A" requests a meeting between individuals "A", "B", "C", and "D". Individual "B" declines attendance to the meeting. Individual "A" decides to cancel the meeting. The following table illustrates the sequence of messages that would be exchanged between these individuals.
個人「A」は個人「A」、「B」、「C」、および「D」の間のミーティングを要求します。 個人「B」はミーティングへの出席を低下させます。 個人「A」は、会議を中止すると決めます。 以下のテーブルはこれらの個人の間で交換されるメッセージの系列を例証します。
Messages related to a previously canceled event ("SEQUENCE" property
value is less than the "SEQUENCE" property value of the "CANCEL"
message) MUST be ignored.
以前に取り消された出来事(「系列」資産価値は「キャンセル」メッセージの「系列」資産価値より少ない)に関連するメッセージを無視しなければなりません。
Silverberg, et. al. Standards Track [Page 72] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[72ページ]。
+--------------------------------------------------------------------+ | Action | "Organizer" | "Attendee" | +--------------------------------------------------------------------+ | Initiate a meeting | "A" sends a REQUEST | | | request | message to "B", "C",| | | | and "D" | | +--------------------------------------------------------------------+ | Decline the meeting| | "B" sends a "REPLY" | | request | | message to "A" with its | | | | "partstat" para- | | | | set to "declined". | +--------------------------------------------------------------------+ | Cancel the meeting | "A" sends a CANCEL | | | | message to "B", "C" | | | | and "D" | | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | 動作| 「オーガナイザー」| 「出席者」| +--------------------------------------------------------------------+ | ミーティングを開始してください。| 「A」はREQUESTを送ります。| | | 要求| 「B」、「C」へのメッセージ| | | | そして、「D」| | +--------------------------------------------------------------------+ | ミーティングを断ってください。| | 「B」は「回答」を送ります。| | 要求| | 「A」へ通信する、それ| | | | "partstat"パラ| | | | 「傾けられること」にセットしてください。 | +--------------------------------------------------------------------+ | 会議を中止してください。| 「A」はキャンセルを送ります。| | | | 「B」、「C」へのメッセージ| | | | そして、「D」| | +--------------------------------------------------------------------+
The example shows how "A" cancels the event.
例は「A」がどう出来事を取り消すかを示しています。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:CANCEL VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com COMMENT:Mr. B cannot attend. It's raining. Lets cancel. UID:calsrv.example.com-873970198738777@example.com SEQUENCE:1 STATUS:CANCELLED DTSTAMP:19970613T190000Z END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD: キャンセルバージョン: 2.0 BEGIN:VEVENT ORGANIZER:Mailto: A@example.com ATTENDEE; TYPE=INDIVIDUAL; Mailto: A@example.com ATTENDEE; TYPE=INDIVIDUAL:Mailto: B@example.com ATTENDEE; TYPE=INDIVIDUAL:Mailto: C@example.com ATTENDEE; TYPE=INDIVIDUAL:Mailto: D@example.com COMMENT: Bさんは出席できません。 雨が降っています。 取り消させます。 UID: calsrv.example.com-873970198738777@example.com 系列: 1つの状態: 取り消されたDTSTAMP: 19970613T190000Zエンド: VEVENTエンド: VCALENDAR
Silverberg, et. al. Standards Track [Page 73] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[73ページ]。
4.2.10 Removing Attendees
4.2.10 出席者を免職すること。
"A" wants to remove "B" from a meeting. This is done by sending a "CANCEL" to "B" and removing "B" from the attendee list in the master copy of the event.
ミーティングからの「B」を取り除く必需品。 「キャンセル」を「B」に送って、出来事のマスターコピーで出席者リストから「B」を移すことによって、これをします。
+--------------------------------------------------------------------+ | Action | "Organizer" | "Attendee" | +--------------------------------------------------------------------+ | Remove an "B" | "A" sends a CANCEL | | | as an "Attendee" | message to "B" | | +--------------------------------------------------------------------+ | Update the master | "A" sends the | | | copy of the event | updated event to | | | | the remaining | | | | "Attendees" | | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | Action | "Organizer" | "Attendee" | +--------------------------------------------------------------------+ | Remove an "B" | "A" sends a CANCEL | | | as an "Attendee" | message to "B" | | +--------------------------------------------------------------------+ | Update the master | "A" sends the | | | copy of the event | updated event to | | | | the remaining | | | | "Attendees" | | +--------------------------------------------------------------------+
The original meeting includes "A", "B", "C", and "D". The example below shows the "CANCEL" that "A" sends to "B". Note that in the example below the "STATUS" property is omitted. This is used when the meeting itself is cancelled and not when the intent is to remove an "Attendee" from the Event.
The original meeting includes "A", "B", "C", and "D". The example below shows the "CANCEL" that "A" sends to "B". Note that in the example below the "STATUS" property is omitted. This is used when the meeting itself is cancelled and not when the intent is to remove an "Attendee" from the Event.
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:CANCEL VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE:mailto:B@example.com COMMENT:You're off the hook for this meeting UID:calsrv.example.com-873970198738777@example.com DTSTAMP:19970613T193000Z SEQUENCE:1 END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:CANCEL VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE:mailto:B@example.com COMMENT:You're off the hook for this meeting UID:calsrv.example.com-873970198738777@example.com DTSTAMP:19970613T193000Z SEQUENCE:1 END:VEVENT END:VCALENDAR
The updated master copy of the event is shown below. The "Organizer" MAY resend the updated event to the remaining "Attendees". Note that "B" has been removed.
The updated master copy of the event is shown below. The "Organizer" MAY resend the updated event to the remaining "Attendees". Note that "B" has been removed.
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com
Silverberg, et. al. Standards Track [Page 74] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 74] RFC 2446 iTIP November 1998
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
ATTENDEE;TYPE=ROOM:CR_Big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;
RSVP=FALSE:Mailto:E@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z
DTEND:19970701T203000Z
SUMMARY:Phone Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:2
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com ATTENDEE;TYPE=ROOM:CR_Big@example.com ATTENDEE;ROLE=NON-PARTICIPANT; RSVP=FALSE:Mailto:E@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T203000Z SUMMARY:Phone Conference UID:calsrv.example.com-873970198738777@example.com SEQUENCE:2 STATUS:CONFIRMED END:VEVENT END:VCALENDAR
4.2.11 Replacing the Organizer
4.2.11 Replacing the Organizer
The scenario for this example begins with "A" as the "Organizer" for a recurring meeting with "B", "C", and "D". "A" receives a new job offer in another country and drops out of touch. "A" left no forwarding address or way to be reached. Using out-of-band communication, the other "Attendees" eventually learn what has happened and reach an agreement that "B" should become the new "Organizer" for the meeting. To do this, "B" sends out a new version of the event and the other "Attendees" agree to accept "B" as the new "Organizer". "B" also removes "A" from the event.
The scenario for this example begins with "A" as the "Organizer" for a recurring meeting with "B", "C", and "D". "A" receives a new job offer in another country and drops out of touch. "A" left no forwarding address or way to be reached. Using out-of-band communication, the other "Attendees" eventually learn what has happened and reach an agreement that "B" should become the new "Organizer" for the meeting. To do this, "B" sends out a new version of the event and the other "Attendees" agree to accept "B" as the new "Organizer". "B" also removes "A" from the event.
When the "Organizer" is replaced, the "SEQUENCE" property value MUST be incremented.
When the "Organizer" is replaced, the "SEQUENCE" property value MUST be incremented.
This is the message "B" sends to "C" and "D"
This is the message "B" sends to "C" and "D"
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:B@example.com ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T203000Z RRULE:FREQ=WEEKLY SUMMARY:Phone Conference UID:123456@example.com
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:B@example.com ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T203000Z RRULE:FREQ=WEEKLY SUMMARY:Phone Conference UID:123456@example.com
Silverberg, et. al. Standards Track [Page 75] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 75] RFC 2446 iTIP November 1998
SEQUENCE:1 STATUS:CONFIRMED END:VEVENT END:VCALENDAR
SEQUENCE:1 STATUS:CONFIRMED END:VEVENT END:VCALENDAR
4.3 Busy Time Examples
4.3 Busy Time Examples
Busy time objects can be used in several ways. First, a CU may request busy time from another CU for a specific range of time. That request can be answered with a busy time Reply. Additionally, a CU may simply publish their busy time for a given interval and point other CUs to the published location. The following examples outline both scenarios.
Busy time objects can be used in several ways. First, a CU may request busy time from another CU for a specific range of time. That request can be answered with a busy time Reply. Additionally, a CU may simply publish their busy time for a given interval and point other CUs to the published location. The following examples outline both scenarios.
Individual "A" publishes busy time for one week.
Individual "A" publishes busy time for one week.
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VFREEBUSY DTSTAMP:19980101T124100Z ORGANIZER:MAILTO:A@Example.com DTSTART:19980101T124200Z DTEND:19980107T124200Z FREEBUSY:19980101T180000Z/19980101T190000Z FREEBUSY:19980103T020000Z/19980103T050000Z FREEBUSY:19980107T020000Z/19980107T050000Z FREEBUSY:19980113T000000Z/19980113T010000Z FREEBUSY:19980115T190000Z/19980115T200000Z FREEBUSY:19980115T220000Z/19980115T230000Z FREEBUSY:19980116T013000Z/19980116T043000Z END:VFREEBUSY END:VCALENDAR
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VFREEBUSY DTSTAMP:19980101T124100Z ORGANIZER:MAILTO:A@Example.com DTSTART:19980101T124200Z DTEND:19980107T124200Z FREEBUSY:19980101T180000Z/19980101T190000Z FREEBUSY:19980103T020000Z/19980103T050000Z FREEBUSY:19980107T020000Z/19980107T050000Z FREEBUSY:19980113T000000Z/19980113T010000Z FREEBUSY:19980115T190000Z/19980115T200000Z FREEBUSY:19980115T220000Z/19980115T230000Z FREEBUSY:19980116T013000Z/19980116T043000Z END:VFREEBUSY END:VCALENDAR
Individual "A" requests busy time from individuals "B", "C". Individual "B" and "C" replies with busy time data to individual "A". The following table illustrates the sequence of messages that would be exchanged between these individuals.
Individual "A" requests busy time from individuals "B", "C". Individual "B" and "C" replies with busy time data to individual "A". The following table illustrates the sequence of messages that would be exchanged between these individuals.
Silverberg, et. al. Standards Track [Page 76] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 76] RFC 2446 iTIP November 1998
+--------------------------------------------------------------------+ | Action | "Organizer" | Attendee | +--------------------------------------------------------------------+ | Initiate a busy | "A" sends "REQUEST" | | | time request | message to "B" and | | | | and "C" | | +--------------------------------------------------------------------+ | Reply to the "BUSY"| | "B" sends a "REPLY" | | request with "BUSY"| | message to "A" with | | time data | | busy time data | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | Action | "Organizer" | Attendee | +--------------------------------------------------------------------+ | Initiate a busy | "A" sends "REQUEST" | | | time request | message to "B" and | | | | and "C" | | +--------------------------------------------------------------------+ | Reply to the "BUSY"| | "B" sends a "REPLY" | | request with "BUSY"| | message to "A" with | | time data | | busy time data | +--------------------------------------------------------------------+
4.3.1 Request Busy Time
4.3.1 Request Busy Time
"A" sends a "BUSY-REQUEST" to "B" and "C" for busy time
"A" sends a "BUSY-REQUEST" to "B" and "C" for busy time
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VFREEBUSY ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com DTSTAMP:19970613T190000Z DTSTART:19970701T080000Z DTEND:19970701T200000 UID:calsrv.example.com-873970198738777@example.com END:VFREEBUSY END:VCALENDAR
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VFREEBUSY ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com DTSTAMP:19970613T190000Z DTSTART:19970701T080000Z DTEND:19970701T200000 UID:calsrv.example.com-873970198738777@example.com END:VFREEBUSY END:VCALENDAR
4.3.2 Reply To A Busy Time Request
4.3.2 Reply To A Busy Time Request
"B" sends a "REPLY" method type of a "VFREEBUSY" calendar component to "A"
"B" sends a "REPLY" method type of a "VFREEBUSY" calendar component to "A"
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0 BEGIN:VFREEBUSY ORGANIZER:MAILTO:A@example.com ATTENDEE:Mailto:B@example.com DTSTART:19970701T080000Z DTEND:19970701T200000Z UID:calsrv.example.com-873970198738777@example.com FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0 BEGIN:VFREEBUSY ORGANIZER:MAILTO:A@example.com ATTENDEE:Mailto:B@example.com DTSTART:19970701T080000Z DTEND:19970701T200000Z UID:calsrv.example.com-873970198738777@example.com FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M
Silverberg, et. al. Standards Track [Page 77] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 77] RFC 2446 iTIP November 1998
DTSTAMP:19970613T190030Z END:VFREEBUSY END:VCALENDAR
DTSTAMP:19970613T190030Z END:VFREEBUSY END:VCALENDAR
"B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.
"B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.
4.4 Recurring Event and Time Zone Examples
4.4 Recurring Event and Time Zone Examples
4.4.1 A Recurring Event Spanning Time Zones
4.4.1 A Recurring Event Spanning Time Zones
This event describes a weekly phone conference. The "Attendees" are each in a different time zone.
This event describes a weekly phone conference. The "Attendees" are each in a different time zone.
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTIMEZONE TZID:America-SanJose TZURL:http://zones.stds_r_us.net/tz/America-SanJose BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp DTSTAMP:19970613T190030Z DTSTART;TZID=America-SanJose:19970701T140000 DTEND;TZID=America-SanJose:19970701T150000 RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU RDATE;TZID=America-SanJose:19970910T140000 EXDATE;TZID=America-SanJose:19970909T140000 EXDATE;TZID=America-SanJose:19971028T140000 SUMMARY:Weekly Phone Conference
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTIMEZONE TZID:America-SanJose TZURL:http://zones.stds_r_us.net/tz/America-SanJose BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp DTSTAMP:19970613T190030Z DTSTART;TZID=America-SanJose:19970701T140000 DTEND;TZID=America-SanJose:19970701T150000 RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU RDATE;TZID=America-SanJose:19970910T140000 EXDATE;TZID=America-SanJose:19970909T140000 EXDATE;TZID=America-SanJose:19971028T140000 SUMMARY:Weekly Phone Conference
Silverberg, et. al. Standards Track [Page 78] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 78] RFC 2446 iTIP November 1998
UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR
UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR
The first two components of this iCalendar object are the time zone components. The "DTSTART" date coincides with the first instance of the RRULE property.
The first two components of this iCalendar object are the time zone components. The "DTSTART" date coincides with the first instance of the RRULE property.
The recurring meeting is defined in a particular time zone, presumably that of the originator. The client for each "Attendee" has the responsibility of determining the recurrence time in the "Attendee's" time zone.
The recurring meeting is defined in a particular time zone, presumably that of the originator. The client for each "Attendee" has the responsibility of determining the recurrence time in the "Attendee's" time zone.
The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. "Attendee" B@example.fr is in France where the local time on this date is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in Japan where local time is 8 hours ahead of UTC or Wednesday, July 2 at 06:00. The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property results in 20 instances. The last instance falls on Tuesday, November 11, 1997 2:00pm PDT. The "RDATE" property adds another instance: WED, 10-SEP-1997 2:00 PM PST.
The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. "Attendee" B@example.fr is in France where the local time on this date is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in Japan where local time is 8 hours ahead of UTC or Wednesday, July 2 at 06:00. The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property results in 20 instances. The last instance falls on Tuesday, November 11, 1997 2:00pm PDT. The "RDATE" property adds another instance: WED, 10-SEP-1997 2:00 PM PST.
There are two exceptions to this recurring appointment. The first one is:
There are two exceptions to this recurring appointment. The first one is:
TUE, 09-SEP-1997 23:00 GMT TUE, 09-SEP-1997 14:00 PDT WED, 10-SEP-1997 06:00 JST
TUE, 09-SEP-1997 23:00 GMT TUE, 09-SEP-1997 14:00 PDT WED, 10-SEP-1997 06:00 JST
and the second is:
and the second is:
TUE, 28-OCT-1997 23:00 GMT TUE, 28-OCT-1997 14:00 PST WED, 29-OCT-1997 06:00 JST
TUE, 28-OCT-1997 23:00 GMT TUE, 28-OCT-1997 14:00 PST WED, 29-OCT-1997 06:00 JST
4.4.2 Modify A Recurring Instance
4.4.2 Modify A Recurring Instance
In this example the "Organizer" issues a recurring meeting. Later the "Organizer" changes an instance of the event by changing the "DTSTART" property. Note the use of "RECURRENCE-ID" property and "SEQUENCE" property in the second request.
In this example the "Organizer" issues a recurring meeting. Later the "Organizer" changes an instance of the event by changing the "DTSTART" property. Note the use of "RECURRENCE-ID" property and "SEQUENCE" property in the second request.
Original Request:
Original Request:
BEGIN:VCALENDAR METHOD:REQUEST
BEGIN:VCALENDAR METHOD:REQUEST
Silverberg, et. al. Standards Track [Page 79] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 79] RFC 2446 iTIP November 1998
PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com SEQUENCE:0 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970601T210000Z DTEND:19970601T220000Z LOCATION:Conference Call DTSTAMP:19970526T083000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com SEQUENCE:0 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970601T210000Z DTEND:19970601T220000Z LOCATION:Conference Call DTSTAMP:19970526T083000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
The event request below is to change the time of a specific instance. This changes the July 1st instance to July 3rd.
The event request below is to change the time of a specific instance. This changes the July 1st instance to July 3rd.
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z SEQUENCE:1 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970703T210000Z DTEND:19970703T220000Z LOCATION:Conference Call DTSTAMP:19970626T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1com RECURRENCE-ID:19970701T210000Z SEQUENCE:1 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970703T210000Z DTEND:19970703T220000Z LOCATION:Conference Call DTSTAMP:19970626T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
Silverberg, et. al. Standards Track [Page 80] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 80] RFC 2446 iTIP November 1998
4.4.3 Cancel an Instance
4.4.3 Cancel an Instance
In this example the "Organizer" of a recurring event deletes the August 1st instance.
In this example the "Organizer" of a recurring event deletes the August 1st instance.
BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com RECURRENCE-ID:19970801T210000Z SEQUENCE:2 STATUS:CANCELLED DTSTAMP:19970721T093000Z END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com RECURRENCE-ID:19970801T210000Z SEQUENCE:2 STATUS:CANCELLED DTSTAMP:19970721T093000Z END:VEVENT END:VCALENDAR
4.4.4 Cancel Recurring Event
4.4.4 Cancel Recurring Event
In this example the "Organizer" wishes to cancel the entire recurring event and any exceptions.
In this example the "Organizer" wishes to cancel the entire recurring event and any exceptions.
BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DTSTAMP:19970721T103000Z STATUS:CANCELLED SEQUENCE:3 END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com ATTENDEE:Mailto:D@example.com DTSTAMP:19970721T103000Z STATUS:CANCELLED SEQUENCE:3 END:VEVENT END:VCALENDAR
Silverberg, et. al. Standards Track [Page 81] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 81] RFC 2446 iTIP November 1998
4.4.5 Change All Future Instances
4.4.5 Change All Future Instances
This example changes the meeting location from a conference call to Seattle starting September 1 and extends to all future instances.
This example changes the meeting location from a conference call to Seattle starting September 1 and extends to all future instances.
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com RECURRENCE-ID;THISANDFUTURE:19970901T210000Z SEQUENCE:3 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com DESCRIPTION:IETF-C&S Discussion CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970901T210000Z DTEND:19970901T220000Z LOCATION:Building 32, Microsoft, Seattle, WA DTSTAMP:19970526T083000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com RECURRENCE-ID;THISANDFUTURE:19970901T210000Z SEQUENCE:3 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com DESCRIPTION:IETF-C&S Discussion CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970901T210000Z DTEND:19970901T220000Z LOCATION:Building 32, Microsoft, Seattle, WA DTSTAMP:19970526T083000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
4.4.6 Add A New Instance To A Recurring Event
4.4.6 Add A New Instance To A Recurring Event
This example adds a one-time additional instance to the recurring event. "Organizer" adds a second July meeting on the 15th.
This example adds a one-time additional instance to the recurring event. "Organizer" adds a second July meeting on the 15th.
BEGIN:VCALENDAR METHOD:ADD PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:4 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC
BEGIN:VCALENDAR METHOD:ADD PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:4 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC
Silverberg, et. al. Standards Track [Page 82] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 82] RFC 2446 iTIP November 1998
SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970715T210000Z DTEND:19970715T220000Z LOCATION:Conference Call DTSTAMP:19970629T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970715T210000Z DTEND:19970715T220000Z LOCATION:Conference Call DTSTAMP:19970629T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
4.4.7 Add A New Series of Instances To A Recurring Event
4.4.7 Add A New Series of Instances To A Recurring Event
The scenario for this example involves an ongoing meeting, originally set up to occur every Tuesday. The "Organizer" later decides that the meetings need to be on Tuesdays and Thursdays, but does not want to reschedule the entire meeting or lose any of the per-instance information already collected.
The scenario for this example involves an ongoing meeting, originally set up to occur every Tuesday. The "Organizer" later decides that the meetings need to be on Tuesdays and Thursdays, but does not want to reschedule the entire meeting or lose any of the per-instance information already collected.
The original event:
The original event:
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:0 RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980303T210000Z DTEND:19980303T220000Z LOCATION:The White Room DTSTAMP:19980301T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:0 RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980303T210000Z DTEND:19980303T220000Z LOCATION:The White Room DTSTAMP:19980301T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR
Assume that many other updates happen to this event and that a lot of instance-specific information exists in the recurring series. The "SEQUENCE" property value is 7 for the next update. Now the "Organizer" wants to add Thursdays to the event:
Assume that many other updates happen to this event and that a lot of instance-specific information exists in the recurring series. The "SEQUENCE" property value is 7 for the next update. Now the "Organizer" wants to add Thursdays to the event:
BEGIN:VCALENDAR METHOD:ADD PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0
BEGIN:VCALENDAR METHOD:ADD PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0
Silverberg, et. al. Standards Track [Page 83] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 83] RFC 2446 iTIP November 1998
BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:7 RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980303T210000Z DTEND:19980303T220000Z DTSTAMP:19980303T193000Z LOCATION:The Usual conference room STATUS:CONFIRMED END:VEVENT END:VCALENDAR
BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:7 RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980303T210000Z DTEND:19980303T220000Z DTSTAMP:19980303T193000Z LOCATION:The Usual conference room STATUS:CONFIRMED END:VEVENT END:VCALENDAR
Alternatively, if the "Organizer" is not concerned with per-instance updates, the entire event can be rescheduled using a "REQUEST". This is done by using the "UID" of the event to reschedule and including the modified "RRULE". Note, that since this is an entire rescheduling of the event, any instance-specific information will be lost.
Alternatively, if the "Organizer" is not concerned with per-instance updates, the entire event can be rescheduled using a "REQUEST". This is done by using the "UID" of the event to reschedule and including the modified "RRULE". Note, that since this is an entire rescheduling of the event, any instance-specific information will be lost.
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:7 RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980303T210000Z DTEND:19980303T220000Z DTSTAMP:19980303T193000Z LOCATION:The White Room STATUS:CONFIRMED END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:7 RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980303T210000Z DTEND:19980303T220000Z DTSTAMP:19980303T193000Z LOCATION:The White Room STATUS:CONFIRMED END:VEVENT END:VCALENDAR
The next series of examples illustrate how an "Organizer" would respond to a "REFRESH" submitted by an "Attendee" after a series of instance-specific modifications. To convey all instance-specific changes, the "Organizer" must provide the latest event description and the relevant instances. The first three examples show the history including the initial "VEVENT" request and subsequent instance
The next series of examples illustrate how an "Organizer" would respond to a "REFRESH" submitted by an "Attendee" after a series of instance-specific modifications. To convey all instance-specific changes, the "Organizer" must provide the latest event description and the relevant instances. The first three examples show the history including the initial "VEVENT" request and subsequent instance
Silverberg, et. al. Standards Track [Page 84] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 84] RFC 2446 iTIP November 1998
changes and finally the "REFRESH".
changes and finally the "REFRESH".
Original Request:
Original Request:
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:0 RDATE:19980304T180000Z RDATE:19980311T180000Z RDATE:19980318T180000Z ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980304T180000Z DTEND:19980304T200000Z DTSTAMP:19980303T193000Z LOCATION:Conference Room A STATUS:CONFIRMED END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:0 RDATE:19980304T180000Z RDATE:19980311T180000Z RDATE:19980318T180000Z ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980304T180000Z DTEND:19980304T200000Z DTSTAMP:19980303T193000Z LOCATION:Conference Room A STATUS:CONFIRMED END:VEVENT END:VCALENDAR
Organizer changes 2nd instance Location and Time:
Organizer changes 2nd instance Location and Time:
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:1 RECURRENCE-ID:19980311T180000Z ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980311T160000Z DTEND:19980311T180000Z DTSTAMP:19980306T193000Z LOCATION:The Small conference room STATUS:CONFIRMED END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:1 RECURRENCE-ID:19980311T180000Z ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980311T160000Z DTEND:19980311T180000Z DTSTAMP:19980306T193000Z LOCATION:The Small conference room STATUS:CONFIRMED END:VEVENT END:VCALENDAR
Silverberg, et. al. Standards Track [Page 85] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 85] RFC 2446 iTIP November 1998
Organizer adds a 4th instance of the meeting using the "ADD" method
Organizer adds a 4th instance of the meeting using the "ADD" method
BEGIN:VCALENDAR METHOD:ADD PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:2 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980315T180000Z DTEND:19980315T200000Z DTSTAMP:19980307T193000Z LOCATION:Conference Room A STATUS:CONFIRMED END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:ADD PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:2 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980315T180000Z DTEND:19980315T200000Z DTSTAMP:19980307T193000Z LOCATION:Conference Room A STATUS:CONFIRMED END:VEVENT END:VCALENDAR
If "B" requests a "REFRESH", "A" responds with the following to capture all instance-specific data. In this case both the initial request and an additional "VEVENT" that specifies the instance- specific data are included. Because these are both of the same type (they are both "VEVENTS"), they can be conveyed in the same iCalendar object.
If "B" requests a "REFRESH", "A" responds with the following to capture all instance-specific data. In this case both the initial request and an additional "VEVENT" that specifies the instance- specific data are included. Because these are both of the same type (they are both "VEVENTS"), they can be conveyed in the same iCalendar object.
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:2 RDATE:19980304T180000Z RDATE:19980311T160000Z RDATE:19980315T180000Z Error! Bookmark not defined. ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980304T180000Z DTEND:19980304T200000Z DTSTAMP:19980303T193000Z LOCATION:Conference Room A STATUS:CONFIRMED
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@host1.com SEQUENCE:2 RDATE:19980304T180000Z RDATE:19980311T160000Z RDATE:19980315T180000Z Error! Bookmark not defined. ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com SUMMARY:Review Accounts DTSTART:19980304T180000Z DTEND:19980304T200000Z DTSTAMP:19980303T193000Z LOCATION:Conference Room A STATUS:CONFIRMED
Silverberg, et. al. Standards Track [Page 86] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 86] RFC 2446 iTIP November 1998
END:VEVENT
END:VEVENT
BEGIN:VEVENT Error! Bookmark not defined. SEQUENCE:2 RECURRENCE-ID:19980311T160000Z Error! Bookmark not defined. ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined. ATTENDEE;Error! Bookmark not defined. SUMMARY:Review Accounts DTSTART:19980311T160000Z DTEND:19980304T180000Z DTSTAMP:19980306T193000Z LOCATION:The Small conference room STATUS:CONFIRMED END:VEVENT
BEGIN:VEVENT Error! Bookmark not defined. SEQUENCE:2 RECURRENCE-ID:19980311T160000Z Error! Bookmark not defined. ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined. ATTENDEE;Error! Bookmark not defined. SUMMARY:Review Accounts DTSTART:19980311T160000Z DTEND:19980304T180000Z DTSTAMP:19980306T193000Z LOCATION:The Small conference room STATUS:CONFIRMED END:VEVENT
END:VCALENDAR
END:VCALENDAR
4.4.8 Counter An Instance Of A Recurring Event
4.4.8 Counter An Instance Of A Recurring Event
In this example one of the "Attendees" counters the "DTSTART" property of the proposed second July meeting.
In this example one of the "Attendees" counters the "DTSTART" property of the proposed second July meeting.
BEGIN:VCALENDAR METHOD:COUNTER PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com RECURRENCE-ID:19970715T210000Z SEQUENCE:4 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970715T220000Z DTEND:19970715T230000Z LOCATION:Conference Call COMMENT:May we bump this by an hour? I have a conflict DTSTAMP:19970629T094000Z END:VEVENT END:VCALENDAR
BEGIN:VCALENDAR METHOD:COUNTER PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com RECURRENCE-ID:19970715T210000Z SEQUENCE:4 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970715T220000Z DTEND:19970715T230000Z LOCATION:Conference Call COMMENT:May we bump this by an hour? I have a conflict DTSTAMP:19970629T094000Z END:VEVENT END:VCALENDAR
Silverberg, et. al. Standards Track [Page 87] RFC 2446 iTIP November 1998
Silverberg, et. al. Standards Track [Page 87] RFC 2446 iTIP November 1998
4.4.9 Error Reply To A Request
4.4.9 Error Reply To A Request
The following example illustrates a scenario where a meeting is proposed containing an unsupported property and a bad property.
The following example illustrates a scenario where a meeting is proposed containing an unsupported property and a bad property.
Original Request
Original Request
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@host1.com SEQUENCE:0 RRULE:FREQ=MONTHLY;BYMONTHDAY=1 ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970601T210000Z DTEND:19970601T220000Z DTSTAMP:19970602T094000Z LOCATION:Conference Call STATUS:CONFIRMED FOO:BAR END:VEVENT END:VCALENDAR
始まってください: VCALENDAR方法: PRODIDを要求してください: -//RDUソフトウェア//NONSGML HandCal//アンバージョン: 2.0は始まります: VEVENT UID: guid-1@host1.com 系列: 0RRULE: FREQは= 本当に; BYMONTHDAY=1オーガナイザー:Mailto: A@example.com 出席者; 役割=議長:Mailto: A@example.com 出席者;毎月のRSVPと等しいです: Mailto: B@example.com 出席者、RSVPが本当に等しい、: Mailto: C@example com ATTENDEE; RSVP=TRUE:Mailto: D@example.com 記述: IETF-CとSコンファレンスCall CLASS:PUBLIC SUMMARY:IETF Calendaring作業部会Meeting DTSTART:19970601T210000Z DTEND:19970601T220000Z DTSTAMP:19970602T094000Z LOCATION:コンファレンスCall STATUS:CONFIRMED FOO:BAR END:VEVENT END:VCALENDAR
Response from "B" to indicate that RRULE is not supported and an unrecognized property was encountered
RRULEが支持されないで、認識されていない特性が遭遇したのを示す「B」からの応答
BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN
METHOD:REPLY
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE:Mailto:B@example.com
REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single
event;RRULE
REQUEST-STATUS:3.0;Invalid Property Name;FOO
UID:guid-1@host1.com
SEQUENCE:0
DTSTAMP:19970603T094000Z
BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//EN METHOD: REPLY VERSION: 2.0 BEGIN:VEVENT ORGANIZER:Mailto: A@example.com ATTENDEE:Mailto: B@example.com REQUEST-STATUS: 2.8; 無視された出来事を繰り返します。 a単一の出来事; RRULE REQUEST-STATUS: 3.0; 無効のProperty Name; FOO UID: guid-1@host1.com SEQUENCE: 0DTSTAMPとして、: 19970603T094000Zの計画をします。
Silverberg, et. al. Standards Track [Page 88] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[88ページ]。
END:VEVENT END:VCALENDAR
終わり: VEVENTエンド: VCALENDAR
4.5 Group To-do Examples
4.5 グループ大騒ぎの例
Individual "A" creates a group task in which individuals "A", "B", "C" and "D" will participate. Individual "B" confirms acceptance of the task. Individual "C" declines the task. Individual "D" tentatively accepts the task. The following table illustrates the sequence of messages that would be exchanged between these individuals. Individual "A" then issues a "REQUEST" method to obtain the status of the to-do from each participant. The response indicates the individual "Attendee's" completion status. The table below illustrates the message flow.
個人「A」は個人「A」、「B」、「C」、および「D」が参加するグループタスクを作成します。 個人「B」はタスクの承認を確認します。 個人「C」はタスクを傾けます。 個人「D」は試験的にタスクを受け入れます。 以下のテーブルはこれらの個人の間で交換されるメッセージの系列を例証します。 そして、個人「A」は各関係者から大騒ぎの状態を得る「要求」方法を発行します。 応答は個々の「を出席者示します。」 完成状態。 以下のテーブルはメッセージ流動を例証します。
+--------------------------------------------------------------------+ | Action | "Organizer" | Attendee | +--------------------------------------------------------------------+ | Initiate a to-do | "A" sends a REQUEST | | | request | message to "B", "C",| | | | and "D" | | +--------------------------------------------------------------------+ | Accept the to-do | | "B" sends a "REPLY" | | request | | message to "A" with its | | | | "partstat" paramater | | | | set to "accepted". | +--------------------------------------------------------------------+ | Decline the to-do | | "C" sends a REPLY | | request | | message to "A" with its | | | | "partstat" parameter | | | | set to "declined". | +--------------------------------------------------------------------+ | Tentatively accept | | "D" sends a REPLY | | the to-do request | | message to "A" with its | | | | "partstat" parameter | | | | set to "tentative". | +--------------------------------------------------------------------+ | Check attendee | "A" sends a REQUEST | | | completion status | message to "B" and | | | | "D" with current | | | | information. | | +--------------------------------------------------------------------+ | Attendee indicates | | "B" sends a "REPLY" | | percent complete | | message indicating | | | | percent complete |
+--------------------------------------------------------------------+ | 動作| 「オーガナイザー」| 出席者| +--------------------------------------------------------------------+ | 大騒ぎを開始してください。| 「A」はREQUESTを送ります。| | | 要求| 「B」、「C」へのメッセージ| | | | そして、「D」| | +--------------------------------------------------------------------+ | 大騒ぎを受け入れてください。| | 「B」は「回答」を送ります。| | 要求| | 「A」へ通信する、それ| | | | "partstat"paramater| | | | 「受け入れられること」にセットしてください。 | +--------------------------------------------------------------------+ | 大騒ぎを断ってください。| | 「C」は返信します。| | 要求| | 「A」へ通信する、それ| | | | "partstat"パラメタ| | | | 「傾けられること」にセットしてください。 | +--------------------------------------------------------------------+ | 試験的に受け入れてください。| | 「D」は返信します。| | 大騒ぎ要求| | 「A」へ通信する、それ| | | | "partstat"パラメタ| | | | 「一時的に」セットしてください。 | +--------------------------------------------------------------------+ | 出席者をチェックしてください。| 「A」はREQUESTを送ります。| | | 完成状態| そして「B」へのメッセージ。| | | | 電流を伴う「D」| | | | 情報。 | | +--------------------------------------------------------------------+ | 出席者は示します。| | 「B」は「回答」を送ります。| | パーセント完全です。| | メッセージ表示| | | | パーセント完全です。|
Silverberg, et. al. Standards Track [Page 89] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[89ページ]。
+--------------------------------------------------------------------+ | Attendee indicates | | "D" sends a "REPLY" | | completion | | message indicating | | | | completion | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | 出席者は示します。| | 「D」は「回答」を送ります。| | 完成| | メッセージ表示| | | | 完成| +--------------------------------------------------------------------+
4.5.1 A VTODO Request
4.5.1 VTODO要求
A sample "REQUEST" for a "VTODO" calendar component that "A" sends to "B", "C", and "D".
「A」が「B」、「C」、および「D」に送る"VTODO"カレンダーコンポーネントのための「要求」というサンプル。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE;RSVP=TRUE:Mailto:B@example.com ATTENDEE;RSVP=TRUE:Mailto:C@example.com ATTENDEE;RSVP=TRUE:Mailto:D@example.com DTSTART:19970701T170000Z DUE:19970722T170000Z PRIORITY:1 SUMMARY:Create the requirements document UID:calsrv.example.com-873970198738777-00@example.com SEQUENCE:0 DTSTAMP:19970717T200000Z STATUS:Needs Action END:VTODO END:VCALENDAR
本当に: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョン: 2.0が= 本当に: VTODOオーガナイザー:Mailto: A@example.com 出席者; 役割=議長:Mailto: A@example.com 出席者; RSVPを始めるという要求: Mailto: B@example.com 出席者; RSVP=を始めてください: Mailto: C@example com ATTENDEE; RSVP=TRUE:Mailto: D@example.com DTSTART: 19970701T170000Z DUE:19970722T170000Z PRIORITY:1SUMMARY: 要件ドキュメントUID: calsrv.example.com-873970198738777-00@example.com SEQUENCE: 0DTSTAMP: 19970717T200000Z STATUS: 必要性Action END:VTODO END:VCALENDARを作成してください。
4.5.2 A VTODO Reply
4.5.2 VTODO回答
"B" accepts the to-do.
「B」は大騒ぎを受け入れます。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:Mailto:A@example.com ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com UID:calsrv.example.com-873970198738777-00@example.com COMMENT:I'll send you my input by e-mail SEQUENCE:0 DTSTAMP:19970717T203000Z REQUEST-STATUS:2.0;Success
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0BEGIN: VTODO ORGANIZER:Mailto: A@example.com ATTENDEE; PARTSTAT=ACCEPTED:Mailto: B@example.com UID: COMMENT: 私がメールSEQUENCEによる私の入力: 0DTSTAMP: 19970717T203000Z REQUEST-STATUS: 2.0にあなたに送るつもりである calsrv.example.com-873970198738777-00@example.com ; 成功
Silverberg, et. al. Standards Track [Page 90] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[90ページ]。
END:VTODO END:VCALENDAR
終わり: VTODOエンド: VCALENDAR
"B" could have declined the TODO or indicated tentative acceptance by setting the "partstat" property parameter sequence to "declined" or "tentative", respectively.
「B」は、それぞれ「傾けられる」か「一時的である」"partstat"特性のパラメタ系列を設定することによって、TODOを傾けたか、または一時的な承認を示したかもしれません。
4.5.3 A VTODO Request for Updated Status
4.5.3 アップデートされた状態を求めるVTODO要求
"A" requests status from all "Attendees".
すべての「出席者」からの要求状態。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com UID:calsrv.example.com-873970198738777-00@example.com SUMMARY:Create the requirements document PRIORITY:1 SEQUENCE:0 STATUS:IN-PROCESS DTSTART:19970701T170000Z DTSTAMP:19970717T230000Z END:VTODO END:VCALENDAR
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0BEGIN: VTODO ORGANIZER:Mailto: A@example.com ATTENDEE; 議長:Mailto: A@example.com ROLE=ATTENDEE; RSVP=TRUE; TYPE=INDIVIDUAL:Mailto: B@example.com ATTENDEE; RSVP=TRUE; TYPE=INDIVIDUAL:Mailto: D@example.com UID: calsrv.example.com-873970198738777-00@example.com SUMMARY: PRIORITY: 1SEQUENCE: 0STATUS: IN-PROCESS DTSTART: 19970701T170000Z DTSTAMP:19970717T230000Z END:VTODO END: 要件ドキュメントVCALENDARを作成してください。
4.5.4 A Reply: Percent-Complete
4.5.4 回答: パーセント完全です。
A reply indicating the task being worked on and that "B" is 75% complete with "B's" part of the assignment.
働いているタスクと、「B」が課題の「ビーズ」部分で完全な75%であることを示す回答。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:MAILTO:A@example.com ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com PERCENT-COMPLETE:75 UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z SEQUENCE:0 END:VTODO END:VCALENDAR
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: 回答バージョン: 2.0が: VTODOオーガナイザー:MAILTO: A@example.com 出席者; PARTSTAT=を始める、製造過程、75UID: DTSTAMP: 19970717T233000Zが配列する calsrv.example.com-873970198738777-00@example.com : 0は終わります: : Mailto: B@example.com は以下を何パーセントも完成して、VTODOは: VCALENDARを終わらせます。
Silverberg, et. al. Standards Track [Page 91] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[91ページ]。
4.5.5 A Reply: Completed
4.5.5 回答: 完成されます。
A reply indicating that "D" completed "D's" part of the assignment.
その「D」を示す回答は「D」の課題の部分を完成しました。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:MAILTO:A@example.com ATTENDEE;PARTSTAT=COMPLETED:Mailto:D@example.com UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z SEQUENCE:0 END:VTODO END:VCALENDAR
VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: 回答バージョン: 2.0は始まります: VTODOオーガナイザー:MAILTO: A@example.com 出席者、始まってください: PARTSTAT=は: Mailto: D@example.com UID: calsrv.example.com-873970198738777-00@example.com DTSTAMP: 19970717T233000Z系列: 0終わり: VTODOエンド: VCALENDARを完成しました。
4.5.6 An Updated VTODO Request
4.5.6 アップデートされたVTODO要求
Organizer "A" resends the "VTODO" calendar component. "A" sets the overall completion for the to-do at 40%.
オーガナイザー「A」は"VTODO"カレンダーコンポーネントを再送します。 「A」は40%で大騒ぎのための総合的な完成を設定します。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com DTSTART:19970701T170000Z DUE:19970722T170000Z PRIORITY:1 SUMMARY:Create the requirements document UID:calsrv.example.com-873970198738777-00@example.com SEQUENCE:1 DTSTAMP:19970718T100000Z STATUS:IN-PROGRESS PERCENT-COMPLETE:40 END:VTODO END:VCALENDAR
VTODOオーガナイザー:Mailto: A@example.com 出席者; ROLE=議長; PARTSTAT=は受け入れました: Mailto: A@example.com 出席者、始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを要求してください: 2.0は始まります: PARTSTAT=は、; タイプ=個人:Mailto: B@example.com 出席者;PARTSTAT=が製造過程であると受け入れました; タイプ=個人:Mailto: D@example com DTSTART:19970701T170000Z DUE:19970722T170000Z PRIORITY: 1SUMMARY: 要件ドキュメントUID: calsrv.example.com-873970198738777-00@example.com SEQUENCE: 1DTSTAMP: 19970718T100000Z STATUS: IN PROGRESS PERCENT-COMPLETE: 40END:VTODO END:VCALENDARを作成してください。
4.5.7 Recurring VTODOs
4.5.7 再発VTODOs
The following examples relate to recurring "VTODO" calendar components.
以下の例は再発"VTODO"カレンダーコンポーネントに関連します。
Silverberg, et. al. Standards Track [Page 92] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[92ページ]。
4.5.7.1 Request for a Recurring VTODO
4.5.7.1 再発には、VTODOを要求してください。
In this example "A" sends a recurring "VTODO" calendar component to "B" and "D".
中では、この例「A」は再発"VTODO"カレンダーコンポーネントを「B」と「D」に送ります。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR:Mailto:A@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR DTSTART:19980101T100000-0700 DUE:19980103T100000-0700 SUMMARY:Send Status Reports to Area Managers UID:calsrv.example.com-873970198738777-00@example.com SEQUENCE:0 DTSTAMP:19970717T200000Z STATUS:NEEDS ACTION PRIORITY:1 END:VTODO END:VCALENDAR
始まってください: VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: バージョンを要求してください: 2.0は始まります: VTODOオーガナイザー:Mailto: A@example.com 出席者; 役割=議長:Mailto: A@example.com 出席者; RSVPは= 本当に; タイプ=個人:Mailto: B@example.com 出席者;本当のRSVPと等しいです; =個人:Mailto: D@example をタイプしてください; com RRULE: FREQ=MONTHLY; COUNT=10; BYDAYは1FR DTSTARTと等しいです: 19980101T100000-0700 DUE: 19980103T100000-0700 SUMMARY: AreaマネージャUID: calsrv.example.com-873970198738777-00@example.com SEQUENCE: 0DTSTAMP: 19970717T200000Z STATUS:NEEDS ACTION PRIORITY:1END:VTODO END:VCALENDARにStatus Reportsを送ってください。
4.5.7.2 Calculating due dates in recurring VTODOs
4.5.7.2 再発VTODOsの計算の期日
The due date in a recurring "VTODO" calendar component is either a fixed interval specified in the "REQUEST" method or specified using the "RECURRENCE-ID" property. The former is calculated by applying the difference between "DTSTART" and "DUE" properties and applying it to each of the start of each recurring instance. Hence, if the initial "VTODO" calendar component specifies a "DTSTART" property value of "19970701T190000Z" and a "DUE" property value of "19970801T190000Z" the interval of one day which is applied to each recurring instance of the "VTODO" calendar component to determine the "DUE" date of the instance.
再発"VTODO"カレンダーコンポーネントの期日は「要求」方法で指定されるか、または「RECURRENCE ID」の特性を使用することで指定された固定間隔です。 前者は、"DTSTART"と「当然」の所有地の違いを適用して、それぞれのそれぞれの再発例の始まりにそれを付けることによって、計算されます。 したがって、初期の"VTODO"カレンダーコンポーネントが"19970701T190000Z"の"DTSTART"資産価値を指定して、"19970801T190000Z"の「当然」の資産価値が1日の間隔を指定するなら、どれが、例の「当然」の期日を測定するために"VTODO"カレンダーコンポーネントのそれぞれの再発例に適用されますか?
4.5.7.3 Replying to an instance of a recurring VTODO
4.5.7.3 再発VTODOの例に答えること。
In this example "B" updates "A" on a single instance of the "VTODO" calendar component.
中では、この例「B」は"VTODO"カレンダーコンポーネントのただ一つの例で「A」をアップデートします。
BEGIN:VCALENDAR PRODID:-//ACME/DesktopCalendar//EN METHOD:REPLY VERSION:2.0
VCALENDAR PRODID: -//ACME/DesktopCalendar//EN方法: 回答バージョン: 2.0に以下を始めてください。
Silverberg, et. al. Standards Track [Page 93] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[93ページ]。
BEGIN:VTODO ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com PERCENT-COMPLETE:75 UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z RECURRENCE-ID:19980101T170000Z SEQUENCE:1 END:VTODO END:VCALENDAR
: VTODO出席者; PARTSTAT=を始めてください、製造過程、: Mailto: B@example.com は: 75UID: DTSTAMP: 19970717T233000Z RECURRENCE ID: 19980101T170000Zが配列する calsrv.example.com-873970198738777-00@example.com : 1つの終わり: VTODOエンド: VCALENDARを何パーセントも完成します。
4.6 Journal Examples
4.6 ジャーナルの例
The iCalendar object below describes a single journal entry for October 2, 1997. The "RELATED-TO" property references the phone conference event for which minutes were taken.
以下のiCalendar物は単一の仕訳記入について1997年10月2日に説明します。 「関連された」という特性は数分がかかった電話会議イベントに参照をつけます。
BEGIN:VCALENDAR
METHOD:PUBLISH
PRODID:-//ACME/DesktopCalendar//EN
VERSION:2.0
BEGIN:VJOURNAL
DTSTART:19971002T200000Z
ORGANIZER:MAILTO:A@Example.com
SUMMARY:Phone conference minutes
DESCRIPTION:The editors meeting was held on October 1, 1997.
Details are in the attached document.
UID:0981234-1234234-2410@example.com
RELATED-TO:0981234-1234234-2402-35@example.com
ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
END:VJOURNAL
END:VCALENDAR
BEGIN:VCALENDAR METHOD:PUBLISH PRODID: -//ACME/DesktopCalendar//ENバージョン: 2.0 BEGIN:VJOURNAL DTSTART:19971002T200000Z ORGANIZER:MAILTO: A@Example.com SUMMARY: 電話会議は記述を書き留めます: 1997年10月1日の会合が行われたエディタ。 詳細が添付書類にあります。 UID: 関連するTO:0981234-1234234-2402-35@example.comが取り付ける 0981234-1234234-2410@example.com : ftp://ftp.example.com/pub/ed/minutes100197.txt エンド: VJOURNALエンド: VCALENDAR
4.7 Other Examples
4.7 他の例
4.7.1 Event Refresh
4.7.1 出来事はリフレッシュします。
Refresh the event with "UID" property value of "guid-1- 12345@host1.com":
「guidに-1 12345@host1.com 」の"UID"資産価値で出来事をリフレッシュしてください:
BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//EN METHOD:REFRESH VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com ATTENDEE:Mailto:C@example.com
始まってください: VCALENDAR PRODID: -//RDUソフトウェア//NONSGML HandCal//アン方法: バージョンをリフレッシュしてください: 2.0は始まります: VEVENTオーガナイザー:Mailto: A@example.com 出席者; ROLE=議長; PARTSTAT=は: Mailto: A@example.com 出席者:Mailto: B@example.com 出席者:Mailto: C@example.com を受け入れました。
Silverberg, et. al. Standards Track [Page 94] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[94ページ]。
ATTENDEE:Mailto:D@example.com UID: guid-1-12345@host1.com DTSTAMP:19970603T094000 END:VEVENT END:VCALENDAR
出席者:Mailto: D@example.com UID: guid-1-12345@host1.com DTSTAMP: 19970603T094000エンド: VEVENTエンド: VCALENDAR
4.7.2 Bad RECURRENCE-ID
4.7.2 悪いRECURRENCE ID
Component instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request to an "Attendee", there are three cases in which an instance cannot be found. They are:
コンポーネント例は"UID"、「RECURRENCE ID」と「系列」の組み合わせで特定されます。 「オーガナイザー」が「出席者」に要求を送るとき、例を見つけることができない3つの場合があります。 それらは以下の通りです。
1. The component with the referenced "UID" and "RECURRENCE-ID" has
been found but the "SEQUENCE" number in the calendar store does
not match that of the ITIP message.
1. 参照をつけられた"UID"と「RECURRENCE ID」があるコンポーネントは見つけられましたが、カレンダー店の「系列」番号はITIPメッセージのものに合っていません。
2. The component with the referenced "UID" has been found, the
"SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
found.
2. 参照をつけられた"UID"があるコンポーネントは見つけられましたが、「系列」番号は合っていますが、「RECURRENCE ID」は見つけることができません。
3. The "UID" and "SEQUENCE" numbers are found but the CUA does not
support recurrences.
3. "UID"と「系列」番号は見つけられますが、クーアは再発を支持しません。
In case (1), two things can happen. If the "SEQUENCE" number of the "Attendee's" instance is larger than that in the "Organizer's" message then the "Attendee" is receiving an out-of-sequence message and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer version of the component and the "Attendee's" version needs to be updated. Since one or more updates have been missed, the "Attendee" SHOULD send a "REFRESH" message to the "Organizer" to get an updated version of the event.
場合(1)では、2つのことが起こることができます。 「出席者による」 例が「のオーガナイザーそれより大きいということです」というメッセージの「系列」番号であるなら、「出席者」は、系列で出ているメッセージを受け取っていて、それを無視しなければなりません。 」 」 例が「の出席者「系列」番号であるなら、より小さい、次に、「オーガナイザー」はコンポーネントの、より新しいバージョンを出すことであって、「は出席者アップデートされるべきバージョンの必要性です。 1つ以上のアップデートが逃されたので、「出席者」SHOULDは出来事のアップデートされたバージョンを得るために「リフレッシュしてください」というメッセージを「オーガナイザー」に送ります。
In case (2), something has gone wrong. Both the "Organizer" and the "Attendee" should have the same instances, but the "Attendee" does not have the referenced instance. In this case the "Attendee" SHOULD send a "REFRESH" to the "Organizer" to get an updated version of the event.
場合(2)では、何かが支障をきたしました。 「オーガナイザー」と「出席者」の両方には、同じ例があるべきですが、「出席者」では、参照をつけられた例がありません。 この場合、「出席者」SHOULDは、出来事のアップデートされたバージョンを得るために「オーガナイザー」への「リフレッシュしてください」を送ります。
In case (3), the limitations of the "Attendee's" CUA makes it impossible to match an instance other than the single instance scheduled. In this case, the "Attendee" need not send a "REFRESH" to the "Organizer".
(3)、」 CUAがそれをする「の出席者制限をただ一つの例以外の例が計画をしたマッチに不可能な状態で中にケースに入れてください。 この場合、「出席者」は「オーガナイザー」への「リフレッシュしてください」を送る必要はありません。
The example below shows a sequence in which an "Attendee" sends a "REFRESH" to the "Organizer".
どの「出席者」の系列が「オーガナイザー」への「リフレッシュしてください」を送るショーの下における例。
Silverberg, et. al. Standards Track [Page 95] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[95ページ]。
+--------------------------------------------------------------------+ | Action | "Organizer" | Attendee | +--------------------------------------------------------------------+ | Update an instance | "A" sends "REQUEST"| | | request | message to "B" | | +--------------------------------------------------------------------+ | Attendee requests | | "B" sends a "REFRESH" | | refresh because | | message to "A" | | "RECURRENCE-ID" was| | | | not found | | | +--------------------------------------------------------------------+ | Refresh the entire | "A" sends the | | | Event | latest copy of the | | | | Event to "B" | | +--------------------------------------------------------------------+ | Attendee handles | | "B" updates to the | | the request and | | latest copy of the | | updates the | | meeting. | | instance | | | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | 動作| 「オーガナイザー」| 出席者| +--------------------------------------------------------------------+ | 例をアップデートしてください。| 「A」は「要求」を送ります。| | | 要求| 「B」へのメッセージ| | +--------------------------------------------------------------------+ | 出席者要求| | 「B」は「リフレッシュ」を送ります。| | リフレッシュ| | 「A」へ通信してください。| | 「RECURRENCE-ID」はそうでした。| | | | 見つけられません。| | | +--------------------------------------------------------------------+ | 全体をリフレッシュしてください。| 「A」は発信します。| | | 出来事| 最新のものはコピーします。| | | | 「B」への出来事| | +--------------------------------------------------------------------+ | 出席者ハンドル| | 「B」はアップデートします。| | そして要求。| | 最新のものはコピーします。| | アップデート| | ミーティング。 | | 例| | | +--------------------------------------------------------------------+
Request from "A":
「A」から以下を要求してください。
BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VEVENT UID:acme-12345@host1.com SEQUENCE:3 RRULE:FREQ=WEEKLY RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z ORGANIZER:Mailto:A@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com ATTENDEE:Mailto:B@example.com DESCRIPTION:IETF-C&S Conference Call SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970801T210000Z DTEND:19970801T220000Z RECURRENCE-ID:19970809T210000Z DTSTAMP:19970726T083000 STATUS:CONFIRMED END:VEVENT END:VCALENDAR
始まってください: VCALENDAR方法: PRODIDを要求してください: -//RDUソフトウェア//NONSGML HandCal//アンバージョン: 2.0は始まります: VEVENT UID: acme-12345@host1.com 系列: 3RRULE: FREQは毎週のRDATEと等しいです; =期間を評価してください: 19970819T210000Z/199700819T220000Zオーガナイザー:Mailto: A@example.com 出席者; ROLE=議長; PARTSTAT=は受け入れました: Mailto: A@example com ATTENDEE:Mailto: B@example.com 記述: Meeting DTSTART: 19970801T210000Z DTEND: 19970801T220000Z RECURRENCE ID: IETF-CとSコンファレンスCall SUMMARY: IETF Calendaring作業部会19970809T210000Z DTSTAMP:19970726T083000 STATUS:CONFIRMED END:VEVENT END:VCALENDAR
"B" has the event with "UID" property "acme-12345@host1.com" but "B's" "SEQUENCE" property value is "1" and the event does not have an instance at the specified recurrence time. This means that "B" has
「B」には、"UID"の特性の" acme-12345@host1.com "がある出来事がありますが、「ビーズ」「系列」資産価値は「1インチと出来事では、指定された再発時間に、例がありません」です。 「B」にはあるこの手段
Silverberg, et. al. Standards Track [Page 96] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[96ページ]。
missed at least one update and needs a new copy of the event. "B" requests the latest copy of the event with the following refresh message:
少なくとも1つのアップデートを逃して、出来事の新しいコピーを必要とします。 「B」は、以下がある出来事の最新のコピーがメッセージをリフレッシュするよう要求します:
BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//EN METHOD:REFRESH VERSION:2.0 BEGIN:VEVENT ORGANIZER:Mailto:A@example.com ATTENDEE:Mailto:B@example.com UID:acme-12345@host1.com DTSTAMP:19970603T094000 END:VEVENT END:VCALENDAR
始まってください: VCALENDAR PRODID: -//RDUソフトウェア//NONSGML HandCal//アン方法: : 2.0が始めるバージョン: VEVENTオーガナイザー:Mailto: A@example.com 出席者:Mailto: B@example.com UID: acme-12345@host1.com DTSTAMP: 19970603T094000エンド: VEVENTエンド: VCALENDARをリフレッシュしてください。
5 Application Protocol Fallbacks
5 アプリケーション・プロトコル後退
5.1 Partial Implementation
5.1 部分的な実現
Applications that support this memo are not required to support the entire protocol. The following describes how methods and properties SHOULD "fallback" in applications that do not support the complete protocol. If a method or property is not addressed in this section, it may be ignored.
このメモを支えるアプリケーションは、全体のプロトコルをサポートするのに必要ではありません。 以下はそうしないアプリケーションにおける方法と特性のSHOULD「後退」がどう完全なプロトコルをサポートするかを説明します。 方法か特性がこのセクションで記述されないなら、それは無視されるかもしれません。
5.1.1 Event-Related Fallbacks
5.1.1 イベント関連の後退
Method Fallback
-------------- -----------------------------------------------------
PUBLISH Required
REQUEST PUBLISH
REPLY Required
ADD Required
CANCEL Required
REFRESH Required
COUNTER Reply with Not Supported
DECLINECOUNTER Required if EVENT-COUNTER is implemented; otherwise
reply with Not Supported
方法後退-------------- ----------------------------------------------------- Not Supported DECLINECOUNTER RequiredとPUBLISH Required REQUEST PUBLISH REPLY Required ADD RequiredキャンセルRequired REFRESH Required COUNTER ReplyはEVENT-COUNTERであるなら実行されます。 さもなければ、Not Supportedと共に返答してください。
iCalendar Property Fallback -------------- ----------------------------------------------------- CALSCALE Ignore; assume GREGORIAN PRODID Ignore METHOD Required as described in the Method list above VERSION Ignore
iCalendar特性の後退-------------- ----------------------------------------------------- CALSCALE、無視します。 バージョンIgnoreの上のMethodリストで説明されるようにグレゴリオのPRODID Ignore METHOD Requiredを仮定してください。
Silverberg, et. al. Standards Track [Page 97] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[97ページ]。
Event-Related Components Fallback -------------- ----------------------------------------------------- VALARM Reply with Not Supported VTIMEZONE Required if any DateTime value refers to a time zone.
イベント関連のコンポーネント後退-------------- ----------------------------------------------------- もしあればNot Supported VTIMEZONE RequiredとVALARM Replyは時間帯について言及しますDateTimeが、評価する。
Component
Property Fallback
-------------- -----------------------------------------------------
ATTACH Ignore
ATTENDEE Required if EVENT-REQUEST is not implemented;
otherwise reply with Not Supported
CATEGORIES Ignore
CLASS Ignore
COMMENT Ignore
COMPLETED Ignore
nCONTACT Ignore
CREATED Ignore
DESCRIPTION Required
DURATION Reply with Not Supported
DTSTAMP Required
DTSTART Required
DTEND Required
EXDATE Ignore
EXRULE Ignore Reply with Not Supported. If implemented,
VTIMEZONE MUST also be implemented.
GEO Ignore
LAST-MODIFIED Ignore
LOCATION Required
ORGANIZER Ignore
PRIORITY Ignore
RELATED-TO Ignore
RDATE Ignore
RRULE Ignore. The first instance occurs on the DTStart
property. If implemented, VTIMEZONE MUST also be
implemented.
RECURRENCE-ID Required if RRULE is implemented; otherwise Ignore
REQUEST-STATUS Required
RESOURCES Ignore
SEQUENCE Required
STATUS Ignore
SUMMARY Ignore
TRANSP Required if FREEBUSY is implemented; otherwise Ignore
URL Ignore
UID Required
X- Ignore
コンポーネント特性の後退-------------- ----------------------------------------------------- ATTACH Ignore ATTENDEE RequiredはEVENT-REQUESTであるなら実行されません。 さもなければ、Not Supported CATEGORIES Ignore CLASS Ignore COMMENT Ignore COMPLETED Ignore nCONTACT Ignore CREATED Ignore記述Required DURATION Replyと共にNot SupportedとNot Supported DTSTAMP Required DTSTART Required DTEND Required EXDATE Ignore EXRULE Ignore Replyで返答してください。 実行されるならVTIMEZONE MUST、また、実行されてください。 RRULEを無視してください。GEOが無視する、最後の変更、無視、位置の必要なオーガナイザーが優先権を無視する、無視、関連されて、RDATEを無視してください、無視します。 最初の例はDTStart所有地の上に起こります。 実行されるならVTIMEZONE MUST、また、実行されてください。 RECURRENCE-ID RequiredはRRULEであるなら実行されます。 そうでなければIgnore REQUEST-STATUS Required RESOURCES Ignore SEQUENCE Required STATUS Ignore SUMMARY Ignore TRANSP RequiredはFREEBUSYであるなら実行されます。 そうでなければIgnore UID Required Xが無視するIgnore URL
Silverberg, et. al. Standards Track [Page 98] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[98ページ]。
5.1.2 Free/Busy-Related Fallbacks
5.1.2 自由であるか忙しい関連の後退
Method Fallback
-------------- -----------------------------------------------------
PUBLISH Implementations MAY ignore the METHOD type. The
REQUEST-STATUS "3.14;Unsupported capability" MUST be
returned.
REQUEST Implementations MAY ignore the METHOD type. The
REQUEST-STATUS "3.14;Unsupported capability" MUST be
returned.
REPLY Implementations MAY ignore the METHOD type. The
REQUEST-STATUS "3.14;Unsupported capability" MUST be
returned.
方法後退-------------- ----------------------------------------------------- PUBLISH ImplementationsはMETHODタイプを無視するかもしれません。 REQUEST-STATUS「サポートされない3.14;能力」を返さなければなりません。 REQUEST ImplementationsはMETHODタイプを無視するかもしれません。 REQUEST-STATUS「サポートされない3.14;能力」を返さなければなりません。 REPLY ImplementationsはMETHODタイプを無視するかもしれません。 REQUEST-STATUS「サポートされない3.14;能力」を返さなければなりません。
iCalendar Property Fallback -------------- ----------------------------------------------------- CALSCALE Ignore; assume GREGORIAN. PRODID Ignore METHOD Required as described in the Method list above. VERSION Ignore
iCalendar特性の後退-------------- ----------------------------------------------------- CALSCALE、無視します。 グレゴリオであると仮定します。 Methodで説明されるPRODID Ignore METHOD Requiredは上に記載します。 バージョンは無視します。
Component Property Fallback -------------- ----------------------------------------------------- COMMENT Ignore CONTACT Ignore DTEND Required DTSTAMP Required DTSTART Required DURATION Required FREEBUSY Required ORGANIZER Ignore REQUEST-STATUS Ignore UID Required URL Ignore X- Ignore
コンポーネント特性の後退-------------- ----------------------------------------------------- コメントが無視する、接触が状態を要求する状態で必要なFREEBUSY必要なオーガナイザーが無視するDTENDの必要なDTSTAMP必要なDTSTART必要な持続時間を無視する、無視、UIDの必要なURLがXを無視する、無視
5.1.3 To-Do-Related Fallbacks
5.1.3 大騒ぎ関連の後退
Method Fallback -------------- ----------------------------------------------------- PUBLISH Required REQUEST PUBLISH REPLY Required ADD Required
方法後退-------------- ----------------------------------------------------- 発行、必要であることで、必要である回答を発行するよう要求してください、必要な状態で、加えてください。
Silverberg, et. al. Standards Track [Page 99] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[99ページ]。
CANCEL Required
REFRESH Required
COUNTER Reply with Not Supported
DECLINECOUNTER Required if VTODO - COUNTER is implemented; otherwise
reply with Not Supported
キャンセルRequired REFRESH Required COUNTER Reply、--VTODOであるならNot Supported DECLINECOUNTER Requiredと共に、COUNTERは実行されます。 さもなければ、Not Supportedと共に返答してください。
iCalendar Property Fallback -------------- ----------------------------------------------------- CALSCALE Ignore; assume GREGORIAN. PRODID Ignore METHOD Required as described in the Method list above. VERSION Ignore
iCalendar特性の後退-------------- ----------------------------------------------------- CALSCALE、無視します。 グレゴリオであると仮定します。 Methodで説明されるPRODID Ignore METHOD Requiredは上に記載します。 バージョンは無視します。
To-Do-Related Components Fallback -------------- ----------------------------------------------------- VALARM Reply with Not Supported VTIMEZONE Required if any DateTime value refers to a time zone.
大騒ぎ関連のコンポーネント後退-------------- ----------------------------------------------------- もしあればNot Supported VTIMEZONE RequiredとVALARM Replyは時間帯について言及しますDateTimeが、評価する。
Component
Property Fallback
-------------- -----------------------------------------------------
ATTACH Ignore
ATTENDEE Required if REQUEST is not implemented; otherwise
ignore
CATEGORIES Ignore
CLASS Ignore
COMMENT Ignore
COMPLETED Required
CONTACT Ignore
CREATED Ignore
DESCRIPTION Required
DUE Required
DURATION Ignore Reply with Not Supported
DTSTAMP Required
DTSTART Required
EXDATE Ignore Reply with Not Supported
EXRULE Ignore Reply with Not Supported. If implemented,
VTIMEZONE MUST also be implemented.
LAST-MODIFIED Ignore
LOCATION Ignore
ORGANIZER Ignore
PERCENT-COMPLETE Ignore
PRIORITY Required
RECURRENCE-ID Ignore
コンポーネント特性の後退-------------- ----------------------------------------------------- ATTACH Ignore ATTENDEE RequiredはREQUESTであるなら実行されません。 さもなければ、Not SupportedとNot Supported EXRULE Ignore ReplyとNot Supported DTSTAMP Required DTSTART Required EXDATE Ignore ReplyとCATEGORIES Ignore CLASS Ignore COMMENT Ignore COMPLETED Required CONTACT Ignore CREATED Ignore記述Required DUE Required DURATION Ignore Replyを無視してください。 実行されるならVTIMEZONE MUST、また、実行されてください。 最後の変更、無視、位置がオーガナイザーを無視する、無視、パーセント完全である、必要なRECURRENCE IDが無視する優先権を無視してください。
Silverberg, et. al. Standards Track [Page 100] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[100ページ]。
RELATED-TO Ignore
REQUEST-STATUS Ignore
RDATE Ignore
RRULE Ignore. The first instance occurs on the DTSTART
property. If implemented, VTIMEZONE MUST also be
implemented.
RESOURCES Ignore
SEQUENCE Required
STATUS Required
SUMMARY Ignore
URL Ignore
UID Required
X- Ignore
RDATEはRRULEを無視します。関連されて、要求状態を無視してください、無視、無視します。 最初の例はDTSTART所有地の上に起こります。 実行されるならVTIMEZONE MUST、また、実行されてください。 リソースが必要な概要が無視する系列求めらる資格を無視する、URLがUIDの必要なXを無視する、無視
5.1.4 Journal-Related Fallbacks
5.1.4 ジャーナル関連の後退
Method Fallback
-------------- -----------------------------------------------------
PUBLISH Implementations MAY ignore the METHOD type. The
REQUEST-STATUS "3.14;Unsupported capability" MUST be
returned.
ADD Implementations MAY ignore the METHOD type. The
REQUEST-STATUS "3.14;Unsupported capability" MUST be
returned.
CANCEL Implementations MAY ignore the METHOD type. The
REQUEST-STATUS "3.14;Unsupported capability" MUST be
returned.
方法後退-------------- ----------------------------------------------------- PUBLISH ImplementationsはMETHODタイプを無視するかもしれません。 REQUEST-STATUS「サポートされない3.14;能力」を返さなければなりません。 ADD ImplementationsはMETHODタイプを無視するかもしれません。 REQUEST-STATUS「サポートされない3.14;能力」を返さなければなりません。 キャンセルImplementationsはMETHODタイプを無視するかもしれません。 REQUEST-STATUS「サポートされない3.14;能力」を返さなければなりません。
iCalendar Property Fallback -------------- ----------------------------------------------------- CALSCALE Ignore; assume GREGORIAN. PRODID Ignore METHOD Required as described in the Method list above. VERSION Ignore
iCalendar特性の後退-------------- ----------------------------------------------------- CALSCALE、無視します。 グレゴリオであると仮定します。 Methodで説明されるPRODID Ignore METHOD Requiredは上に記載します。 バージョンは無視します。
Journal-Related Components Fallback -------------- ----------------------------------------------------- VTIMEZONE Required if any DateTime value refers to a time zone.
ジャーナル関連のコンポーネント後退-------------- ----------------------------------------------------- もしあればVTIMEZONE Requiredは時間帯について言及しますDateTimeが、評価する。
Silverberg, et. al. Standards Track [Page 101] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[101ページ]。
Component
Property Fallback
-------------- -----------------------------------------------------
ATTACH Ignore
ATTENDEE Required if JOURNAL-REQUEST is implemented; otherwise
ignore
CATEGORIES Ignore
CLASS Ignore
COMMENT Ignore
CONTACT Ignore
CREATED Ignore
DESCRIPTION Required
DTSTAMP Required
DTSTART Required
EXDATE Ignore
EXRULE Ignore Reply with Not Supported. If implemented,
VTIMEZONE MUST also be implemented.
LAST-MODIFIED Ignore
ORGANIZER Ignore
RECURRENCE-ID Ignore
RELATED-TO Ignore
RDATE Ignore.
RRULE Ignore. The first instance occurs on the DTSTART
property. If implemented, VTIMEZONE MUST also be
implemented.
SEQUENCE Required
STATUS Ignore
SUMMARY Required
URL Ignore
UID Required
X- Ignore
コンポーネント特性の後退-------------- ----------------------------------------------------- ATTACH Ignore ATTENDEE RequiredはJOURNAL-REQUESTであるなら実行されます。 さもなければ、Not SupportedとCATEGORIES Ignore CLASS Ignore COMMENT Ignore CONTACT Ignore CREATED Ignore記述Required DTSTAMP Required DTSTART Required EXDATE Ignore EXRULE Ignore Replyを無視してください。 実行されるならVTIMEZONE MUST、また、実行されてください。 RDATEを無視してください。最後の変更、無視、オーガナイザーが無視する、関連されて、RECURRENCE IDが無視する、無視します。 RRULEは無視します。 最初の例はDTSTART所有地の上に起こります。 実行されるならVTIMEZONE MUST、また、実行されてください。 系列求めらる資格が無視する、要約の必要なURLがUIDの必要なXを無視する、無視
5.2 Latency Issues
5.2 潜在問題
With a store-and-forward transport, it is possible for events to arrive out of sequence. That is, a "CANCEL" method may be received prior to receiving the associated "REQUEST" for the calendar component. This section discusses a few of these scenarios.
店とフォワード輸送では、出来事が順序が狂って到着するのは、可能です。 カレンダーコンポーネントを求める関連「要求」を受ける前に、すなわち、「キャンセル」方法を受け取るかもしれません。 このセクションはこれらのシナリオのいくつかについて論じます。
5.2.1 Cancellation of an Unknown Calendar Component.
5.2.1 未知のカレンダーコンポーネントのキャンセル。
When a "CANCEL" method is received before the original "REQUEST" method the calendar will be unable to correlate the "UID" property of the cancellation with an existing calendar component. It is suggested that messages that can not be correlated that also contain non-zero sequence numbers be held and not discarded. Implementations MAY age them out if no other messages arrive with the same "UID" property value and a lower sequence number.
オリジナルの「要求」方法の前に「キャンセル」方法を受け取るとき、カレンダーは既存のカレンダーコンポーネントによるキャンセルの"UID"の特性を関連させることができないでしょう。 それが関連できないというまた、非ゼロ一連番号を含むメッセージが保持されて、捨てられないことが提案されます。 他のメッセージが全く同じ"UID"資産価値と下側の一連番号と共に到着しないなら、実現はそれらに年をとらせるかもしれません。
Silverberg, et. al. Standards Track [Page 102] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[102ページ]。
5.2.2 Unexpected Reply from an Unknown Delegate
5.2.2 未知の代表からの予期しない返答
When an "Attendee" delegates an item to another CU they MUST send a "REPLY" method to the "Organizer" using the "ATTENDEE" properties to indicate that the request was delegated and to whom. Hence, it is possible for an "Organizer" to receive an "REPLY" from a CU not listed as one of the original "Attendees". The resolution is left to the implementation but it is expected that the calendaring software will either accept the reply or hold it until the related "REPLY" method is received from the "Delegator". If the version of the "REPLY" method is out of date the "Organizer" SHOULD treat the message as a "REFRESH" message and update the delegate with the correct version.
「出席者」が別のCUへ商品を代表として派遣するとき、要求が代表として派遣されたのを示すのに「出席者」の特性を使用して、だれに送って、彼らは「回答」方法を「オーガナイザー」に送らなければなりません。 したがって、「オーガナイザー」がオリジナルの「出席者」の1つとして記載されなかったCuから「回答」を受けるのは、可能です。 解決は実現に残されますが、calendaringソフトウェアが"Delegator"から関連する「回答」方法を受け取るまで回答を受け入れるか、またはそれを保持すると予想されます。 「回答」方法のバージョンが時代遅れであるなら、「オーガナイザー」は、「リフレッシュしてください」というメッセージとしてメッセージを扱って、正しいバージョンで代表をアップデートするべきです。
5.3 Sequence Number
5.3 一連番号
Under some conditions, a CUA may receive requests and replies with the same "SEQUENCE" property value. The "DTSTAMP" property is utilized as a tie-breaker when two items with the same "SEQUENCE" property value are evaluated.
いくつかの条件のもとでは、CUAは同じ「系列」資産価値で要求と回答を受け取るかもしれません。 同じ「系列」資産価値がある2つの項目が評価されるとき、"DTSTAMP"の特性はタイブレークとして利用されます。
6 Security Considerations
6 セキュリティ問題
ITIP is an abstract transport protocol which will be bound to a real-time transport, a store-and-forward transport, and perhaps other transports. The transport protocol will be responsible for providing facilities for authentication and encryption using standard Internet mechanisms that are mutually understood between the sender and receiver.
ITIPはリアルタイムの輸送に縛られる、抽象的なトランスポート・プロトコルと、店とフォワード輸送と、恐らく他の輸送です。 トランスポート・プロトコルは認証と暗号化のために送付者と受信機の間で互いに理解されている標準のインターネットメカニズムを使用することで便宜を与えるのに原因となるようになるでしょう。
6.1 Security Threats
6.1 セキュリティの脅威
6.1.1 Spoofing the "Organizer"
6.1.1 「オーガナイザー」をだますこと。
In iTIP, the "Organizer" (or someone working on the "Organizer's" behalf) is the only person authorized to make changes to an existing "VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or redistribute updates to the "Attendees". An iCalendar object that maliciously changes or cancels an existing "VEVENT", "VTODO" or "VJOURNAL" calendar component may be constructed by someone other than the "Organizer" and republished or sent to the "Attendees".
iTIPでは、「オーガナイザー」(または、「をオーガナイザー」 利益を扱っているだれか)は「出席者」に既存の"VEVENT"、"VTODO""VJOURNAL"カレンダーコンポーネントへの変更を行って、それを再刊するか、またはアップデートを再配付するのに権限を与えられた唯一の人です。 陰湿に既存の"VEVENT"、"VTODO"または"VJOURNAL"カレンダーコンポーネントを変えるか、または取り消すiCalendar物を、「出席者」に「オーガナイザー」を除いただれかが組み立てて、再刊するか、または送るかもしれません。
6.1.2 Spoofing the "Attendee"
6.1.2 「出席者」をだますこと。
In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component (or someone working on the "Attendee's" behalf) is the only person authorized to update any parameter associated with their "ATTENDEE" property and send it to the "Organizer". An iCalendar object that
iTIPでは、"VEVENT"か"VTODO"カレンダーコンポーネント(または、「を出席者」 利益を扱っているだれか)の「出席者」は彼らの「出席者」の特性に関連しているどんなパラメタもアップデートして、「オーガナイザー」にそれを送るのに権限を与えられた唯一の人です。 iCalendar物、それ
Silverberg, et. al. Standards Track [Page 103] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[103ページ]。
maliciously changes the "ATTENDEE" parameters may be constructed by someone other than the real "Attendee" and sent to the "Organizer".
陰湿に、本当の「出席者」を除いただれかが組み立てて、「オーガナイザー」に送って、パラメタがそうするかもしれない「出席者」を変えます。
6.1.3 Unauthorized Replacement of the Organizer
6.1.3 オーガナイザーの権限のない交換
There will be circumstances when "Attendees" of an event or to-do decide, using out-of-band mechanisms, that the "Organizer" must be replaced. When the new "Organizer" sends out the updated "VEVENT" or "VTODO" the "Attendee's" CUA will detect that the "Organizer" has been changed, but it has no way of knowing whether or not the change was mutually agreed upon.
出来事か大騒ぎの「出席者」が決めるとき、事情があるでしょう、バンドの外でメカニズムを使用してその「オーガナイザー」を取り替えなければなりません。 新しい「オーガナイザー」がアップデートされた"VEVENT"を出すか、または「」 VTODO「出席者」のクーアがそれを検出すると、「オーガナイザー」を変えましたが、それには、変化が互いに同意されたかどうかを知る方法が全くありません。
6.1.4 Eavesdropping
6.1.4 雨垂れ
The iCalendar object is constructed with human-readable clear text. Any information contained in an iCalendar object may be read and/or changed by unauthorized persons while the object is in transit.
iCalendar物は人間読み込み可能なクリアテキストで組み立てられます。 物がトランジット中である間、iCalendar物に含まれたどんな情報も、権限のない人によって読まれる、そして/または、変えられるかもしれません。
6.1.5 Flooding a Calendar
6.1.5 カレンダーをあふれさせること。
Implementations MAY provide a means to automatically incorporate "REQUEST" methods into a calendar. This presents the opportunity for a calendar to be flooded with requests, which effectively block all the calendar's free time.
実現は自動的に「要求」方法をカレンダーに組み入れる手段を提供するかもしれません。 これは要求がカレンダーに殺到する機会を提示します。事実上、要求はすべてを妨げます。カレンダーの空き時間。
6.1.6 Procedural Alarms
6.1.6 手続き上のアラーム
The "REQUEST" methods for "VEVENT" and "VTODO" calendar components MAY contain "VALARM" calendar components. The "VALARM" calendar component may be of type "PROCEDURE" and MAY have an attachment containing an executable program. Implementations that incorporate these types of alarms are subject to any virus or malicious attack that may occur as a result of executing the attachment.
"VEVENT"と"VTODO"カレンダーコンポーネントのための「要求」方法は"VALARM"カレンダーコンポーネントを含むかもしれません。 "VALARM"カレンダーコンポーネントには、タイプ「手順」があって、実行可能プログラムを含む付属があるかもしれません。 これらのタイプに関するアラームを組み込む実現は付属を実行することの結果、起こるどんなウイルスや悪意ある攻撃にもなりやすいです。
6.1.7 Unauthorized REFRESH Requests
6.1.7 権限のない、要求をリフレッシュしてください。
It is possible for an "Organizer" to receive a "REFRESH" request from someone who is not an "Attendee" of an event or to-do. Only "Attendee's" of an event or to-do are authorized to receive replies to "REFRESH" requests. Replying to such requests to anyone who is not an "Attendee" may be a security problem.
「オーガナイザー」が出来事か大騒ぎの「出席者」でないだれかから「リフレッシュしてください」という要求を受け取るのは、可能です。 「だけ出席者」 認可された出来事か大騒ぎでは、受信するのは、要求を「リフレッシュする」ために返答します。 だれへのもどんな「出席者」もだれでないかというそのような要求に答えるのは、警備上の問題であるかもしれません。
6.2 Recommendations
6.2 推薦
For an application where the information is sensitive or critical and the network is subject is subject to a high probability of attack, iTIP transactions SHOULD be encrypted. This may be accomplished using public key technology, specifically Security Multiparts for MIME
情報が機密であるか、または批判的であり、ネットワークが対象は攻撃の高い確率を受けることがあります、iTIP取引SHOULDということであるアプリケーションには、コード化されてください。 これは、MIMEに公開鍵技術、明確にSecurity Multipartsを使用することで達成されるかもしれません。
Silverberg, et. al. Standards Track [Page 104] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[104ページ]。
[RFC-1847] in the iTIP transport binding. This helps mitigate the threats of spoofing, eavesdropping and malicious changes in transit.
iTIPの[RFC-1847]は結合を輸送します。 これは、トランジットにおける、スプーフィング、雨垂れ、および悪意がある変化の脅威を緩和するのを助けます。
6.2.1 Use of [RFC-1847] to secure iTIP transactions
6.2.1 iTIP取引を保証する[RFC-1847]の使用
iTIP transport bindings MUST provide a mechanism based on Security Multiparts for MIME [RFC-1847] to enable authentication of the sender's identity, and privacy and integrity of the data being transmitted. This allows the receiver of a signed iCalendar object to verify the identity of the sender. This sender may then be correlated to an "ATTENDEE" property in the iCalendar object. If the correlation is made and the sender is authorized to make the requested change or update then the operation may proceed. It also allows the message to be encrypted to prevent unauthorized reading of the message contents in transit. iTIP transport binding documents describe this process in detail.
iTIP輸送結合はMIME[RFC-1847]が送られるデータの送付者のアイデンティティの認証、プライバシー、および保全を可能にするようにSecurity Multipartsに基づくメカニズムを提供しなければなりません。 これで、サインされたiCalendar物の受信機は送付者のアイデンティティについて確かめることができます。 そして、この送付者はiCalendar物の「出席者」の特性に関連するかもしれません。 相関関係が作られていて、送付者が要求された変更かアップデートを行うのに権限を与えられるなら、操作は続くかもしれません。 また、それはトランジットにおける、メッセージ内容の権限のない読書を防ぐためにコード化されるべきメッセージを許容します。iTIPは詳細にこの過程について説明します輸送結合が、ドキュメントである。
Implementations MAY provide controls for users to disable this capability.
ユーザがこの能力を無効にするように、実現はコントロールを提供するかもしれません。
6.2.2 Implementation Controls
6.2.2 実現コントロール
The threat of unauthorized replacement of the "Organizer" SHOULD be mitigated by a calendar system that uses this protocol by providing controls or alerts that make "Calendar Users" aware of such "Organizer" changes and allowing them to decide whether or not the request should be honored.
「オーガナイザー」SHOULDの権限のない交換が、コントロールを提供することによってこのプロトコルを使用するカレンダーシステムか「カレンダーユーザ」をそのような「オーガナイザー」変化を意識するようにする警戒によって緩和されて、要求が光栄に思うべきであるかどうか決めるのを許容する脅威。
The threat of flooding a calendar SHOULD be mitigated by a calendar system that uses this protocol by providing controls that may be used to limit the acceptable sources for iTIP transactions, and perhaps the size of messages and volume of traffic, by source.
脅威、カレンダーSHOULDをあふれさせるのにおいて、iTIP取引のための許容できるソース、およびメッセージと交通量のサイズを制限するのに使用されるかもしれないコントロールを提供することによってこのプロトコルを使用するカレンダーシステムによって緩和されてください、ソースで。
The threat of malicious procedural alarms SHOULD be mitigated by a calendar system that uses this protocol by providing controls that may be used to disallow procedural alarms in iTIP transactions and/or remove all alarms from the object before delivery to the recipient.
悪意がある手続き上のアラームSHOULDの脅威は、iTIP取引で手続き上のアラームを禁じるのに使用されるかもしれないコントロールを提供しながらこのプロトコルを使用するカレンダーシステムによって緩和される、そして/または、配送の前の物から受取人まですべてのアラームを取り除きます。
The threat of unauthorized "REFRESH" requests SHOULD be mitigated by a calendar system that uses this protocol by providing controls or alerts that allow "Calendar User" to decide whether or not the request should be honored. An implementation MAY decide to maintain, for audit or historical purposes, "Calendar Users" who were part of an attendee list and who were subsequently uninvited. Similar controls or alerts should be provided when a "REFRESH" request is received from these "Calendar Users" as well.
「リフレッシュしてください」という権限のない要求の脅威はコントロールを提供することによってこのプロトコルを使用するカレンダーシステムか「カレンダーユーザ」が要求が光栄に思うべきであるかどうか決めることができる警戒によって緩和されるべきです。 実現は、監査か歴史的な目的のために出席者リストの一部である、次に押しかけのである「カレンダーユーザ」を維持すると決めるかもしれません。 また、これらの「カレンダーユーザ」から「リフレッシュしてください」という要求を受け取るとき、同様のコントロールか警戒を提供するべきです。
Silverberg, et. al. Standards Track [Page 105] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[105ページ]。
7 Acknowledgments
7つの承認
A hearty thanks to the following individuals who have participated in the drafting, review and discussion of this memo:
草稿に参加した以下の個人への心からの感謝、レビュー、およびこのメモの議論:
Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug Royer, Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun, Alexander Taler, Kevin Tsurutome.
ガングリー、アーニク衛星ダン・ヒックマン、ポール・ヒル、ダリルHuff、ブルース・カーン、アントワーヌ・ルカ、ボブ・マホニー、ジョンNoerenberg、レオ・パーカー、ジョンは上昇しました、ダグ・ロワイエー、Vinod Seraphin、リチャードShusterman、Derik Stenerson、ジョンSun、アレクサンダーTaler、ケビンTsurutome。
8 Bibliography
8 図書目録
[iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification - iCalendar", RFC
2445, November 1998.
[iCAL] ドーソン、F.、およびD.Stenerson、「インターネットCalendaringとスケジューリングは物の仕様の芯を取ります--iCalendar」、RFC2445、11月1998日
[iMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
Message-Based Interoperability Protocol - iMIP", RFC 2447,
November 1998.
[iMIP] ドーソン、F.、マンスール、S.、およびS.シルバーバーグ、「iCalendarのメッセージベースの相互運用性は議定書を作ります--iMIP」、RFC2447、11月1998日
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[US-ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
Silverberg, et. al. Standards Track [Page 106] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[106ページ]。
9 Authors' Addresses
9人の作者のアドレス
The following address information is provided in a vCard v3.0, Electronic Business Card, format.
vCard v3.0、Electronic Business Card、形式に以下のアドレス情報を提供します。
The authors of this memo are:
このメモの作者は以下の通りです。
BEGIN:VCARD
VERSION:3.0
N:Dawson;Frank
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-
3502;USA
TEL;TYPE=WORK,MSG:+1-919-676-9515
TEL;TYPE=WORK,FAX:+1-919-676-9564
EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD
VCARDバージョン: 3.0に以下を始めてください。N: ドーソン; フランクFN: フランクドーソンORG: Lotus Development Corporation ADR; 仕事; 郵便である;は以下を包みにします。6544年のバトルフォードのドライブ; ローリー; NC; 27613- 3502; 米国TEL;は=仕事、エムエスジーをタイプします: +1-919-676-9515 TEL; タイプ=仕事、Fax:+1-919-676-9564メール;はインターネット: =PREF、 Frank_Dawson@Lotus.com メールをタイプします; =インターネット: fdawson@earthlink.net URL: http://home.earthlink.net/~fdawsonエンド: VCARDをタイプしてください。
BEGIN:VCARD
VERSION:3.0
N:Hopson;Ross
FN:Ross Hopson
ORG:On Technology, Inc.
ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 1600;434 Fayetteville St.
Mall\, Two Hannover Square;Raleigh;NC;27601
TEL;TYPE=WORK,MSG:+1-919-890-4036
TEL;TYPE=WORK,FAX:+1-919-890-4100
EMAIL;TYPE=INTERNET:rhopson@on.com
END:VCARD
N: ホプソン; ロスFN: 技術Inc.のADR; タイプする=仕事をであって、郵便のロスホプソンORG、以下を包みにしてください; VCARDバージョン: 3.0に以下を始めてください、そして、エムエスジー: +1-919-890-4036 TEL; タイプ=仕事、Fax:+1-919-890-4100メール; \、2ハノーバー正方形; ローリー; NC; 27601TEL; タイプ=が扱うスイート1600;434フェーエットビル聖ショッピングセンター、タイプはインターネット: rhopson@on.com エンド: VCARDと等しいです。
BEGIN:VCARD
VERSION:3.0
N:Mansour;Steve
FN:Steve Mansour
ORG:Netscape Communications Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain
View;CA;94043;USA
TEL;TYPE=WORK,MSG:+1-650-937-2378
TEL;TYPE=WORK,FAX:+1-650-937-2103
EMAIL;TYPE=INTERNET:sman@netscape.com
END:VCARD
始まってください: VCARDバージョン: N: マンスール; スティーブFN: スティーブマンスールORG: ネットスケープ社ADR; タイプ=が扱う郵便であることの3.0は以下を包みにします。501の東Middlefield道路; マウンテンビュー; カリフォルニア; 94043; 米国TEL;は=仕事、エムエスジーをタイプします: +1-650-937-2378 TEL; タイプ=仕事、Fax:+1-650-937-2103メール;は=インターネット: sman@netscape.com エンド: VCARDをタイプします。
Silverberg, et. al. Standards Track [Page 107] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[107ページ]。
BEGIN:VCARD VERSION:3.0 N:Silverberg;Steve FN:Steve Silverberg ORG:Microsoft Corporation ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; Redmond;WA;98052-6399;USA TEL;TYPE=WORK,MSG:+1-425-936-9277 TEL;TYPE=WORK,FAX:+1-425-936-8019 EMAIL;INTERNET:stevesil@Microsoft.com END:VCARD
始まってください: VCARDバージョン: N: シルバーバーグ; スティーブFN: スティーブシルバーバーグORG: マイクロソフト社ADR; タイプ=が扱う郵便であることの3.0は以下を包みにします。1つのマイクロソフト方法。 仕事、レッドモンド; ワシントン; 98052-6399; 米国TEL; タイプ=エムエスジー: +1-425-936-9277 TEL; タイプ=仕事、Fax:+1-425-936-8019メール; インターネット: stevesil@Microsoft.com エンド: VCARD
The iCalendar object is a result of the work of the Internet Engineering Task Force Calendaring and scheduling Working Group. The chairman of that working group is:
iCalendar物はインターネット・エンジニアリング・タスク・フォースCalendaringとスケジューリング作業部会の仕事の結果です。 そのワーキンググループの議長は以下の通りです。
BEGIN:VCARD
VERSION:3.0
N:Ganguly;Anik
FN:Anik Ganguly
ORG:Open Text Inc.
ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
Livonia;MI;48152;USA
TEL;TYPE=WORK,MSG:+1-734-542-5955
EMAIL;TYPE=INTERNET:ganguly@acm.org
END:VCARD
始まってください: VCARDバージョン: N: ガングリー; アーニク衛星FN: アーニク衛星ガングリーORG: オープンテキスト株式会社ADR; タイプ=が扱う郵便であることの3.0は以下を包みにします; スイートの101;38777の6マイルの西道路 リボニア; MI; 48152; 米国TEL;は=仕事、エムエスジーをタイプします: +1-734-542-5955 メールしてください; =インターネット: ganguly@acm.org エンド: VCARDをタイプしてください。
The co-chairman of that working group is:
そのワーキンググループの共同議長は以下の通りです。
BEGIN:VCARD VERSION:3.0 N:Moskowitz;Robert FN:Robert Moskowitz NICKNAME:Bob EMAIL; TYPE=INTERNET:rgm-ietf@htt-consult.com END:VCARD
: VCARDバージョン: 3.0にN: マスコウィッツを始めてください; ロバートFN: ロバートマスコウィッツNICKNAME: ボブEMAIL タイプ=インターネット: rgm-ietf@htt-consult.com エンド: VCARD
Silverberg, et. al. Standards Track [Page 108] RFC 2446 iTIP November 1998
etシルバーバーグ、アル。 規格はiTIP1998年11月にRFC2446を追跡します[108ページ]。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Silverberg, et. al. Standards Track [Page 109]
etシルバーバーグ、アル。 標準化過程[109ページ]
一覧
スポンサーリンク
