RFC4324 日本語訳
4324 Calendar Access Protocol (CAP). D. Royer, G. Babics, S. Mansour. December 2005. (Format: TXT=254638 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Royer
Request for Comments: 4324 IntelliCal, LLC
Category: Experimental G. Babics
Oracle
S. Mansour
eBay
December 2005
コメントを求めるワーキンググループD.ロワイエーの要求をネットワークでつないでください: 4324IntelliCal、LLCカテゴリ: 実験的なG.のBabicsオラクルS.マンスールeBay2005年12月
Calendar Access Protocol (CAP)
カレンダーアクセス・プロトコル(上限)
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols.
このメモで説明されたCalendar Accessプロトコル(CAP)は、Calendar User(CU)がiCALベースのCalendarストア(CS)にアクセスするのに、Calendar Userエージェント(CUA)を利用することを許可します。 この書くこと時点で、3つのベンダーがCAPを実装しますが、いくつかの変化が必要であることを既に決定しました。 実装経験を得るために、関係者は、CAP仕様が何年も仕事を保存するのに必要であると感じました。 何年も討論を持って、他のiCalendarプロトコルで使用できるCAPの多くの特性。
Royer, et al. Experimental [Page 1] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [1ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Table of Contents
目次
1. Introduction ....................................................5
1.1. Formatting Conventions .....................................5
1.2. Related Documents ..........................................6
1.3. Definitions ................................................7
2. Additions to iCalendar .........................................11
2.1. New Value Types (Summary) ................................14
2.1.1. New Parameters (summary) .............................14
2.1.2. New or Updated Properties (summary) ..................14
2.1.3. New Components (summary) .............................17
2.2. Relationship of RFC-2446 (ITIP) to CAP ...................18
3. CAP Design .....................................................20
3.1. System Model ..............................................20
3.2. Calendar Store Object Model ...............................20
3.3. Protocol Model ............................................21
3.3.1. Use of BEEP, MIME, and iCalendar .....................22
4. Security Model .................................................23
4.1. Calendar User and UPNs ....................................23
4.1.1. UPNs and Certificates ................................24
4.1.2. Anonymous Users and Authentication ...................25
4.1.3. User Groups ..........................................25
4.2. Access Rights .............................................26
4.2.1. Access Control and NOCONFLICT ........................26
4.2.2. Predefined VCARs .....................................26
4.2.3. Decreed VCARs ........................................28
4.3. CAP Session Identity ......................................28
5. CAP URL and Calendar Address ...................................29
6. New Value Types ................................................30
6.1. Property Value Data Types .................................30
6.1.1. CAL-QUERY Value Type .................................30
6.1.1.1. [NOT] CAL-OWNERS() ..............................36
6.1.1.2. CURRENT-TARGET() ................................37
6.1.1.3. PARAM() .........................................37
6.1.1.4. SELF() ..........................................38
6.1.1.5. STATE() .........................................38
6.1.1.6. Use of Single Quote .............................38
6.1.1.7. Comparing DATE and DATE-TIME Values .............39
6.1.1.8. DTEND and DURATION ..............................40
6.1.1.9. [NOT] LIKE ......................................40
6.1.1.10. Empty vs. NULL .................................41
6.1.1.11. [NOT] IN .......................................41
6.1.1.12. DATE-TIME and TIME Values in a WHERE Clause ....42
6.1.1.13. Multiple Contained Components ..................43
6.1.1.14. Example, Query by UID ..........................43
6.1.1.15. Query by Date-Time Range .......................43
6.1.1.16. Query for All Unprocessed Entries ..............44
6.1.1.17. Query with Subset of Properties by Date/Time ...44
1. 序論…5 1.1. 形式コンベンション…5 1.2. ドキュメントについて話します…6 1.3. 定義…7 2. iCalendarへの追加…11 2.1. 新しい値は(概要)をタイプします…14 2.1.1. 新しいパラメタ(概要)…14 2.1.2. 新しいかアップデートされた特性(概要)…14 2.1.3. 新しいコンポーネント(概要)…17 2.2. ふたをするRFC-2446(ITIP)の関係…18 3. デザインにふたをしてください…20 3.1. システムモデル…20 3.2. カレンダーストアオブジェクト・モデル…20 3.3. モデルについて議定書の中で述べてください…21 3.3.1. ビープ音、MIME、およびiCalendarの使用…22 4. セキュリティはモデル化されます…23 4.1. カレンダーのユーザとUPNs…23 4.1.1. UPNsと証明書…24 4.1.2. 匿名のユーザと認証…25 4.1.3. ユーザは分類します…25 4.2. アクセス権…26 4.2.1. コントロールとNOCONFLICTにアクセスしてください…26 4.2.2. VCARsを事前に定義します…26 4.2.3. VCARsは命じました…28 4.3. セッションのアイデンティティにふたをしてください…28 5. URLとカレンダーアドレスにふたをしてください…29 6. 新しい値のタイプ…30 6.1. 資産価値データ型…30 6.1.1. カル-質問値のタイプ…30 6.1.1.1. [NOT]カル所有者()…36 6.1.1.2. 現在の目標()…37 6.1.1.3. PARAM()…37 6.1.1.4. 自己()…38 6.1.1.5. 状態()…38 6.1.1.6. ただ一つの引用文の使用…38 6.1.1.7. 日付と日付時間的価値を比較します…39 6.1.1.8. DTENDと持続時間…40 6.1.1.9. [NOT] 好きです。40 6.1.1.10. ヌルに対して空になってください…41 6.1.1.11. [NOT] 中…41 6.1.1.12. aの日付-時間と時間的価値、どこ、節…42 6.1.1.13. 複数の含まれたコンポーネント…43 6.1.1.14. 例、UIDによる質問…43 6.1.1.15. 日付-時間範囲のそばで質問します。43 6.1.1.16. すべての未加工のエントリーに質問します。44 6.1.1.17. 特性の部分集合で、日付/時間までに質問します。44
Royer, et al. Experimental [Page 2] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [2ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
6.1.1.18. Query with Components and Alarms in A Range ....45
6.1.2. UPN Value Type .......................................45
6.1.3. UPN-FILTER Value .....................................46
7. New Parameters .................................................48
7.1. ACTION Parameter ..........................................48
7.2. ENABLE Parameter ..........................................48
7.3. ID Parameter ..............................................49
7.4. LATENCY Parameter .........................................50
7.5. LOCAL Parameter ...........................................50
7.6. LOCALIZE Parameter ........................................51
7.7. OPTIONS Parameter .........................................52
8. New Properties .................................................52
8.1. ALLOW-CONFLICT Property ...................................52
8.2. ATT-COUNTER Property ......................................53
8.3. CALID Property ............................................54
8.4. CALMASTER Property ........................................54
8.5. CAP-VERSION Property ......................................55
8.6. CARID Property ............................................55
8.7. CAR-LEVEL Property ........................................56
8.8. COMPONENTS Property .......................................56
8.9. CSID Property .............................................58
8.10. DECREED Property .........................................58
8.11. DEFAULT-CHARSET Property .................................59
8.12. DEFAULT-LOCALE Property ..................................60
8.13. DEFAULT-TZID Property ....................................61
8.14. DEFAULT-VCARS Property ...................................62
8.15. DENY Property ............................................62
8.16. EXPAND property ..........................................63
8.17. GRANT Property ...........................................64
8.18. ITIP-VERSION Property ....................................64
8.19. MAX-COMP-SIZE Property ...................................65
8.20. MAXDATE Property .........................................65
8.21. MINDATE Property .........................................66
8.22. MULTIPART Property .......................................66
8.23. NAME Property ............................................67
8.24. OWNER Property ...........................................68
8.25. PERMISSION Property ......................................68
8.26. QUERY property ...........................................69
8.27. QUERYID property .........................................70
8.28. QUERY-LEVEL Property .....................................70
8.29. RECUR-ACCEPTED Property ..................................71
8.30. RECUR-LIMIT Property .....................................71
8.31. RECUR-EXPAND Property ....................................72
8.32. RESTRICTION Property .....................................72
8.33. SCOPE Property ...........................................73
8.34. STORES-EXPANDED Property .................................74
8.35. TARGET Property ..........................................74
8.36. TRANSP Property ..........................................75
6.1.1.18. コンポーネントとアラームで、範囲で質問します。45 6.1.2. UPNはタイプを評価します…45 6.1.3. UPN-フィルタ値…46 7. 新しいパラメタ…48 7.1. 動作パラメタ…48 7.2. パラメタを可能にしてください…48 7.3. IDパラメタ…49 7.4. 潜在パラメタ…50 7.5. ローカルのパラメタ…50 7.6. パラメタをローカライズしてください…51 7.7. オプションパラメタ…52 8. 新しい特性…52 8.1. 闘争を許している特性…52 8.2. ATT-カウンタの特性…53 8.3. CALIDの特性…54 8.4. CALMASTERの特性…54 8.5. 上限バージョンの特性…55 8.6. CARIDの特性…55 8.7. 車レベルの特性…56 8.8. コンポーネントの特性…56 8.9. CSIDの特性…58 8.10. 特性を命じます…58 8.11. デフォルト-CHARSETの特性…59 8.12. デフォルト現場の特性…60 8.13. デフォルト-TZIDの特性…61 8.14. デフォルト-VCARSの特性…62 8.15. 特性を否定してください…62 8.16. EXPANDの特性…63 8.17. 資産を与えてください…64 8.18. ITIP-バージョンの特性…64 8.19. マックスコンピュータサイズの特性…65 8.20. MAXDATEの特性…65 8.21. MINDATEの特性…66 8.22. 複合特性…66 8.23. 特性を命名してください…67 8.24. 所有者の特性…68 8.25. 許可の特性…68 8.26. QUERYの特性…69 8.27. QUERYIDの特性…70 8.28. 質問レベルの特性…70 8.29. 再発、-受け入れた、特性…71 8.30. 再発、-、限界、特性…71 8.31. 再発、-広がってください、特性…72 8.32. 制限の特性…72 8.33. 範囲の特性…73 8.34. 店で拡張している特性…74 8.35. 特性を狙ってください…74 8.36. TRANSPの特性…75
Royer, et al. Experimental [Page 3] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [3ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
9. New Components .................................................76
9.1. VAGENDA Component .........................................76
9.2. VCALSTORE Component .......................................78
9.3. VCAR Component ............................................80
9.4. VRIGHT Component ..........................................82
9.5. VREPLY Component ..........................................83
9.6. VQUERY Component ..........................................83
10. Commands and Responses ........................................85
10.1. CAP Commands (CMD) .......................................85
10.2. ABORT Command ............................................88
10.3. CONTINUE Command .........................................89
10.4. CREATE Command ...........................................90
10.5. DELETE Command ...........................................96
10.6. GENERATE-UID Command .....................................98
10.7. GET-CAPABILITY Command ..................................100
10.8. IDENTIFY Command ........................................103
10.9. MODIFY Command ..........................................105
10.10. MOVE Command ...........................................110
10.11. REPLY Response to a Command ............................112
10.12. SEARCH Command .........................................113
10.13. SET-LOCALE Command .....................................116
10.14. TIMEOUT Command ........................................118
10.15. Response Codes .........................................118
11. Object Registration ..........................................120
11.1. Registration of New and Modified Entities ...............120
11.2. Post the Item Definition ................................120
11.3. Allow a Comment Period ..................................120
11.4. Release a New RFC .......................................120
12. BEEP and CAP .................................................120
12.1. BEEP Profile Registration ...............................120
12.2. BEEP Exchange Styles ....................................123
12.3. BEEP Connection Details .................................123
13. IANA Considerations ..........................................125
14. Security Considerations ......................................125
Appendix A. Acknowledgements ....................................127
Appendix B. References ..........................................127
Appendix B.1. Normative References ..........................127
Appendix B.2. Informative References ........................128
9. 新しいコンポーネント…76 9.1. VAGENDAの部品…76 9.2. VCALSTOREの部品…78 9.3. VCARの部品…80 9.4. VRIGHTの部品…82 9.5. VREPLYの部品…83 9.6. VQUERYの部品…83 10. コマンドと応答…85 10.1. コマンド(CMD)にふたをしてください…85 10.2. コマンドを中止してください…88 10.3. コマンドを続けてください…89 10.4. コマンドを作成してください…90 10.5. コマンドを削除してください…96 10.6. UIDを生成しているコマンド…98 10.7. 能力を得ているコマンド…100 10.8. コマンドを特定してください…103 10.9. コマンドを変更してください…105 10.10. コマンドを動かしてください…110 10.11. コマンドへの回答応答…112 10.12. コマンドを捜してください…113 10.13. セット現場コマンド…116 10.14. タイムアウトコマンド…118 10.15. 応答コード…118 11. オブジェクト登録…120 11.1. 新しくて変更された実体の登録…120 11.2. 項目定義を掲示してください…120 11.3. コメントの期間を許容してください…120 11.4. 新しいRFCをリリースしてください…120 12. 鳴って、ふたをしています。120 12.1. プロフィール登録を鳴らしてください…120 12.2. 交換様式を鳴らしてください…123 12.3. 接続の詳細を鳴らしてください…123 13. IANA問題…125 14. セキュリティ問題…125 付録A.承認…127 付録B.参照…127 付録B.1。 標準の参照…127 付録B.2。 有益な参照…128
Royer, et al. Experimental [Page 4] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [4ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
1. Introduction
1. 序論
This document specifies the Calendar Access Protocol (CAP). CAP permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS) and manage calendar information. In particular, the document specifies how to query, create, modify, and delete iCalendar components (e.g., events, to- dos, or daily journal entries). It further specifies how to search for available busy time information. Synchronization with CUAs is not covered, but it is believed to be possible using CAP.
このドキュメントはCalendar Accessプロトコル(CAP)を指定します。 CAPは、Calendar User(CU)がiCALベースのCalendarストア(CS)にアクセスして、予定表を管理するのに、Calendar Userエージェント(CUA)を利用するのを可能にします。 特に、ドキュメントがどのようにiCalendarの部品を質問して、作成して、変更して、削除するかを指定する、(例えば、イベント、-、dosであるか、または毎日の仕訳記入) それはさらに利用可能な繁忙期情報を検索する方法を指定します。 CUAsとの同期はカバーされていませんが、CAPを使用することで可能であると信じられています。
At the time of this writing, three vendors are implementing CAP. It has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP can be used by other iCalendar protocols and have had many years of debate.
この書くこと時点で、3つのベンダーがCAPを実装します。 既に、いくつかの変化が必要であることを決定しました。 実装経験を得るために、関係者は、CAP仕様が何年も仕事を保存するのに必要であると感じました。 CAPの多くの特性が、他のiCalendarプロトコルで使用できて、何年も討論を持っていました。
CAP is specified as a BEEP (Block Extensible Exchange Protocol) "profile" [BEEP] [BEEPGUIDE]. Many aspects of the protocol (e.g., authentication and privacy) are provided within BEEP. The protocol data units of CAP leverage the standard iCalendar format iCAL [iCAL] to convey calendar-related information.
CAPはBEEP(ブロックExtensible Exchangeプロトコル)「プロフィール」[BEEP][BEEPGUIDE]として指定されます。 BEEPの中でプロトコル(例えば、認証とプライバシー)の多くの局面を提供します。 データ単位のプロトコルCAPは、カレンダー関連の情報を伝えるために、標準のiCalendar形式iCAL[iCAL]を利用します。
CAP can also be used to store and fetch iCalendar Transport- Independent Interoperability Protocol (iTIP) objects [iTIP]. iTIP objects used are exactly as defined in [iTIP]. When iCalendar objects are transferred between the CUA and a CS, some additional properties and parameters may be added; the CUA is responsible for correctly generating iCalendar objects to non-CAP processes.
また、iCalendar Transportの独立しているInteroperabilityプロトコル(iTIP)オブジェクト[iTIP]を保存して、とって来るのにCAPを使用できます。使用されるiTIP目的はまさに[iTIP]で定義されるようにそうです。 CUAとCSの間にiCalendarオブジェクトを移すとき、いくつかの追加特性とパラメタを加えるかもしれません。 CUAは正しく非CAPプロセスへのオブジェクトをiCalendarに生成するのに責任があります。
The definition of new components, properties, parameters, and value types are broken into two parts. The first part summarizes and defines the new objects. The second part provides detail and ABNF for those objects. The ABNF rules for CAP, as for other iCalendar specifications, are order-independent. That is, properties in a component may occur in any order, and parameters in any property may occur in any order.
新しいコンポーネントの定義であり、2つの部品が特性、パラメタ、および値のタイプに細かく分けられます。 最初の部分は、新しいオブジェクトをまとめて、定義します。 第二部は詳細とABNFをそれらのオブジェクトに供給します。 他のiCalendar仕様のように、CAPのためのABNF規則はオーダーから独立しています。 すなわち、コンポーネントにおける特性は順不同に現れるかもしれません、そして、どんな所有地のパラメタも順不同に現れるかもしれません。
1.1. Formatting Conventions
1.1. 形式コンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
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)
役割のCalendaringして、計画をするのは大文字における、それぞれの単語の最初のキャラクタと共にテキストに関する引用文字列で言及されます。 例えば、「オーガナイザー」は「カレンダーユーザ」の役割を示します。(Cu)
Royer, et al. Experimental [Page 5] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [5ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
within the protocol defined by [iTIP]. Calendar components defined by [iCAL] are referred to with capitalized, quoted-strings of text. All iCalendar components should start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do component, and "VJOURNAL" refers to the daily journal component.
[iTIP]によって定義されたプロトコルの中で。 [iCAL]によって定義されたカレンダーコンポーネントが大文字で書かれることで言及される、テキストに関する引用文字列。 すべてのiCalendarの部品が文字「V」から始まるはずです。 例えば、"VEVENT"はイベントカレンダーコンポーネントを示します、そして、"VTODO"は大騒ぎコンポーネントを示します、そして、"VJOURNAL"は日計表コンポーネントを示します。
Scheduling methods defined by [iTIP] are referred to with capitalized, quoted-strings of text. For example, "REPLY" refers to the method for replying to a "REQUEST".
定義されたメソッドの計画をする[iTIP]が大文字で書かれることで参照されるテキストに関する引用文字列。 例えば、「回答」は「要求」に答えるためのメソッドを示します。
CAP commands are referred to by upper-case, quoted-strings of text, followed by the word "command". For example, '"CREATE" command' refers to the command for creating a calendar entry, '"SEARCH" command' refers to the command for reading calendar components. CAP commands are named using the "CMD" property.
CAPコマンドは大文字、「コマンド」という言葉があとに続いたテキストに関する引用文字列によって示されます。 例えば、'"CREATE"コマンド'はカレンダーエントリーを作成するためのコマンドを示して、'「検索」コマンド'は読書カレンダーコンポーネントのためのコマンドを示します。 CAPコマンドは"CMD"の特性を使用すると命名されます。
Properties defined by this memo 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 that has been invited to a "VEVENT" or "VTODO" component.
このメモで定義された特性が大文字で書かれることで示される、「特性」という言葉があとに続いたテキストに関する引用文字列。 例えば、'"ATTENDEE"の特性'は"VEVENT"か"VTODO"コンポーネントに招待されたカレンダーアドレスを伝えるのに使用されるiCalendarの特性を示します。
Property parameters defined by this memo are referred to with capitalized, quoted-strings of text, followed by the word "parameter". For example, "PARTSTAT" parameter refers to the iCalendar property parameter used to specify the participation status of an attendee. Enumerated values defined by this memo are referred to with capitalized text, either alone or followed by the word "value".
このメモで定義された特性のパラメタが大文字で書かれることで示される、「パラメタ」という言葉があとに続いたテキストに関する引用文字列。 例えば、"PARTSTAT"パラメタは出席者の参加状態を指定するのに使用されるiCalendar特性のパラメタを示します。 このメモで定義された列挙された値の、大文字で書かれたテキストで単独で言及されるか、または「値」という言葉はあとに続いています。
Object states defined by this memo are referred to with capitalized, quoted-strings of text, followed by the word "state". For example, '"BOOKED" state' refers to an object in the booked state.
このメモで定義されたオブジェクト州が大文字で書かれることで言及される、「状態」という言葉があとに続いたテキストに関する引用文字列。 例えば、'"BOOKED"状態'は予約している状態でオブジェクトについて言及します。
Within a query, the different parts are referred to as a "clause" and its value as "clause value" and the clause name will be in uppercase enclosed in quotes, for example, 'The "SELECT" claus' or 'if the "SELECT" clause value contains ...'.
質問の中では、'例えば、'「選んだ」クラウス'という引用文に同封された大文字には「節値」と節名があるか、または「選んだ」節値が'…を含んでいるなら、異なった部品は「節」とその値と呼ばれます。'.
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. These documents are as follows.
Implementersは、これと共に規格のcalendaringして、計画をするインターネットについて説明する他のいくつかのメモによく知られる必要があるでしょう。 これらのドキュメントは以下の通りです。
Royer, et al. Experimental [Page 6] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [6ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
[iCAL] (RFC2445) specifies the objects, data types, properties and
property parameters used in the protocols, along with the
methods for representing and encoding them.
[iCAL](RFC2445)はパラメタがプロトコルに使用したオブジェクト、データ型、特性、および特性を指定します、それらを表して、コード化するためのメソッドと共に。
[iTIP] (RFC2446) specifies an interoperability protocol for
scheduling between different installations.
[iTIP](RFC2446)は異なったインストールの間のスケジューリングに相互運用性プロトコルを指定します。
[iMIP] (RFC2447) specifies the Internet email binding for [iTIP].
[iMIP](RFC2447)は[iTIP]で付くインターネットメールを指定します。
[GUIDE] (RFC3283) is a guide to implementers and describes the
elements of a calendaring system, how they interact with each
other, how they interact with end users, and how the standards
and protocols are used.
[ガイド](RFC3283)は、implementersのガイドであり、それらがどう互いであって、規格とプロトコルがそれらがどうエンドユーザと対話するか、そして、どう使用されているかと対話するかというcalendaringシステムの原理について説明します。
This memo does not attempt to repeat the specification of concepts and definitions from these earlier memos. Where possible, references are made to the memo that provides the specification of these concepts and definitions.
このメモは、これらの以前のメモから概念と定義の仕様を繰り返すのを試みません。 可能であるところでは、これらの概念と定義の仕様を提供するメモを参照します。
1.3 Definitions
1.3 定義
UNPROCESSED, BOOKED, DELETED - A conceptual state of an object in
the calendar store. There are three conceptual states:
"UNPROCESSED" state, "BOOKED" state, and marked for deletion,
which is the "DELETED" state. How the implementation stores the
state of any object is not a protocol issue and is not discussed.
An object can be said to be booked, unprocessed, or marked for
deletion.
UNPROCESSED、BOOKED、DELETED--カレンダー店のオブジェクトの概念的な状態。 3つの概念的な州があります: "UNPROCESSED"州、「予約された」州、および「削除」が削除のための、どれであるかという著しい状態。 実装がどうどんなオブジェクトの状態も保存するかについて、プロトコル問題でなく、また議論しません。 オブジェクトを予約されていて、未加工であると言うか、または削除のためにマークできます。
1. An "UNPROCESSED" state scheduling object has been stored in
the calendar store but has not been acted on by a CU or CUA.
All scheduled entries are [iTIP] objects. No [iTIP] objects
in the store are in the "BOOKED" state. To retrieve any
[iTIP] object, simply do a query asking for any objects that
are stored in the "UNPROCESSED" state.
1. 「未加工」の州のスケジューリングオブジェクトは、カレンダー店に保存されましたが、Cuかクーアによって影響されていません。 すべての予定されているエントリーが[iTIP]オブジェクトです。 店の[iTIP]オブジェクトが全く「予約された」状態にありません。 どんな[iTIP]オブジェクトも検索するには、「未加工」の状態に保存されるどんなオブジェクトも求めながら、単に質問してください。
2. A "BOOKED" state entry is stored with the "CREATE" command.
It is an object that has been acted on by a CU or CUA and
there has been a decision to store an object. To retrieve any
booked object, simply do a query asking for any objects that
were stored in the "BOOKED" state.
2. 「予約された」州のエントリーは「作成」コマンドで保存されます。 それはCUかCUAによって影響されたオブジェクトです、そして、オブジェクトを保存するという決定がありました。 どんな予約しているオブジェクトも検索するには、「予約された」状態に保存されたどんなオブジェクトも求めながら、単に質問してください。
3. A "DELETED" state entry is created by sending a "DELETE"
command with the "OPTION" parameter value set to "MARK". To
retrieve any deleted object, simply do a query asking for any
objects that were stored in the "DELETED" state. By default
objects marked for delete are not returned. The CUA must
specifically ask for marked-for-deletion objects. You cannot
3. 「削除された」州のエントリーは、「マークする」「オプション」パラメタ選択値群による「削除」コマンドを送ることによって、作成されます。 どんな削除されたオブジェクトも検索するには、「削除された」状態に保存されたどんなオブジェクトも求めながら、単に質問してください。 デフォルトで著しい状態で反対する、削除、返されません。 CUAは明確に削除に、著しいオブジェクトを求めなければなりません。 あなたはそうすることができません。
Royer, et al. Experimental [Page 7] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [7ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
ask for components in the "DELETED" state and in other states
in the same "VQUERY" component, as there would be no way to
distinguish between them in the reply.
「削除された」州と他の州で同じ"VQUERY"コンポーネントでコンポーネントを求めてください、回答でそれらを見分ける方法が全くないでしょう、したがって。
Calendar - A collection of logically related objects or entities
each of which may be associated with a calendar date and possibly
time of day. These entities can include calendar properties or
components. In addition, a calendar might be related to other
calendars with the "RELATED-TO" property. A calendar is
identified by its unique calendar identifier. The [iCAL] defines
the initial calendar properties, calendar components and
properties that make up the contents of a calendar.
カレンダー--論理的に関連するオブジェクトかそれぞれ実体のそれの収集がカレンダ日付とことによると時刻に関連しているかもしれない。 これらの実体はカレンダーの特性かコンポーネントを含むことができます。 さらに、カレンダーは「関連された」という特性がある他のカレンダーに関連するかもしれません。 カレンダーはユニークなカレンダー識別子によって特定されます。 [iCAL]はカレンダーのコンテンツを作る初期のカレンダーの特性、カレンダーコンポーネント、および特性を定義します。
Calendar Access Protocol (CAP) - The Internet protocol that permits
a CUA to access and manipulate calendars residing on a Calendar
Store. (This memo.)
カレンダーAccessプロトコル(CAP)--CUAがCalendarストアの上にあるカレンダーをアクセスして、操ることを許可するインターネットプロトコル。 (このメモ。)
Calendar Access Rights (VCAR) - The mechanism for specifying the CAP
operations ("PERMISSION") that a particular calendar user ("UPN",
defined below) is granted or denied permission to perform on a
given calendar object ("SCOPE"). The calendar access rights are
specified with a "VCAR" component. (Section 9.3)
カレンダーAccess Rights(VCAR)--CAP操作(「許可」)を指定するための与えられたカレンダーオブジェクト(「範囲」)に実行する特定のカレンダーユーザ(以下で定義された"UPN")が与えられて、許可を否定されるメカニズム。 カレンダーアクセス権は"VCAR"コンポーネントで指定されます。 (セクション9.3)
Calendar Address - Also see Calendar URL, which is the same as a CAP
address. The calendar address can also be the value to the
"ATTENDEE" and "ORGANIZER" properties, as defined in [iCAL].
Calendar URL - A calendar URL is a URL, defined in this memo,
that specifies the address of a CS or Calendar.
カレンダーAddress--また、Calendar URLを見てください。(それは、CAPアドレスと同じです)。 また、カレンダーアドレスは[iCAL]で定義されるように「出席者」と「オーガナイザー」の特性への値であるかもしれません。 カレンダーURL--カレンダーURLはCSかCalendarのアドレスを指定するこのメモで定義されたURLです。
Component - Any object that conforms to the iCalendar object format
and that is either defined in an Internet Draft, registered with
IANA, or is an experimental object that is prefixed with "x-".
Some types of components include calendars, events, to-dos,
journals, alarms, and time zones. A component consists of
properties and possibly other contained components. For example,
an event may contain an alarm component.
コンポーネント--iCalendarオブジェクト形式とそれに一致しているどんな目的も、IANAに登録されたインターネットDraftで定義されるか、「x」で前に置かれている実験的なオブジェクトです。 何人かのタイプの成分はカレンダー、イベント、大騒ぎ、ジャーナル、アラーム、および時間帯を含んでいます。 コンポーネントは特性とことによると他の含まれたコンポーネントから成ります。 例えば、イベントはアラームの部品を含むかもしれません。
Container - This is a generic name for VCALSTORE or VAGENDA.
コンテナ--これはVCALSTOREかVAGENDAのための総称です。
Properties - An attribute of a particular component. Some
properties are applicable to different types of components. For
example, the "DTSTART" property is applicable to the "VEVENT",
"VTODO", and "VJOURNAL" components. Other components are
applicable only to an individual type of calendar component. For
example, the "TZURL" property may only be applicable to the
"VTIMEZONE" components.
特性--特定のコンポーネントの属性。 いくつかの特性が異なったタイプの成分に適切です。 例えば、"DTSTART"の特性は"VEVENT"、"VTODO"、および"VJOURNAL"コンポーネントに適切です。 他のコンポーネントは独特のタイプのカレンダー成分だけに適切です。 例えば、"TZURL"の特性は単に"VTIMEZONE"コンポーネントに適切であるかもしれません。
Royer, et al. Experimental [Page 8] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [8ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Calendar Identifier (CALID) - A globally unique identifier
associated with a calendar. Calendars reside within a CS. See
Qualified Calendar Identifier and Relative Calendar Identifier.
All CALIDs start with "cap:".
カレンダーIdentifier(CALID)--カレンダーに関連しているグローバルにユニークな識別子。 カレンダーはCSの中にあります。 適切なカレンダー識別子と相対的なカレンダー識別子を見てください。 CALIDsが始めるすべてが「以下にふたをしています」。
Calendar Policy - A CAP operational restriction on the access or
manipulation of a calendar. These may be outside the scope of the
CAP protocol. An example of an implementation or site policy is,
"events MUST be scheduled in unit intervals of one hour".
カレンダーPolicy--カレンダーのアクセスか操作のCAPの操作上の制限。 CAPプロトコルの範囲の外にこれらはあるかもしれません。 実装かサイト方針に関する例は「1時間のユニット間隔でイベントを予定しなければならない」ということです。
Calendar Property - An attribute of a calendar ("VAGENDA"). The
attribute applies to the calendar, as a whole. For example, the
"CALSCALE" property specifies the calendar scale (e.g., the
"GREGORIAN" value) for the all entries within the calendar.
カレンダーProperty--カレンダー("VAGENDA")の属性。 属性は全体でカレンダーに適用されます。 例えば、"CALSCALE"の特性がカレンダースケール(例えば、「グレゴリオ」の値)を指定する、すべてのエントリー、カレンダーの中で。
Calendar Store (CS) - The data and service model definitions for a
Calendar Store as defined in this memo. This memo does not
specify how the CS is implemented.
カレンダーストア(CS)--データとサービスはこのメモで定義されるようにCalendarストアのための定義をモデル化します。 このメモはCSがどう実装されるかを指定しません。
Calendar Server - An implementation of a Calendar Store (CS) that
manages one or more calendars.
カレンダーServer--1つ以上のカレンダーを管理するCalendarストア(CS)の実装。
Calendar Store Identifier (CSID) - The globally unique identifier
for an individual CS. A CSID consists of the host and port
portions of a "Common Internet Scheme Syntax" part of a URL, as
defined by [URL]. The CSID excludes any reference to a specific
calendar. (Section 8.9)
カレンダーストアIdentifier(CSID)--個々のCSに、グローバルにユニークな識別子。 CSIDは1つのURLの「一般的なインターネット体系構文」部分のホストとポート部分から成ります、[URL]によって定義されるように。 CSIDは特定のカレンダーのどんな参照も除きます。 (セクション8.9)
Calendar Store Components - Components maintained in a CS specify a
grouping of calendar store-wide information.
カレンダーストアComponents--CSで維持されたコンポーネントはカレンダーの店全体の情報の組分けを指定します。
Calendar Store Properties - Properties maintained in a Calendar
Store represent store-wide information.
カレンダーストアProperties--Calendarストアで維持された特性は店全体の情報を表します。
Calendar User (CU) - An entity (often biological) that uses a
calendaring system.
カレンダーUser(CU)--calendaringシステムを使用する実体(しばしば生物学的な)。
Calendar User Agent (CUA) - The client application that a CU
utilizes to access and manipulate a calendar.
カレンダーUserエージェント(CUA)--CUがカレンダーにアクセスして、操るのに利用するクライアントアプリケーション。
CAP Session - An open communication channel between a CUA and a CS.
If the CAP session is authenticated, the CU is "authenticated" and
it is an "authenticated CAP session".
CAP Session--CUAとCSの間のオープンコミュニケーションチャンネル。 CAPセッションが認証されるなら、CUは「認証されます」、そして、それは「認証されたCAPセッション」です。
Contained Component / Contained Properties - A component or property
that is contained inside of another component. For example, a
"VALARM" component may be contained inside a "VEVENT" component,
含まれたComponent/含まれたProperties--中に含まれている別のコンポーネントのコンポーネントか特性。 例えば、"VALARM"コンポーネントは"VEVENT"コンポーネントに含まれるかもしれません。
Royer, et al. Experimental [Page 9] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [9ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
and a "TRIGGER" property could be a contained property of a
"VALARM" component.
そして、「引き金」の特性は"VALARM"コンポーネントの含まれた特性であるかもしれません。
Delegate - A CU (sometimes called the delegatee) who has been
assigned participation in a scheduled component (e.g., VEVENT) by
one of the attendees in the scheduled component (sometimes called
the delegator). An example of a delegate is a team member told to
go to a particular meeting in place of another invitee who is
unable to attend.
代表--予定されているコンポーネント(例えば、VEVENT)への参加が予定されているコンポーネント(時々「反-遺贈者」と呼ばれる)における出席者のひとりによって割り当てられたCU(時々「反-遺産受取人」と呼ばれます)。 代表の例は出席できない別の招待参加者に代わって特定のミーティングに行くように言われるチームメンバーです。
Designate - A CU who is authorized to act on behalf of another CU.
An example of a designate is an assistant.
指定、--別のCUを代表して行動するのが認可されるCU。 aに関する例が指定する、アシスタントはそうです。
Experimental - The CUA and CS may implement experimental extensions
to the protocol. They might also have experimental components,
properties, and parameters. These extensions MUST start with "x-"
(or "X-") and should include a vendor prefix (such as "x-
myvendor-"). There is no guarantee that these experimental
extensions will interoperate with other implementations. There is
no guarantee that they will not interact in unpredictable ways
with other vendor experimental extensions. There is no guarantee
that the same specific experimental extension is not used by
multiple vendors in incompatible ways. Implementations should
limit sending those extensions to other implementations.
実験的である、--CUAとCSは実験的な拡大をプロトコルに実装するかもしれません。 また、彼らには、実験的なコンポーネント、特性、およびパラメタがあるかもしれません。 これらの拡大は、「x」(または、「X」)から始まらなければならなくて、ベンダー接頭語(「x myvendor」などの)を含むべきです。 これらの実験的な拡大が他の実装で共同利用するという保証が全くありません。 他のベンダーの実験的な拡大を伴う予測できない方法で相互作用しないという保証が全くありません。 同じ特定の実験的な拡張子が複数のベンダーによって両立しない方法で使用されないという保証が全くありません。 実装は、それらの拡大を送るのを他の実装に制限するべきです。
Object - A generic name for any component, property, parameter, or
value type to be used in iCalendar.
反対してください--iCalendarで使用されるべきどんなコンポーネント、特性、パラメタ、または値のタイプのための総称。
Overlapped Booking - A policy that indicates whether or not
components with a "TRANSP" property not set to "TRANSPARENT-
NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap one another.
When the policy is applied to a calendar it indicates whether or
not the time span of any component (VEVENT, VTODO, ...) in the
calendar can overlap the time span of any other component in the
same calendar. When applied to an individual object, it indicates
whether or not any other component's time span can overlap that
individual component. If the CS does not allow overlapped
booking, then the CS is unwilling to allow any overlapped bookings
within any calendar or entry in the CS.
重ね合わせられたBooking--"TRANSP"の特性があるコンポーネントが「透明なNOCONFLICT」か「不透明なNOCONFLICT」値にセットしなかったかどうかを示す方針はお互いを重ね合わせることができます。 方針がカレンダーに適用されるとき、それは、何かカレンダーのコンポーネント(VEVENT、VTODO)のタイム・スパンが同じカレンダーのコンポーネントのいかなる他のもタイム・スパンを重ね合わせることができるかどうかを示します。 個々のオブジェクトに適用されると、それは、コンポーネントのいかなる他のもタイム・スパンがその個々のコンポーネントを重ね合わせることができるかどうかを示します。 CSが重ね合わせられた予約を許容しないなら、CSはどんなカレンダーの中のどんな重ね合わせられた予約かCSのエントリーも許容したがっていません。
Owner - One or more CUs or UGs that are listed in the "OWNER"
property in a calendar. There can be more than one owner.
所有者--「所有者」所有地にカレンダーで記載されている1CUsかUGs。 1人以上の所有者がいることができます。
Qualified Calendar Identifier (Qualified CALID) - A CALID in which
both the scheme and CSID of the CAP URI are present.
適切なCalendar Identifier(適切なCALID)--体系とCAP URIのCSIDの両方が現在であるCALID。
Realm - A collection of calendar user accounts, identified by a
string. The name of the Realm is only used in UPNs. In order to
分野--ストリングによって特定されたカレンダーユーザアカウントの収集。 Realmという名前はUPNsで使用されるだけです。 in order to
Royer, et al. Experimental [Page 10] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [10ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
avoid namespace conflict, the Realm SHOULD be postfixed with an
appropriate DNS domain name (e.g., the foobar Realm could be
called foobar.example.com).
名前空間闘争を避けてください、Realm SHOULD。適切なDNSドメイン名で、語尾に添えられてください(例えばfoobar Realmをfoobar.example.comと呼ぶことができました)。
Relative Calendar Identifier (Relative CALID) - An identifier for an
individual calendar in a calendar store. It MUST be unique within
a calendar store. A Relative CALID consists of the "URL path" of
the "Common Internet Scheme Syntax" portion of a URL, as defined
by [URI] and [URLGUIDE].
親類Calendar Identifier(親類CALID)--カレンダー店の個々のカレンダーのための識別子。 それはカレンダー店の中でユニークであるに違いありません。 Relative CALIDは1つのURLの「一般的なインターネット体系構文」一部の「URL経路」から成ります、[URI]と[URLGUIDE]によって定義されるように。
Session Identity - A UPN associated with a CAP session. A session
gains an identity after successful authentication. The identity
is used in combination with VCAR to determine access to data in
the CS.
セッションIdentity--UPNはCAPセッションと交際しました。 セッションはうまくいっている認証の後にアイデンティティを獲得します。 アイデンティティは、VCARと組み合わせてCSのデータへのアクセスを決定するのに使用されます。
User Group (UG) - A collection of Calendar Users and/or User Groups.
These groups are expanded by the CS and may reside either locally
or in an external database or directory. The group membership may
be fixed or dynamic over time.
ユーザグループ(UG)--Calendar Users、そして/または、ユーザグループの収集。 これらのグループは、CSによって広げられて、局所的か外部のデータベースかディレクトリにあるかもしれません。 グループ会員資格は、時間がたつにつれて、固定されているか、またはダイナミックであるかもしれません。
Username - A name that denotes a Calendar User within a Realm. This
is part of a UPN.
ユーザ名--Realmの中でCalendar Userを指示する名前。 これはUPNの一部です。
User Principal Name (UPN) - A unique identifier that denotes a CU or
a group of CUs. (Section 6.1.2)
ユーザプリンシパルName(UPN)--CUを指示するユニークな識別子かCUsのグループ。 (セクション6.1.2)
2. Additions to iCalendar
2. iCalendarへの追加
Several new components, properties, parameters, and value types are added in CAP. This section summarizes those new objects.
いくつかの新しいコンポーネント、特性、パラメタ、および値のタイプはCAPで加えられます。 このセクションはそれらの新しいオブジェクトをまとめます。
This memo extends the properties that can go into 'calprops' as defined in [iCAL] section 4.6 page 51, to allow [iTIP] objects transmitted between a CAP aware CUA and the CS to contain the "TARGET" and "CMD" properties. This memo also adds to the [iCAL] ABNF to allow IANA and experimental extensions. This memo does not address how a CUA transmits [iTIP] or [iMIP] objects to non-CAP programs. What follows is ABNF, as described in [ABNF].
このメモはCAPの意識しているCUAとCSの間に伝えられた[iTIP]オブジェクトが「目標」と"CMD"の特性を含むのを許容するために[iCAL]セクション4.6 51ページで定義されるように'calprops'に入ることができる特性を広げています。 また、このメモは、IANAと実験的な拡大を許すために[iCAL]ABNFに加えます。 このメモはCUAがどう[iTIP]か[iMIP]オブジェクトを非CAPプログラムに伝えるかを扱いません。続くことはABNFです、[ABNF]で説明されるように。
calprops= 2*(
calprops=2*、(
; 'prodid' and 'version' are both REQUIRED,
; but MUST NOT occur more than once.
;
prodid /version /
;
; These are optional, but MUST NOT occur
; more than once.
; 'prodid'と'バージョン'が両方である、REQUIRED。 しかし、NOTは一度より起こらなければなりませんか? ; prodid /version /。 ; これらは、任意ですが、起こってはいけません。 一度より多くです。
Royer, et al. Experimental [Page 11] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [11ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
;
calscale /
method /
cmd /
;
; Target is optional, and may occur more
; than once.
;
target / other-props )
;
other-props = *(x-prop) *(iana-prop) *(other-props)
;
iana-prop = ; Any property registered by IANA directly or
; included in an RFC that may be applied to
; the component and within the rules published.
;
x-prop = ; As defined in [iCAL].
;
methodp = ; As defined in [iCAL].
;
prodid = ; As defined in [iCAL].
;
calscale = ; As defined in [iCAL].
;
; calscale/メソッド/ cmd /。 ; 目標は、任意であり、さらに現れるかもしれません。 一度より。 ; 他の目標/支柱) ; 他の支柱は*(x-支柱)と等しいです。 *(iana-支柱) *(他の支柱) ; iana-支柱=。 または、どんな特性もIANAによって直接示された、。 適用されるかもしれないRFCでは、含まれています。 コンポーネントと発表された規則の中で。 ; x-支柱=。 [iCAL]で定義されるように。 ; methodp=。 [iCAL]で定義されるように。 ; prodid=。 [iCAL]で定義されるように。 ; calscale=。 [iCAL]で定義されるように。 ;
Another change is that the 'component' part of the 'icalbody' ABNF as described in [iCAL] section 4.6 is optional when sending a command, as shown in the following updated ABNF:
別の変化はコマンドを送るとき、[iCAL]セクション4.6の説明されるとしての'icalbody'ABNFの'コンポーネント'部分が任意であるということです、以下のアップデートされたABNFに示されるように:
icalbody = calprops component
icalbodyはcalpropsの部品と等しいです。
; If the "VCALENDAR" component contains the "CMD"
; property then the 'component' is optional:
;
/ calprops ; Which MUST include a "CMD" property
;
component = ; As defined in [iCAL].
; "VCALENDAR"コンポーネントが"CMD"を含んでいるなら。 特性、次に、'コンポーネント'は任意です: ; /calprops。 どれが"CMD"の特性を含まなければならないか。 コンポーネント=。 [iCAL]で定義されるように。
In addition, a problem exists with the control of "VALARM" components and their "TRIGGER" properties. A CU may wish to set its own alarms (local alarms) on components. These local alarms are not to be forwarded to other CUs, CUAs, or CSs. Similarly, the "SEQUENCE" property and the "ENABLE" parameter in local alarms are not to be forwarded to other CUs, CUAs, or CSs. Therefore, for the protocol between a CUA and a CS, the following changes from [iCAL] section 4.6.6 page 67 apply to the CAP protocol:
さらに、問題は"VALARM"コンポーネントと彼らの「引き金」の特性のコントロールで存在しています。 CUはコンポーネントのそれ自身のアラーム(ローカルのアラーム)を設定したがっているかもしれません。 これらのローカルのアラームは他のCUs、CUAs、またはCSsに送られないことです。 同様に、「系列」の特性とローカルのアラームの「可能にする」パラメタは他のCu、CUAs、またはCSsに送られないことです。 したがって、CUAとCSの間のプロトコルのために、[iCAL]セクション4.6.6 67ページからの以下の変化はCAPプロトコルに申し込まれます:
alarmc = "BEGIN" ":" "VALARM" CRLF
「alarmcは「始まってください」と等しい」:、」 "VALARM"CRLF
Royer, et al. Experimental [Page 12] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [12ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
alarm-seq
other-props
(audioprop / dispprop / emailprop / procprop)
"END" ":" "VALARM" CRLF
;
emailprop = ; As defined in [iCAL]
;
procprop = ; As defined in [iCAL]
;
dispprop = ; As defined in [iCAL]
;
audioprop = ; As defined in [iCAL]
;
alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF
;
alarmseqparams = other-params [";" local-param] other-params
;
; Where DIGIT is defined in [iCAL]
;
posint0 = 1*DIGIT
posint1 = posintfirst 1*DIGIT
;
; A number starting with 1 through 9.
;
posintfirst = %x31-39
;
other-params = *(";" xparam) *(";" iana-params)
*(";" other-params)
;
iana-params = ; Any parameter registered by IANA directly or
; included in an RFC that may be applied to
; the property and within the rules published.
;
xparam ; As defined in [iCAL].
;
「アラーム-seq他の支柱(audioprop/dispprop/emailprop/procprop)「終わり」」:、」 "VALARM"CRLF。 emailprop=。 [iCAL]で定義されるように。 procprop=。 [iCAL]で定義されるように。 dispprop=。 [iCAL]で定義されるように。 audioprop=。 [iCAL]で定義されるように。 「アラーム-seqは「」 系列alarmseqparams」と等しいです」 posint0 CRLF。 alarmseqparamsが他のparamsと等しい、[「; 」 地方のparam] 他のparams。 ; DIGITが[iCAL]で定義されるところ。 posint0=1*DIGIT posint1はposintfirst1*DIGITと等しいです。 ; 1〜9から始まる数。 ; posintfirst=%x31-39。 他のparamsが*と等しい、(「」、;、xparam) *、(「」、;、iana-params) *、(「」、;、他のparams)、。 iana-params=。 または、どんなパラメタもIANAによって直接示された、。 適用されるかもしれないRFCでは、含まれています。 所有地と発表された規則の中で。 ; xparam。 [iCAL]で定義されるように。 ;
The CUA adds a "SEQUENCE" property to each "VALARM" component as it books the component. This property, along with the "LOCAL" and "ENABLE" parameters, allows the CUA to uniquely identify any VALARM in any component. The CUA should remove those before forwarding to non-CAP-aware CUAs.
コンポーネントを予約するとき、CUAはそれぞれの"VALARM"コンポーネントへの「系列」の特性を加えます。 この特性で、クーアは「地方」と「可能にする」パラメタと共にどんなコンポーネントでもどんなVALARMも唯一特定できます。 CUAが推進の前のそれらを取り除くはずである、非CAP意識する、CUAs。
In addition, if a CUA wished to ignore a "TRIGGER" property in a "VALARM" component that was supplied to it by the "Organizer", the CUA needs a common way to tag that trigger as disabled. So the following is a modification to [iCAL] section 4.8.6.3 page 127:
さらに、CUAが「オーガナイザー」によってそれに供給された"VALARM"コンポーネントで「引き金」の特性を無視したかったなら、クーアは無効にされるようにその引き金にタグ付けをする一般的な方法を必要とします。 したがって、↓これは[iCAL]セクション4.8への変更です。.6 .3 127を呼び出してください:
trigger = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs)
=「引き金」1*の引き金となってください、(「」、;、paramを有効にする、)(trigrel / trigabs)
Royer, et al. Experimental [Page 13] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [13ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
;
trigrel = ; As defined in [iCAL].
;
trigabs = ; As defined in [iCAL].
; trigrel=。 [iCAL]で定義されるように。 ; trigabs=。 [iCAL]で定義されるように。
See Section 7.2 and Section 7.5.
セクション7.2とセクション7.5を見てください。
2.1. New Value Types (Summary)
2.1. 新しい値のタイプ(概要)
UPN: The UPN value type is a text value type restricted to only UPN
values (see Section 6.1.2).
UPN: UPN値のタイプはUPN値だけに制限されたテキスト値のタイプ(セクション6.1.2を見る)です。
UPN-FILTER: Like the UPN value type, but also includes filter rules
that allow wildcards (see Section 6.1.3).
UPN-フィルタ: 値がタイプしますが、また含むUPNのように、ワイルドカードを許容する規則をフィルターにかけてください(セクション6.1.3を見てください)。
CALQUERY: The "CAL-QUERY" value type is a query syntax that is used
by the CUA to specify the rules that apply to a CAP command (see
Section 6.1.1).
CALQUERY: 「カル-質問」値のタイプは上限コマンドに適用される規則を指定するのにクーアによって使用される質問構文(セクション6.1.1を見る)です。
2.1.1. New Parameters (summary)
2.1.1. 新しいパラメタ(概要)
ACTION - The "ACTION" parameter informs the endpoint if it should
abort or ask to continue on timeout. (Section 7.1)
ACTION--「動作」パラメタは、それが、中止になるべきであるか、またはタイムアウトで続くように頼むべきであるかを終点に知らせます。 (セクション7.1)
ENABLE - The "ENABLE" parameter in CAP is used to tag a property in
a component as disabled or enabled. (Section 7.2)
ENABLE--上限における「可能にする」パラメタは、無効にされるか、または可能にされるようにコンポーネントで特性にタグ付けをするのに使用されます。 (セクション7.2)
ID - The "ID" parameter specifies a unique identifier to be used for
any outstanding commands.
ID--「ID」パラメタは、どんな傑出しているコマンドにも使用されるためにユニークな識別子を指定します。
LATENCY - The "LATENCY" parameter supplies the timeout value for
command completion to the other endpoint. (Section 7.4)
LATENCY--「潜在」パラメタはコマンド完成のためのタイムアウト値をもう片方の終点に供給します。 (セクション7.4)
LOCAL - The "LOCAL" parameter in CAP is used to tag a property in a
component to signify that the component is local or to be
distributed. (Section 7.5)
LOCAL--上限における「地方」のパラメタは、コンポーネントが地方であることを意味するか、または分配されるためにコンポーネントで特性にタグ付けをするのに使用されます。 (セクション7.5)
LOCALIZE - The "LOCALIZE" parameter specifies the locale to be used
in error and warning messages.
LOCALIZE--「ローカライズしてください」というパラメタは、誤りと警告メッセージに使用されるために現場を指定します。
OPTIONS - The "OPTIONS" parameter passes optional information for
the command being sent.
OPTIONS--「オプション」パラメタは送られるコマンドのための任意の情報を通過します。
2.1.2. New or Updated Properties (summary)
2.1.2. 新しいかアップデートされた特性(概要)
ALLOW-CONFLICT - Some entries in a calendar might not be valid if
other entries were allowed to overlap the same time span.
(Section 8.1)
ALLOW-CONFLICT--他のエントリーが同じタイム・スパンを重ね合わせることができるなら、カレンダーにおけるいくつかのエントリーは有効でないでしょうに。 (セクション8.1)
Royer, et al. Experimental [Page 14] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [14ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
ATT-COUNTER - When storing a "METHOD" property with the "COUNTER"
method, there needs to be a way to remember the "ATTENDEE" value
that sent the COUNTER. (Section 8.2)
ATT-COUNTER--「カウンタ」メソッドで「メソッド」の特性を保存するとき、カウンタを送った「出席者」値を思い出す方法があるのが必要です。 (セクション8.2)
CAP-VERSION - The version of CAP that the implementation supports.
(Section 8.5)
CAP-バージョン--実装がサポートするCAPのバージョン。 (セクション8.5)
CAR-LEVEL - The level of calendar access supported. (Section 8.7)
CAR-LEVEL--アクセスがサポートしたカレンダーのレベル。 (セクション8.7)
COMPONENTS - The list of components supported. (Section 8.8)
COMPONENTS--サポートされたコンポーネントのリスト。 (セクション8.8)
CSID - The Calendar Store IDentifier (CSID) uniquely identifies a
CAP server. (Section 8.9)
CSID--CalendarストアIDentifier(CSID)は唯一CAPサーバを特定します。(セクション8.9)
CALID - Each calendar within a CS needs to be uniquely identifiable.
The "CALID" property identifies a unique calendar within a CS. It
can be a full CALID or a relative CALID. (Section 8.3)
CALID--CSの中の各カレンダーは、唯一身元保証可能である必要があります。 "CALID"の特性はCsの中でユニークなカレンダーを特定します。 それは、完全なCALIDか親類CALIDであるかもしれません。 (セクション8.3)
CALMASTER - The "CALMASTER" property specifies the contact
information for the CS. (Section 8.4)
CALMASTER--"CALMASTER"の特性はCsのための問い合わせ先を指定します。 (セクション8.4)
CARID - Access rights can be saved and fetched by unique ID - the
"CARID" property. (Section 8.6)
CARID--ユニークなIDは、アクセス権を保存して、とって来ることができます--"CARID"の特性。 (セクション8.6)
CMD - The CAP commands, as well as replies are transmitted using the
"CMD" property. (Section 10.1)
CMD--CAPは回答が"CMD"の特性を使用することで伝えられるのと同じくらいよく命令します。 (セクション10.1)
DECREED - Some access rights are not changeable by the CUA. When
that is the case, the "DECREED" property value in the "VCAR"
component will be "TRUE". (Section 8.10)
DECREED--いくつかのアクセス権はCUAが変わりやすくはありません。 それがそうであるときに、"VCAR"コンポーネントにおける「命じられた」資産価値は「本当でしょう」。 (セクション8.10)
DEFAULT-CHARSET - The list of charsets supported by the CS. The
first entry is the default for the CS. (Section 8.11)
DEFAULT-CHARSET--CSによってサポートされたcharsetsのリスト。 初記入はCSのためのデフォルトです。 (セクション8.11)
DEFAULT-LOCALE - The list of locales supported by the CS. The first
entry in the list is the default locale. (Section 8.12)
DEFAULT-LOCALE--CSによってサポートされた現場のリスト。 リストにおける初記入はデフォルト現場です。 (セクション8.12)
DEFAULT-TZID - This is the list of known timezones supported. The
first entry is the default. (Section 8.13)
DEFAULT-TZID--これはサポートされた知られているタイムゾーンのリストです。 初記入はデフォルトです。 (セクション8.13)
DEFAULT-VCARS - A list of the "CARID" properties that will be used
to create new calendars. (Section 8.14)
DEFAULT-VCARS--新暦を作成するのに使用される"CARID"の特性のリスト。 (セクション8.14)
DENY - The UPNs listed in the "DENY" property of a "VCAR" component
will be denied access, as described in the "VRIGHT" component.
(Section 8.15)
DENY--アクセスは"VCAR"コンポーネントの「否定」所有地に記載されたUPNsに拒絶されるでしょう、"VRIGHT"コンポーネントで説明されるように。 (セクション8.15)
Royer, et al. Experimental [Page 15] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [15ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
EXPAND - This property tells the CS if the query reply should expand
components into multiple instances. The default is "FALSE" and is
ignored for CSs that cannot expand recurrence rules. (Section
8.16)
EXPAND--この特性は、質問回答が複数のインスタンスにコンポーネントを広くするべきであるかどうかCSに言います。 デフォルトは、「誤っ」て、再発規則を広げることができないCSsのために無視されます。 (セクション8.16)
GRANT - The UPNs listed in the "GRANT" property of a "VCAR"
component will be allowed access as described in the "VRIGHT"
component. (Section 8.17)
グラント--アクセスは"VRIGHT"コンポーネントで説明されるように"VCAR"コンポーネントの「交付金」所有地に記載されたUPNsに許されるでしょう。 (セクション8.17)
ITIP-VERSION - The version of [iTIP] supported. (Section 8.18)
ITIP-バージョン--サポートされた[iTIP]のバージョン。 (セクション8.18)
MAXDATE - The maximum date supported by the CS. (Section 8.20)
MAXDATE--CSによってサポートされた最大の期日。 (セクション8.20)
MAX-COMP-SIZE - The largest component size allowed in the
implementation including attachments in octets. (Section 8.19)
マックス-COMP-SIZE--八重奏に付属を含む実装で許容される中で最も大きいコンポーネントサイズ。 (セクション8.19)
MINDATE - The minimum date supported by the CS. (Section 8.21)
MINDATE--CSによってサポートされた最小の期日。 (セクション8.21)
MULTIPART - Passed in the capability messages to indicate which MIME
multipart types the sender supports. (Section 8.22)
MULTIPART--送付者がどのMIMEの複合タイプをサポートするかを示す能力メッセージでは、通過されます。 (セクション8.22)
NAME - The "NAME" property is used to add locale-specific
descriptions into components. (Section 8.23)
NAME--「名前」の特性は、現場明確な記述をコンポーネントに加えるのに使用されます。 (セクション8.23)
OWNER - Each calendar has at least one "OWNER" property. (xref
target="OWNER"/>) Related to the "CAL-OWNERS()" query clause.
(Section 6.1.1.1)
OWNER--各カレンダーには、少なくとも1「所有者」の特性があります。 (xref目標=「所有者」/>) 「カル所有者()」質問節に関連しました。 (セクション6.1.1、.1)
PERMISSION - This property specifies the permission being granted or
denied. Examples are the "SEARCH" and "MODIFY" values. (Section
8.25)
PERMISSION--この特性は与えるか、または否定する許可を指定します。 例は、「検索」であり、値を「変更します」。 (セクション8.25)
QUERY - Used to hold the CAL-QUERY (Section 8.26) for the component.
QUERY--コンポーネントのためのカル-QUERY(セクション8.26)を持つのにおいて、使用されています。
QUERYID - A unique id for a stored query. (Section 8.27)
QUERYID--保存された質問のためのユニークなイド。 (セクション8.27)
QUERY-LEVEL - The level of the query language supported. (Section
8.28)
QUERY-LEVEL--サポートされた照会言語のレベル。 (セクション8.28)
RECUR-ACCEPTED - If the implementation support recurrence rules.
(Section 8.29)
RECUR-ACCEPTED--実装サポート再発が統治されるなら。 (セクション8.29)
RECUR-EXPAND - If the implementation support expanding recurrence
rules. (Section 8.31)
RECUR-EXPAND--再発を広くする実装サポートが統治されるなら。 (セクション8.31)
RECUR-LIMIT - Any maximum limit on the number of instances the
implementation will expand recurring objects. (Section 8.30)
RECUR-LIMIT--実装がそうするインスタンスの数におけるどんな最大の限界も再発オブジェクトを広くします。 (セクション8.30)
Royer, et al. Experimental [Page 16] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [16ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to
include new error numbers.
REQUEST-STATUS--[iCAL]「要求状態」の特性は、新しいエラー番号を含むように広げられます。
RESTRICTION - In the final check when granting calendar access
requests, the CS test the results of a command for the value of
the "RESTRICTION" property in the corresponding "VRIGHT"
component, to determine if the access meets that restriction.
(Section 8.32)
RESTRICTION--カレンダーアクセス要求を承諾するときの最終的なチェックでは、CSは、アクセスがその制限を満たすかどうか決定するために対応する"VRIGHT"コンポーネントにおける、「制限」属性の価値のためのコマンドの結果をテストします。 (セクション8.32)
SCOPE - The "SCOPE" property is used in "VRIGHT"s component to
select the subset of data that may be acted upon when checking
access rights. (Section 8.33)
SCOPE、--、「範囲」の特性が中で使用される「「アクセス権をチェックするとき実行されるかもしれないデータの部分集合を選択するためにはsコンポーネント」のVRIGHT (セクション8.33)
SEQUENCE - When the "SEQUENCE" property is used in a "VALARM"
component, it uniquely identifies the instances of the "VALARM"
within that component.
SEQUENCE--「系列」の特性が"VALARM"コンポーネントに使用されるとき、それはそのコンポーネントの中で唯一"VALARM"のインスタンスを特定します。
STORES-EXPANDED - Specifies if the implementation stores recurring
objects expanded or not. (Section 8.34)
ストア-EXPANDED--実装がオブジェクトが広げた再発を保存するかどうか指定します。 (セクション8.34)
TARGET - The new "VCALENDAR" component property "TARGET" (Section
8.35) is used to specify which calendar(s) will be the subject of
the CAP command.
TARGET--新しい"VCALENDAR"コンポーネント特性の「目標」(セクション8.35)は、どのカレンダーが上限コマンドの対象になるかを指定するのに使用されます。
TRANSP - This is a modification of the [iCAL] "TRANSP" property and
it allows more values. The new values are related to conflict
control. (Section 8.36)
TRANSP--これは[iCAL]"TRANSP"の特性の変更であり、それは、より多くの値を許容します。 新しい値は闘争コントロールに関連します。 (セクション8.36)
2.1.3. New Components (summary)
2.1.3. 新しいコンポーネント(概要)
VAGENDA - CAP allows the fetching and storing of the entire contents
of a calendar. The "VCALENDAR" component is not sufficient to
encapsulate all of the needed data that describes a calendar. The
"VAGENDA" component is the encapsulating object for an entire
calendar. (Section 9.1)
VAGENDA--CAPはカレンダーの全体のコンテンツのとって来るのと保存を許します。 "VCALENDAR"コンポーネントは、カレンダーについて説明する必要なデータのすべてをカプセル化するために十分ではありません。 "VAGENDA"コンポーネントは全体のカレンダーのための要約オブジェクトです。 (セクション9.1)
VCALSTORE - Each CS contains one or more calendars (VAGENDAs), the
"VCALSTORE" component is the encapsulating object that can hold
all of the "VAGENDA" components along with any components and
properties that are unique to the store level. (Section 9.2)
VCALSTORE--"VCALSTORE"コンポーネントは、各CSが1つ以上のカレンダー(VAGENDAs)を含んでいて、どんなコンポーネントに伴う"VAGENDA"コンポーネントのすべても保持できる要約オブジェクトと店レベルにユニークな特性です。 (セクション9.2)
VCAR - Calendar Access Rights are specified and encapsulated in the
new iCalendar "VCAR" component. The "VCAR" component holds some
new properties and at least one "VRIGHT" component. (Section 9.3)
VCAR--カレンダーAccess Rightsは新しいiCalendar"VCAR"の部品で指定されて、カプセル化されます。 "VCAR"コンポーネントはいくつかの新しい特性と少なくとも1つの"VRIGHT"コンポーネントを保持します。 (セクション9.3)
VRIGHT - This component encapsulates a set of instructions to the
CS to define the rights or restrictions needed. (Section 9.4)
VRIGHT--このコンポーネントは、必要である権利か制限を定義するために1セットの指示をCSにカプセル化します。 (セクション9.4)
Royer, et al. Experimental [Page 17] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [17ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
VREPLY - This component encapsulates a set of data that can consist
of an arbitrary number of properties and components. Its contents
are dependent on the command that was issued. (Section 9.5)
VREPLY--このコンポーネントは特性とコンポーネントの特殊活字の数字から成ることができる1セットのデータをカプセル化します。 内容は発行されたコマンドに依存しています。 (セクション9.5)
VQUERY - The search operation makes use of a new component, called
"VQUERY" and a new value type "CAL-QUERY" (Section 6.1.1). The
"VQUERY" component is used to fetch objects from the CS. (Section
9.6)
VQUERY--索敵行動は"VQUERY"と新しい値のタイプ「カル-質問」(セクション6.1.1)と呼ばれる新しいコンポーネントを利用します。 "VQUERY"コンポーネントは、Csからオブジェクトをとって来るのに使用されます。 (セクション9.6)
2.2. Relationship of RFC-2446 (ITIP) to CAP
2.2. ふたをするRFC-2446(ITIP)の関係
[iTIP] describes scheduling methods that result in indirect manipulation of components. In CAP, the "CREATE" command is used to deposit entities into the store. Other CAP commands, such as "DELETE", "MODIFY", and "MOVE" command values, provide direct manipulation of components. In the CAP calendar store model, scheduling messages are conceptually kept separate from other components by their state.
[iTIP]はコンポーネントの間接的な操作をもたらすスケジューリング法を説明します。 CAPでは、「作成」コマンドは、店に実体を預けるのに使用されます。 他のCAPコマンド(コマンド値を「削除し」て、「変更し」て、「動く」)はコンポーネントの直接操作を提供します。 CAPカレンダー店モデルでは、スケジューリングメッセージは概念的にそれらの状態のそばで他のコンポーネントから別々に保たれます。
All scheduling operations are as defined in [iTIP]. This memo makes no changes to any of the methods or procedures described in [iTIP]. In this memo, referring to the presence of the "METHOD" property in an object is the same as saying an [iTIP] object.
すべてのスケジューリング操作が[iTIP]で定義されるようにあります。 このメモは[iTIP]で説明されたメソッドか手順のどれかへの変更を全く行いません。 このメモでは、オブジェクトでの「メソッド」の特性の存在について言及するのは[iTIP]オブジェクトを示すのと同じです。
A CUA may create a "BOOKED" state object by depositing an iCalendar object into the store. This is done by depositing an object that does not have a "METHOD" property. The CS then knows to set the state of the object to the "BOOKED" state. If the object has a "METHOD" property, then the object is stored in the "UNPROCESSED" state.
CUAは、iCalendarオブジェクトを店に預けることによって、「予約された」州のオブジェクトを作成するかもしれません。 「メソッド」の特性を持っていないオブジェクトを預けることによって、これをします。 そして、CSは、「予約された」状態にオブジェクトの状態を設定するのを知っています。 オブジェクトに「メソッド」の特性があるなら、オブジェクトは「未加工」の状態に保存されます。
If existing "UNPROCESSED" state objects exist in the CS for the same UID (UID is defined in [iCAL]), then a CUA may wish to consolidate the objects into one "BOOKED" state object. The CUA would fetch the "UNPROCESSED" state objects for that UID and process them in the CUA as described in [iTIP]. Then, if the CUA wished to book the UID, the CUA would issue a "CREATE" command to create the new "BOOKED" state object in the CS, followed by a "DELETE" command to remove any related old [iTIP] objects from the CS. It might also involve the CUA sending some [iMIP] objects or contacting other CSs and performing CAP operations on those CSs.
既存の「未加工」の州のオブジェクトが同じUIDのためのCsで存在しているなら(UIDは[iCAL]で定義されます)、クーアは1個の「予約された」州のオブジェクトにオブジェクトを統合したがっているかもしれません。 CUAは[iTIP]で説明されるようにそのUIDのために「未加工」の州のオブジェクトをとって来て、クーアでそれらを処理するでしょう。 そして、CUAがUIDを予約したいなら、CUAはCsからどんな関連する古い[iTIP]オブジェクトも取り除く「削除」コマンドがあとに続いたCsで新しい「予約された」州のオブジェクトを作成する「作成」コマンドを発行するでしょうに。 また、それはいくつかの[iMIP]オブジェクトを送るか、他のCSsに連絡して、またはそれらのCSsにCAP操作を実行するCUAにかかわるかもしれません。
The CUA could also decide not to book the object. In this case, the "UNPROCESSED" state objects could be removed from the CS, or the CUA could set those objects to the marked-for-delete state. The CUA could also ignore objects for later processing.
また、CUAは、オブジェクトを予約しないと決めることができました。 この場合、Csから「未加工」の州のオブジェクトを取り除くことができたか、またはクーアがそれらのオブジェクトを設定できた、マークされる、削除、状態。 また、CUAは、後で処理するためにオブジェクトを無視できました。
Royer, et al. Experimental [Page 18] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [18ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
The marked-for-delete state is used to keep the object around so that the CUA can process duplicate requests automatically. If a duplicate [iTIP] object is deposited into the CS and there exists identical marked-for-delete objects, then a CUA acting on behalf of the "OWNER" can silently drop those duplicate entries.
マークされる、削除、状態は、CUAが自動的に写し要求を処理できるようにオブジェクトを置くのに使用されます。 写し[iTIP]オブジェクトがCSに預けられて、同じ状態で存在している、マークされる、削除、オブジェクト、そして、「所有者」を代表して行動するCUAは静かにそれらの写しエントリーを下げることができます。
Another purpose for the marked-for-delete state is so that, when a CU decides they do not wish to have the object show in their calendar, the CUA can book the object by changing the "PARTSTAT" parameter to "DECLINED" in the "ATTENDEE" property that corresponds to their UPN. Then the CUA can perform [iTIP] processing such as sending back a decline, and then mark that object as marked-fo-delete. The CUA might be configurable to automatically drop any updates for that object, knowing the CU has already declined.
別の目的、マークされる、削除、状態は、CUが、彼らがそれらのカレンダーでオブジェクトを目立たせたくないと決めると、CUAが"PARTSTAT"パラメタをそれらのUPNに対応する「出席者」の特性で「傾けられること」に変えることによってオブジェクトを予約できるためのそうです。 CUAが衰退を返送などなどの[iTIP]処理を実行して、次にそのオブジェクトをマークできるその時、著しいfoは削除します。 CUが既に減退したのを知っていて、CUAは自動的にその趣意でどんなアップデートも下げるのにおいて構成可能であるかもしれません。
When synchronizing with multiple CUAs, the marked-for-delete state could be used to inform the synchronization process that an object is to be deleted. How synchronization is done is not specified in this memo.
複数のCUAsに同期してマークされる、削除、状態は、オブジェクトが削除されることになっていることを同期プロセスに知らせるのに使用されるかもしれません。 同期がどう完了しているかはこのメモで指定されません。
Several "UNPROCESSED" state entries can be in the CS for the same UID. However, once consolidated, only one object exists in the CS and that is the booked object. The other objects MUST be removed or have their state changed to "DELETED".
同じUIDのためのCsにはいくつかの「未加工」の州のエントリーがあることができます。 しかしながら、いったん統合されると、1個のオブジェクトだけがCSに存在しています、そして、それは予約しているオブジェクトです。 他のオブジェクトは、「削除される」ように移されなければならないか、またはそれらの状態を変えるのをしなければなりません。
There MUST NOT be more than one "BOOKED" state object in a calendar for the same "UID". The "ADD" method value may create multiple objects in the "BOOKED" state for the same UID; however, for the purpose of this memo, they are the same object and simply have multiple "VCALENDAR" components.
同じ"UID"のためのカレンダーには1個以上の「予約された」州のオブジェクトがあるはずがありません。 メソッド値が作成するかもしれない「加えてください」倍数は同じUIDのために「予約された」状態で反対します。 しかしながら、彼らは、このメモの目的のために、同じオブジェクトであり、単に複数の"VCALENDAR"コンポーネントを持っています。
For example, if you were on vacation, you could have received a "REQUEST" method to attend a meeting and several updates to that meeting. Your CUA would have to issue "SEARCH" commands to find them in the CS using CAP, process them, and determine the final state of the object from a possible combination of user input and programmed logic. Then the CUA would instruct the CS to create a new booked object from the consolidated results. Finally, the CUA could do a "DELETE" command to remove the related "UNPROCESSED" state objects. See [iTIP] for details on resolving multiple [iTIP] scheduling entries.
例えば、休みをとっていたなら、あなたはミーティングといくつかのアップデートにそのミーティングに出席する「要求」メソッドを受けたかもしれません。 あなたのCUAはCsで上限を使用することでそれらを見つけて、それらを処理して、ユーザの可能な組み合わせからのオブジェクトの最終的な州が論理を入力して、プログラムしたことを決定する「検索」コマンドを発行しなければならないでしょう。 そして、CUAは、統合結果から新しい予約しているオブジェクトを作成するようCSに命令するでしょう。 最終的に、CUAは関連する「未加工」の州のオブジェクトを取り除く「削除」コマンドができました。 エントリーの計画をしながら複数の[iTIP]を決議することに関する詳細に関して[iTIP]を見てください。
Royer, et al. Experimental [Page 19] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [19ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
3. CAP Design
3. 上限デザイン
3.1. System Model
3.1. システムモデル
The system model describes the high level components of a calendar system and how they interact with each other.
システムモデルはカレンダーシステムとそれらがどう互いに対話するかに関する高い平らなコンポーネントについて説明します。
CAP is used by a CUA to send commands to, and receive responses from, a CS.
CAPは、CSからコマンドを送って、応答を受けるのにCUAによって使用されます。
The CUA prepares a [MIME] encapsulated message, sends it to the CS, and receives a [MIME] encapsulated response. The calendaring-related information within these messages are represented by iCalendar objects. In addition, the "GET-CAPABILITY" command can be sent from the CS to the CUA.
CUAはメッセージであるとカプセル化された[MIME]を準備して、それをCSに送って、応答であるとカプセル化された[MIME]を受けます。 これらのメッセージの中のcalendaring関連の情報はiCalendarオブジェクトによって表されます。 さらに、「能力を得る、」 コマンド、Csからクーアに送ることができます。
There are two distinct protocols in operation to accomplish this exchange. [BEEP] is the transport protocol used to move these encapsulations between a CUA and a CS. CAP's [BEEP] profile defines the application protocol that specifies the content and semantics of the messages sent between the CUA and the CS.
2つの異なったプロトコルが、この交換を実行するために稼働中です。 [BEEP]はこれらのカプセル化をCUAとCSの間に動かすのに使用されるトランスポート・プロトコルです。 CAP[BEEP]のプロフィールはCUAとCSの間に送られたメッセージの内容と意味論を指定するアプリケーション・プロトコルを定義します。
3.2. Calendar Store Object Model
3.2. カレンダーストアオブジェクト・モデル
[iCAL] describes components such as events, todos, alarms, and timezones. CAP requires additional object infrastructure, in particular, detailed definitions of the containers for events and todos (calendars), access control objects, and a query language.
[iCAL]はイベントや、todosや、アラームや、タイムゾーンなどの成分について説明します。 CAPは追加オブジェクトインフラストラクチャを必要とします、イベントのためのコンテナの特定の、そして、詳細な定義、todos(カレンダー)、アクセス制御オブジェクト、および照会言語で。
The conceptual model for a calendar store is shown below. The calendar store (VCALSTORE - Section 9.2) contains "VCAR"s, "VQUERY"s, "VTIMEZONE"s, "VAGENDA"s and calendar store properties.
カレンダー店への概念モデルは以下で見せられます。 カレンダー店(VCALSTORE--セクション9.2)が含んでいる、「VCAR、「s、「VQUERY、「s、「VTIMEZONE、「s、「VAGENDA、「sとカレンダー店の特性。」
Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s, and calendar properties.
カレンダー(VAGENDAs)が含んでいる、「VEVENT、「s、「VTODO、「s、「VJOURNAL、「s、「VCAR、「s、「VTIMEZONE、「s、"VFREEBUSY"、「VQUERY、「s、およびカレンダーの特性。」
The component "VCALSTORE" is used to denote the root of the calendar store and contains all of the calendars.
コンポーネント"VCALSTORE"は、カレンダー店の根を指示するのに使用されて、カレンダーのすべてを含んでいます。
Royer, et al. Experimental [Page 20] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [20ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Calendar Store
カレンダーストア
VCALSTORE
|
+-- properties
+-- VCARs
+-- VQUERYs
+-- VTIMEZONEs
+-- VAGENDA
| |
| +--properties
| +--VEVENTs
| | |
| | +--VALARMs
| +--VTODOs
| | |
| | +--VALARMs
| +--VJOURNALs
| +--VCARs
| +--VTIMEZONEs
| +--VQUERYs
| +--VFREEBUSYs
| |
| | ...
.
.
+-- VAGENDA
. .
. .
. .
VCALSTORE| +--+--VCARs+--特性のVQUERYs+--VTIMEZONEs+--VAGENDA| | | +--特性| +--VEVENTs| | | | | +--VALARMs| +--VTODOs| | | | | +--VALARMs| +--VJOURNALs| +--VCARs| +--VTIMEZONEs| +--VQUERYs| +--VFREEBUSYs| | | | ... . . +--VAGENDA……
Calendars within a Calendar Store are identified by their unique Relative CALID.
Calendarストアの中のカレンダーはそれらのユニークなRelative CALIDによって特定されます。
3.3. Protocol Model
3.3. プロトコルモデル
CAP uses [BEEP] as the transport and authentication protocol.
輸送と認証が議定書を作るとき、CAPは[BEEP]を使用します。
The initial charset MUST be UTF-8 for a session in an unknown locale. If the CS supplied the [BEEP] 'localize' attribute in the [BEEP] 'greeting', then the CUA may tell the CS to switch locales for the session by issuing the "SET-LOCALE" CAP command and supplying one of the locales supplied by the [BEEP] 'localize' attribute. If a locale is supplied, the first locale in the [BEEP] 'localize' attribute is the default locale of the CS. The locale is switched only after a successful reply.
初期のcharsetは未知の現場でのセッションのためのUTF-8でなければなりません。 CSが'ローカライズしてください'という[BEEP]'挨拶'における[BEEP]属性を供給したなら、CUAは、セッションのために「セット現場」上限コマンドを発行して、[ビープ音]によって供給された現場の1つを供給することによって現場を切り換えるCSが属性を'ローカライズする'と言うかもしれません。 現場を供給するなら、'ローカライズしてください'という[BEEP]属性における最初の現場はCSのデフォルト現場です。 現場はうまくいっている回答の後にだけ切り換えられます。
Royer, et al. Experimental [Page 21] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [21ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
The "DEFAULT-CHARSET" property of the CS contains the list of charsets supported by the CS with the first value being the default for new calendars. If the CUA wishes to switch to one of those charsets for the session, the CUA issues the "SET-LOCALE" command. The CUA would have to first perform a "GET-CAPABILITY" command on the CS to get the list of charsets supported by the CS. The charset is switched only after a successful reply.
Csの「デフォルト-CHARSET」の特性は新暦のためにCsによってデフォルトである最初の値でサポートされたcharsetsのリストを含んでいます。 CUAがセッションのためにそれらのcharsetsの1つに切り替わりたいなら、CUAは「セット現場」コマンドを発行します。 CUAが最初にaを実行しなければならないだろう、「能力を得る、」 CsでCsでcharsetsのリストをサポートさせると命令してください。 charsetはうまくいっている回答の後にだけ切り換えられます。
The CUA may switch locales and charsets as needed. There is no requirement that a CS support multiple locales or charsets.
CUAは必要に応じて現場とcharsetsを切り換えるかもしれません。 CSが複数の現場かcharsetsをサポートするという要件が全くありません。
3.3.1. Use of BEEP, MIME, and iCalendar
3.3.1. ビープ音、MIME、およびiCalendarの使用
CAP uses the [BEEP] application protocol over TCP. Refer to [BEEP] and [BEEPTCP] for more information. The default port on which the CS listens for connections is user port 1026.
CAPはTCPの上で[BEEP]アプリケーション・プロトコルを使用します。 詳しい情報について[BEEP]と[BEEPTCP]を参照してください。 CSが接続の聞こうとするデフォルトポートはユーザポート1026です。
The [BEEP] data exchanged in CAP is a iCalendar MIME content that fully conforms to [iCAL] iCalendar format.
CAPで交換された[BEEP]データは[iCAL]iCalendar形式に完全に従うiCalendar MIME内容です。
This example tells the CS to generate and return 10 UIDs to be used by the CUA. Note that throughout this memo, 'C:' refers to what the CUA sends, 'S:' refers to what the CS sends, 'I:' refers to what the initiator sends, and 'L:' refers to what the listener sends. Here initiator and listener are used as defined in [BEEP].
この例はCUAによって使用されるように、10UIDsを生成して、返すようにCSに言います。 'このメモ中でそれに注意してください'、C: 'CUAが送るものについて言及する、である:'、言及、CSが送るもの、'I: '創始者が何に発信するか、そして、'Lを参照します:、'リスナーが送るものについて言及します。 ここで、創始者とリスナーは[BEEP]で定義されるように使用されています。
C: MSG 1 2 . 432 62
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID
C: END:VCALENDAR
C: エムエスジー1 2.43262C: コンテントタイプ: テキスト/カレンダーC: C: : VCALENDAR Cを始めてください: バージョン: 2.0C: PRODID:、-、だれかの//prodid C: CMD;、ID=ユニークである、-、cua-123; オプション=10: UIDを生成しているC: 終わり: VCALENDAR
NOTE: The following examples will not include the [BEEP] header and footer information. Only the iCalendar objects that are sent between the CUA and CS will be shown because the [BEEP] payload boundaries are independent of CAP.
以下に注意してください。 以下の例は[BEEP]ヘッダーとフッター情報を含まないでしょう。 [BEEP]ペイロード境界がCAPから独立しているので、CUAとCSの間に送られるiCalendarオブジェクトだけが見せられるでしょう。
The commands listed below are used to manipulate or access the data on the calendar store:
以下に記載されたコマンドはカレンダー店に関するデータに操るか、またはアクセスするのに使用されます:
ABORT - Sent to halt the processing of some of the commands.
(Section 10.2)
ABORT--いくつかのコマンドの処理を止めるために、送ります。 (セクション10.2)
CONTINUE - Sent to continue processing a command that has reached
its specified timeout time. (Section 10.3)
CONTINUE--指定されたタイムアウト時間に達したコマンドを処理し続けるために、送ります。 (セクション10.3)
Royer, et al. Experimental [Page 22] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [22ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
CREATE - Create a new object on the CS. Initiated only by the CUA.
(Section 10.4)
CREATE--新しいオブジェクトをCSに作成してください。 単にCUAによって開始されます。 (セクション10.4)
SET-LOCALE - Tell the CS to use any named locale and charset
supplied. Initiated by the CUA only. (Section 10.13)
SET-LOCALE--命名された現場とcharsetが供給したいずれも使用するようにCSに言ってください。 CUAだけによって開始されます。 (セクション10.13)
DELETE - Delete objects from the CS. Initiated only by the CUA.
Can also be used to mark an object for deletion. (Section 10.5)
DELETE--CSからオブジェクトを削除してください。 単にCUAによって開始されます。 また、削除のためにオブジェクトをマークするのに使用できます。 (セクション10.5)
GENERATE-UID - Generate one or more unique ids. Initiated only by
the CUA. (Section 10.6)
GENERATE-UID--1つ以上のユニークなイドを生成してください。 単にCUAによって開始されます。 (セクション10.6)
GET-CAPABILITY - Query the capabilities of the other end point of the
session. (Section 10.7)
GET-CAPABILITY--セッションのもう片方のエンドポイントの能力について質問してください。 (セクション10.7)
IDENTIFY - Set a new identity for the session. Initiated only by
the CUA. (Section 10.8)
IDENTIFY--セッションのために新しいアイデンティティを設定してください。 単にCUAによって開始されます。 (セクション10.8)
MODIFY - Modify components. Initiated by the CUA only. (Section
10.9)
MODIFY--コンポーネントを変更してください。 CUAだけによって開始されます。 (セクション10.9)
MOVE - Move components to another container. Initiated only by the
CUA. (Section 10.10)
MOVE--コンポーネントを別のコンテナに動かしてください。 単にCUAによって開始されます。 (セクション10.10)
REPLY - When replying to a command, the "CMD" value will be set to
"REPLY" so that it will not be confused with a new command.
(Section 10.11)
REPLY--コマンドに答えるとき、"CMD"値が新しいコマンドに混乱しないように「返答する」ように設定されるでしょう。 (セクション10.11)
SEARCH - Search for components. Initiated only by the CUA.
(Section 10.12)
検索--コンポーネントを捜し求めてください。 単にCUAによって開始されます。 (セクション10.12)
TIMEOUT - Sent when a specified amount of time has lapsed and a
command has not finished. (Section 10.14)
TIMEOUT--指定された時間が経過したとき、発信して、コマンドは終わっていません。 (セクション10.14)
4. Security Model
4. 機密保護モデル
BEEP transport performs all session authentication.
BEEP輸送はすべてのセッション認証を実行します。
4.1. Calendar User and UPNs
4.1. カレンダーユーザとUPNs
A CU is an entity that can be authenticated. It is represented in CAP as a UPN, which is a key part of access rights. The UPN representation is independent of the authentication mechanism used during a particular CUA/CS interaction. This is because UPNs are used within VCARs. If the UPN were dependent on the authentication mechanism, a VCAR could not be consistently evaluated. A CU may use one mechanism while using one CUA, but the same CU may use a
CUは認証できる実体です。 それはUPNとしてCAPに表されます。(UPNはアクセス権の主要な部分です)。 UPN表現は特定のCUA/CS相互作用の間に使用される認証機構から独立しています。 これはUPNsがVCARsの中で使用されるからです。 UPNが認証機構に依存しているなら、一貫してVCARを評価できないでしょうに。 CUはあるCUAを使用している間あるメカニズムを使用するかもしれませんが、同じCUはaを使用するかもしれません。
Royer, et al. Experimental [Page 23] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [23ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
different authentication mechanism when using a different CUA, or while connecting from a different location.
別の場所と異なった認証機構、いつが異なったCUAを使用するか、そして、または接続しています。
The user may also have multiple UPNs for various purposes.
また、ユーザは様々な目的のための複数のUPNsを持っているかもしれません。
Note that the immutability of the user's UPN may be achieved by using SASL's authorization identity feature. The transmitted authorization identity may be different than the identity in the client's authentication credentials [SASL, section 3]. This also permits a CU to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying SASL. Also, the form of authentication identity supplied by a service like TLS may not correspond to the UPNs used to express a server's access rights, requiring a server-specific mapping to be done. The method by which a server determines a UPN, based on the authentication credentials supplied by a client, is implementation-specific. See [BEEP] for authentication details; [BEEP] relies on SASL.
ユーザのUPNの不変性がSASLの承認アイデンティティ機能を使用することによって達成されるかもしれないことに注意してください。 伝えられた承認のアイデンティティはクライアントの認証資格証明書[SASL、セクション3]におけるアイデンティティと異なっているかもしれません。 また、これはそれら自身の資格証明書を使用するしかし、アクセスが特権を与えさせるアイデンティティの要求を認証するそれらがproxying SASLであるCUを可能にします。 また、TLSがUPNsに対応しないかもしれないようにサービスで供給された認証のアイデンティティのフォームは以前はよくサーバのアクセス権を言い表していました、サーバ特有のマッピングが完了しているのが必要であることで。 サーバがクライアントによって供給された認証資格証明書に基づくUPNを決定するメソッドは実装特有です。 認証の詳細に関して[BEEP]を見てください。 [BEEP]はSASLを当てにします。
4.1.1. UPNs and Certificates
4.1.1. UPNsと証明書
When using X.509 certificates for purposes of CAP authentication, the UPN should appear in the certificate. Unfortunately, there is no single correct guideline for which field should contain the UPN.
CAP認証の目的にX.509証明書を使用するとき、UPNは証明書に現れるはずです。 残念ながら、分野がUPNを含むべきであるどんなただ一つの正しいガイドラインもありません。
Quoted from RFC-2459, section 4.1.2.6 (Subject):
RFC-2459、セクション4.1.2.6(対象)から引用される:
If subject naming information is present only in the
subjectAlt-Name extension (e.g., a key bound only to an email
address or URI), then the subject name MUST be an empty
sequence and the subjectAltName extension MUST be critical.
対象の命名情報がsubjectAlt-名前拡大だけで存在しているなら(例えばキーはEメールアドレスかURIだけに固まりました)、対象の名前は空の系列であるに違いありません、そして、subjectAltName拡張子は重要であるに違いありません。
Implementations of this specification MAY use these comparison
rules to process unfamiliar attribute types (i.e., for name
chaining). This allows implementations to process certificates
with unfamiliar attributes in the subject name.
この仕様の実装は、なじみのない属性タイプ(すなわち、名前推論のための)を処理するのにこれらの比較規則を使用するかもしれません。 これで、なじみのない属性が対象の名前にある状態で、実装は証明書を処理できます。
In addition, legacy implementations exist where an RFC 2822
name [RFC2822] is embedded in the subject distinguished name as
an EmailAddress attribute. The attribute value for
EmailAddress is of type IA5String to permit inclusion of the
character '@', which is not part of the PrintableString
character set. EmailAddress attribute values are not case
sensitive (e.g., "fanfeedback@redsox.example.com" is the same
as "FANFEEDBACK@REDSOX.EXAMPLE.COM").
さらに、レガシー実装はRFC2822名[RFC2822]がEmailAddress属性として対象の分類名に埋め込まれているところに存在しています。 EmailAddressのための属性値は、キャラクタ'@'の包含を可能にするためにはタイプIA5Stringのものです。(包含はPrintableString文字集合の一部ではありません)。 EmailAddress属性値は大文字と小文字を区別していません(例えば、" fanfeedback@redsox.example.com "は" FANFEEDBACK@REDSOX.EXAMPLE.COM "と同じです)。
Conforming implementations generating new certificates with
electronic mail addresses MUST use the rfc822Name in the
subject alternative name field (see sec. 4.2.1.7 of [X509CRL])
新しい証明書を作る実装を電子メールアドレスに一致させると、rfc822Nameは分野という対象の代替名に使用されなければなりません。(秒に遭遇してください。 4.2.1.7 [X509CRL]について)
Royer, et al. Experimental [Page 24] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [24ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
to describe such identities. Simultaneous inclusion of the
EmailAddress attribute in the subject distinguished name to
support legacy implementations is deprecated but permitted.
そのようなアイデンティティについて説明するために。 レガシー実装をサポートする対象の分類名でのEmailAddress属性の同時の包含は、推奨しないのですが、受入れられます。
Since no single method of including the UPN in the certificate will work in all cases, CAP implementations MUST support the ability to configure what the mapping will be by the CS administrator. Implementations MAY support multiple mapping definitions, for example, the UPN may be found in either the subject alternative name field, or the UPN may be embedded in the subject distinguished name as an EmailAddress attribute.
証明書にUPNを含むどんなただ一つのメソッドもすべての場合で利かないので、CAP実装はCS管理者がマッピングがなるか何を構成するか能力をサポートしなければなりません。 実装が、複数のマッピングが定義であるとサポートするかもしれませんか、例えば、UPNが分野という対象の代替名で見つけられるかもしれませんか、またはUPNはEmailAddress属性として対象の分類名に埋め込まれるかもしれません。
Note: If a CS or CUA is validating data received via [iMIP], if the "ORGANIZER" or "ATTENDEE" properties said, for example, "ATTENDEE;CN=Joe Random User:MAILTO:juser@example.com", then the email address should be checked against the UPN. This is so the "ATTENDEE" property cannot be changed to something misleading like "ATTENDEE;CN=Joe Rictus User:MAILTO:jrictus@example.com" and have it pass validation. Note that it is the email addresses that miscompare, the CN miscompare is irrelevant.
以下に注意してください。 CSかCUAであるなら、例えば、「オーガナイザー」か「出席者」の特性が、「出席者; CNはジョー任意のユーザー:MAILTO: juser@example.com と等しく」、次に、EメールアドレスがUPNに対してチェックされるべきであると言ったなら、[iMIP]を通してデータを有効にするのを受け取りますか? これは、「出席者」の特性で「出席者; CNはジョーリクタスユーザ:MAILTO: jrictus@example.com と等しいです」のように何か紛らわしいものに変えられて、それが合法化を通過できないようにそうです。 不一致、CN不一致はEメールアドレスですが、それがそうであることに注意してください。無関係。
4.1.2. Anonymous Users and Authentication
4.1.2. 匿名のユーザと認証
Anonymous access is often desirable. For example, an organization may publish calendar information that does not require any access control for viewing or login. Conversely, a user may wish to view unrestricted calendar information without revealing their identity.
匿名のアクセスはしばしば望ましいです。 例えば、組織は見るためにアクセス制御を必要としないか、またはログインしない予定表を発表するかもしれません。 逆に、彼らのアイデンティティを明らかにしないで、ユーザは無制限な予定表を見たがっているかもしれません。
4.1.3. User Groups
4.1.3. ユーザグループ
A User Group is used to represent a collection of CUs or other UGs that can be referenced in VCARs. A UG is represented in CAP as a UPN. The CUA cannot distinguish between a UPN that represents a CU or a UG.
ユーザグループは、VCARsで参照をつけることができるCUsか他のUGsの収集を表すのに使用されます。 UGはUPNとしてCAPに表されます。 CUAはCUかUGを表すUPNを見分けることができません。
UGs are expanded as necessary by the CS. The CS MAY expand a UG (including nested UGs) to obtain a list of unique CUs. Duplicate UPNs are filtered during expansion.
UGsは同じくらい必要な状態でCSによって広げられます。 CS MAYは、ユニークなCUsのリストを得るために、UG(入れ子にされたUGsを含んでいる)を広げます。 写しUPNsは拡張の間、フィルターにかけられます。
How the UG expansion is maintained across commands is implementation-specific. A UG may reference a static list of members, or it may represent a dynamic list. Operations SHOULD recognize changes to UG membership.
UG拡張がコマンドの向こう側にどう維持されるかは、実装特有です。 UGは静的な会員名簿に参照をつけるかもしれませんか、またはそれがダイナミックなリストを表すかもしれません。 操作SHOULDはUG会員資格への変化を認識します。
CAP does not define commands or methods for managing UGs.
CAPはUGsを管理するためのコマンドかメソッドを定義しません。
Royer, et al. Experimental [Page 25] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [25ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
4.2. Access Rights
4.2. アクセス権
Access rights are used to grant or deny access to calendars, components, properties, and parameters in a CS to a CU. CAP defines a new component type called a Calendar Access Right (VCAR). Specifically, a "VCAR" component grants, or denies, UPNs the right to search and write components, properties, and parameters on calendars within a CS.
アクセス権は、CSのカレンダー、コンポーネント、特性、およびパラメタへのアクセスをCUに承諾するか、または拒絶するのに使用されます。 CAPはCalendar Access Right(VCAR)と呼ばれる新しいコンポーネント型を定義します。 明確に"VCAR"コンポーネント交付金、否定、UPNs、Csの中にカレンダーに関するコンポーネント、特性、およびパラメタを捜して、書く権利。
The "VCAR" component model does not put any restriction on the sequence in which the object and access rights are created. That is, an object associated with a particular "VCAR" component might be created before or after the actual "VCAR" component is defined. In addition, the "VCAR" and "VEVENT" components might be created in the same iCalendar object and passed together in a single object.
"VCAR"コンポーネントモデルはオブジェクトとアクセス権が作成される系列に少しの制限も置きません。 以前か実際の"VCAR"コンポーネントが定義された後にすなわち、特定の"VCAR"コンポーネントに関連しているオブジェクトは作成されるかもしれません。 さらに、"VCAR"と"VEVENT"コンポーネントは、同じiCalendarオブジェクトで作成されて、単一のオブジェクトで一緒に通過されるかもしれません。
All rights MUST be denied unless specifically granted.
明確に与えられない場合、すべての権利を否定しなければなりません。
If two rights specified in "VCAR" components are in conflict, the right that denies access always takes precedence over the right that grants access. Any attempt to create a "VCAR" component that conflicts with a "VCAR" components with a "DECREED" property set to the "TRUE" value must fail.
"VCAR"コンポーネントで指定された2つの権利が闘争中であるなら、アクセスを拒絶する権利はアクセサリーを与える右の上でいつも優先します。 「命じられた」特性がある"VCAR"コンポーネントとの闘争が「本当」の値に設定する"VCAR"コンポーネントを作成するどんな試みも失敗しなければなりません。
4.2.1. Access Control and NOCONFLICT
4.2.1. アクセスコントロールとNOCONFLICT
The "TRANSP" property can take on values -- "TRANSPARENT-NOCONFLICT" and "OPAQUE-NOCONFLICT" -- that prohibit other components from overlapping it. This setting overrides access. The "ALLOW-CONFLICT" CS, Calendar or component setting may also prevent overlap, returning an error code "6.3".
"TRANSP"の特性は「透明なNOCONFLICT」と「不透明なNOCONFLICT」というそれを重ね合わせるのから他のコンポーネントを禁じる値を呈することができます。 この設定はアクセサリーをくつがえします。 「闘争を許す、」 Cs、カレンダーかコンポーネントの設定はまた、オーバラップを防いで、「6.3インチ」をエラーコードに返すのがそうするかもしれません。
4.2.2. Predefined VCARs
4.2.2. 事前に定義されたVCARs
The predefined calendar access CARIDs that MUST be implemented are:
実装しなければならない事前に定義されたカレンダーアクセスCARIDsは以下の通りです。
CARID:READBUSYTIMEINFO - Specifies the "GRANT" and "DENY" rules
that allow UPNs to search "VFREEBUSY" components. An example
definition for this VCAR is:
CARID: READBUSYTIMEINFO--「交付金」を指定して、規則に対してそれを「否定すること」に、UPNsは"VFREEBUSY"コンポーネントを捜すことができます。 このVCARのための例の定義は以下の通りです。
BEGIN:VCAR
CARID:READBUSYTIMEINFO
BEGIN:VRIGHT
GRANT:*
PERMISSION:SEARCH
SCOPE:SELECT * FROM VFREEBUSY WHERE STATE() = 'BOOKED'
END:VRIGHT
END:VCAR
始まってください: : READBUSYTIMEINFOが始めるVCAR CARID: VRIGHT交付金: *許可: 検索範囲: 状態()=は終わりを'予約した': VRIGHTが終わるVFREEBUSY: VCARからの選んだ*
Royer, et al. Experimental [Page 26] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [26ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
CARID:REQUESTONLY - Specifies the "GRANT" and "DENY" rules to
UPNs other than the owner of the calendar and specifies the
ability to write new objects with the "METHOD" property set to
the "REQUEST" value. This CARID allows the owner to specify
which UPNs are allowed to make scheduling requests. An example
definition for this VCAR is:
CARID: REQUESTONLY--「交付金」を指定して、カレンダーの所有者以外のUPNsに対して規則を「否定し」て、「メソッド」特性のセットで新しいオブジェクトを書く能力を「要求」値に指定します。 このCARIDはどのUPNsがスケジューリング要求をすることができるかを所有者を指定させます。 このVCARのための例の定義は以下の通りです。
BEGIN:VCAR
CARID:REQUESTONLY
BEGIN:VRIGHT
GRANT:NON CAL-OWNERS()
PERMISSION:CREATE
RESTRICTION:SELECT VEVENT FROM VAGENDA
WHERE METHOD = 'REQUEST'
RESTRICTION:SELECT VTODO FROM VAGEND
WHERE METHOD = 'REQUEST'
RESTRICTION:SELECT VJOURNAL FROM VAGEND
WHERE METHOD = 'REQUEST'
END:VRIGHT
END:VCAR
始まってください: VCAR CARID: REQUESTONLYは始まります: VRIGHT交付金: 非カル所有者()PERMISSION: 制限を作成してください: メソッドが'要求'制限と等しいVAGENDAからVEVENTを選択してください: メソッドは'要求'制限と等しいです: メソッドが'要求'と等しいVAGENDからの選んだVJOURNALは終わります: VRIGHTが終わるVAGEND: VCARからVTODOを選択してください。
CARID:UPDATEPARTSTATUS - Grants authenticated users the right to
modify the instances of the "ATTENDEE" property set to one of
their calendar addresses in any components for any booked
component containing an "ATTENDEE" property. This allows (or
denies) a CU the ability to update their own participation
status in a calendar where they might not otherwise have
"MODIFY" command access. They are not allowed to change the
"ATTENDEE" property value. An example definition for this VCAR
(only affecting the "VEVENT" components) is:
CARID: UPDATEPARTSTATUS--「出席者」の特性を含むどんな予約しているコンポーネントのためにもどんなコンポーネントでも「出席者」特性のセットのインスタンスをそれらのカレンダーアドレスの1つに変更する権利を認証されたユーザに与えます。 これが許容する、(否定、)、CU、そうでなければ彼らが「変更」コマンドアクセサリーを持っていないかもしれないカレンダーのそれら自身の参加状態をアップデートする能力 彼らは「出席者」資産価値を変えることができません。 このVCAR("VEVENT"コンポーネントに影響するだけである)のための例の定義は以下の通りです。
BEGIN:VCAR
CARID:UPDATEPARTSTATUS
BEGIN:VRIGHT
GRANT:*
PERMISSION:MODIFY
SCOPE:SELECT ATTENDEE FROM VEVENT
WHERE ATTENDEE = SELF()
AND ORGANIZER = CURRENT-TARGET()
AND STATE() = 'BOOKED'
RESTRICTION:SELECT * FROM VEVENT
WHERE ATTENDEE = SELF()
END:VRIGHT
END:VCAR
始まってください: VCAR CARID: UPDATEPARTSTATUSは始まります: VRIGHTグラント: *許可: 範囲を変更してください: 出席者=自己()とオーガナイザー=現在の目標()と状態()=が制限を'予約した'VEVENTから出席者を選んでください: 自己()終わり: 出席者=VRIGHTが終わるVEVENT: VCARからの*を選択してください。
CARID:DEFAULTOWNER - Grants to any owner the permission they have
for the target. An example definition for this VCAR is:
CARID: DEFAULTOWNER--彼らが目標のために持っている許可をどんな所有者にも与えます。 このVCARのための例の定義は以下の通りです。
Royer, et al. Experimental [Page 27] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [27ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
BEGIN:VCAR
CARID:DEFAULTOWNER
BEGIN:VRIGHT
GRANT:CAL-OWNERS()
PERMISSION:*
SCOPE:SELECT * FROM VAGENDA
END:VRIGHT
END:VCAR
始まってください: : DEFAULTOWNERが始めるVCAR CARID: VRIGHT交付金: カル所有者()PERMISSION: *範囲: VAGENDAエンド: VRIGHTエンド: VCARからの選んだ*
4.2.3. Decreed VCARs
4.2.3. 命じられたVCARs
A CS MAY choose to implement and allow persistent immutable VCARs that may be configured by the CS administrator. A reply from the CS may dynamically create "VCAR" components that are decreed depending on the implementation. To the CUA, any "VCAR" component with the "DECREED" property set to "TRUE" cannot be changed by the currently authenticated UPN, and, depending on the implementation and other "VCAR" components, might not be able to be changed by any UPN using CAP (never when the CUA gets a "DECREED:TRUE" VCAR).
CS MAYはCS管理者によって構成されるかもしれない永続的な不変のVCARsを実装して、許容するのを選びます。 CSからの回答はダイナミックに実装によって、命じられる"VCAR"コンポーネントを作成するかもしれません。 CUAには、「本当に」設定された「命じられた」特性があるどんな"VCAR"コンポーネントも、現在認証されたUPNが変えることができないで、実装と他の"VCAR"コンポーネントによって、どんなUPNも、上限を使用することで変えることができないかもしれません(決していつでないことのクーアは「命じられました: 本当である」というVCARを手に入れるか)。
When a user attempts to modify or override a decreed "VCAR" component rules, an error will be returned indicating that the user has insufficient authorization to perform the operation. The reply to the CUA MUST be the same as if a non-decreed VCAR caused the failure.
ユーザが、命じられた"VCAR"コンポーネント規則を変更するか、またはくつがえすのを試みると、操作を実行するためにユーザには不十分な承認があるのを示しながら、誤りは返されるでしょう。 まるで非命じられたVCARが失敗を引き起こすかのようにクーアに関する回答は同じであるに違いありません。
The CAP protocol does not define the semantics used to initially create a decreed VCAR. This administrative task is outside the scope of the CAP protocol.
CAPプロトコルは初めは命じられたVCARを作成するのに使用される意味論を定義しません。 CAPプロトコルの範囲の外にこの管理業務はあります。
For example, an implementation or a CS administrator may wish to define a VCAR that will always allow the calendar owners to have full access to their own calendars.
例えば、実装かCS管理者がカレンダー所有者をそれら自身のカレンダーに完全にいつも近づく手段を持たせるVCARを定義したがっているかもしれません。
Decreed "VCAR" components MUST be readable by the calendar owner in standard "VCAR" component format.
命じられた"VCAR"コンポーネントはカレンダー所有者で標準の"VCAR"コンポーネント形式に読み込み可能であるに違いありません。
4.3. CAP Session Identity
4.3. 上限セッションのアイデンティティ
A [BEEP] session has an associated set of authentication credentials, from which is derived a UPN. This UPN is the identity of the CAP session, and is used to determine access rights for the session.
[BEEP]セッションには、関連セットの認証資格証明書があります。(資格証明書から、UPNは引き出されます)。 このUPNは、CAPセッションのアイデンティティであり、セッションのためにアクセス権を決定するのに使用されます。
The CUA may change the identity of a CAP session by calling the "IDENTIFY" command. The CS only permits the operation if the session's authentication credentials are good for the requested identity. The method of checking this permission is implementation- dependent, but it may be thought of as a mapping from authentication credentials to UPNs. The "IDENTIFY" command allows a single set of
CUAは、「特定」コマンドを呼ぶことによって、CAPセッションのアイデンティティを変えるかもしれません。 要求されたアイデンティティに、セッションの認証資格証明書が良い場合にだけ、CSは操作を可能にします。 この許可をチェックするメソッドは実装に依存していますが、それはマッピングとして認証資格証明書からUPNsまで考えられるかもしれません。 「特定」コマンドはセットされたシングルを許容します。
Royer, et al. Experimental [Page 28] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [28ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
authentication credentials to choose from multiple identities, and allows multiple sets of authentication credentials to assume the same identity.
認証資格証明書、複数のアイデンティティから選んで、複数のセットの認証資格証明書が同じアイデンティティを仮定するのを許容します。
For anonymous access, the identity of the session is "@". A UPN with a null Username and null Realm is anonymous. A UPN with a null Username but non-null Realm (e.g.,"@example.com") may be used to mean any identity from that Realm. This is useful to grant access rights to all users in a given Realm. A UPN with a non-null Username and null Realm (e.g., "bob@") could be a security risk and MUST NOT be used.
匿名のアクセスのために、セッションのアイデンティティは"@"です。 ヌルUsernameとヌルRealmとUPNは匿名です。 「ヌルUsernameにもかかわらず、非ヌルのRealmとUPN、(」 @example例えば、.com、」、)、そのRealmからどんなアイデンティティも意味するのに使用されるかもしれません。 これは、与えられたRealmのすべてのユーザにアクセス権を与えるために役に立ちます。 非ヌルのUsernameとヌルRealm(例えば、「ボブの@」)とUPNはセキュリティリスクであるかもしれなく、使用されてはいけません。
Because the UPN includes Realm information, it may be used to govern calendar store access rights across Realms. However, governing access rights across Realms is only useful if login access is available. This could be done through a trusted server relationship or a temporary account. Note that trusted server relationships are outside the scope of CAP.
UPNがRealm情報を含んでいるので、それはRealmsの向こう側にカレンダー店アクセス権を治めるのに使用されるかもしれません。ログインアクセスが利用可能である場合にだけ、しかしながら、Realmsの向こう側にアクセス権を治めるのは役に立ちます。 信じられたサーバ関係か仮勘定を通してこれができました。 それが、CAPの範囲の外にサーバ関係があると信じたことに注意してください。
The "IDENTIFY" command also provides for a weak group implementation. By allowing multiple sets of authentication credentials belonging to different users to identify as the same UPN, that UPN essentially identifies a group of people, and may be used for group calendar ownership, or the granting of access rights to a group.
また、「特定」コマンドは弱いグループ実装に備えます。 異なったユーザのものである複数のセットの認証資格証明書が、同じくらいがUPNであると認識するのを許容することによって、そのUPNは本質的には人々のグループを特定して、グループカレンダー所有権、またはアクセス権の認可にグループに使用されるかもしれません。
5. CAP URL and Calendar Address
5. 上限URLとカレンダーアドレス
The CAP URL scheme is used to designate both calendar stores and calendars accessible using the CAP protocol.
CAP URL体系は、CAPプロトコルを使用することでカレンダー店とカレンダーにアクセスしやすい状態で両方を指定するのに使用されます。
The CAP URL scheme conforms to the generic URL syntax defined in RFC 2396 and follows the Guidelines for URL Schemes set forth in RFC 2718.
CAP URL体系は、RFC2396で定義されたジェネリックURL構文に従って、RFC2718に詳しく説明されたURL SchemesのためにGuidelinesに続きます。
A CAP URL begins with the protocol prefix "cap" and is defined by the following grammar.
CAP URLはプロトコル接頭語「上限」で始まって、以下の文法によって定義されます。
capurl = "cap://" csidpart [ "/" relcalid ]
;
csidpart = hostport ; As defined in Section 3.2.2 of RFC 2396
;
relcalid = *uric ; As defined in Section 2 of RFC 2396
capurlは「上限://」csidpart[「/」relcalid]と等しいです。 csidpartはhostportと等しいです。 .2セクション3.2RFC2396で定義されるように。 relcalid=*尿。 RFC2396のセクション2では、定義されます。
A 'relcalid' is an identifier that uniquely identifies a calendar on a particular calendar store. There is no implied structure in a Relative CALID (relcalid). It may refer to the calendar of a user or of a resource such as a conference room. It MUST be unique within the calendar store.
'relcalid'は特定のカレンダー店の上で唯一カレンダーを特定する識別子です。 どんな暗示している構造もRelative CALID(relcalid)にありません。 それはユーザか会議室などのリソースのカレンダーを示すかもしれません。 それはカレンダー店の中でユニークであるに違いありません。
Royer, et al. Experimental [Page 29] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [29ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Here are some examples:
ここに、いくつかの例があります:
cap://cal.example.com
cap://cal.example.com/Company/Holidays
cap://cal.example.com/abcd1234Usr
上限://cal.example.com上限://cal.example.com/会社/愛の休日上限://cal.example.com/abcd1234Usr
A 'relcalid' is permitted and is resolved according to the rules defined in Section 5 of RFC 2396.
'relcalid'は、受入れられて、RFC2396のセクション5で定義された規則に従って、決議されています。
Examples of valid relative CAP URLs:
有効な相対的なCAP URLに関する例:
opqaueXzz123String
UserName/Personal
opqaueXzz123Stringユーザ名/個人的です。
Calendar addresses can be described as qualified or relative CAP URLs.
適切であるか相対的なCAP URLとしてカレンダーアドレスを記述できます。
For a user currently authenticated to the CS on cal.example.com, these two example calendar addresses refer to the same calendar:
現在cal.example.comの上のCSに認証されているユーザについてこれらの2つの例のカレンダーアドレスが同じカレンダーを示します:
cap://cal.example.com/abcd1234USR
abcd1234USR
上限://cal.example.com/abcd1234USR abcd1234USR
6. New Value Types
6. 新しい値のタイプ
The following sections contains new components, properties, parameters, and value definitions.
以下のセクションは新しいコンポーネント、特性、パラメタ、および値の定義を含みます。
The purpose of these is to extend the iCalendar objects in a compatible way so that existing iCalendar "VERSION" property "2.0" value parsers can still parse the objects without modification.
これらの目的がコンパチブル道そのように、その既存のiCalendar「バージョン」でiCalendarオブジェクトを広げることである、特性、「2インチの値のパーサは変更なしでオブジェクトをまだ分析できます」。
6.1. Property Value Data Types
6.1. 資産価値データ型
6.1.1. CAL-QUERY Value Type
6.1.1. カル-質問値のタイプ
Subject: Registration of text/calendar MIME value type CAL-QUERY
Subject: テキスト/カレンダーMIME値のタイプカル-QUERYの登録
Value Name: CAL-QUERY
名前を評価してください: カル-質問
Value Type Purpose: This value type is used to identify values and
contains query statements targeted at locating those values. This
is based on [SQL92] and [SQLCOM].
タイプ目的を評価してください: この値のタイプは、値を特定するのに使用されて、それらの値の場所を見つけるのに狙う質問声明を含んでいます。 これは[SQL92]と[SQLCOM]に基づいています。
1. For the purpose of a query, all components should be handled
as tables, and the properties of those components should be
handled as columns.
1. 質問の目的のために、すべてのコンポーネントがテーブルとして扱われるべきです、そして、それらのコンポーネントの特性はコラムとして扱われるべきです。
Royer, et al. Experimental [Page 30] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [30ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
2. All VAGENDAs and CSs look like tables for the purpose of a
QUERY, and all of their properties look like columns in those
tables.
2. すべてのVAGENDAsとCSsはQUERYの目的のためのテーブルに似ています、そして、彼らの特性のすべてがそれらのテーブルのコラムに似ています。
3. You MUST NOT do any cross-component-type joins. That means
you can ONLY have one component OR one "VAGENDA" component OR
one "VCALSTORE" component in the "FROM" clause.
3. あなたは少しの十字コンポーネント型もしてはいけません。加わります。 それは、あなたが“FROM"節の1つのコンポーネントOR1"VAGENDA"コンポーネントか1つの"VCALSTORE"コンポーネントしか持つことができないことを意味します。
4. Everything in the "SELECT" clause and "WHERE" clauses MUST be
from the same component type or "VAGENDA" component OR
"VCALSTORE" component in the "FROM" clause.
4. “FROM"節の「選んだ」節と節が「どこ」で同じコンポーネント型から来ているに違いないか、そして、"VAGENDA"コンポーネントか"VCALSTORE"コンポーネントにおけるすべて。
5. When multiple "QUERY" properties are supplied in a single
"VQUERY" component, the results returned are the same as the
results returned for multiple "VQUERY" components that each
have a single "QUERY" property.
5. ただ一つの"VQUERY"コンポーネントで複数の「質問」資産を供給するとき、返された結果は結果がそれぞれただ一つの「質問」の特性を持っている複数の"VQUERY"コンポーネントのために戻ったのと同じです。
6. The '.' is used to separate the table name (component) and
column name (property or component) when selecting a property
that is contained inside a component that is targeted in the
TARGET property.
6. '、'.'TARGET所有地で狙うコンポーネントに含まれている特性を選択するとき、テーブル名(コンポーネント)とコラム名(特性かコンポーネント)を切り離すために、使用されます。
7. A contained component without a '.' is not the same as
"component-name.*". If given as "component-name" (no dot),
the encapsulating BEGIN/END statement will be supplied for
"component-name".
7. 'a'のない含まれたコンポーネント'は「コンポーネント名*」と同じではありません。 「コンポーネント名」(ドットがない)として考えて、「コンポーネント名」に要約のBEGIN/END声明を供給するでしょう。
In the following example, '.' is used to separate the "TRIGGER" property from its contained component (VALARM), which is contained in any "VEVENT" component in the selected "TARGET" property value (a relcalid). All "TRIGGER" properties in any "VEVENT" component in relcalid would be returned.
'以下の例'. '含まれたコンポーネント(VALARM)と「引き金」の特性を切り離すために、使用されます。(コンポーネントはどんな"VEVENT"コンポーネントにも選択された「目標」資産価値(relcalid)に含まれています)。 relcalidのどんな"VEVENT"コンポーネントのすべての「引き金」資産も返すでしょう。
TARGET:relcalid
QUERY:SELECT VALARM.TRIGGER FROM VEVENT
SELECT VALARM FROM VEVENT WHERE UID = "123"
目標: relcalid質問: VEVENTの選んだVALARMからUIDが「123」と等しいVEVENTからVALARM.TRIGGERを選択してください。
This returns one BEGIN/END "VALARM" component for each "VALARM" component in the matching "VEVENT" component. As there is no '.' (dot) in the VALARM after the SELECT above, it returns:
これは合っている"VEVENT"コンポーネントのそれぞれの"VALARM"コンポーネントあたり1つのBEGIN/END"VALARM"の部品を返します。 'いいえがあるので'。. '(点を打ちます) SELECTの後のVALARMでは、上に、戻ります:
Royer, et al. Experimental [Page 31] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [31ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
BEGIN:VALARM
TRIGGER;RELATED=END:PT5M
REPEAT:4
...
END:VALARM
BEGIN:VALARM
TRIGGER;RELATED=START:PT5M
DURATION:PT10M
...
END:VALARM
...
...
始まってください: VALARM引き金、終わり: 関連する=PT5Mは繰り返します: 4 終わり: VALARMは始まります: VALARM引き金; 関係するのは始め: PT5M持続時間と等しいです: PT10M 終わってください: VALARM ...
If the SELECT parameter is provided as "component-name.*", then only the properties and any contained components will be returned. The example:
「コンポーネント名*」としてSELECTパラメタを提供すると、資産とどんな含まれたコンポーネントだけも返すでしょう。 例:
SELECT VALARM.* FROM VEVENT WHERE UID = "123"
選んだVALARM UIDが「123」と等しいVEVENTからの*
will return all of the properties in each "VALARM" component in the matching "VEVENT" component:
合っている"VEVENT"コンポーネントのそれぞれの"VALARM"コンポーネントで特性のすべてを返すでしょう:
TRIGGER;RELATED=END:PT5M
REPEAT:4
...
TRIGGER;RELATED=START:PT5M
DURATION:PT10M
...
...
引き金; 終わり: 関連する=PT5Mは繰り返します: 4 引き金; =始め: PT5M持続時間: PT10Mは関係づけました… ...
In the following SELECT clauses:
以下のSELECT節で:
(a) SELECT <a-property-name> FROM VEVENT
(a) VEVENTから<のa-特性名義の>を選択してください。
(b) SELECT VALARM FROM VEVENT
(b) VEVENTからVALARMを選択してください。
(c) SELECT VALARM.* FROM VEVENT
(c) VALARM VEVENTからの*を選択してください。
(d) SELECT * FROM VEVENT
(d) VEVENTからの*を選択してください。
(e) SELECT * FROM VEVENT WHERE
VALARM.TRIGGER < '20020201T000000Z'
AND VALARM.TRIGGER > '20020101T000000Z'
(e) VEVENTどこVALARM.TRIGGER<'20020201T000000Z'AND VALARM.TRIGGER>'20020101T000000Z'からの*を選択してくださいか。
Clause (a) elects all instances of <a-property-name> from all "VEVENT" components.
節(a)は<のすべての例をすべての"VEVENT"コンポーネントからa-特性の名義の>に選出します。
Royer, et al. Experimental [Page 32] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [32ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Clauses (b) and (c) select all "VALARM" components from all "VEVENT" components. (b) would return them in BEGIN/END VALARM tags. (c) would return all of the properties without BEGIN/END VALARM tags.
節(b)と(c)はすべての"VEVENT"コンポーネントからすべての"VALARM"コンポーネントを選択します。 (b) BEGIN/END VALARMタグでそれらを返すでしょう。 (c) BEGIN/END VALARMタグなしで特性のすべてを返すでしょう。
Clause (d) selects every property and every component that is in any "VEVENT" component, with each "VEVENT" component wrapped in a BEGIN/END VEVENT tags.
すなわち、あらゆる"VEVENT"コンポーネントに、VEVENTタグを節(d)はあらゆる特性とあらゆるコンポーネントを選択して、始まるか、またはそれぞれの"VEVENT"コンポーネントがaで包装されている状態で、終わらせてください。
Clause (e) selects all properties and all contained components in all "VEVENT" components that have a "VALARM" component with a "TRIGGER" property value between the provided dates and times, with each "VEVENT" component wrapped in BEGIN/END VEVENT tags.
VEVENTタグを節(e)は提供された期日と回の間には、「引き金」資産価値がある状態で"VALARM"コンポーネントを持っているすべての"VEVENT"コンポーネントのすべての特性とすべての含まれたコンポーネントを選択して、始まるか、または中のそれぞれの"VEVENT"コンポーネントが包装されていた状態で、終わらせてください。
Here are two invalid SELECT clauses:
ここに、2つの無効のSELECT節があります:
(f) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT
(f) VEVENTからVEVENT.VALARM.TRIGGERを選択してください。
(g) SELECT DTSTART,UID FROM VEVENT
WHERE VTODO.SUMMERY = "Fix typo in CAP"
(g) SELECT DTSTART、UID FROM VEVENT WHERE VTODO.SUMMERY=は「CAPの誤植を修理します」。
Clause (f) is invalid because it contains two '.' characters.
2を含んでいるので、'節(f)は無効です。'.'キャラクタ。
Clause (g) Is invalid because it mixes VEVENT and VTODO properties in the same VQUERY.
同じVQUERYのVEVENTとVTODOの特性を混ぜるので、節(g)は無効です。
Formal Definition: The value type is defined by the following notation:
公式の定義: 値のタイプは以下の記法で定義されます:
cal-query = "SELECT" SP cap-val SP
"FROM" SP comp-name SP
"WHERE" SP cap-expr
ヴァルに帽子をかぶらせている「選んだ」cal質問=SP “FROM" SPコンピュータ名SP「どこ」SP SPキャップ-expr
/ "SELECT" SP cap-cols SP
"FROM" SP comp-name
;
cap-val = cap-cols / param
/ ( cap-val "," cap-val )
/「選んだ」SPキャップあん部SP “FROM" SPコンピュータ名。 キャップ-valはキャップ-cols / param /と等しいです。「(キャップ-val、」、」 キャップ-val、)
; NOTE: there is NO space around the "," on
; the next line
cap-cols = cap-col / ( cap-cols "," cap-col)
/ "*"
/ "*.*" ; only valid when the target is a "VAGENDA"
;
; A 'cap-col' is:
;
; Any property name ('cap-prop') found in the
; component named in the 'comp-name' used in the
; 以下に注意してください。 「スペースが全く周囲にない、」、」 オン。 「次の線キャップあん部がキャップあん部/と等しい、(キャップあん部、」、」 キャップあん部) /「*」/、」 **、」、。 有効だけ目標が"VAGENDA"であるなら。 ; 'キャップあん部'は以下の通りです。 ; ; 中で見つけられたどんな特性の名('キャップ支柱')、も。 コンポーネントは中で中で使用された'コンピュータ名'を命名しました。
Royer, et al. Experimental [Page 33] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [33ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
; "FROM" clause.
;
; SELECT ORGANIZER FROM VEVENT ...
;
; OR
;
; A component name ('comp-name') of an existing
; component contained inside of the 'comp-name'
; used in the "FROM" clause.
;
; SELECT VALARM FROM VEVENT ...
;
; OR
;
; A component name ('comp-name') of an existing
; component contained inside of the 'comp-name' used
; in the "FROM" clause followed by a property
; name ('cap-prop') to be selected from that
; component.
; (comp-name "." cap-prop)
; "FROM"節。 ; ; VEVENTからオーガナイザーを選んでください… ; ; OR。 ; 存在のコンポーネント名('コンピュータ名')。 'コンピュータ名'のコンポーネントの含まれた内部。 “FROM"節では、使用されています。 ; ; VEVENTからVALARMを選択してください… ; ; OR。 ; 存在のコンポーネント名('コンピュータ名')。 使用される'コンピュータ名'のコンポーネントの含まれた内部。 “FROM"では、節は特性で従いました。 ('キャップ支柱')を命名して、それから選択されてください。 コンポーネント。 ; 「(」 . 」 キャップ支柱をコンピュータで命名します)
; SELECT VALARM.TRIGGER FROM VEVENT ...
; VEVENTからVALARM.TRIGGERを選択してください…
cap-col = comp-name
/ comp-name "." cap-prop
/ cap-prop
「コンピュータキャップあん部=コンピュータ名/名」 」 キャップキャップ支柱/支柱
comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY"
/ "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA"
/ "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE"
/ "VRIGHT" / x-comp / iana-comp
iana xコンピュータ名="VEVENT"/"VTODO"/"VJOURNAL"/"VFREEBUSY"/"VALARM"/「日光」/「規格」/"VAGENDA"/"VCAR"/"VCALSTORE"/"VQUERY"/"VTIMEZONE"/"VRIGHT"/コンピュータ/コンピュータ
cap-prop = ; A property that may be in the 'cap-comp' named
; in the "SELECT" clause.
キャップ支柱=。 指定された'キャップコンピュータ'にあるかもしれない特性。 「選んだ」節で。
cap-expr = "(" cap-expr ")"
/ cap-term
用語に「(「キャップ-expr」)」というキャップ-expr=/ふたをしています。
cap-term = cap-expr SP cap-logical SP cap-expr
/ cap-factor
キャップ用語=キャップキャップ-expr SPのキャップ論理的なSPキャップ-expr/要素
cap-logical= "AND" / "OR"
キャップ論理的な=“AND"/「OR」
cap-factor = cap-colval SP cap-oper SP col-value
/ cap-colval SP "LIKE" SP col-value
/ cap-colval SP "NOT LIKE" SP col-value
/ cap-colval SP "IS NULL"
/ cap-colval SP "IS NOT NULL"
= キャップキャップ-colval SPが「好きでない」というSPあん部キャップ-colval SP “LIKE" SPあん部キャップ-colval SPキャップ-oper SPあん部価値/価値/価値/colval SPが「ヌルである」というキャップ要素/キャップ-colval SPは「ヌルではありません」。
Royer, et al. Experimental [Page 34] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [34ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
/ col-value SP "IN" cap-colval
/ col-value SP "NOT IN" cap-colval
/ "STATE()" "=" ( "BOOKED"
/ "UNPROCESSED"
/ "DELETED"
/ iana-state
/ x-state )
;
iana-state = ; Any state registered by IANA directly or
; included in an RFC that may be applied to
; the component and within the rules published.
;
x-state = ; Any experimental state that starts with
; "x-" or "X-".
/あん部あん部価値のSP「IN」キャップ-colval/価値のSP「NOT IN」キャップ-colval/「状態()」は(x「予約される」か「未加工」の、または、「削除された」/iana-状態/状態)と「等しいです」。 iana-州の=。 または、どんな状態もIANAによって直接示された、。 適用されるかもしれないRFCでは、含まれています。 コンポーネントと発表された規則の中で。 ; x-州の=。 それが始まるどんな実験状態も。 「x」 または、「X。」
cap-colval = cap-col / param
;
param = "PARAM(" cap-col "," cap-param ")"
;
cap-param = ; Any parameter that may be contained in the cap-col
; in the supplied PARAM() function
キャップ-colvalはキャップあん部/paramと等しいです。 「paramが等しい、「PARAM、(」 「キャップあん部」、キャップ-param、」、)、」、。 キャップ-param=。 キャップあん部に保管されているどんなパラメタも。 供給されたPARAM()機能で
col-value = col-literal
/ "SELF()"
/ "CAL-OWNERS()"
/ "CAL-OWNERS(" cal-address ")"
/ "CURRENT-TARGET()"
;
cal-address = ; A CALID as define by CAP
;
col-literal = "'" literal-data "'"
;
literal-data = ; Any data that matches the value type of the
; column that is being compared. That is, you
; cannot compare PRIORITY to "some string" because
; PRIORITY has a value type of integer. If it is
; not preceded by the LIKE element, any '%' and '_'
; characters in the literal data are not treated as
; wildcard characters and do not have to be
; backslash-escaped.
;
; OR
;
; If the literal-data is preceded by the LIKE
; element it may also contain the '%' and '_'
; wildcard characters. And, if the literal data
; that is comparing contains any '%' or '_'
; characters, they MUST be backslash-escaped as
あん部値はあん部文字通りの/「自己()」/「カル所有者()」/「カル所有者(「カル-アドレス」)」/「現在の目標()」と等しいです。 calアドレス=。 CALID、CAPを定義するので。 あん部文字通りの=、「'、「「'「;」'という文字通りのデータ 文字通りのデータ=。 それが値のタイプに合っているどんなデータ、も。 比較されているコラム。 すなわち、あなた。 「何らかのストリング」とPRIORITYを比較できない、。 PRIORITYには、整数の値のタイプがあります。 それがそうなら。 LIKE要素、どんな'%'、および'_'によっても先行されていません。 文字通りのデータのキャラクタとして、扱われません。 そして、ワイルドカードキャラクタ、である必要はない。 バックスラッシュで、逃げられます。 ; ; OR。 ; 文字通りのデータがLIKEによって先行されているなら。 またそれがそうするかもしれない要素は''%'_'を含んでいます。 ワイルドカードキャラクタ。 そして、文字通りのデータであるなら。 すなわち、比較はどんな'%'や'_'も含んでいます。 キャラクタ、彼らはバックスラッシュで逃げなければなりません。
Royer, et al. Experimental [Page 35] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [35ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
; described in the notes below, in order for them
; not to be treated as wildcard characters.
;
; And, if the literal data contains any characters
; that would have to be backslash-escaped if
; a property or parameter value, then they must
; be backslash-escaped in the literal-data.
; Also, the quote character (') must be backslash
; escaped. Example:
;
; ... WHERE SUBJECT = 'It\'s time to ski'
;
cap-oper = "="
/ "!="
/ "<"
/ ">"
/ "<="
/ ">="
;
SP = ; A single white space ASCII character
; (value in HEX %x20).
;
x-comp = ; As defined in [iCAL] section 4.6.
;
iana-comp = ; As defined in [iCAL] section 4.6.
; 以下での注意、それらの注文では、説明されます。 ワイルドカードキャラクタとして扱われないように。 ; ; そして、文字通りであるなら、データはどんなキャラクタも含んでいます。 それがバックスラッシュによって逃げられなければならないだろう、。 特性かパラメタ値、それらがそうしなければならないその時。 バックスラッシュで、文字通りのデータで逃げられてください。 ; 引用文字、も('、)、バックスラッシュでなければならない、'、。 逃げられる。 例: ; ; ... WHERE SUBJECTが'それと等しい、スキーをする\の時間、'、。 「キャップ-oper=「=!」/」 」 =/"<"/">"/「<=」/「>=」。 SP=。 単独の余白ASCIIキャラクタ。 (十六進法%x20の値。) ; x-コンピュータ=。 [iCAL]セクション4.6で定義されるように。 ; iana-コンピュータ=。 [iCAL]セクション4.6で定義されるように。
6.1.1.1. [NOT] CAL-OWNERS()
6.1.1.1. [NOT]カル-所有者()
This function returns the list of "OWNER" properties for the named calendar when used in the "SELECT" clause.
「選んだ」節で使用されると、この機能は命名されたカレンダーのために「所有者」の特性のリストを返します。
If called as 'CAL-OWNERS()', it is equivalent to the comma-separated list of all of the owners of the calendar that match the provided "TARGET" property value. If the target is a "VCALSTORE", it returns the "CALMASTER" property.
'カル-OWNERS()'として呼ばれるなら、提供された「目標」資産価値に合っているカレンダーの所有者のすべてのコンマで切り離されたリストに同等です。 目標が"VCALSTORE"であるなら、それは"CALMASTER"資産を返します。
If called as 'CAL-OWNERS(cal-address)', then it is the equivalent to the comma-separated list of owners for the named calendar id. If 'cal-address' is a CS, it returns the "CALMASTER" property.
'カル-OWNERS(calアドレス)'として呼ばれるなら、それは命名されたカレンダーイドのための所有者のコンマで切り離されたリストと同等物です。 'calアドレス'がCSであるなら、それは"CALMASTER"資産を返します。
If used in the "WHERE" clause, it returns true if the currently authenticated UPN is an owner of the currently selected object matched in the provided "TARGET" property. Used in a CAL-QUERY "WHERE" clause and in the UPN-FILTER.
「どこ」節で使用されるかなら、それは現在認証されたUPNが提供された「目標」所有地で合わせられた現在選択された物の所有者であるなら本当に戻ります。 カル-QUERY「どこ」節とUPN-フィルタで、使用されているか。
Royer, et al. Experimental [Page 36] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [36ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
6.1.1.2. CURRENT-TARGET()
6.1.1.2. 現在の目標()
This is equivalent to the value of the "TARGET" property in the current command. It is used in a CAL-QUERY "WHERE" clause.
これは現在のコマンドにおける、「目標」属性の価値に同等です。 それはカル-QUERY「どこ」節で使用されるか。
6.1.1.3. PARAM()
6.1.1.3. PARAM()
This is used in a CAL-QUERY. It returns or tests for the value of the named parameter from the named property.
これはカル-QUERYで使用されます。 それは、命名された特性からの命名されたパラメタの値がないかどうか戻るか、またはテストされます。
6.1.1.3.1. PARAM() in SELECT
6.1.1.3.1. PARAM()は中で選択します。
When used in a "SELECT" clause, it returns the entire property and all of that property's parameters; the result is not limited to the supplied parameter. If the property does not contain the named parameter, then the property is not returned. However, it could be returned as a result of another "SELECT" clause value. If multiple properties of the supplied name have the named parameter, all properties with that named parameter are returned. If multiple PARAM() clauses in a single "SELECT" CLAUSE match the same property, then the single matching property is returned only once.
「選んだ」節で使用されると、その特性のパラメタの全体の資産とすべてを返します。 結果は供給されたパラメタに制限されません。 特性が命名されたパラメタを含んでいないなら、資産は返されません。 しかしながら、別の「選んだ」節値の結果、それを返すことができました。 命名されたパラメタが供給された名前の複数の特性にあるなら、それがパラメタと命名されているすべての資産を返します。 1つの「選んだ」節の複数のPARAM()節が同じ特性に合っているなら、一度だけただ一つの合っている資産を返します。
Also, note that many parameters have default values defined in [iCAL] that must be treated as existing with their default value in the properties, as defined in [iCAL], even when not explicitly present. For example, if a query were performed with PARAM(ATTENDEE,ROLE) then ALL "ATTENDEE" properties would match because, even when they do not explicitly contain the "ROLE" parameter, it has a default value and therefore must match.
また、多くのパラメタにはそれらのデフォルト値が所有地にある状態で存在するとして扱わなければならない[iCAL]で定義されたデフォルト値があることに注意してください、[iCAL]で定義されるように、明らかに存在してさえいないとき。 例えば、質問がPARAM(ATTENDEE、ROLE)と共に実行されたなら、すべての「出席者」の特性が、明らかに「役割」パラメタを含んでいないと、それにはデフォルト値があるので合っていて、したがって、合わなければなりません。
Therefore, when PARAM() is used in a "SELECT" clause, it is more accurate to say that it means return the property, if it contains the named parameter explicitly in the property or simply because the parameter has a default for that property.
したがって、PARAM()が「選んだ」節で使用されるとき、資産を返すことを意味すると言うのは、より正確です、所有地に明らかに命名されたパラメタを含んでいるか、または単にパラメタにはデフォルトがその特性のためにあるので。
6.1.1.3.2. PARAM() in WHERE
6.1.1.3.2. PARAM()、どこ
When PARAM() is used in the "WHERE" clause, a match is true when the parameter value matches the compare clause (according to the supplied WHERE values). If multiple named properties contain the named parameter, then each parameter value is compared in turn to the condition; if any match, the results would be true for that condition the same as if only one had existed. Each matching property or component is returned only once.
PARAM()が「どこ」節で使用されるかとき、パラメタ値が合っているとき、マッチが本当である、節を比較してください、(値をどこに供給するか、) 複数の命名された特性が命名されたパラメタを含んでいるなら、それぞれのパラメタ値は順番に状態にたとえられます。 どんなマッチであるならも、まるで1つだけが存在したかのようにその状態には、結果は同じように本当でしょう。 一度だけ各合っている資産かコンポーネントを返します。
Because a parameter may be multi-valued, the comparison might need to be done with an "IN" or "NOT IN" comparator.
パラメタがマルチ評価されているかもしれないので、比較が、「IN」と共にする必要があるかもしれないか、「中でない」という比較器です。
Royer, et al. Experimental [Page 37] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [37ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Given the following query:
以下を考えて、以下について質問してください。
ATTENDEE;PARTSTAT=ACCEPTED:cap://host.com/joe
出席者; PARTSTAT=は受け入れました: ://host.com/joeにふたをしてください。
SELECT VEVENT FROM VAGENDA
WHERE PARAM(ATTENDEE,PARTSTAT) = 'ACCEPTED'
PARAM(出席者、PARTSTAT)=が'受け入れた'VAGENDAからVEVENTを選択してください。
Thus, all "VEVENT" components that contain one or more "ATTENDEE" properties that have a "PARTSTAT" parameter with a "ACCEPTED" value would be returned. Also, each uniquely matching VEVENT would be returned only once, no matter how many "ATTENDEE" properties had matching roles, in each unique "VEVENT" component.
したがって、「受け入れられた」値がある"PARTSTAT"パラメタを持っている1つ以上の「出席者」の特性を含むすべての"VEVENT"コンポーネントを返すでしょう。 また、一度だけそれぞれの唯一合っているVEVENTを返すでしょう、合っている役割がいくつの「出席者」の特性にあったかとしても、それぞれのユニークな"VEVENT"コンポーネントで。
Also note that many parameters have default values defined in [iCAL]. Therefore, if the following query were performed on the "ATTENDEE" property in the above example:
また、多くのパラメタには[iCAL]で定義されたデフォルト値があることに注意してください。 以下の質問が上記の例でしたがって、「出席者」所有地に実行されたなら:
SELECT VEVENT FROM VAGENDA
WHERE PARAM(ATTENDEE,ROLE) = 'REQ-PARTICIPANT'
PARAM(出席者、役割)が'REQ-関係者'と等しいVAGENDAからVEVENTを選択してください。
It would return the "ATTENDEE" property shown above because the default value for the "ROLE" parameter is "REQ-PARTICIPANT".
それは「役割」パラメタのためのデフォルト値が「REQ関与している」ので上に示された「出席者」資産を返すでしょう。
6.1.1.4. SELF()
6.1.1.4. 自己()
Used in a CAL-QUERY "WHERE" clause. Returns the UPN of the currently authenticated UPN or their current UPN as a result of an IDENTIFY command.
カル-QUERY「どこ」節で、使用されているか。 IDENTIFYコマンドの結果、現在認証されたUPNかそれらの現在のUPNのUPNを返します。
6.1.1.5. STATE()
6.1.1.5. 状態()
Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" depending on the state of the object. "DELETED" is a component in the marked-for-delete state. Components that have been removed from the store are never returned.
「予約され」て、「未加工」の3つの値の復帰1、または物の状態に依存する「削除されました」。 "DELETED"が中のコンポーネントである、マークされる、削除、状態。 店から取り外されたコンポーネントを決して返しません。
If not specified in a query then both "BOOKED" and "UNPROCESSED" data is returned. Each unique "METHOD" property must be in a separate MIME object, per the [iCAL] section 3.2 restriction.
質問で指定しないなら、ともに「予約され」て「未加工」のデータを返します。 それぞれのユニークな「方法」の特性が[iCAL]セクション3.2制限あたり1個の別々のMIME物にあるに違いありません。
6.1.1.6. Use of Single Quote
6.1.1.6. ただ一つの引用文の使用
All literal values are surrounded by single quotes ('), not double
quotes ("), and not without any quotes. If the value contains quotes
or any other ESCAPED-CHAR, they MUST be backslash-escaped as
described in section 4.3.11 "Text" of [iCAL]. Any "LIKE" clause
wildcard characters that are part of any literal data that is
preceded by a "LIKE" clause or "NOT LIKE" clause and is not intended
すべての文字通りの値がシングル・クォーテション・マークによって囲まれる、('、)、引用文を倍にしない、(「)、どんな引用文、も」、' 値が引用文か他のESCAPED-CHARを含んでいるなら、それらは[iCAL]のバックスラッシュでセクション4.3で説明されるとして逃げられた.11「テキスト」であるに違いありません。 “LIKE"節が先行するか、節が「好きでなく」、またまたは意図しない少しの文字通りのデータの一部であるどんな“LIKE"節ワイルドカードキャラクタ
Royer, et al. Experimental [Page 38] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [38ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
to mean wildcard search MUST be escaped as described in note (7) below.
以下で注意(7)で説明されるようにワイルドカード検索から逃げなければならないことを意味するために。
6.1.1.7. Comparing DATE and DATE-TIME Values
6.1.1.7. 日付と日付時間的価値を比較します。
When comparing "DATE-TIME" values to "DATE" values and when comparing "DATE" values to "DATE-TIME" values, the result will be true if the "DATE" value is on the same day as the "DATE-TIME" value. They are compared in UTC no matter what time zone the data may have been stored in.
値の「日付を入れる」ために「日付-時間」値を比較するとき、「日付-時間」値に「日付」値をたとえるとき、「日付-時間」値として「日付」値がその日のうちにあるなら、結果は本当になるでしょう。 データが何時に格納されたとしても、それらはUTCで比較されます。
Local time event, as described in section 4.2.19 of [iCAL], must be considered to be in the CUA default timezone that was supplied by the CUA in the "CAPABILITY" exchange.
「能力」交換でCUAによって供給されたCUAデフォルトタイムゾーンにはあると.19セクション4.2[iCAL]で説明される出来事を考えなければならない現地時間。
VALUE-1 VALUE-2 Compare Results
値-1値-2は結果を比較します。
20020304 20020304T123456 TRUE
(in UTC-3) (in UTC-3)
20020304 20020304T123456、本当(UTC-3の)(UTC-3の)
20020304 20020304T003456 FALSE
(in UTC) (in UTC-4)
20020304 20020304T003456偽(UTCの)(UTC-4の)
20020304T003456Z 20020205T003456 FALSE
(in UTC-0) (in UTC-7)
20020304T003456Z 20020205T003456偽(UTC-0の)(UTC-7の)
When "DATE" values and "DATE-TIME" values are compared with the "LIKE" clause, the comparison will be done as if the value is a [iCAL] DATE or DATE-TIME string value.
「日付」値と「日付-時間」値が“LIKE"節と比べるとき、まるで値が[iCAL]日付か日付-時間ストリング価値であるかのように、比較するでしょう。
LIKE '2002%' will match anything in the year 2002.
LIKE'2002%'は2002年の間、何にでも合うでしょう。
LIKE '200201%' will match anything in January 2002.
LIKE'200201%'は2002年1月に何にでも合うでしょう。
LIKE '%T000000' will match anything at midnight.
'LIKE'%T000000'は真夜中に何にでも合うでしょう。
LIKE '____01__T%' will match anything for any year or
time that is in January.
(Four '_', '01', two '_' 'T%').
'好き'____'01__T%'は1月に、ある年間や何時でも、何にでも合うでしょう。 (4'_'、'01'、2'_''T%'。)
Using a "LIKE" clause value of "%00%", would return any value that contained two consecutive zeros.
「」 %の“LIKE"節価値を00%使用します」は2つの連続したゼロを含んだどんな値も返すでしょう。
All comparisons will be done in UTC.
UTCですべての比較をするでしょう。
Royer, et al. Experimental [Page 39] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [39ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
6.1.1.8. DTEND and DURATION
6.1.1.8. DTENDと持続時間
The "DTEND" property value is not included in the time occupied by the component. That is, a "DTEND" property value of 20030614T12000 includes all of the time up to, but not including, noon on that day.
"DTEND"資産価値はコンポーネントによって占領された時間、含まれていません。 すなわち、20030614T12000の"DTEND"資産価値は、絶えず密かに企てますが、含んでいるのを含んでいません、当日正午。
The "DURATION" property value end time is also not inclusive. So an object with a "DTSTART" property value of 20030514T110000 and a "DURATION" property value of "1H" does not include noon on that day.
また、「持続時間」資産価値終わりの時間も含んでいません。 それで、20030514T110000の"DTSTART"資産価値と"1H"の「持続時間」資産価値がある物は当日、正午を含んでいません。
When a "QUERY" property value contains a "DTEND" value, then the CS MUST also evaluate any existing "DURATION" property value and determine if it has an effective end time that matches the "QUERY" property supplied "DTEND" value or any range of values supplied by the "QUERY" property.
「質問」資産価値が"DTEND"値を含んでいると、Csは、また、どんな既存の「持続時間」資産価値も評価して、それが特性が「質問」の特性によって供給された"DTEND"値か何か範囲の値を供給した「質問」に合っている有効な終わりの時間を過すかどうか決定しなければなりません。
When a "QUERY" property contains a "DURATION" value, then the CS MUST also evaluate any existing "DTEND" property values and determine if they have an effective duration that matches the value, or any range of values, supplied by the "QUERY" property.
「質問」の特性が「持続時間」値を含んでいると、Csは、また、どんな既存の"DTEND"特性の値も評価して、それらで「質問」の特性によって供給された値、または何か範囲の値に合っている有効な持続時間があるかどうか決定しなければなりません。
6.1.1.9. [NOT] LIKE
6.1.1.9. [NOT] 同類
The pattern matching characters are the '%' that matches zero or more characters, and '_' that matches exactly one character (where character does not always mean octet).
'_'パターン・マッチングキャラクタはゼロか以上に合っている'%'キャラクタです、そして、それはまさに1つのキャラクタ(キャラクタがいつも八重奏を意味するというわけではないところ)に合っています。
"LIKE" clause pattern matches always cover the entire string. To match a pattern anywhere within a string, the pattern must start and end with a percent sign.
"LIKE"節パターンマッチはいつも全体のストリングをカバーしています。 ストリングの中にどこでもパターンを合わせるために、パターンはパーセント記号で終始しなければなりません。
To match a '%' or '_' in the data and not have it interpreted as a wildcard character, they MUST be backslash-escaped. Thus, to search for a '%' or '_' in the string:
データで'%'か'_'を合わせて、ワイルドカードキャラクタとしてそれを解釈させないように、それらはバックスラッシュで逃げなければなりません。 このようにしてストリングで'%'か'_'を捜し求めるために:
LIKE '%\%%' Matches any string with a '%' in it.
LIKE '%\_%' Matches any string with a '_' in it.
'LIKE'%、''%'がそれにある状態でいずれも結ぶ\%%Matches。 LIKE '%\_%' Matches any string with a '_' in it.
Strings compared using the "LIKE" clause MUST be performed using case insensitive comparisoison assumes 'a' = 'A').
大文字と小文字を区別しないcomparisoisonが仮定する実行された使用が'a'='A'であったに違いないなら“LIKE"節を使用することで比較されたストリング)
If the "LIKE" clause is preceded by 'NOT' then there is a match when the string compare fails.
ストリングが比較されるとき、“LIKE"節が''ないどんなその時までにも先行されているなら、マッチは失敗します。
Some property values (such as the 'recur' value type), contain commas and are not multi-valued. The CS must understand the objects being compared and understand how to determine how any multi-valued or multi-instances properties or parameter values are separated, quoted,
いくつかの特性の値('再発してください'という値のタイプなどの)は、コンマを含んでいて、マルチ評価されていません。 CSは物が比較されるのを理解していて、何かマルチ評価されたかマルチ例の特性やパラメタ値がどのように切り離されて、引用されているかを決定する方法を理解しなければなりません。
Royer, et al. Experimental [Page 40] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [40ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
and backslash-escaped. THE CS must perform the comparisons as if each value existed by itself and was not quoted or backslash-escaped, when comparing using the LIKE element.
そして、バックスラッシュで、逃げられます。 まるでLIKE要素を使用することで比較するとき、それぞれの値がそれ自体を生きさせて、引用されなかったバックスラッシュによって逃げられるかのようにTHE CSは比較を実行しなければなりません。
See related examples in Section 6.1.1.11.
.11にセクション6.1.1における関連する例を見てください。
6.1.1.10. Empty vs. NULL
6.1.1.10. ヌルに対して空になってください。
When used in a CAL-QUERY value, "NULL" means that the property or parameter is not present in the object. Paramaters that are not provided and have a default value in the property are considered to exist with their default value and will not be "NULL".
カル-QUERY値に使用されると、「ヌル」は、特性かパラメタが物に存在していないことを意味します。 提供されないで、デフォルト値を持っているParamatersは所有地で彼らのデフォルト値で存在すると考えられて、「ヌルでないでしょう」。
If the property exists but has no value, then "NULL" MUST NOT
match.
特性では存在していますが、値が全くないなら、「ヌル」は合ってはいけません。
If the parameter exists but has no value, then "NULL" MUST NOT
match.
パラメタでは、存在していますが、値が全くないなら、「ヌル」は合ってはいけません。
If the parameter not present and has a default value, then "NULL"
MUST NOT match.
パラメタがデフォルト値を提示して、持っていないなら、「ヌル」は合ってはいけません。
If the property (or parameter) exists but has no value, then it
matches the empty string '' (quote quote).
特性(または、パラメタ)では存在していますが、値が全くないなら、それは空のストリングに合っています「(引用始めを引用してください)」という。
6.1.1.11. [NOT] IN
6.1.1.11. [NOT] IN
This is similar to the "LIKE" clause, except it does value matching and not string comparison matches.
それ以外に、これは、“LIKE"節と同様であり、マッチングを評価して、比較マッチを結びません。
Some iCalendar objects can be multi-instance and multi-valued. The "IN" clause will return a match if the literal value supplied as part of the "IN" clause is contained in the value of any instance of the named property or parameter, or is in any of the multiple values in the named property or parameter. Unlike the "LIKE" clause, the '%' and '_' matching characters are not used with the "IN" clause and have no special meaning.
いくつかのiCalendar物が、マルチ例であってマルチ評価できます。 「IN」節の一部として供給された文字通りの値は名前付の特性かパラメタのどんな例の値にも含まれているか、または名前付の所有地かパラメタの複数の値のどれかにあると、「IN」節はマッチを返すでしょう。 “LIKE"節と異なって、'%'とキャラクタに合っている'_'が、「IN」節と共に使用されないで、またどんな特別な意味も持っていません。
BEGIN:A-COMPONENT
(a) property:value1,value2 One property, two values.
(b) property:"value1,value2" One property, one value.
(c) property:parameter=1,2:x One parameter, two values.
(d) property:parameter="1,2",3:y One parameter, one value.
(e) property:parameter=",":z One parameter, one value.
(f) property:x,y,z One property, three values
END:A-COMPONENT
BEGIN: 1COMPONENTの(a)の特性: value1、value2 Oneの特性、2つの値。 (b) 特性: 「value1、value2" Oneの特性、1つの値。」 (c) 特性: 1、パラメタ=2: x Oneパラメタ、2つの値。 (d) 特性: パラメタ=、「1 2インチ、3: y Oneパラメタ、1つの値、」 (e) 」 「特性: パラメタ=」、: z Oneパラメタ、1つの値。 (f) 特性: x、y、z Oneの特性、3はEND: A-COMPONENTを評価します。
Royer, et al. Experimental [Page 41] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [41ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
In this example:
この例で:
'value1' IN property would match (a) only.
'value1,value2' IN property would match (b) only.
'value%' IN property would NOT match any.
',' IN property would NOT match any.
'%,%' IN property would NOT match any.
'x' IN property would match (f) and (c).
'2' IN parameter would match (c) only.
'1,2' IN parameter would match (d) only.
',' IN parameter would match (e) only.
'%,%' IN parameter would NOT match any.
'value1'INの特性は(a)だけに合っているでしょう。 'value1、value2'INの特性は(b)だけに合っているでしょう。 '値の%'INの特性はいずれにも合っていないでしょう。 ''INの特性はいずれにも合っていないでしょう。 INの特性がそうする'%、%'はいずれにも合っていません。 'x'INの特性は(f)と(c)に合っているでしょう。 '2'INパラメタは(c)だけに合っているでしょう。 '1 2 'INパラメタは(d)だけに合っているでしょう。 ''INパラメタは(e)だけに合っているでしょう。 INパラメタがそうする'%、%'はいずれにも合っていません。
property LIKE 'value1%' would match (a) and (b).
property LIKE 'value%' would match (a) and (b).
property LIKE 'x' would match (f) and (c).
parameter LIKE '1%' would match (c) and (d).
parameter LIKE '%2%' would match (c) and (d).
parameter LIKE ',' would match (e) only.
'特性のLIKE'value1%'は(a)と(b)に合っているでしょう。特性のLIKE'値の%'は(a)と(b)に合っているでしょう。特性のLIKE'x'は'%が'(c)と(d) パラメタLIKEを合わせるだろう'という1%2%は'(c)と(d) パラメタLIKEを合わせ'であるだろうこと'が合っている(f)と(c) パラメタLIKEだけに合っているでしょう。
Some property values (such as the "RECUR" value type), contain commas and are not multi-valued. The CS must understand the objects being compared and understand how to determine how any multi-valued or multi-instance properties or parameter values are separated, quoted, and backslash-escaped and perform the comparisons as if each value existed by itself and not quoted or backslash-escaped when comparing using the IN element.
いくつかの特性の値(「再発してください」という値のタイプなどの)は、コンマを含んでいて、マルチ評価されていません。 CSは物が比較されるのを理解していて、どのように何かマルチ評価されたかマルチ例の特性やパラメタ値がどのように切り離されて、引用されて、バックスラッシュによって逃げられるかを決定して、まるで各値がIN要素をそれ自体を生きさせて、引用したか、または使用を比較するときバックスラッシュで逃げないかのように比較を実行するかを理解しなければなりません。
If the "IN" clause is preceded by 'NOT', then there is a match when the value does not exist in the property or parameter value.
値が特性かパラメタ値で存在しないとき、'NOT'が「IN」節に先行するなら、マッチがあります。
6.1.1.12. DATE-TIME and TIME Values in a WHERE Clause
6.1.1.12. aの日付-時間と時間的価値、どこ、節
All "DATE-TIME" and "TIME" literal values supplied in a "WHERE" clause MUST be terminated with 'Z'. That means that the CUA MUST supply the values in UTC.
「'Zと共に」 節がそうしなければならないところで終えられてください'で供給されたすべての「日付-時間」と「時間」文字通りの値。 それは、クーアがUTCで値を供給しなければならないことを意味します。
Valid:
有効:
WHERE alarm.TRIGGER < '20020201T000000Z'
AND alarm.TRIGGER > '20020101T000000Z'
どこalarm.TRIGGER<'20020201T000000Z'とalarm.TRIGGER>'20020101T000000Z'
Not valid; it is a syntax error and the CS MUST reject the QUERY:
有効でない。 それは構文エラーです、そして、CS MUSTはQUERYを拒絶します:
WHERE alarm.TRIGGER < '20020201T000000'
AND alarm.TRIGGER > '20020101T000000'
どこalarm.TRIGGER<'20020201T000000'とalarm.TRIGGER>'20020101T000000'
Royer, et al. Experimental [Page 42] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [42ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
6.1.1.13. Multiple Contained Components
6.1.1.13. 複数の含まれたコンポーネント
If a query references a component and a component or property contained in the component, any clauses referring to the contained component or property must be evaluated on all of the contained components or properties. If any of the contained components or properties match the query, and the conditions on the containing component are also true, the component matches the query.
質問であるなら、含まれたコンポーネントか特性のすべてでコンポーネントとコンポーネントか特性がコンポーネントに含んだ参照、含まれたコンポーネントについて言及するどんな節または特性も評価しなければなりません。 含まれたコンポーネントか特性のどれかが質問に合って、また、含んでいるコンポーネントに関する状態も本当であるなら、コンポーネントは質問に合っています。
For example, in the query below, if a BOOKED VEVENT contains multiple VALARMs, and the VALARM.TRIGGER clause is true for any of the VALARMs in the VEVENT, then the UID, SUMMARY, and DESCRIPTION of this VEVENT would be included in the QUERY results.
例えば、以下での質問では、BOOKED VEVENTが複数のVALARMsを含んでいて、VEVENTのVALARMsのどれかに、VALARM.TRIGGER節が正しいなら、このVEVENTのUID、SUMMARY、および記述はQUERY結果に含まれているでしょう。
BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
WHERE VALARM.TRIGGER >= '20000101T030405Z'
AND VALARM.TRIGGER <= '20001231T235959Z'
AND STATE() = 'BOOKED'
END:VQUERY
始まってください: VQUERYは広がります: 本当の質問: '20000101T030405Z'とVALARM.TRIGGER VALARM.TRIGGER>=<が'20001231T235959Z'と等しく、状態()=が終わり: VQUERYを'予約した'VEVENTからUID、概要、記述を選択してください。
6.1.1.14. Example, Query by UID
6.1.1.14. 例、UIDによる質問
The following example would match the entire content of a "VEVENT" or "VTODO" component with the "UID" property equal to "uid123" , and it would not expand any multiple instances of the component. If the CUA does not know if "uid123" was a "VEVENT", "VTODO", "VJOURNAL", or any other component, then all components that the CUA supports MUST be supplied in a QUERY property. This example assumes the CUA is only interested in "VTODO" and "VEVENT" components.
以下の例は"VEVENT"か"VTODO"コンポーネントの全体の内容を"uid123"と等しい"UID"の特性に合わせるでしょう、そして、それはコンポーネントのどんな複数のインスタンスも広げないでしょう。 CUAが、"uid123"が"VEVENT"、"VTODO"、"VJOURNAL"、またはコンポーネントであったかをいかなる他のも知らないなら、質問所有地でクーアがサポートするすべてのコンポーネントを供給しなければなりません。 この例は、CUAが"VTODO"と"VEVENT"コンポーネントに興味を持っているだけであると仮定します。
If the results were empty it could also mean that "uid123" was a property in a component other than a VTODO or VEVENT.
また、結果が空であるなら、それは、"uid123"がVTODOかVEVENT以外のコンポーネントで特性であったことを意味するかもしれないでしょうに。
BEGIN:VQUERY
QUERY:SELECT * FROM VTODO WHERE UID = 'uid123'
QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123'
END:VQUERY
始まってください: VQUERY質問: UIDが'uid123'質問と等しいVTODO: UIDが'uid123'終わり: VQUERYと等しいVEVENTからの選んだ*からの選んだ*
6.1.1.15. Query by Date-Time Range
6.1.1.15. 日付-時間範囲のそばでの質問
This query selects the entire content of every booked "VEVENT"
component that has an instance greater than or equal to July 1,
2000 00:00:00 UTC and less than or equal to July 30, 2000 23:59:59
UTC. This includes single instance "VEVENT" components that do
not explicitly contain any recurrence properties or "RECURRENCE-
ID" properties. This works only for CSs that have the "RECUR-
この質問は2000年7月1日協定世界時0時0分0秒にインスタンスをより持っているあらゆる予約している"VEVENT"コンポーネントと2000年7月30日より協定世界時23時59分59秒の全体の内容を選択します。 これは明らかに少しの再発の特性や「RECURRENCE ID」の特性も含まないただ一つのインスタンス"VEVENT"コンポーネントを含んでいます。 これは「再発」を持っているCSsのためだけに働いています。
Royer, et al. Experimental [Page 43] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [43ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
EXPAND" property value set to "TRUE" in the "GET-CAPABILITY"
exchange.
"EXPAND"資産価値が「本当」にセットした、「能力を得る、」 交換。
BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT * FROM VEVENT
WHERE RECURRENCE-ID >= '20000701T000000Z'
AND RECURRENCE-ID <= '20000730T235959Z'
AND STATE() = 'BOOKED'
END:VQUERY
始まってください: VQUERYは広がります: 本当に、質問: RECURRENCE ID>が'20000701T000000Z'と等しく、RECURRENCE ID<が'20000730T235959Z'と状態()=と等しいVEVENTからの選んだ*は終わり: VQUERYを'予約しました'。
6.1.1.16. Query for All Unprocessed Entries
6.1.1.16. すべての未加工のエントリーのための質問
The following example selects the entire contents of all non-booked "VTODO" and "VEVENT" components in the "UNPROCESSED" state. The default for the "EXPAND" property is "FALSE", so the recurrence rules will not be expanded.
以下の例は「未加工」の状態のすべての非予約している"VTODO"と"VEVENT"コンポーネントの全体のコンテンツを選択します。 「広がってください」という特性のためのデフォルトが「誤っている」ので、再発規則は広げられないでしょう。
BEGIN:VQUERY
QUERYID:Fetch VEVENT and VTODO iTIP components
QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED'
QUERY:SELECT * FROM VTODO WHERE STATE() = 'UNPROCESSED'
END:VQUERY
BEGIN:VQUERY QUERYID:フェッチVEVENTとVTODO iTIPコンポーネントQUERY: SELECT*FROM VEVENT WHERE STATE()は'UNPROCESSED'QUERYと等しいです: SELECT*FROM VTODO WHERE STATE()は'UNPROCESSED'END: VQUERYと等しいです。
The following example fetches all "VEVENT" and "VTODO" components in the "BOOKED" state.
以下の例は「予約された」状態ですべての"VEVENT"と"VTODO"にコンポーネントをとって来ます。
BEGIN:VQUERY
QUERYID:Fetch All Booked VEVENT and VTODO components
QUERY:SELECT * FROM VEVENT WHERE STATE() = 'BOOKED'
QUERY:SELECT * FROM VTODO WHERE STATE() = 'BOOKED'
END:VQUERY
BEGIN:VQUERY QUERYID:フェッチAll Booked VEVENTとVTODOコンポーネントQUERY: SELECT*FROM VEVENT WHERE STATE()は'BOOKED'QUERYと等しいです: SELECT*FROM VTODO WHERE STATE()は'BOOKED'END: VQUERYと等しいです。
The following fetches the "UID" property for all "VEVENT" and "VTODO" components that have been marked for delete.
以下はそれがマークされたすべての"VEVENT"と"VTODO"コンポーネントのために"UID"の特性をとって来ます。削除します。
BEGIN:VQUERY
QUERYID:Fetch UIDs of marked-for-delete VEVENTs and VTODOs
QUERY:SELECT UID FROM VEVENT WHERE STATE() = 'DELETED'
QUERY:SELECT UID FROM VTODO WHERE STATE() = 'DELETED'
END:VQUERY
BEGIN:VQUERY QUERYID:フェッチUIDs、マークされる、削除、VEVENTsとVTODOs QUERY: SELECT UID FROM VEVENT WHERE STATE()は'DELETED'QUERYと等しいです: SELECT UID FROM VTODO WHERE STATE()は'DELETED'END: VQUERYと等しいです。
6.1.1.17. Query with Subset of Properties by Date/Time
6.1.1.17. 日付/時間までに特性の部分集合との質問
In this example, only the named properties will be selected, and all booked and non-booked components have a "DTSTART" value from February 1st to February 10th 2000 (in UTC) will also be selected.
この例では、命名された特性だけが選択されるでしょう、そして、また、"DTSTART"が予約されていて非予約しているコンポーネントで2月1日から2000年2月10日(UTCの)まで評価するすべてが選択されるでしょう。
Royer, et al. Experimental [Page 44] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [44ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
BEGIN:VQUERY
QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT
WHERE DTSTART >= '20000201T000000Z'
AND DTSTART <= '20000210T235959Z'
END:VQUERY
始まってください: VQUERY質問: DTSTART>が'そして、DTSTART<は'20000210T235959Zと等しい'という'20000201T000000Zエンド: VQUERYと等しいVEVENTからUID、DTSTART、記述、概要を選択してください。
6.1.1.18. Query with Components and Alarms in A Range
6.1.1.18. コンポーネントとアラームが範囲にある質問
This example fetches all booked "VEVENT" components with an alarm that triggers within the specified time range. In this case only the "UID", "SUMMARY", and "DESCRIPTION" properties will be selected for all booked "VEVENTS" components that have an alarm between the two date-times supplied.
この例はそれが指定された時間範囲の中で引き金となるアラームですべての予約している"VEVENT"コンポーネントをとって来ます。 この場合、"UID"、「概要」、および「記述」の特性だけが2日付時間の間のアラームを提供するすべての予約している「VEVENTS」コンポーネントのために選択されるでしょう。
BEGIN:VQUERY
EXPAND:TRUE
QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT
WHERE VALARM.TRIGGER >= '20000101T030405Z'
AND VALARM.TRIGGER <= '20001231T235959Z'
AND STATE() = 'BOOKED'
END:VQUERY
始まってください: VQUERYは広がります: 本当の質問: '20000101T030405Z'とVALARM.TRIGGER VALARM.TRIGGER>=<が'20001231T235959Z'と等しく、状態()=が終わり: VQUERYを'予約した'VEVENTからUID、概要、記述を選択してください。
6.1.2. UPN Value Type
6.1.2. UPN値のタイプ
Value Name: UPN
名前を評価してください: UPN
Purpose: This value type is used to identify values that contain user
principal name of a CU or a group of CUs.
目的: この値のタイプは、ユーザ主体名(CU)かCUsのグループを含む値を特定するのに使用されます。
Formal Definition: The value type is defined by the following
notation:
公式の定義: 値のタイプは以下の記法で定義されます:
;
upn = "@"
/ [ dot-atom-text ] "@" dot-atom-text
;
; dot-atom-text is defined in RFC 2822 [RFC2822]
;
;
dot-atom-text = ; As defined in [iCAL].
; upnは[ドット原子テキスト]"@"/"@"ドット原子テキストと等しいです。 ; ドット原子テキストはRFC2822[RFC2822]で定義されます。 ; ドット原子テキスト=。 [iCAL]で定義されるように。
Description: This data type is an identifier that denotes a CU or a
group of CU. A UPN is an RFC 2822-compliant email address
[RFC2822], with exceptions listed below, and in most cases it is
deliverable to the CU. In some cases it is identical to the CU's
well known email address. A CU's UPN MUST never be an e-mail
address that is deliverable to a different person. And there is
no requirement that a person's UPN MUST be their e-mail address.
記述: このデータ型は、CUを指示する識別子かCUのグループです。 UPNは例外が以下に記載されているRFCの2822年の対応することのEメールアドレス[RFC2822]です、そして、多くの場合、それはCUへの提出物です。 いくつかの場合、それはCUのよく知られているEメールアドレスと同じです。 CUのUPN MUST、決して異なった人にとっての提出物であるEメールアドレスいるのでないでください。 そして、人のUPN MUSTがそれらのEメールアドレスであるという要件が全くありません。
Royer, et al. Experimental [Page 45] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [45ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
A UPN is formatted as a user name followed by "@", followed by a
Realm in the form of a valid and unique DNS domain name. The user
name MUST be unique within the Realm. In its simplest form it
looks like "user@example.com".
ユーザ名が有効でユニークなDNSドメイン名の形の分野によって続かれた"@"で従って、UPNはフォーマットされます。 ユーザ名はRealmの中でユニークであるに違いありません。 最も簡単なフォームでは、それは" user@example.com "に似ています。
In certain cases a UPN will not be RFC 2822-compliant. When
anonymous authentication is used, or anonymous authorization is
being defined, the special UPN "@" will be used. When
authentication MUST be used, but unique identity MUST be obscured,
a UPN of the form @DNS-domain-name may be used. For example,
"@example.com".
ある場合には、RFCが2822年の対応であったなら、UPNはそうしないでしょう。 匿名の認証が使用されているか、または匿名の承認が定義されているとき、特別なUPN"@"は使用されるでしょう。 認証を使用しなければなりませんが、ユニークなアイデンティティをあいまいにしなければならないとき、フォーム@DNSドメイン名のUPNは使用されるかもしれません。 「例えば」、@example.com、」
Example:
例:
The following is a UPN for a CU:
↓これはCUのためのUPNです:
jdoe@example.com
jdoe@example.com
The following is an example of a UPN that could be for a group of
CU:
↓これはCUのグループのためのものであるかもしれないUPNに関する例です:
staff@example.com
staff@example.com
The following is a UPN for an anonymous CU that belongs to a
specific realm. When used as a UPN-FILTER, it applies to all UPNs
in a specific realm:
↓これは特定の分野のもの匿名のCUのためのUPNです。 UPN-FILTERとして使用されると、それは特定の分野のすべてのUPNsに適用されます:
@example.com
@example.com
The following is a UPN for an anonymous CU:
↓これは匿名のCUのためのUPNです:
@
@
6.1.3. UPN-FILTER Value
6.1.3. UPN-フィルタ値
Value Name: UPN-FILTER
名前を評価してください: UPN-フィルタ
Purpose: This value type is used to identify values that contain a
user principal name filter.
目的: この値のタイプは、ユーザ主体名前フィルタを含む値を特定するのに使用されます。
Formal Definition: The value type is defined by the following
notation:
公式の定義: 値のタイプは以下の記法で定義されます:
;
; NOTE: "CAL-OWNERS(cal-address)"
; and "NOT CAL-OWNERS(cal-address)"
; are both NOT allowed below.
;
; ; 以下に注意してください。 「カル-所有者(calアドレス)」。 「NOTカル-所有者(calアドレス)」。 以下にともに許容されていません。 ;
Royer, et al. Experimental [Page 46] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [46ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
upn-filter = "CAL-OWNERS()" /
"NOT CAL-OWNERS()" /
"*" /
[ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text )
;
; dot-atom-text is defined in RFC 2822
upn-フィルタ=「カル所有者()」/「カル所有者()でない」[ドット原子「*」/テキスト]/「*」/"@"(ドット原子「*」/テキスト)。 ; ドット原子テキストはRFC2822で定義されます。
Description: The value is used to match user principal names (UPNs). For "CAL-OWNERS()" and "NOT CAL-OWNERS()", see Section 8.24.
記述: 値は、ユーザ主体名(UPNs)を合わせるのに使用されます。 「カル所有者()」と「カル所有者()でない」に関しては、セクション8.24を見てください。
* Matches all UPNs.
* マッチUPNs。
@ Matches the UPN of anonymous CUs
belonging to the null realm
@はヌル分野のもの匿名のCUsのUPNに合っています。
@* Matches the UPN of anonymous CUs
belonging to any non-null realm
@*はどんな非ヌル分野ももの匿名のCUsのUPNに合っています。
@realm Matches the UPN of anonymous CUs
belonging to the specified realm.
指定された分野のもの匿名のCUsの@realm Matches UPN。
*@* Matches the UPN of non-anonymous CUs
belonging to any non-null realm
*@*はどんな非ヌル分野ももの非匿名のCUsのUPNに合っています。
*@realm Matches the UPN of non-anonymous CUs
belonging to the specified realm
*指定された分野のもの非匿名のCUsの@realm Matches UPN
user@realm Matches the UPN of the specified CU
belonging to the specified realm
user@realm は指定された分野のもの指定されたCUのUPNに合っています。
user@* Not allowed.
許容されなかった user@* 。
user@ Not allowed.
Notが許容したユーザ@。
Example: The following are examples of this value type:
例: ↓これはこの値のタイプに関する例です:
DENY:NON CAL-OWNERS()
DENY:@hackers.example.com
DENY:*@hackers.example.com
GRANT:sam@example.com
以下を否定してください、そして、非カル所有者()は: .example.comが否定する@hackers: *@hackers.example.com 交付金: sam@example.com を否定します。
Royer, et al. Experimental [Page 47] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [47ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
7. New Parameters
7. 新しいパラメタ
7.1. ACTION Parameter
7.1. 動作パラメタ
Parameter Name: ACTION
パラメタ名: 動作
Purpose: This parameter indicates the action to be taken when a
timeout occurs.
目的: このパラメタは、タイムアウトが起こるとき、取るために動作を示します。
Value Type: TEXT
タイプを評価してください: テキスト
Conformance: This property can be specified in the "CMD" property.
順応: "CMD"所有地でこの特性を指定できます。
When present in a "CMD" property, the "ACTION" parameter specifies
the action to be taken when the command timeout expires.
"CMD"所有地に存在しているとき、「動作」パラメタは、コマンドタイムアウトが期限が切れるとき、取るために動作を指定します。
Formal Definition: The parameter is defined by the following
notation:
公式の定義: パラメタは以下の記法で定義されます:
action-param = ";" "ACTION" "=" ( "ASK" / "ABORT" )
; If 'action-param' is supplied then
; 'latency-param' MUST be supplied.
「動作-param=」;、」 「動作」「=」(「尋ねる」か、または「中止になります」)。 その時'動作-param'を供給するなら。 '潜在-param'を供給しなければなりません。
Example:
例:
CMD;LATENCY=10;ACTION=ASK:CREATE
CMD; 潜在=10; 動作=は尋ねます:、作成
7.2. ENABLE Parameter
7.2. パラメタを可能にしてください。
Parameter Name: ENABLE
パラメタ名: 可能にします。
Purpose: This parameter indicates whether or not the property should
be ignored. For example, it can indicate that a "TRIGGER"
property in a "VALARM" component should be ignored.
目的: このパラメタは、特性が無視されるべきであるかどうかを示します。 例えば、それは、"VALARM"コンポーネントにおける「引き金」の特性が無視されるべきであるのを示すことができます。
Value Type: BOOLEAN
タイプを評価してください: 論理演算子
Conformance: This property can be specified in the "TRIGGER"
properties.
順応: 「引き金」所有地でこの特性を指定できます。
Description: When a non owner sends an [iTIP] "REQUEST" to a calendar
that object might contain a "VALARM" component. The owner may
wish to have local control over their own CUA and when or how
alarms are triggered.
記述: 非所有者が[iTIP]「要求」をカレンダーに送るとき、そのオブジェクトは"VALARM"コンポーネントを含むかもしれません。 所有者は、それら自身のCUAの上の現場制御と、いつかアラームがどう引き起こされるかをさせたがっているかもしれません。
A CUA may add the "ENABLE" parameter to any "TRIGGER" property
before booking the component. If the "ENABLE" parameter is set to
"FALSE", then the alarm will be ignored by the CUA. If set to
コンポーネントを予約する前に、CUAは「可能にする」パラメタをどんな「引き金」の特性にも追加するかもしれません。 「可能にする」パラメタが「誤っていること」に設定されると、アラームはクーアによって無視されるでしょう。 セットされます。
Royer, et al. Experimental [Page 48] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [48ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
"TRUE", or if the "ENABLE" property is not in the "TRIGGER"
property, the alarm is enabled. This parameter may not be known
by pre-CAP implementations, but this should not be an issue as it
conforms to an 'ianaparam' [iCAL].
「TRUE、」 「可能にすること」の特性が「よりこぎれいな」所有地にないなら、アラームは可能にされます。 このパラメタはプレCAP実装によって知られていないかもしれませんが、'ianaparam'[iCAL]に従うとき、これは問題であるべきではありません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
enable-param = "ENABLE" "=" boolean
;
boolean = ; As defined in [iCAL].
paramを有効にしている=「可能にすること」は論理演算子と「等しいです」。 論理演算子=。 [iCAL]で定義されるように。
Example: The following is an example of this property for a "VAGENDA"
component:
例: ↓これは"VAGENDA"コンポーネントのためのこの特性に関する例です:
TRIGGER;ENABLE=FALSE;RELATED=END:PT5M
引き金; =を虚偽で可能にします; 関係するのは終わり: PT5Mと等しいです。
7.3. ID Parameter
7.3. IDパラメタ
Parameter Name: ID
パラメタ名: ID
Purpose: When used in a "CMD" component, it provides a unique
identifier.
目的: "CMD"コンポーネントに使用されると、それはユニークな識別子を提供します。
Value Type: TEXT
タイプを評価してください: テキスト
Conformance: This parameter can be specified in the "CMD" property.
順応: "CMD"所有地でこのパラメタを指定できます。
Description: If more than one command is sent, then the "ID"
parameter is used to uniquely identify the command.
記述: 1つ以上のコマンドを送るなら、唯一コマンドを特定するのに「ID」パラメタを使用します。
A CUA may add the "ID" parameter to any "CMD" property before
sending the command. There must not be more than one outstanding
command tagged with the same "ID" parameter value.
コマンドを送る前に、CUAはどんな"CMD"の特性にも「ID」パラメタを追加するかもしれません。 同じ「ID」パラメタ価値でタグ付けをされた1つ以上の傑出しているコマンドがあるはずがありません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
id-param = ";" "ID" "=" unique-id
; The text value supplied is a unique value
; shared between the CUA and CS to uniquely
; identify the instance of command in the
; the current CUA session. The value has
; no meaning to other CUAs or other sessions.
;
unique-id = ; text
;
text = ; As defined in [iCAL].
「イド-param=」;、」 「ID」はユニークなイドと「等しいです」。 値が供給したテキストはユニークな値です。 CUAとCSの間で唯一共有する、。 中でコマンドのインスタンスを特定してください、。 現在のCUAセッション。 値はそうしました。 他のCUAsか他のセッションまでの意味しないこと。 ; ユニークなイド=。 テキスト。 テキスト=。 [iCAL]で定義されるように。
Example: The following is an example of this parameter component:
例: ↓これはこのパラメタコンポーネントに関する例です:
Royer, et al. Experimental [Page 49] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [49ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
CMD;UD=some-unique-value:CREATE
CMD; UDはいくつかユニークな値と等しいです:、作成
7.4. LATENCY Parameter
7.4. 潜在パラメタ
Parameter Name: LATENCY
パラメタ名: 潜在
Purpose: This parameter indicates time in seconds for when a timeout
occurs.
目的: このパラメタは秒にタイムアウトが起こる時の間、時間を示します。
Value Type: TEXT
タイプを評価してください: テキスト
Conformance: This property can be specified in the "CMD" property.
順応: "CMD"所有地でこの特性を指定できます。
When present in a "CMD" property, the "LATENCY" parameter specifies
the time in seconds when the command timeout expires.
秒の時に"CMD"所有地に存在しているとき、「潜在」パラメタは、コマンドタイムアウトがいつ期限が切れるかを指定します。
Formal Definition: The parameter is defined by the following
notation:
公式の定義: パラメタは以下の記法で定義されます:
latency-param = ";" "LATENCY" "=" latency-sec
; The value supplied in the time in seconds.
; If 'latency-param' is supplied then
; 'action-param' MUST be supplied.
;
latency-sec = posint1
「潜在-param=」;、」 "LATENCY"「=」潜在秒。 秒に時間供給された値。 ; その時'潜在-param'を供給するなら。 '動作-param'を供給しなければなりません。 ; 潜在秒=posint1
; Default is zero (0) meaning no timeout.
; デフォルトはタイムアウトを全く意味しない(0)ではありません。
Example: The following is an example of this parameter:
例: ↓これはこのパラメタに関する例です:
CMD;LATENCY=10;ACTION=ASK:CREATE
CMD; 潜在=10; 動作=は尋ねます:、作成
7.5. LOCAL Parameter
7.5. ローカルのパラメタ
Parameter Name: LOCAL
パラメタ名: ローカル
Purpose: Indicates if the named component should be exported to any
non-organizer calendar.
目的: 命名されたコンポーネントが何か非オーガナイザーカレンダーにエクスポートされるべきであるかどうかを示します。
Value Type: BOOLEAN
タイプを評価してください: 論理演算子
Conformance: This parameter can be specified in the "SEQUENCE"
properties in a "VALARM" component.
順応: 「系列」所有地で"VALARM"コンポーネントでこのパラメタを指定できます。
Description: When a non-owner sends an [iTIP] "REQUEST" to a calendar
that object might contain a "VALARM" component. The owner may
wish to have local control over their own CUA and when or how
alarms are triggered.
記述: 非所有者が[iTIP]「要求」をカレンダーに送るとき、そのオブジェクトは"VALARM"コンポーネントを含むかもしれません。 所有者は、それら自身のCUAの上の現場制御と、いつかアラームがどう引き起こされるかをさせたがっているかもしれません。
Royer, et al. Experimental [Page 50] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [50ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
A CUA may add the "LOCAL" parameter to the "SEQUENCE" property
before booking the component. If the "LOCAL" parameter is set to
"TRUE", then the alarm MUST NOT be forwarded to any other
calendar. If set to "FALSE", or if the "LOCAL" parameter is not
in the "SEQUENCE" property, the alarm is global.
コンポーネントを予約する前に、CUAは「地方」のパラメタを「系列」の特性に追加するかもしれません。 「地方」のパラメタを「本当に」設定するなら、いかなる他のカレンダーにもアラームを転送してはいけません。 「誤っていること」に設定されるか、または「地方」のパラメタが「系列」所有地にないなら、アラームはグローバルです。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
local-param = "LOCAL" "=" boolean
地方のparamは「地方」の「=」論理演算子と等しいです。
Example: The following is an example of this parameter:
例: ↓これはこのパラメタに関する例です:
SEQUENCE;LOCAL=TRUE:4
系列; ローカルは本当に等しいです:、4
7.6. LOCALIZE Parameter
7.6. パラメタをローカライズしてください。
Parameter Name: LOCALIZE
パラメタ名: ローカライズしてください。
Purpose: If provided, specifies the desired language for error and
warning messages.
目的: 提供して、誤りと警告メッセージに必要な言語を指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Conformance: This parameter can be specified in the "CMD" properties.
順応: "CMD"所有地でこのパラメタを指定できます。
When the "LOCALIZE" parameter is supplied, its value MUST be one
of the values listed in the initial [BEEP] greeting 'localize'
attribute.
「ローカライズしてください」というパラメタを提供するとき、値は初期の[ビープ音]挨拶で記載された値が'ローカライズする'という属性の1つでなければなりません。
A CUA may add the "LOCALIZE" parameter to the "CMD" property to
specify the language of any error or warning messages.
CUAは、どんな誤りや警告メッセージの言語も指定するために「ローカライズしてください」というパラメタを"CMD"の特性に追加するかもしれません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
localize-param = ";" "LOCALIZE" "=" beep-localize
;
beep-localize = text ; As defined in [BEEP]
; The value supplied MUST be one value from
; the initial [BEEP] greeting 'localize'
; attribute, specifying the locale to use
; for error messages during
; this instance of the command.
「paramをローカライズしている=」;、」 "LOCALIZE"「=」はビープ音でローカライズします。 =がテキストであるとビープ音でローカライズしてください。 [BEEP]で定義されるように。 供給された値が1つの値でなければならない、。 'ローカライズしてください'に挨拶する初期の[BEEP]。 使用する現場を指定する属性。 エラーメッセージ、。 コマンドのこのインスタンス。
Example: The following is an example of this parameter:
例: ↓これはこのパラメタに関する例です:
CMD;LOCALIZE=fr_CA:CREATE
CMD; =がfr_カリフォルニアであるとローカライズしてください:、作成
Royer, et al. Experimental [Page 51] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [51ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
7.7. OPTIONS Parameter
7.7. オプションパラメタ
Parameter Name: OPTIONS
パラメタ名: オプション
Purpose: If provided the "OPTIONS" parameter specifies some "CMD"
property-specific options.
目的: 提供するなら、「オプション」パラメタはいくつかの"CMD"特性の特有のオプションを指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Conformance: This parameter can be specified in the "CMD" properties.
順応: "CMD"所有地でこのパラメタを指定できます。
A CUA adds the "OPTIONS" parameter to the "CMD" property when the
command needs extra values.
コマンドが超過価値を必要とすると、CUAは「オプション」パラメタを"CMD"の特性に追加します。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
option-param = ";" "OPTIONS" "=" cmd-specific
;
cmd-specific = ; The value supplied is dependent on the
; CMD value. See the specific CMDs for the
; correct values to use for each CMD.
「オプション-param=」;、」 「OPTIONS」はcmd-詳細と「等しいです」。 cmd特有の=。 供給された値が依存している、オンである、。 CMD値。 特定のCMDsを見る、。 各CMDに使用する値を修正してください。
Example: The following is an example of this parameter:
例: ↓これはこのパラメタに関する例です:
CMD;OPTIONS=10:GENERATE-UID
CMD; オプション=10:、UIDを生成します。
8. New Properties
8. 新しい特性
8.1. ALLOW-CONFLICT Property
8.1. 闘争を許している特性
Property Name: ALLOW-CONFLICT
特性の名: 闘争を許します。
Purpose: This property indicates whether or not the calendar and CS
supports component conflicts. That is, whether or not any of the
components in the calendar can overlap.
目的: この特性は、カレンダーとCSがコンポーネント闘争をサポートするかどうかを示します。 すなわち、カレンダーのコンポーネントのどれかは重なるのであることができるかどうか
Value Type: BOOLEAN
タイプを評価してください: 論理演算子
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VAGENDA" and
"VCALSTORE" component.
順応: "VAGENDA"と"VCALSTORE"コンポーネントでこの特性を指定できます。
Description: This property is used to indicate whether components may
conflict, that is, whether their expanded instances may share the
same time or overlap the same time periods. If it has a value of
記述: この特性はコンポーネントが闘争するかもしれないかどうかを示すのに使用されます、すなわち、それらの拡張インスタンスが同時間を共有するか、または同じ期間を重ね合わせるかもしれないことにかかわらず。 それには、値があります。
Royer, et al. Experimental [Page 52] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [52ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
"TRUE", then conflicts are allowed. If "FALSE", the no two
components may conflict.
当時の闘争は"TRUE"が許されています。 「誤っている」なら、いいえtwo、コンポーネントは闘争するかもしれません。
If "FALSE" in the "VCALSTORE" component, then all "VAGENDA"
component "ALLOW-CONFLICT" property values MUST be "FALSE" in the
CS.
"VAGENDA"コンポーネント、"VCALSTORE"コンポーネントで「誤る」なら「闘争を許す、」 特性の値はCsで「誤っていなければなりません」。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
allow-conflict = "ALLOW-CONFLICT" other-params ":" boolean
CRLF
「闘争を許している=、「闘争を許す、」 他のparams、」、:、」 論理演算子CRLF
Example: The following is an example of this property for a "VAGENDA"
component:
例: ↓これは"VAGENDA"コンポーネントのためのこの特性に関する例です:
ALLOW-CONFLICT:FALSE
闘争を許します:、誤り
8.2. ATT-COUNTER Property
8.2. ATT-カウンタの特性
Property Name: ATT-COUNTER
特性の名: ATT-カウンタ
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property MUST be specified in an iCalendar object
that specifies a counter proposal to a group-scheduled calendar
entity. When storing a "METHOD" property with the "COUNTER"
method, there needs to be a way to remember who sent the COUNTER.
The ATT-COUNTER property MUST be added to all "COUNTER" [iTIP]
components by the CUA before storing in a CS.
順応: グループによって予定されているカレンダー実体に対案を指定するiCalendarオブジェクトでこの特性を指定しなければなりません。 「カウンタ」メソッドで「メソッド」の特性を保存するとき、だれがカウンタを送ったかを思い出す方法があるのが必要です。 クーアはCsにおける保存の前にすべての「カウンタ」[iTIP]コンポーネントにATT-COUNTERの特性を加えなければなりません。
Description: This property is used to identify the CAL-ADDRESS of the
entity that sent the "COUNTER" [iTIP] object.
記述: この特性は、「カウンタ」[iTIP]を送った実体のカル-ADDRESSオブジェクトを特定するのに使用されます。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
attcounter = "ATT-COUNTER" other-params ":" cal-address CRLF
「attcounterは「」 ATT-カウンタの他のparams」と等しいです」 calアドレスCRLF
Examples:
例:
ATT-COUNTER:cap:example.com/Doug
ATT-COUNTER:mailto:Doug@Example.com
ATT-カウンタ: 上限: example.com/ダグATT-COUNTER: mailto: Doug@Example.com
Royer, et al. Experimental [Page 53] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [53ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
8.3. CALID Property
8.3. CALIDの特性
Property Name: CALID
特性の名: CALID
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in the "VAGENDA"
component.
順応: "VAGENDA"コンポーネントでこの特性を指定できます。
Description: This property is used to specify a fully-qualified
CALID.
記述: この特性は、完全に適切なCALIDを指定するのに使用されます。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
calid = "CALID" other-params ":" relcalid CRLF
「calidは"CALID"とparamsである状態で他の等しい」:、」 relcalid CRLF
Example:
例:
CALID:cap://cal.example.com/sdfifgty4321
CALID: 上限://cal.example.com/sdfifgty4321
8.4. CALMASTER Property
8.4. CALMASTERの特性
Property Name: CALMASTER
特性の名: CALMASTER
Purpose: The property specifies an e-mail address of a person responsible for the calendar store.
目的: 特性はカレンダー店に責任がある人のEメールアドレスを指定します。
Value Type: URI
タイプを評価してください: URI
Property Parameters: Non-standard property parameters can be specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in a "VCALSTORE" component.
順応: "VCALSTORE"コンポーネントで特性を指定できます。
Description: The parameter value SHOULD be a MAILTO URI as defined in [URL]. It MUST be a contact URI such as a MAILTO URI and not a home page or file URI that describes how to contact the calmasters.
記述: パラメタは定義されるとしてのMAILTO URIがコネ[URL]であったならSHOULDを評価します。 calmastersに連絡する方法を説明するのは、ホームページかファイルURIではなく、MAILTO URIなどの接触URIであるに違いありません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
calmaster = "CALMASTER" other-params ":" uri CRLF
;
uri = ; IANA registered uri as defined in [iCAL].
「calmasterは"CALMASTER"とparamsである状態で他の等しい」:、」 uri CRLF。 uri=。 IANAは[iCAL]で定義されるようにuriを登録しました。
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
Royer, et al. Experimental [Page 54] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [54ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
CALMASTER:mailto:administrator@example.com
CALMASTER:mailto: administrator@example.com
8.5. CAP-VERSION Property
8.5. 上限バージョンの特性
Property Name: CAP-VERSION
特性の名: 上限バージョン
Purpose: This property specifies the version of CAP supported.
目的: この特性はサポートされたCAPのバージョンを指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property is specified in the "VREPLY" component
that is sent in response to a "GET-CAPABILITY" command.
順応: この特性がaに対応して送られる"VREPLY"コンポーネントで指定される、「能力を得る、」 命令してください。
Description: This specifies the version of CAP that the endpoint
supports. The list is a comma-separated list of supported RFC
numbers. The list MUST contain at least 4324.
記述: これは終点がサポートするCAPのバージョンを指定します。 リストはサポートしているRFC番号のコンマで切り離されたリストです。 リストは少なくとも4324を含まなければなりません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
cap-version = "CAP-VERSION" other-params ":" text CRLF
「上限バージョンは「」 上限バージョンの他のparams」と等しいです」 テキストCRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
CAP-VERSION:4324
上限バージョン: 4324
8.6. CARID Property
8.6. CARIDの特性
Property Name: CARID
特性の名: CARID
Purpose: This property specifies the identifier for an access right
component.
目的: この特性はアクセス権コンポーネントのための識別子を指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property MUST be specified once in a "VCAR"
component.
順応: "VCAR"コンポーネントでこの特性を一度指定しなければなりません。
Description: This property is used in the "VCAR" component to specify
an identifier. A "CARID" property value is unique per container.
記述: この特性は、識別子を指定するのに"VCAR"コンポーネントに使用されます。 "CARID"資産価値はコンテナ単位でユニークです。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
Royer, et al. Experimental [Page 55] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [55ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
carid = "CARID" other-params ":" text CRLF
「caridは"CARID"とparamsである状態で他の等しい」:、」 テキストCRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
CARID:xyzzy-007
CARID:User Rights
CARID:xyzzy-007 CARID:ユーザ権利
8.7. CAR-LEVEL Property
8.7. 車レベルの特性
Property Name: CAR-LEVEL
特性の名: 車レベル
Purpose: The property specifies the level of VCAR supported.
目的: 特性はサポートされたVCARのレベルを指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in a "VREPLY" component
that is sent in response to a "GET-CAPABILITY" command.
順応: aに対応して送られる"VREPLY"コンポーネントで特性を指定できる、「能力を得る、」 命令してください。
Description: The value is one from a list of "CAR-NONE", "CAR-MIN",
or "CAR-FULL-1". If "CAR-FULL-1" is supplied, then "CAR-MIN" is
also available. A "CAR-MIN" implementation only supported the
"DEFAULT-VCARS" property values listed in the "VCALSTORE"
component, and a "CAR-MIN" implementation does not support the
creation or modification of "VCAR" components from the CUA.
記述: 値は「なにもの車」、「車分」、または「車の完全な1インチ」のリストからの1です。 「また、供給されて、当時の車の完全な1インチがそうである「車分」も利用可能である」なら。 "VCALSTORE"コンポーネント、および「車分」実装で記載された「デフォルト-VCARS」特性の値であるとサポートされただけである「車分」実装はクーアから"VCAR"コンポーネントの作成か変更をサポートしません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
car-level = "CAR-LEVEL" ":" other-params ":"
car-level-values
「車レベルは「車レベル」と等しい」:、」 「他のparams」:、」 車のレベル値
car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1"
/ other-levels )
車のレベル値の=(「なにもの車」/「車分」/、「/がもう一方で平らにする車の完全な1インチ)」
other-levels = ; Any name published in an RFC for a
; "CAR-LEVEL" property value.
他のレベル=。 aのためにRFCで発表されたどんな名前も。 "CAR-LEVEL"資産価値。
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
CAR-LEVEL:CAR-FULL-1
車レベル: 車完全な1
8.8. COMPONENTS Property
8.8. コンポーネントの特性
Property Name: COMPONENTS
特性の名: コンポーネント
Royer, et al. Experimental [Page 56] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [56ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Purpose: The property specifies a the list of components supported by
the endpoint.
目的: 特性はコンポーネントのリストが終点でサポートしたaを指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in a "VREPLY" component in
response to a "GET-CAPABILITY" command.
順応: aに対応して"VREPLY"コンポーネントで特性を指定できる、「能力を得る、」 命令してください。
Description: A comma-separated list of components that are supported
by the endpoint. A component that is not in the list sent from
the endpoint is not supported by that endpoint. Sending an
unsupported component results in unpredictable results. This
includes any components inside of other components (VALARM for
example). The recommended list is
"VCALSTORE,VCALENDAR,VREPLY,VAGENDA,
VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO,VALARM,
DAYLIGHT,STANDARD,VCAR,VRIGHT,VQUERY".
記述: 終点によってサポートされるコンポーネントのコンマで切り離されたリスト。 終点から送られたリストにないコンポーネントはその終点によってサポートされません。 サポートされないコンポーネントを送ると、予測できない結果はもたらされます。 これは他のコンポーネント(例えば、VALARM)のどんなコンポーネント内部も含んでいます。 お勧めのリストは「VCALSTORE、VCALENDAR、VREPLY、VAGENDA、VEVENT、VALARM、VTIMEZONE、VJOURNAL、VTODO、VALARM、日光、規格、VCAR、VRIGHT、VQUERY」です。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
components = "COMPONENTS" other-params ":" comp-list CRLF
;
; All of these MUST be supplied only once.
;
comp-list-req = "VCALSTORE" "," "VCALENDAR" "," "VTIMEZONE" ","
"VREPLY" "," "VAGENDA" "," "STANDARD" ","
"DAYLIGHT"
; At least one MUST be supplied. The same value
; MUST NOT occur more than once.
;
comp-list-min = ( "," "VEVENT")
/ ( "," "VTODO")
/ ( "," "VJOURNAL" )
; The same value MUST NOT occur
; more than once. If "VCAR" is supplied then
; "VRIGHT" must be supplied.
;
comp-list-opt = ( "," "VFREEBUSY" ) / ( "," "VALARM" )
/ ( "," "VCAR" ) / ( "," "VRIGHT" )
/ ( "," "VQUERY") / ( "," x-comp )
/ ( "," iana-comp )
;
comp-list = comp-list-req 1*3comp-list-min *(comp-list-opt)
「コンポーネントは「」 コンポーネントの他のparams」と等しいです」 コンピュータリストCRLF。 ; 一度だけこれらのすべてを供給しなければなりません。 ; 」 「コンピュータリストreqは"VCALSTORE"と等しい」"VCALENDAR"、」、」 "VTIMEZONE"、」、」 "VREPLY"、」、」 "VAGENDA"、」、」 「規格」、」、」 「日光」。 少なくとも供給しなければなりません。 同じ値。 NOTは一度より起こらなければなりませんか? ; コンピュータリスト分=、(「」、"VEVENT") /、(「」、"VTODO") /、(「」、"VJOURNAL")、。 同じ値は起こってはいけません。 一度より多くです。 その時"VCAR"を供給するなら。 "VRIGHT"を供給しなければなりません。 ; comp-list-opt = ( "," "VFREEBUSY" ) / ( "," "VALARM" ) / ( "," "VCAR" ) / ( "," "VRIGHT" ) / ( "," "VQUERY") / ( "," x-comp ) / ( "," iana-comp ) ; コンピュータリスト=コンピュータリストreq1*3comp-リスト分*(コンピュータリストは選ばれます)です。
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
Royer, et al. Experimental [Page 57] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [57ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
COMPONENTS:VCALSTORE,VCALENDAR,VREPLY,VAGENDA,
VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO,
DAYLIGHT,STANDARD,VFREEBUSY,VCAR,VRIGHT,VQUERY
コンポーネント: VCALSTORE、VCALENDAR、VREPLY、VAGENDA、VEVENT、VALARM、VTIMEZONE、VJOURNAL、VTODO、日光、規格、VFREEBUSY、VCAR、VRIGHT、VQUERY
8.9. CSID Property
8.9. CSIDの特性
Property Name: CSID
特性の名: CSID
Purpose: The property specifies a globally unique identifier for the
calendar store.
目的: 特性はカレンダー店のためのグローバルにユニークな識別子を指定します。
Value Type: URI
タイプを評価してください: URI
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in a "VCALSTORE"
component.
順応: "VCALSTORE"コンポーネントで特性を指定できます。
Description: The identifier MUST be globally unique. Each CS needs
its own unique identifier. The "CSID" property is the official
unique identifier for the CS. If the BEEP 'serverName' attribute
was supplied in the BEEP 'start' message, then the CSID will be
mapped to the virtual host name supplied, and the host name part
of the CSID MUST be the same as the 'serverName' value. This
allows one CS implementation to service multiple virtual hosts.
CS's are not required to support virtual hosting. If a CS does
not support virtual hosting, then it must ignore the BEEP
'serverName' attribute.
記述: 識別子はグローバルにユニークでなければなりません。 各CSはそれ自身のユニークな識別子を必要とします。 "CSID"の特性はCsのための公式のユニークな識別子です。 '始めBEEP'メッセージでBEEP'serverName'属性を供給したなら、供給という仮想のホスト名、および部分というホスト名にCSIDを写像するでしょう。CSID MUSTでは、'serverName'値と同じにしてください。 これは、複数の事実上のホストにサービスを提供するために1つのCS実装を許容します。 CSのものは仮想の接待をサポートする必要はありません。 CSが仮想の接待をサポートしないなら、それはBEEP'serverName'属性を無視しなければなりません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
csid = "CSID" other-params ":" capurl CRLF
「csidは"CSID"とparamsである状態で他の等しい」:、」 capurl CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
CSID:cap://calendar.example.com
CSID: 上限://calendar.example.com
8.10. DECREED Property
8.10. 命じられた特性
Property Name: DECREED
特性の名: 命じられます。
Purpose: This property specifies if an access right calendar
component is decreed or not.
目的: この特性は、アクセス権カレンダーコンポーネントが命じられるかどうか指定します。
Value Type: BOOLEAN
タイプを評価してください: 論理演算子
Royer, et al. Experimental [Page 58] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [58ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property MAY be specified once in a "VCAR"
component.
順応: この特性は"VCAR"コンポーネントで一度指定されるかもしれません。
Description: This property is used in the "VCAR" component to specify
whether the component is decreed or not. If the "DECREED"
property value is "TRUE" then the CUA will be unable to change the
contents of the "VCAR" component and any attempt will fail with an
error.
記述: この特性は、コンポーネントが命じられるかどうか指定するのに"VCAR"コンポーネントに使用されます。 「命じられた」資産価値が「本当である」なら、クーアは"VCAR"コンポーネントのコンテンツを変えることができないでしょう、そして、誤りに応じて、どんな試みも失敗するでしょう。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
decreed = "DECREED" other-params ":" boolean CRLF
「命じられて、=は「」 他のparamsを命じました」」 論理演算子CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
DECREED:TRUE
命じられる:、本当
8.11. DEFAULT-CHARSET Property
8.11. デフォルト-CHARSETの特性
Property Name: DEFAULT-CHARSET
特性の名: デフォルト-CHARSET
Purpose: This property indicates the default charset.
目的: この特性はデフォルトcharsetを示します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VAGENDA" and
"VCALSTORE" calendar component.
順応: "VAGENDA"と"VCALSTORE"カレンダーコンポーネントでこの特性を指定できます。
Description: In a "VAGENDA" component this property is used to
indicate the charset of calendar. If not specified, the default
is the first value in the "VCALSTORE" components "DEFAULT-CHARSET"
property value list. The value MUST be an IANA registered
character set as defined in [CHARREG].
記述: "VAGENDA"コンポーネントでは、この特性は、カレンダーのcharsetを示すのに使用されます。 指定されないなら、デフォルトは"VCALSTORE"コンポーネント「デフォルト-CHARSET」資産価値リストで最初の値です。 値はIANAが[CHARREG]で定義されるように文字集合を登録したということでなければなりません。
In a "VCALSTORE" component it is a comma-separated list of charsets
supported by the CS. The first entry is the default entry for all
newly created "VAGENDA" components. The "UTF-8" value MUST be in
the "VCALSTORE" component "DEFAULT-CHARSET" property list. All
compliant
"VCALSTORE"コンポーネントでは、それはCsによってサポートされたcharsetsのコンマで切り離されたリストです。 初記入はすべての新たに作成された"VAGENDA"コンポーネントのためのデフォルトエントリーです。 「UTF-8インチの値が"VCALSTORE"コンポーネント「デフォルト-CHARSET」特性のリストにあるに違いありません。」 すべて言いなりになります。
CAP implementations (CS and CUA) MUST support at least the "UTF-8"
charset.
CAP実装(CSとクーア)は少なくとも「UTF-8インチのcharset」をサポートしなければなりません。
Royer, et al. Experimental [Page 59] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [59ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
If a charset name contains a comma (,), that comma must be
backslash-escaped in the value.
charset名がコンマを含んでいる、()、そのコンマは値でバックスラッシュで逃げなければなりません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
default-charset = "DEFAULT-CHARSET" other-params ":" text
*( "," text) CRLF
「デフォルト-charsetは「デフォルト-CHARSET」とparamsである状態で他の等しい」:、」 テキスト*、(「」、テキスト) CRLF
Example: The following is an example of this property for a "VAGENDA" component:
例: ↓これは"VAGENDA"コンポーネントのためのこの特性に関する例です:
DEFAULT-CHARSET:Shift_JIS,UTF-8
デフォルト-CHARSET: _JIS、UTF-8を移動させてください。
8.12. DEFAULT-LOCALE Property
8.12. デフォルト現場の特性
Property Name: DEFAULT-LOCALE
特性の名: デフォルト現場
Purpose: This property specifies the default language for text
values.
目的: この特性はテキスト値にデフォルト言語を指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VAGENDA" and
"VCALSTORE" components.
順応: "VAGENDA"と"VCALSTORE"コンポーネントでこの特性を指定できます。
Description: In a "VAGENDA" component, the "DEFAULT-LOCALE" property
is used to indicate the locale of the calendar. The full locale
SHOULD be used. The default and minimum locale is POSIX (aka the
'C' locale).
記述: "VAGENDA"コンポーネントでは、「デフォルト現場」の特性は、カレンダーの現場を示すのに使用されます。 現場SHOULDを洗い張りしてください。使用されます。 デフォルトと最小の現場はPOSIX(通称'C'現場)です。
In a "VCALSTORE" component, it is a comma-separated list of
locales supported by the CS. The first value in the list is the
default for all newly created VAGENDAs. "POSIX" MUST be in the
list.
"VCALSTORE"コンポーネントでは、それはCsによってサポートされた現場のコンマで切り離されたリストです。 リストにおける最初の値はすべての新たに作成されたVAGENDAsのためのデフォルトです。 "POSIX"がリストにあるに違いありません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
default-locale = "DEFAULT-LOCALE" other-params ":" language
*( "," language) CRLF
;
language = ; Text identifying a locale, as defined in [CHARPOL]
「デフォルト現場は「」 デフォルト現場の他のparams」と等しいです」 言語*、(「」、言語) CRLF。 言語=。 中で定義されるように現場を特定するテキスト[CHARPOL]
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
DEFAULT-LOCALE:en-US.iso-8859-1,POSIX
デフォルト現場: アン-US.iso-8859-1、POSIX
Royer, et al. Experimental [Page 60] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [60ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
8.13. DEFAULT-TZID Property
8.13. デフォルト-TZIDの特性
Property Name: DEFAULT-TZID
特性の名: デフォルト-TZID
Purpose: This property specifies the text value that specifies the
time zones.
目的: この特性は時間帯を指定するテキスト値を指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property may be specified once in a "VAGENDA" and
"VCALSTORE" components.
順応: この特性は"VAGENDA"と"VCALSTORE"コンポーネントで一度指定されるかもしれません。
Description: A multi-valued property that lists the known time zones.
The first is the default. Here "TZID" property values are the
same as the "TZID" property defined in [iCAL].
記述: 知られている時間帯を記載するマルチ評価された特性。 1番目はデフォルトです。 ここで、"TZID"特性の値は[iCAL]で定義された"TZID"の特性と同じです。
If used in a "VCALSTORE" component, it is a comma-separated list
of TZIDs known to the CS. The entry is used as the default TZID
list for all newly created calendars. The list MUST contain at
least "UTC". A "VCALSTORE" components MUST contain one
"VTIMEZONE" component for each value in the "DEFAULT-TZID"
property value.
"VCALSTORE"コンポーネントに使用されるなら、それはCsに知られているTZIDsのコンマで切り離されたリストです。 デフォルトTZIDがすべての新たに作成されたカレンダーのために記載するようにエントリーは使用されています。 リストは少なくとも"UTC"を含まなければなりません。 "VCALSTORE"コンポーネントは「デフォルト-TZID」資産価値における各値あたり1つの"VTIMEZONE"コンポーネントを含まなければなりません。
If used in a "VAGENDA" component, it is a comma-separated list of
"TZID" property values naming the time zones known to the
calendar. The first time zone in the list is the default and is
used as the localtime for objects that contain a date or date-time
value without a time zone. All "VAGENDA" components MUST have one
"VTIMEZONE" component contained for each value in the "DEFAULT-
TZID" property value.
"VAGENDA"コンポーネントに使用されるなら、それはカレンダーに知られている時間帯を命名する"TZID"特性の値のコンマで切り離されたリストです。 リストの初めてのゾーンは、デフォルトであり、時間帯なしで日付か日付時間的価値を含むオブジェクトにローカルタイムとして使用されます。 すべての"VAGENDA"コンポーネントで、「デフォルトTZID」資産価値における各値のために1つの"VTIMEZONE"コンポーネントを含んでいなければなりません。
If a "TZID" property value contains a comma (,), the comma must be
backslash-escaped.
"TZID"資産価値がコンマを含んでいる、()、コンマはバックスラッシュで逃げなければなりません。
Formal Definition: This property is defined by the following
notation:
公式の定義: この特性は以下の記法で定義されます:
default-tzid = "DEFAULT-TZID" other-params
":" [tzidprefix] text
*("," [tzidprefix] text) CRLF
;
txidprefix = ; As defined in [iCAL].
「デフォルト-tzidは「デフォルト-TZID」とparamsである状態で他の等しい」:、」 [tzidprefix]テキスト*、(「」、[tzidprefix] テキスト)CRLF。 txidprefix=。 [iCAL]で定義されるように。
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
Royer, et al. Experimental [Page 61] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [61ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
DEFAULT-TZID:US/Mountain,UTC
デフォルト-TZID: 米国/山、UTC
8.14. DEFAULT-VCARS Property
8.14. デフォルト-VCARSの特性
Property Name: DEFAULT-VCARS
特性の名: デフォルト-VCARS
Purpose: This property is used to specify the "CARID" property ids of
the default "VCAR" components for newly created "VAGENDA"
components.
目的: この特性は、デフォルト"VCAR"コンポーネントの"CARID"特性のイドを新たに作成された"VAGENDA"コンポーネントに指定するのに使用されます。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property MUST be specified in "VCALSTORE" calendar
component and MUST at least specify the following values:
"READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and
"DEFAULTOWNER".
順応: この特性は、"VCALSTORE"カレンダーコンポーネントで指定しなければならなくて、以下の値を少なくとも指定しなければなりません: "READBUSYTIMEINFO"、"REQUESTONLY"、「UPDATEPARTSTATUS」、および"DEFAULTOWNER"。
Description: This property is used in the "VCALSTORE" component to
specify the "CARID" value of the "VCAR" components that MUST be
copied into now "VAGENDA" components at creation time by the CS.
All "DEFAULT-VCAR" values must have "VCARS" components stored in
the "VCALSTORE".
記述: この特性は、作成時にCsで現在の"VAGENDA"コンポーネントにコピーしなければならない"VCAR"コンポーネントの"CARID"値を指定するのに"VCALSTORE"コンポーネントに使用されます。 すべての「デフォルト-VCAR」値で、"VCALSTORE"に「VCARS」コンポーネントを保存しなければなりません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
defautl-vcars = "DEFAULT-VCARS" other-params ":" text
*( "," text ) CRLF
「defautl-vcarsは「デフォルト-VCARS」とparamsである状態で他の等しい」:、」 テキスト*、(「」、テキスト) CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY,
UPDATEPARTSTATUS,DEFAULTOWNER
デフォルト-VCARS: READBUSYTIMEINFO、REQUESTONLY、UPDATEPARTSTATUS、DEFAULTOWNER
8.15. DENY Property
8.15. 特性を否定してください。
Property Name: DENY
特性の名: 否定します。
Purpose: This property identifies the UPN(s) being denied access in
the "VRIGHT" component.
目的: この特性は"VRIGHT"コンポーネントにおけるアクセスが拒絶されるUPN(s)を特定します。
Value Type: UPN-FILTER
タイプを評価してください: UPN-フィルタ
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Royer, et al. Experimental [Page 62] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [62ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Conformance: This property can be specified in "VRIGHT" components.
順応: "VRIGHT"コンポーネントでこの特性を指定できます。
Description: This property is used in the "VRIGHT" component to
define the CU or UG being denied access.
記述: この特性はCuを定義する"VRIGHT"コンポーネントかアクセサリーが否定されるUGで使用されます。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
deny = "DENY" other-params ":" upn-filter CRLF
「= 「」 他のparamsを否定してください」と否定してください」 upn-フィルタCRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
DENY:*
: *を否定してください。
DENY:bob@example.com
: bob@example.com を否定してください。
8.16. EXPAND property
8.16. EXPANDの特性
Property Name: EXPAND
特性の名: 広がってください。
Purpose: This property is used to notify the CS whether to expand any
component with recurrence rules into multiple instances, in a
query reply.
目的: この特性は再発に従ってどんなコンポーネントも広げるのが複数のインスタンスに統治されるか否かに関係なく、CSに通知するのに使用されます、質問回答で。
Value Type: BOOLEAN
タイプを評価してください: 論理演算子
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VQUERY" components.
順応: "VQUERY"コンポーネントでこの特性を指定できます。
Description: If a CUA wishes to see all of the instances of a
recurring component, the CUA sets EXPAND=TRUE in the "VQUERY"
component. If not specified, the default is "FALSE". Note that
if the CS has its "RECUR-EXPAND" CS property value set to "FALSE",
then the "EXPAND" property will be ignored and the result will be
as if the "EXPAND" value was set to "FALSE". The results will be
bounded by any date range or other limits in the query.
記述: CUAが再発コンポーネントのインスタンスのすべてを見たいなら、CUAは"VQUERY"コンポーネントにEXPAND=TRUEをはめ込みます。 指定されないなら、デフォルトは「誤っています」。 CSが注意したならそれに注意してください、それ、「再発、-広がってください、」 資産価値が「誤っていること」に設定するCs、次に、「広がってください」という特性は無視されるでしょう、そして、結果はまるで「広がってください」という値が「誤っていること」へのセットであるかのように無視されるでしょう。 結果は質問でどんな日付の範囲のそばでも境界があるか他の限界になるでしょう。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
expand = "EXPAND" other-params ":" ("TRUE" / "FALSE") CRLF
「=「広がってください」他のparamsを広げてください」:、」 (「本当である」か「誤っている」)です。 CRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
EXPAND:FALSE
EXPAND:TRUE
以下を虚偽で広げてください、そして、本当に以下を広げてください。
Royer, et al. Experimental [Page 63] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [63ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
8.17. GRANT Property
8.17. 交付金の特性
Property Name: GRANT
特性の名: 交付金
Purpose: This property identifies the UPN(s) being granted access in
the "VRIGHT" component.
目的: この特性は"VRIGHT"コンポーネントにおけるアクセスが承諾されるUPN(s)を特定します。
Value Type: UPN-FILTER
タイプを評価してください: UPN-フィルタ
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VRIGHT" calendar
components.
順応: "VRIGHT"カレンダーコンポーネントでこの特性を指定できます。
Description: This property is used in the "VRIGHT" component to
specify the CU or UG being granted access.
記述: この特性はCuを指定する"VRIGHT"コンポーネントかアクセサリーが与えられるUGで使用されます。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
grant = "GRANT" other-params ":" upn-filter CRLF
「=「」 交付金の他のparams」を与えてください」 upn-フィルタCRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
GRANT:*
交付金: *
GRANT:bob@example.com
交付金: bob@example.com
8.18. ITIP-VERSION Property
8.18. ITIP-バージョンの特性
Property Name: ITIP-VERSION
特性の名: ITIP-バージョン
Purpose: This property specifies the version of ITIP supported.
目的: この特性はサポートされたITIPのバージョンを指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property is specified in the "VREPLY" component
that is sent in response to a "GET-CAPABILITY" command.
順応: この特性がaに対応して送られる"VREPLY"コンポーネントで指定される、「能力を得る、」 命令してください。
Description: This specifies the version of ITIP that the endpoint
supports. The list is a comma-separated list of supported RFC
numbers. The list MUST contain at least 2446, which is [iTIP]
記述: これは終点がサポートするITIPのバージョンを指定します。 リストはサポートしているRFC番号のコンマで切り離されたリストです。 リストは少なくとも2446を含まなければならなくて、どれがありますか?[iTIP]
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
Royer, et al. Experimental [Page 64] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [64ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
itip-version = "ITIP-VERSION" other-params ":" text CRLF
「itip-バージョンは「」 ITIP-バージョンの他のparams」と等しいです」 テキストCRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
ITIP-VERSION:2446
ITIP-バージョン: 2446
8.19. MAX-COMP-SIZE Property
8.19. マックスコンピュータサイズの特性
Property Name: MAX-COMP-SIZE
特性の名: マックスコンピュータサイズ
Purpose: This property specifies the largest size of any object
accepted.
目的: この特性は受け入れられたどんなオブジェクトの最も大きいサイズも指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property is specified in the "VREPLY" component
that is sent in response to a "GET-CAPABILITY" command.
順応: この特性がaに対応して送られる"VREPLY"コンポーネントで指定される、「能力を得る、」 命令してください。
Description: A positive integer value that specifies the size of the
largest iCalendar object that can be accepted in octets. Objects
larger than this will be rejected. A value of zero (0) means no
limit. This is also the maximum value of any [BEEP] payload that
will be accepted or sent.
記述: 八重奏で受け入れることができる中で最も大きいiCalendarオブジェクトのサイズを指定する正の整数値。 これより大きいオブジェクトは拒絶されるでしょう。 (0)がない値は限界を全く意味しません。 また、これは受け入れるか、または送るどんな[BEEP]ペイロードの最大値です。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
max-comp-size = "MAX-COMP-SIZE" other-params ":" posint0 CRLF
「最大コンピュータサイズは「」 マックスコンピュータサイズの他のparams」と等しいです」 posint0 CRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
MAX-COMP-SIZE:1024
マックスコンピュータサイズ: 1024
8.20. MAXDATE Property
8.20. MAXDATEの特性
Property Name: MAXDATE
特性の名: MAXDATE
Purpose: This property specifies the date/time in the future, beyond
which the CS or CUA cannot represent.
目的: この特性は将来、向こうのCSかCUAが表すことができない日付/時間を指定します。
Value Type: DATE-TIME
タイプを評価してください: 日付-時間
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Royer, et al. Experimental [Page 65] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [65ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Conformance: The property can be specified in the "VCALSTORE"
component.
順応: "VCALSTORE"コンポーネントで特性を指定できます。
Description: The date and time MUST be a UTC value and end with 'Z'.
記述: 日時は、'Z'があるUTC値と終わりであるに違いありません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
maxdate = "MAXDATE" other-params ":" date-time CRLF
「maxdateは"MAXDATE"とparamsである状態で他の等しい」:、」 日付-時間CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
MAXDATE:20990101T000000Z
MAXDATE: 20990101T000000Z
8.21. MINDATE Property
8.21. MINDATEの特性
Property Name: MINDATE
特性の名: MINDATE
Purpose: This property specifies the date/time in the past, prior to
which the server cannot represent.
目的: この特性は過去の日付/時に指定します。(その時、サーバは表すことができません前)。
Value Type: DATE-TIME
タイプを評価してください: 日付-時間
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in the "VCALSTORE"
component.
順応: "VCALSTORE"コンポーネントで特性を指定できます。
Description: The date and time MUST be a UTC value and end with 'Z'.
記述: 日時は、'Z'があるUTC値と終わりであるに違いありません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
mindate = "MINDATE" other-params ":" date-time CRLF
「mindateは"MINDATE"とparamsである状態で他の等しい」:、」 日付-時間CRLF
date-time = ; As defined in [iCAL].
日付-時間=。 [iCAL]で定義されるように。
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
MINDATE:19710101T000000Z
MINDATE: 19710101T000000Z
8.22. MULTIPART Property
8.22. 複合特性
Property Name: MULTIPART
特性の名: 複合
Purpose: This property provides a comma-separated list of supported
MIME multipart types supported by the sender.
目的: この特性は送付者によってサポートされたサポートしているMIME複合タイプのコンマで切り離されたリストを提供します。
Royer, et al. Experimental [Page 66] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [66ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property is specified in the "VREPLY" component
that is sent in response to a "GET-CAPABILITY" command.
順応: この特性がaに対応して送られる"VREPLY"コンポーネントで指定される、「能力を得る、」 命令してください。
Description: This property is used in the in the "GET-CAPABILITY"
command reply to indicate the MIME multipart types supported. A
CS and CUA SHOULD support all registered MIME multipart types.
記述: この特性がコネに使用される、「能力を得る、」 回答が複合タイプがサポートしたMIMEを示すと命令してください。 CSとCUA SHOULDは、すべての登録されたMIMEが複合タイプであるとサポートします。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
multipart = "MULTIPART" other-params ":" text *( "," text) CRLF
「複合=「複合」の他のparams」:、」 テキスト*、(「」、テキスト) CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
MULTIPART:related,alternate,mixed
複合:、関連して、代替の、混ぜられる。
8.23. NAME Property
8.23. 名前の特性
Property Name: NAME
特性の名: 名前
Purpose: This property provides a localizable display name for a
component.
目的: この特性はローカライズ可能ディスプレイ名をコンポーネントに提供します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in a component.
順応: コンポーネントでこの特性を指定できます。
Description: This property is used in the component to specify a
localizable display name. If more than one "NAME" properties are
in a component, then they MUST have unique "LANG" parameters. If
the "LANG" parameter is not supplied, then it defaults to the
"VAGENDA" component's "DEFAULT-LOCALE" first value. If the
component is a "VAGENDA", then the default value is the "VAGENDA"s
component's "DEFAULT-LOCALE" first value. A "VCALSTORE"
component's "DEFAULT-LOCALE" first value is the default if the
component is stored at the "VCALSTORE" level.
記述: この特性は、ローカライズ可能ディスプレイ名を指定するのにコンポーネントに使用されます。 コンポーネントに1つ以上の「名前」の特性があるなら、それらには、ユニークな「ラング」パラメタがなければなりません。 「ラング」パラメタが提供されないなら、それは"VAGENDA"コンポーネントの「デフォルト現場」最初の値をデフォルトとします。 コンポーネントが"VAGENDA"であるなら、デフォルト値は「VAGENDA「sコンポーネント「デフォルト現場」最初の値」です。 コンポーネントが"VCALSTORE"レベルで保存されるなら、"VCALSTORE"コンポーネントの「デフォルト現場」最初の値はデフォルトです。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
Royer, et al. Experimental [Page 67] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [67ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
name = "NAME" nameparam ":" text CRLF
;
nameparam = other-params [ ";" languageparam ] other-params
;
languageparam = ; As defined in [iCAL].
「「」 名前nameparam」と=を命名してください」 テキストCRLF。 nameparamが他のparamsと等しい、[「; 」 languageparam] 他のparams。 languageparam=。 [iCAL]で定義されるように。
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
NAME:Restrict Guests From Creating VALARMs On VEVENTs
名前: VALARMsをVEVENTsに作成するので、ゲストを制限してください。
8.24. OWNER Property
8.24. 所有者の特性
Property Name: OWNER
特性の名: 所有者
Purpose: The property specifies an owner of the component.
目的: 特性はコンポーネントの所有者を指定します。
Value Type: UPN
タイプを評価してください: UPN
Property Parameters: Non-standard, alternate text representation and
language property parameters can be specified on this property.
特性のパラメタ: この所有地の上で標準的でない代替テキスト表現と言語特性のパラメタを指定できます。
Conformance: The property MUST be specified in a "VAGENDA" component.
順応: "VAGENDA"コンポーネントで特性を指定しなければなりません。
Description: A multi-instanced property indicating the calendar
owner.
記述: カレンダー所有者を示すマルチ例証された特性。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
owner = "OWNER" other-params ":" upn CRLF
「所有者は「」 所有者の他のparams」と等しいです」 upn CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
OWNER:jsmith@example.com
OWNER:jdough@example.com
所有者: jsmith@example.com 所有者: jdough@example.com
8.25. PERMISSION Property
8.25. 許可の特性
Property Name: PERMISSION
特性の名: 許可
Purpose: This property defines a permission that is granted or denied
in a "VRIGHT" component.
目的: この特性は"VRIGHT"コンポーネントで与えるか、または否定する許可を定義します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VRIGHT" components.
順応: "VRIGHT"コンポーネントでこの特性を指定できます。
Royer, et al. Experimental [Page 68] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [68ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Description: This property is used in the "VRIGHT" component to
define a permission that is granted or denied.
記述: この特性は、与えるか、または否定する許可を定義するのに"VRIGHT"コンポーネントに使用されます。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
permission = "PERMISSION" other-params ":" permvalue CRLF
;
permvalue = ( "SEARCH" / "CREATE" / "DELETE"
/ "MODIFY" / "MOVE" / all
/ iana-cmd / x-cmd )
;
all = "*"
;
iana-cmd = ; Any command registered by IANA directly or
; included in an RFC that may be applied as
; a command.
;
x-cmd = ; Any experimental command that starts with
; "x-" or "X-".
「許可は「」 許可の他のparams」と等しいです」 permvalue CRLF。 permvalueは(/が「作成する」か、「削除する」、「変更する」、または「動く」「検索」// iana-cmd / x-cmd)と等しいです。 すべてが「*」と等しいです。 iana-cmd=。 または、どんなコマンドもIANAによって直接登録された、。 適用されるかもしれないRFCでは、含まれています。 コマンド。 ; x-cmd=。 それが始まるどんな実験的なコマンドも。 「x」 または、「X。」
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
PERMISSION:SEARCH
許可: 探してください。
8.26. QUERY property
8.26. QUERYの特性
Property Name: QUERY
特性の名: 質問
Purpose: Specifies the query for the component.
目的: コンポーネントのための質問を指定します。
Value Type: CAL-QUERY
タイプを評価してください: カル-質問
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VQUERY" components.
順応: "VQUERY"コンポーネントでこの特性を指定できます。
Description: A "QUERY" is used to specify the "CAL-QUERY" (Section
6.1.1 for the query.
記述: 「質問」は、「カル-質問」を指定するのに使用されます。(質問のためのセクション6.1.1。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
query = "QUERY" other-params ":" cal-query CRLF
「=「」 質問の他のparams」について質問してください」 cal質問CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
QUERY:SELECT * FROM VEVENT
質問: VEVENTからの*を選択してください。
Royer, et al. Experimental [Page 69] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [69ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
8.27. QUERYID property
8.27. QUERYIDの特性
Property Name: QUERYID
特性の名: QUERYID
Purpose: Specifies a unique ID for a query in the targeted container.
目的: 狙っているコンテナでの質問に固有のIDを指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters are specified
on this property.
特性のパラメタ: 標準的でない特性のパラメタはこの所有地の上で指定されます。
Conformance: This property can be specified in "VQUERY" components.
順応: "VQUERY"コンポーネントでこの特性を指定できます。
Description: A "QUERYID" property is used to specify the unique id
for a query. A "QUERYID" property value is unique per container.
記述: "QUERYID"の特性は、ユニークなイドを質問に指定するのに使用されます。 "QUERYID"資産価値はコンテナ単位でユニークです。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
queryid = "QUERYID" other-params ":" text CRLF
「queryidは"QUERYID"とparamsである状態で他の等しい」:、」 テキストCRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
QUERYID:Any Text String
QUERYID:fetchUnProcessed
QUERYID: どんなテキスト文字列QUERYIDも: fetchUnProcessed
8.28. QUERY-LEVEL Property
8.28. 質問レベルの特性
Property Name: QUERY-LEVEL
特性の名: 質問レベル
Purpose: This property specifies the level of query supported.
目的: この特性はサポートされた質問のレベルを指定します。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in the "VREPLY" component
in response to a "GET-CAPABILITY" command.
順応: aに対応して"VREPLY"コンポーネントで特性を指定できる、「能力を得る、」 命令してください。
Description: Indicates level of query support. CAL-QL-NONE is for
CS's that allow ITIP methods only to be deposited and nothing
else.
記述: 質問サポートのレベルを示します。 カル-QL-NONEは単に預けられるべきITIPメソッドと他に何もを許容するCSのもののためのものです。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
query-level = "QUERY-LEVEL" other-params
":" ( "CAL-QL-1" / "CAL-QL-NONE") CRLF
「質問レベルは「」 質問レベルの他のparams」と等しいです」 (「カルQL、1インチ、/、「カルQL、なにも、」、)、」 CRLF
Royer, et al. Experimental [Page 70] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [70ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
QUERY-LEVEL:CAL-QL-1
質問レベル: カル-QL-1
8.29. RECUR-ACCEPTED Property
8.29. 再発、-受け入れた、特性
Property Name: RECUR-ACCEPTED
特性の名: 再発、-受け入れました。
Purpose: This property specifies if the endpoint supports recurring
instances.
目的: この特性は、終点が再発インスタンスをサポートするかどうか指定します。
Value Type: BOOLEAN
タイプを評価してください: 論理演算子
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in the "VREPLY" component
in response to a "GET-CAPABILITY" command.
順応: aに対応して"VREPLY"コンポーネントで特性を指定できる、「能力を得る、」 命令してください。
Description: Indicates if recurrence rules are supported. If "FALSE"
then the endpoint cannot process any kind of recurring rules.
記述: 再発規則がサポートされるかどうかを示します。 「誤っている」なら、終点はどんな種類の再発規則も処理できません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
recur-accepted = "RECUR-ACCEPTED" other-params ":" boolean CRLF
「再発、-、受諾、等しさ、「再発、-受け入れた、」 他のparams、」、:、」 論理演算子CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
RECUR-ACCEPTED:TRUE
RECUR-ACCEPTED:FALSE
再発、-受け入れた、:、本当である、再発、-受け入れた、: 偽
8.30. RECUR-LIMIT Property
8.30. 再発、-、限界、特性
Property Name: RECUR-LIMIT
特性の名: 再発、-、限界
Purpose: This property specifies the maximum number of instances the
endpoint will expand instances at query or storage time.
目的: この特性はインスタンスの最大数を指定します。終点は質問か蓄積時間にインスタンスを広げるでしょう。
Value Type: INTEGER
タイプを評価してください: 整数
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in the "VREPLY" component
in response to a "GET-CAPABILITY" command.
順応: aに対応して"VREPLY"コンポーネントで特性を指定できる、「能力を得る、」 命令してください。
Description: For implementations that have the "STORES-EXPANDED"
value set to "TRUE", this value specifies the maximum number of
記述: この値は、そうした実装のために「店で広げられた」値が「本当に」セットしたと最大数を指定します。
Royer, et al. Experimental [Page 71] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [71ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
instances that will be stored and fetched. For all
implementations, this is the maximum number of instances that will
be returned when the "EXPAND" parameter is specified as "TRUE" and
the results contain an infinite or large number of recurring
instances.
保存されて、とって来られるインスタンス。 すべての実装のために、これは「広がってください」というパラメタが「本当である」として指定されて、結果が無限か多くの再発インスタンスを含むとき返されるインスタンスの最大数です。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
recur-limit = "RECUR-LIMIT" other-params ":" posint1 CRLF
「再発、-、限界、等しさ、「再発、-、限界、」 他のparams、」、:、」 posint1 CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
RECUR-LIMIT:1000
再発、-、限界、: 1000
8.31. RECUR-EXPAND Property
8.31. 再発、-広がってください、特性
Property Name: RECUR-EXPAND
特性の名: 再発、-広がってください。
Purpose: This property specifies if the endpoint can expand
recurrences into multiple objects.
目的: この特性は、終点が複数のオブジェクトに再発を広げることができるかどうか指定します。
Value Type: BOOLEAN
タイプを評価してください: 論理演算子
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: The property can be specified in the "VREPLY" component
in response to a "GET-CAPABILITY" command.
順応: aに対応して"VREPLY"コンポーネントで特性を指定できる、「能力を得る、」 命令してください。
Description: If "TRUE", then the endpoint can expand an object into
multiple instances as defined by its recurrence rules when the
"EXPAND" property is supplied. If "FALSE", then the endpoint
ignores the "EXPAND" property.
記述: 「本当である」なら、終点は「広がってください」という資産を供給するとき、再発規則で定義するように複数のインスタンスにオブジェクトを広げることができます。 「誤っている」なら、終点は「広がってください」という特性を無視します。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
recur-expand = "RECUR-EXPAND" other-params ":" boolean CRLF
「再発、-広がってください、等しさ、「再発、-広がってください、」 他のparams、」、:、」 論理演算子CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
RECUR-EXPAND:TRUE
RECUR-EXPAND:FALSE
再発、-広がってください、:、本当である、再発、-広がってください、: 偽
8.32. RESTRICTION Property
8.32. 制限の特性
Property Name: RESTRICTION
特性の名: 制限
Royer, et al. Experimental [Page 72] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [72ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Purpose: This property defines restrictions on the result value of
new or existing components.
目的: この特性は新しいか既存のコンポーネントの結果値で制限を定義します。
Value Type: CAL-QUERY
タイプを評価してください: カル-質問
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VRIGHT" components,
but only when the "PERMISSION" property is set to "CREATE",
"MODIFY", or "*" property value.
順応: 「許可」の特性が「作成する」セット、「変更」、または「*」資産価値であるときにだけ、"VRIGHT"コンポーネントでこの特性を指定できます。
Description: This property is used in the "VRIGHT" component to
define restrictions on the components that can be written (i.e.,
by using the "CREATE" or "MOVE" commands) as well as on the values
that may take existent calendar store properties, calendar
properties, components, and properties (i.e., by using the
"MODIFY" command). Accepted values MUST match any specified
"RESTRICTION" property values.
記述: この特性は、書くことができる(すなわち、「作成」か「移行」コマンドを使用するのによる)コンポーネントの上と、そして、目下のカレンダー店資産、カレンダー資産、コンポーネント、および資産(すなわち、「変更」コマンドを使用するのによる)を取るかもしれない値の上で制限を定義するのに"VRIGHT"コンポーネントに使用されます。 受け入れられた値はどんな指定された「制限」特性の値にも合わなければなりません。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
restriction = "RESTRICTION" other-params ":" cal-query CRLF
「制限は「」 制限の他のparams」と等しいです」 cal質問CRLF
Example: The following are examples of this property:
例: ↓これはこの特性に関する例です:
RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'
制限: メソッドが'要求'と等しいVCALENDARからの*を選択してください。
RESTRICTION:SELECT * FROM VEVENT WHERE
SELF() IN ORGANIZER
制限: VEVENTからの*を選択してください、どこ、オーガナイザーという自己()
RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN
CATEGORIES
制限: カテゴリで'ビジネスである'ところでVEVENTからの*を選択してください。
8.33. SCOPE Property
8.33. 範囲の特性
Property Name: SCOPE
特性の名: 範囲
Purpose: This property identifies the objects in the CS to which the
access rights apply.
目的: この特性はアクセス権が申請されるCSでオブジェクトを特定します。
Value Type: CAL-QUERY
タイプを評価してください: カル-質問
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in "VRIGHT" components.
順応: "VRIGHT"コンポーネントでこの特性を指定できます。
Royer, et al. Experimental [Page 73] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [73ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Description: This property is used in the "VRIGHT" component to
define the set of objects, subject to the access right being
defined.
記述: この特性は、定義されるアクセス権を条件としてオブジェクトのセットを定義するのに"VRIGHT"コンポーネントに使用されます。
Formal Definition: The property is defined by the following notation:
公式の定義: 特性は以下の記法で定義されます:
scope = "SCOPE" other-params ":" cal-query CRLF
「範囲は「」 範囲の他のparams」と等しいです」 cal質問CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC'
範囲: クラスが'公衆'と等しいVEVENTからDTSTART、DTENDを選択してください。
8.34. STORES-EXPANDED Property
8.34. 店で拡張している特性
Property Name: STORES-EXPANDED
特性の名: 店で、広げられます。
Purpose: This property specifies if the sending endpoint expands
recurrence rules prior to storing them into the CS.
目的: この特性は、CSとしてそれらを保存する前に送付終点が再発規則を広げるかどうか指定します。
Value Type: BOOLEAN
タイプを評価してください: 論理演算子
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in a "VREPLY" component
in response to a "GET-CAPABILITY" command.
順応: aに対応して"VREPLY"コンポーネントでこの特性を指定できる、「能力を得る、」 命令してください。
Description: If the value is "TRUE", then the endpoint expands
recurrence rules and stores the results into the CS. If this is
"TRUE", then the "RECUR-LIMIT" property is significant because an
infinitely-recurring appointment will store no more than "RECUR-
LIMIT" property values into the CS and all other instances will be
lost.
記述: 値が「本当である」なら、終点は、再発規則を広げて、Csとして結果を保存します。 再発します。これがそうであるなら「本当に」、そして「再発、-、限界、無限に再発しているアポイントメントがいいえをさらに保存するので」 特性が重要である、「」 特性の値をCsに制限してください。そうすれば、他のすべてのインスタンスが失われるでしょう。
Formal Definition: The property is specified by the following
notation:
公式の定義: 特性は以下の記法で指定されます:
stores-expanded = "STORES-EXPANDED" other-params ":" boolean
CRLF
「店で拡張している=「店で広げられた」他のparams」:、」 論理演算子CRLF
The following is an example of this property:
↓これはこの特性に関する例です:
STORES-EXPANDED:TRUE
STORES-EXPANDED:FALSE
店で広げられる:、本当である、: 偽を店で広げます。
8.35. TARGET Property
8.35. 目標の特性
Property Name: TARGET
特性の名: 目標
Royer, et al. Experimental [Page 74] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [74ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Purpose: This property defines the container that the issued command
will act upon. Its value is a capurl, as defined in Section 5.
目的: この特性は発行されたコマンドが作用するコンテナを定義します。 値はセクション5で定義されるようにcapurlです。
Value Type: URI
タイプを評価してください: URI
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in a command component.
順応: コマンドコンポーネントでこの特性を指定できます。
Description: This property value is used to specify the container
that the command will effect. When used in a command, the command
will be performed on the container that has a capurl matching the
value.
記述: この資産価値は、コマンドが作用するコンテナを指定するのに使用されます。 コマンドに使用されると、コマンドはcapurlが値に合っているコンテナに実行されるでしょう。
Formal Definition: The property is specified by the following
notation:
公式の定義: 特性は以下の記法で指定されます:
target = "TARGET" other-params ":" ( capurl / relcalid ) CRLF
「=「」 目標の他のparams」を狙ってください」 (capurl / relcalid) CRLF
Example: The following is an example of this property:
例: ↓これはこの特性に関する例です:
TARGET:cap://mycal.example.com
TARGET:SomeRelCalid
目標: 上限://mycal.example.com目標: SomeRelCalid
8.36. TRANSP Property
8.36. TRANSPの特性
Property Name: TRANSP
特性の名: TRANSP
Purpose: This property defines whether a component is transparent or
not to busy-time searches. This is a modification to [iCAL]
"TRANSP" property, in that it adds some values.
目的: この特性は、コンポーネントが繁忙期検索に透明であるかどうかを定義します。 いくつかの値を加えるので、これは[iCAL]"TRANSP"の特性への変更です。
Value Type: TEXT
タイプを評価してください: テキスト
Property Parameters: Non-standard property parameters can be
specified on this property.
特性のパラメタ: この所有地の上で標準的でない特性のパラメタを指定できます。
Conformance: This property can be specified in a component.
順応: コンポーネントでこの特性を指定できます。
Description: Time Transparency is the characteristic of an object
that determines whether it appears to consume time on a calendar.
Objects that consume actual time for the individual or resource
associated with the calendar SHOULD be recorded as "OPAQUE",
allowing them to be detected by free-busy time searches. Other
objects, which do not take up the individual's (or resource's)
time SHOULD be recorded as "TRANSPARENT", making them invisible to
free/busy time searches.
記述: 時間Transparencyはそれがカレンダーの時間を費やすように見えるかどうか決定する目的の特性です。 「不透明なもの」として記録されるカレンダーSHOULDに関連している個人かリソースのための実際の時間を費やすオブジェクト、それらが自由な繁忙期によって検出されるのを許容するのを探されます。 他のオブジェクトが「透明である」として記録されて、自由であるか忙しい時間までそれらを目に見えなくするのは探されます。(オブジェクトは個人(または、リソースのもの)の時間SHOULDを取りません)。
Royer, et al. Experimental [Page 75] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [75ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Formal Definition: The property is specified by the following
notation:
公式の定義: 特性は以下の記法で指定されます:
transp = "TRANSP" other-params ":" transvalue CRLF
;
transvalue = "OPAQUE" ;Blocks or opaque on busy time searches.
「transpは"TRANSP"とparamsである状態で他の等しい」:、」 transvalue CRLF。 「移-値」は「不透明なもの」と等しいです; 繁忙期検索でのブロックか不透明なもの。
/ "TRANSPARENT"
; Transparent on busy time searches.
/「透明」。 繁忙期検索のときに、透明です。
/ "TRANSPARENT-NOCONFLICT"
; Transparent on busy time searches,
; and no other OPAQUE or OPAQUE-
; NOCONFLICT objects can overlap it.
;
/ "OPAQUE-NOCONFLICT"
; Opaque on busy time searches, and
; no other OPAQUE or OPAQUE-NOCONFLICT
; objects can overlap it.
;
; Default value is OPAQUE
/「透明なNOCONFLICT」。 繁忙期検索に透明。 他のものOPAQUEかOPAQUEでない。 NOCONFLICTオブジェクトはそれを重ね合わせることができます。 ; /「不透明なNOCONFLICT」。 そして、繁忙期に検索について不透明にしてください、。 他のOPAQUEでないOPAQUE-NOCONFLICTがありません。 オブジェクトはそれを重ね合わせることができます。 ; ; デフォルト値はOPAQUEです。
The following is an example of this property for an object that is
opaque or blocks on free/busy time searches, and no other object
can overlap it:
自由であるか忙しい時間でのブロックは探されます、そして、↓これは不透明なオブジェクトのためのこの特性に関する例であるか他のどんなオブジェクトもそれを重ね合わせることができません:
TRANSP:OPAQUE-NOCONFLICT
TRANSP: 不透明なNOCONFLICT
9. New Components
9. 新しいコンポーネント
9.1. VAGENDA Component
9.1. VAGENDAの部品
Component Name: VAGENDA
コンポーネント名: VAGENDA
Purpose: Provide a grouping of properties that defines an agenda.
目的: 議題を定義する特性の組分けを提供してください。
Formal Definition: There are two formats of the "VAGENDA" component.
(1) When it is being created, and (2) how it exists in the
"VCALSTORE" component.
公式の定義: "VAGENDA"コンポーネントの2つの形式があります。 (1) (2) それはいつ作成されていますか、そして、"VCALSTORE"コンポーネントでどう存在するか。
A "VAGENDA" component in a "VCALSTORE" component is defined by the
following notes and ABNF notation:
"VCALSTORE"コンポーネントにおける"VAGENDA"コンポーネントは以下の注意とABNF記法で定義されます:
CALSCALE - The value MUST be from the "VCALSTORE" "CALSCALE"
property list. The default is the first entry in the
VCALSTORE CALSCALE list.
CALSCALE--値は"VCALSTORE""CALSCALE"特性のリストから来ているに違いありません。 デフォルトはVCALSTORE CALSCALEリストで初記入です。
CREATED - The timestamp of the calendar's create date. This
CREATED--カレンダーのものに関するタイムスタンプは日付を作成します。 これ
Royer, et al. Experimental [Page 76] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [76ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
is a READ ONLY property in a "VAGENDA".
READは"VAGENDA"の特性にすぎませんか?
LAST-MODIFIED - The timestamp of any change to the "VAGENDA"
properties or when any component was last created, modified,
or deleted.
LAST-MODIFIED--何かコンポーネントがいつ"VAGENDA"の特性最後に作成されたか、変更されたか、または削除されたかへのどんな変化に関するタイムスタンプ。
agenda = "BEGIN" ":" "VAGENDA" CRLF
agendaprop
*(icalobject) ; as defined in [iCAL]
"END" ":" "VAGENDA" CRLF
「「始まってください」という議題=」:、」 "VAGENDA"CRLF agendaprop*(icalobject)。 「[iCAL]で定義されるように「終わってください」」:、」 "VAGENDA"CRLF
agendaprop = *(
; The following MUST occur exactly once.
;
allow-conflict / relcalid / calscale / created
/ default-charset / default-locale
/ default-tzid / last-mod
;
; The following MUST occur at least once.
; and the value MUST NOT be empty.
;
/ owner
;
; The following are optional,
; and MAY occur more than once.
;
/ name / related-to / other-props / x-comp
)
agendapropは*と等しいです。( ; 以下はまさに一度起こらなければなりません。 ; 最後のデフォルトconflict / relcalid / calscale /を許容している作成された/デフォルトデフォルト-charset/現場/tzid/モッズ。 ; 以下は少なくとも一度起こらなければなりません。 ; そして、値は空であるはずがありません。 ; /所有者。 ; 以下は任意です。 そして、一度より起こるかもしれません。 ; /名/関連している/x他の支柱/コンピュータ)
icalobject = ; As defined in [iCAL].
;
created = ; As defined in [iCAL].
;
related-to = ; As defined in [iCAL].
icalobject=。 [iCAL]で定義されるように。 ; =を作成します。 [iCAL]で定義されるように。 ; =に関連します。 [iCAL]で定義されるように。
When creating a VAGENDA, use the following notation:
VAGENDAを作成するときには、以下の記法を使用してください:
agendac = "BEGIN" ":" "VAGENDA" CRLF
agendacprop
*(icalobject) ; as defined in [iCAL].
"END" ":" "VAGENDA" CRLF
「agendacは「始まってください」と等しい」:、」 "VAGENDA"CRLF agendacprop*(icalobject)。 [iCAL]で定義されるように。 「「終わってください」」:、」 "VAGENDA"CRLF
agendacprop = *(
; The following MUST occur exactly once.
;
allow-conflict / relcalid / calscale
/ default-charset / default-locale
/ default-tzid
以下はまさに一度起こらなければなりません。agendacpropが*と等しい、(;闘争を許している/デフォルトデフォルトrelcalid/calscale/charset/現場/が-tzidにデフォルトである
Royer, et al. Experimental [Page 77] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [77ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
;
; The following MUST occur at least once.
; and the value MUST NOT be empty.
;
/ owner
;
; The following are optional,
; and MAY occur more than once.
;
/ name / related-to / other-props / x-comp
)
; ; 以下は少なくとも一度起こらなければなりません。 ; そして、値は空であるはずがありません。 ; /所有者。 ; 以下は任意です。 そして、一度より起こるかもしれません。 ; 名義の、または、関連している//x他の支柱/コンピュータ)
To fetch all of the properties from the targeted "VAGENDA" component but do not fetch any components, use:
狙っている"VAGENDA"コンポーネントから特性のすべてをとって来ますが、どんなコンポーネントもとって来ないように、以下を使用してください。
SELECT * FROM VAGENDA
VAGENDAからの*を選択してください。
To fetch all of the properties from the targeted VAGENDA and all of the contained components, use the special '*.*' value:
'狙っているVAGENDAからの特性のすべてと含まれたコンポーネントのすべてをとって来るには、特別番組を使用してください'という**'以下を評価してください。
SELECT *.* FROM VAGENDA
選んだ*VAGENDAからの*
9.2. VCALSTORE Component
9.2. VCALSTOREの部品
Component Name: VCALSTORE
コンポーネント名: VCALSTORE
Purpose: Provide a grouping of properties that defines a calendar
store.
目的: カレンダー店を定義する特性の組分けを提供してください。
Formal Definition: A "VCALSTORE" component is defined by the
following table and ABNF notation. The creation of a "VCALSTORE"
component is an administrative task and not part of the CAP
protocol.
公式の定義: "VCALSTORE"コンポーネントは以下のテーブルとABNF記法で定義されます。 "VCALSTORE"コンポーネントの作成は上限プロトコルの一部ではなく、管理業務です。
The following are notes to some of the properties in the
"VCALSTORE" component.
↓これは"VCALSTORE"コンポーネントにおけるいくつかの特性への注意です。
CALSCALE - A comma-separated list of CALSCALEs supported by
this CS. All "VAGENDA" component calendar CALSCALE
properties MUST be from this list. This list MUST contain
at least "GREGORIAN". The default for newly created
"VAGENDA" components is the first entry.
CALSCALE--このCSによってサポートされたCALSCALEsのコンマで切り離されたリスト。 すべての"VAGENDA"コンポーネントカレンダーCALSCALEの特性がこのリストから来ているに違いありません。 このリストは少なくとも「グレゴリオ」を含まなければなりません。 新たに作成された"VAGENDA"コンポーネントのためのデフォルトは初記入です。
RELATED-TO - This is a multiple-instance property. There MUST
be a "RELATED-TO" property for each of the "VAGENDA"
components contained in the "VCALSTORE" component, each with
the "RELTYPE" parameter value set to "CHILD". Other
"RELATED-TO" properties may be included.
関連TO--これは複数のインスタンスの特性です。 "VCALSTORE"コンポーネントに含まれたそれぞれの"VAGENDA"コンポーネントのための「関連された」という特性があるに違いありません、それぞれ「子供」への"RELTYPE"パラメタ選択値群で。 「関連された」という他の特性は含まれるかもしれません。
Royer, et al. Experimental [Page 78] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [78ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
CREATED - The timestamp of the CS creation time. This is a
READ ONLY property.
CREATED--CS作成時間に関するタイムスタンプ。 これはREAD ONLYの特性です。
CSID - The CSID of this calendar store. This MUST NOT be
empty. How this property is set in the VCALSTORE is an
administrative or implementation-specific issue and is not
covered in CAP. This is a READ ONLY property. A suggested
value is the fully-qualified host name or a fully-qualified
virtual host name supported by the system.
CSID--このカレンダー店のCSID。 これは空であるはずがありません。 この特性がVCALSTOREにどう設定されるかは、管理の、または、実装特有の問題であり、CAPでカバーされていません。 これはREAD ONLYの特性です。 提案された値は、完全に適切なホスト名かシステムによってサポートされた完全に適切な仮想のホスト名です。
LAST-MODIFIED - The timestamp when the Properties of the
"VCALSTORE" component were last updated or calendars were
created or deleted. This is a READ ONLY PROPERTY.
LAST-MODIFIED--"VCALSTORE"コンポーネントのPropertiesであるときに、タイムスタンプをアップデートしたか、またはカレンダーは、作成されたか、削除されました。 これはREAD ONLY PROPERTYです。
calstorec = "BEGIN" ":" "VCALSTORE" CRLF
calstoreprop
*(vagendac)
"END" ":" "VCALSTORE" CRLF
;
calstoreprop = *(
; the following MUST occur exactly once
;
allow-conflict / calscale / calmaster
/ created / csid / default-charset
/ default-locale / default-vcars
/ default-tzid / last-mod / maxdate / mindate
;
; the following are optional,
; and MAY occur more than once
;
/ name / related-to / other-props / x-comp
)
;
「calstorecは「始まってください」と等しい」:、」 「「」 CRLF calstoreprop*(vagendac)が「終わらせる」VCALSTORE」:」 "VCALSTORE"CRLF。 calstorepropは*と等しいです(;以下は、一度より任意であり、起こるかもしれません;、 /が/x他の支柱/コンピュータを以下はまさに一度起こらなければなりません; 最後のデフォルトデフォルトデフォルトconflict / calscale / calmaster /を許容している作成された/ csid / default-charset/現場/vcars/tzid/モッズ/maxdate/mindate、命名したか、または関連した )。
vagendac = ; As defined in [iCAL].
;
last-mod = ; As defined in [iCAL].
vagendac=。 [iCAL]で定義されるように。 ; 最後のモッズ=。 [iCAL]で定義されるように。
To fetch all of the properties from the targeted VCALSTORE and not fetch the calendars that it contains, use:
狙っているVCALSTOREから特性のすべてをとって来て、それが含むカレンダーはとって来ないように、以下を使用してください。
SELECT * FROM VCALSTORE
VCALSTOREからの*を選択してください。
To fetch all of the properties from the targeted "VCALSTORE" component and all of the contained calendars and all of those calendars' contained properties and components, use the special '*.*' value:
'狙っている"VCALSTORE"コンポーネントからの特性のすべて、含まれたカレンダーのすべて、およびそれらのカレンダーの含まれた特性とコンポーネントのすべてをとって来るには、特別番組を使用してください'という**'以下を評価してください。
Royer, et al. Experimental [Page 79] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [79ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
SELECT *.* FROM VCALSTORE
選んだ*VCALSTOREからの*
9.3. VCAR Component
9.3. VCARの部品
Component Name: VCAR
コンポーネント名: VCAR
Purpose: Provide a grouping of calendar access rights.
目的: カレンダーアクセス権の組分けを提供してください。
Formal Definition: A "VCAR" component is defined by the following
notation:
公式の定義: "VCAR"コンポーネントは以下の記法で定義されます:
carc = "BEGIN" ":" "VCAR" CRLF
carprop 1*rightc
"END" ":" "VCAR" CRLF
;
carprop = 1*(
;
; 'carid' is REQUIRED,
; but MUST NOT occur more than once
;
carid /
;
; the following are OPTIONAL,
; and MAY occur more than once
;
name / decreed / other-props
)
「carcは「始まってください」と等しい」:、」 「「」 CRLF carprop1*rightcが「終わらせる」VCAR」:」 "VCAR"CRLF。 carprop=1*(;、;''一度よりcaridに、(REQUIREDは);NOTが一度より起こらなければならない;/をcaridします; ↓これがOPTIONALであるということであり、起こるかもしれません; 命じられるか他の名前/支柱)である
Description: A "VCAR" component is a grouping of properties, and
"VRIGHT" components, that represents access rights granted or
denied to UPNs.
記述: "VCAR"コンポーネントはUPNsに対して与えるか、または否定するアクセス権を表す特性、および"VRIGHT"コンポーネントの組分けです。
The "CARID" property specifies the local identifier for the "VCAR"
component. The "NAME" property specifies a localizable display
name.
"CARID"の特性は"VCAR"コンポーネントのためのローカルの識別子を指定します。 「名前」の特性はローカライズ可能ディスプレイ名を指定します。
Example: In the following example, the UPN "foo@example.com" is given
search access to the "DTSTART" and "DTEND" VEVENT properties. No
other access is specified:
例: 以下の例では、"DTSTART"と"DTEND"VEVENTの特性への検索アクセスをUPN" foo@example.com "に与えます。 他のアクセスは全く指定されません:
Royer, et al. Experimental [Page 80] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [80ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
BEGIN:VCAR
CARID:View Start and End Times
NAME:View Start and End Times
BEGIN:VRIGHT
GRANT:foo@example.com
PERMISSION:SEARCH
SCOPE:SELECT DTSTART,DTEND FROM VEVENT
END:VRIGHT
END:VCAR
始まってください: VCAR CARID: 回が命名する始めと端を見てください: 視点始めと終わりの回は始まります: VRIGHT交付金: foo@example.com 許可: 範囲を捜してください: VEVENTエンド: VRIGHTエンド: VCARからDTSTART、DTENDを選択してください。
In this example, all UPNs are given search access to "DTSTART" and
"DTEND" properties of VEVENT components. "All CUs and UGs" are
specified by the UPN value "*". Note that this enumerated UPN
value is not in quotes:
この例では、VEVENTの部品の"DTSTART"と"DTEND"の特性への検索アクセスをすべてのUPNsに与えます。 「すべてのCUsとUGs」はUPN値の「*」によって指定されます。 この列挙されたUPN値が引用文にないことに注意してください:
BEGIN:VCAR
CARID:ViewStartEnd2
NAME:View Start and End Times 2
BEGIN:VRIGHT
GRANT:*
PERMISSION:SEARCH
SCOPE:SELECT DTSTART,DTEND FROM VEVENT
END:VRIGHT
END:VCAR
始まってください: VCAR CARID: ViewStartEnd2名: 視点始めと終わりの回2は始まります: VRIGHT交付金: *許可: 範囲を捜してください: VEVENTエンド: VRIGHTエンド: VCARからDTSTART、DTENDを選択してください。
In these examples, full calendar access rights are given to the
CAL-OWNERS(), and a hypothetical administrator is given access
rights to specify calendar access rights. If no other rights are
specified, only these two UPNs can specify calendar access rights:
これらの例では、完全なカレンダーアクセス権をカル-OWNERS()に与えます、そして、カレンダーアクセス権を指定するために仮定している管理者にアクセス権を与えます。 他の権利が全く指定されないなら、これらの2UPNsだけがカレンダーアクセス権を指定できます:
BEGIN:VCAR
CARID:some-id-3
NAME:Only OWNER or ADMIN Settable VCARs
BEGIN:VRIGHT
GRANT:CAL-OWNERS()
PERMISSION:*
SCOPE:SELECT * FROM VAGENDA
END:VRIGHT
BEGIN:VRIGHT
GRANT:cal-admin@example.com
PERMISSION:*
SCOPE:SELECT * FROM VCAR
RESTRICTION:SELECT * FROM VCAR
END:VRIGHT
END:VCAR
始まってください: VCAR CARID: 何らかのイド3名: 所有者かアドミンSettable VCARsだけが始まります: VRIGHT交付金: カル所有者()PERMISSION: *。範囲: VAGENDAエンドからの選んだ*: VRIGHTは始まります: VRIGHT交付金: cal-admin@example.com 許可: *範囲: VCAR制限: VCARエンド: VRIGHTエンド: VCARからの選んだ*からの選んだ*
In this example, rights to write, search, modify or delete
calendar access are denied to all UPNs. This example would
この例では、カレンダーアクセスを書くか、捜すか、変更するか、または削除する権利はすべてのUPNsに対して否定されます。 この例はそうするでしょう。
Royer, et al. Experimental [Page 81] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [81ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
disable providing different access rights to the calendar store or
calendar. This calendar access right should be specified with
great care, as it removes the ability to change calendar access;
even for the owner or administrator. It could be used by small
devices that do not support changing any VCAR:
提供が異なったアクセス権であるとカレンダー店かカレンダーに無効にしてください。 カレンダーアクセスを変える能力を取り除くとき、このカレンダーアクセス権は細心の注意を払って指定されるべきです。 所有者か管理者のためにさえ。 変化があらゆるVCARであるとサポートしない小さいデバイスはそれを使用できました:
BEGIN:VCAR
CARID:VeryRestrictiveVCAR-2
NAME:No CAR At All
BEGIN:VRIGHT
DENY:*
PERMISSION:*
SCOPE:SELECT * FROM VCAR
END:VRIGHT
END:VCAR
始まってください: : : 全くいいえ車が始めるVeryRestrictiveVCAR-2名: VRIGHTが否定するVCAR CARID: *許可: *範囲: VCARエンド: VRIGHTエンド: VCARからの選んだ*
9.4. VRIGHT Component
9.4. VRIGHTの部品
Component Name: "VRIGHT"
コンポーネント名: "VRIGHT"
Purpose: Provide a grouping of properties that describe an access
right (granted or denied).
Purpose: Provide a grouping of properties that describe an access right (granted or denied).
Formal Definition: A "VRIGHT" component is defined by the following
notation:
Formal Definition: A "VRIGHT" component is defined by the following notation:
rightc = "BEGIN" ":" "VRIGHT" CRLF
rightprop
"END" ":" "VRIGHT" CRLF
;
rightprop = 2*(
;
; either 'grant' or 'deny' MUST
; occur at least once
; and MAY occur more than once
;
grant / deny /
;
; 'permission' MUST occur at least once
; and MAY occur more than once
;
permission /
;
; the following are optional,
; and MAY occur more than once
;
scope / restriction / other-props
)
rightc = "BEGIN" ":" "VRIGHT" CRLF rightprop "END" ":" "VRIGHT" CRLF ; rightprop = 2*( ; ; either 'grant' or 'deny' MUST ; occur at least once ; and MAY occur more than once ; grant / deny / ; ; 'permission' MUST occur at least once ; and MAY occur more than once ; permission / ; ; the following are optional, ; and MAY occur more than once ; scope / restriction / other-props )
Royer, et al. Experimental [Page 82] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 82] RFC 4324 Calendar Access Protocol December 2005
Description: A "VRIGHT" component is a grouping of calendar access
right properties.
Description: A "VRIGHT" component is a grouping of calendar access right properties.
The "GRANT" property specifies the UPN that is being granted
access. The "DENY" property specifies the UPN that is being
denied access. The "PERMISSION" property specifies the actual
permission being set. The "SCOPE" property identifies the
calendar store properties, calendar properties, components, or
properties to which the access right applies. The "RESTRICTION"
property specifies restrictions on commands and results. If the
command does not match the restrictions, or if the results of the
command do not match the restrictions, then it is an access
violation.
The "GRANT" property specifies the UPN that is being granted access. The "DENY" property specifies the UPN that is being denied access. The "PERMISSION" property specifies the actual permission being set. The "SCOPE" property identifies the calendar store properties, calendar properties, components, or properties to which the access right applies. The "RESTRICTION" property specifies restrictions on commands and results. If the command does not match the restrictions, or if the results of the command do not match the restrictions, then it is an access violation.
9.5. VREPLY Component
9.5. VREPLY Component
Component Name: "VREPLY"
Component Name: "VREPLY"
Purpose: Provide a grouping of arbitrary properties and components
that are the data set result from an issued command.
Purpose: Provide a grouping of arbitrary properties and components that are the data set result from an issued command.
Formal Definition: A "VREPLY" component is defined by the following
notation:
Formal Definition: A "VREPLY" component is defined by the following notation:
replyc = "BEGIN" ":" "VREPLY" CRLF
any-prop-or-comp
"END" ":" "VREPLY" CRLF
;
any-prop-or-comp = ; Zero or more iana or experimental
; properties and components, in any order.
replyc = "BEGIN" ":" "VREPLY" CRLF any-prop-or-comp "END" ":" "VREPLY" CRLF ; any-prop-or-comp = ; Zero or more iana or experimental ; properties and components, in any order.
Description: Provide a grouping of arbitrary properties and
components that are the data set result from an issued command.
Description: Provide a grouping of arbitrary properties and components that are the data set result from an issued command.
A query can return a predictable set of arbitrary properties and
components. This component is used by query and other commands to
return data that does not fit into any other component. It may
contain any valid property or component, even if they are not
registered.
A query can return a predictable set of arbitrary properties and components. This component is used by query and other commands to return data that does not fit into any other component. It may contain any valid property or component, even if they are not registered.
9.6. VQUERY Component
9.6. VQUERY Component
Component Name: VQUERY
Component Name: VQUERY
Purpose: A component describes a set of objects to be acted upon.
Purpose: A component describes a set of objects to be acted upon.
Royer, et al. Experimental [Page 83] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 83] RFC 4324 Calendar Access Protocol December 2005
Formal Definition: A "VQUERY" component is defined by the following
notation:
Formal Definition: A "VQUERY" component is defined by the following notation:
queryc = "BEGIN" ":" "VQUERY" CRLF
queryprop
"END" ":" "VCAR" CRLF
;
queryprop = 1*(
;
; 'queryid' is OPTIONAL but MUST NOT occur
; more than once. If the "TARGET" property
; is supplied then the "QUERYID" property
; MUST be supplied.
;
queryid / target
;
; 'expand' is OPTIONAL but MUST NOT occur
; more than once.
;
expand
;
; the following are OPTIONAL, and MAY occur
; more than once
;
/ name / other-props
;
; the following MUST occur at least once if
; queryid is not supplied.
;
/ query
)
queryc = "BEGIN" ":" "VQUERY" CRLF queryprop "END" ":" "VCAR" CRLF ; queryprop = 1*( ; ; 'queryid' is OPTIONAL but MUST NOT occur ; more than once. If the "TARGET" property ; is supplied then the "QUERYID" property ; MUST be supplied. ; queryid / target ; ; 'expand' is OPTIONAL but MUST NOT occur ; more than once. ; expand ; ; the following are OPTIONAL, and MAY occur ; more than once ; / name / other-props ; ; the following MUST occur at least once if ; queryid is not supplied. ; / query )
Description: A "VQUERY" contains properties that describe which
properties and components the CS is requested to act upon.
Description: A "VQUERY" contains properties that describe which properties and components the CS is requested to act upon.
The "QUERYID" property specifies the local identifier for a
"VQUERY" component.
The "QUERYID" property specifies the local identifier for a "VQUERY" component.
For a search, if the "TARGET" property is supplied in a "VQUERY"
component, then the CS is to search for the query in the CALID
supplied by the "TARGET" property value.
For a search, if the "TARGET" property is supplied in a "VQUERY" component, then the CS is to search for the query in the CALID supplied by the "TARGET" property value.
For a create, the "TARGET" property MUST NOT be supplied because
the destination container is already supplied in the "TARGET"
property of the "VCALENDAR" component.
For a create, the "TARGET" property MUST NOT be supplied because the destination container is already supplied in the "TARGET" property of the "VCALENDAR" component.
Examples: see Section 6.1.1.
Examples: see Section 6.1.1.
Royer, et al. Experimental [Page 84] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 84] RFC 4324 Calendar Access Protocol December 2005
10. Commands and Responses
10. Commands and Responses
CAP commands and responses are described in this section.
CAP commands and responses are described in this section.
10.1. CAP Commands (CMD)
10.1. CAP Commands (CMD)
All commands are sent using the CMD property.
All commands are sent using the CMD property.
Property Name: CMD
Property Name: CMD
Purpose: This property defines the command to be sent.
Purpose: This property defines the command to be sent.
Value Type: TEXT
Value Type: TEXT
Property Parameters: Non-standard, id, localize, latency, action or
options.
Property Parameters: Non-standard, id, localize, latency, action or options.
Conformance: This property is the method used to specify the commands
to a CS; it can exist in any object sent to the CS.
Conformance: This property is the method used to specify the commands to a CS; it can exist in any object sent to the CS.
Description: All of the commands to the CS are supplied in this
property. The "OPTIONS" parameter is overloaded and its meaning
is dependent on the CMD value supplied.
Description: All of the commands to the CS are supplied in this property. The "OPTIONS" parameter is overloaded and its meaning is dependent on the CMD value supplied.
Formal Definition: The property is defined by the following
notation:
Formal Definition: The property is defined by the following notation:
cmd = "CMD" (
abort-cmd
/ continue-cmd
/ create-cmd
/ delete-cmd
/ generate-uid-cmd
/ get-capability-cmd
/ identify-cmd
/ modify-cmd
/ move-cmd
/ reply-cmd
/ search-cmd
/ set-locale-cmd
/ iana-cmd
/ x-cmd
) CRLF
;
option-value = "OPTION" "=" paramtext
;
paramtext ; As defined in [iCAL].
cmd = "CMD" ( abort-cmd / continue-cmd / create-cmd / delete-cmd / generate-uid-cmd / get-capability-cmd / identify-cmd / modify-cmd / move-cmd / reply-cmd / search-cmd / set-locale-cmd / iana-cmd / x-cmd ) CRLF ; option-value = "OPTION" "=" paramtext ; paramtext ; As defined in [iCAL].
Royer, et al. Experimental [Page 85] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 85] RFC 4324 Calendar Access Protocol December 2005
Calendaring commands allow a CUA to directly manipulate a calendar.
Calendaring commands allow a CUA to directly manipulate a calendar.
Calendar access rights can be granted or denied for any commands.
Calendar access rights can be granted or denied for any commands.
10.1.1. Bounded Latency
10.1.1. Bounded Latency
A CAP command can have an associated maximum latency time by specifying the "LATENCY" parameter. If the command is unable to be completed in the specified amount of time (as specified by the "LATENCY" parameter value with an "ACTION" parameter set to the "ASK" value), then a "TIMEOUT" command MUST be sent on the same channel". The reply MUST be a an "ABORT" or a "CONTINUE" command. If the CUA initiated the original command, then the CS would issue the "TIMEOUT" command and the CUA would then have to issue an "ABORT" or "CONTINUE" command. If the CS initiated the original command then the CUA would have to issue the "TIMEOUT" and the CS would send the "ABORT" or "CONTINUE".
A CAP command can have an associated maximum latency time by specifying the "LATENCY" parameter. If the command is unable to be completed in the specified amount of time (as specified by the "LATENCY" parameter value with an "ACTION" parameter set to the "ASK" value), then a "TIMEOUT" command MUST be sent on the same channel". The reply MUST be a an "ABORT" or a "CONTINUE" command. If the CUA initiated the original command, then the CS would issue the "TIMEOUT" command and the CUA would then have to issue an "ABORT" or "CONTINUE" command. If the CS initiated the original command then the CUA would have to issue the "TIMEOUT" and the CS would send the "ABORT" or "CONTINUE".
Upon receiving an "ABORT" command, the command must then be terminated. Only the "ABORT", "TIMEOUT", "REPLY, and "CONTINUE" commands cannot be aborted. The "ABORT", "TIMEOUT", and "REPLY" commands MUST NOT have latency set.
Upon receiving an "ABORT" command, the command must then be terminated. Only the "ABORT", "TIMEOUT", "REPLY, and "CONTINUE" commands cannot be aborted. The "ABORT", "TIMEOUT", and "REPLY" commands MUST NOT have latency set.
Upon receiving a "CONTINUE" command the work continues as if it had not been delayed or stopped. Note that a new latency time MAY be included in a "CONTINUE" command indicating to continue the original command until the "LATENCY" parameter value expires or the results of the original command can be returned.
Upon receiving a "CONTINUE" command the work continues as if it had not been delayed or stopped. Note that a new latency time MAY be included in a "CONTINUE" command indicating to continue the original command until the "LATENCY" parameter value expires or the results of the original command can be returned.
Both the "LATENCY" parameter and the "ACTION" parameter MUST be supplied to any "CMD" property, or nether can be added to the "CMD" property. The "LATENCY" parameter MUST be set to the maximum latency time in seconds. The "ACTION" parameter accepts the following values: "ASK" and "ABORT" parameters.
Both the "LATENCY" parameter and the "ACTION" parameter MUST be supplied to any "CMD" property, or nether can be added to the "CMD" property. The "LATENCY" parameter MUST be set to the maximum latency time in seconds. The "ACTION" parameter accepts the following values: "ASK" and "ABORT" parameters.
If the maximum latency time is exceeded and the "ACTION" parameter is set to the "ASK" value, then "TIMEOUT" command MUST be sent. Otherwise, if the "ACTION" parameter is set to the "ABORT" value, then the command MUST be terminated and return a REQUEST-STATUS code of 2.0.3 for the original command.
If the maximum latency time is exceeded and the "ACTION" parameter is set to the "ASK" value, then "TIMEOUT" command MUST be sent. Otherwise, if the "ACTION" parameter is set to the "ABORT" value, then the command MUST be terminated and return a REQUEST-STATUS code of 2.0.3 for the original command.
If a CS can both start sending the reply to a command and guarantee that all of the results can be sent from a command (short of something like network or power failure) prior to the "LATENCY" timeout value, then the "LATENCY" time has not expired.
If a CS can both start sending the reply to a command and guarantee that all of the results can be sent from a command (short of something like network or power failure) prior to the "LATENCY" timeout value, then the "LATENCY" time has not expired.
Example:
Example:
Royer, et al. Experimental [Page 86] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 86] RFC 4324 Calendar Access Protocol December 2005
In this example the initiator asks for the listeners capabilities.
In this example the initiator asks for the listeners capabilities.
I: Content-Type: text/calendar
I:
I: BEGIN:VCALENDAR
I: VERSION:2.0
I: PRODID:The CUA's PRODID
I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY
I: END:VCALENDAR
I: Content-Type: text/calendar I: I: BEGIN:VCALENDAR I: VERSION:2.0 I: PRODID:The CUA's PRODID I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY I: END:VCALENDAR
# After 3 seconds
# After 3 seconds
L: Content-Type: text/calendar
L:
L: BEGIN:VCALENDAR
L: PRODID:-//someone's prodid
L: VERSION:2.0
L: CMD;ID=xyz12346:TIMEOUT
L: END:VCALENDAR
L: Content-Type: text/calendar L: L: BEGIN:VCALENDAR L: PRODID:-//someone's prodid L: VERSION:2.0 L: CMD;ID=xyz12346:TIMEOUT L: END:VCALENDAR
In order to continue and give the CS more time, the CUA would issue a "CONTINUE" command:
In order to continue and give the CS more time, the CUA would issue a "CONTINUE" command:
I: Content-Type: text/calendar
I:
I: BEGIN:VCALENDAR
I: VERSION:2.0
I: PRODID:-//someone's prodid
I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:CONTINUE
I: END:VCALENDAR
I: Content-Type: text/calendar I: I: BEGIN:VCALENDAR I: VERSION:2.0 I: PRODID:-//someone's prodid I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:CONTINUE I: END:VCALENDAR
L: Content-Type: text/calendar
L:
L: BEGIN:VCALENDAR
L: VERSION:2.0
L: PRODID:-//someone's prodid
L: CMD;ID=xyz12346:REPLY
L: BEGIN:VREPLY
L: REQUEST-STATUS:2.0.3;Continued for 3 more seconds
L: END:VREPLY
L: END:VCALENDAR
L: Content-Type: text/calendar L: L: BEGIN:VCALENDAR L: VERSION:2.0 L: PRODID:-//someone's prodid L: CMD;ID=xyz12346:REPLY L: BEGIN:VREPLY L: REQUEST-STATUS:2.0.3;Continued for 3 more seconds L: END:VREPLY L: END:VCALENDAR
Here the "2.0.3" status is returned because it is not an error, it is a progress status sent in reply to the "CONTINUE" command.
Here the "2.0.3" status is returned because it is not an error, it is a progress status sent in reply to the "CONTINUE" command.
To abort the command and not wait any further, issue an "ABORT" command:
To abort the command and not wait any further, issue an "ABORT" command:
Royer, et al. Experimental [Page 87] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 87] RFC 4324 Calendar Access Protocol December 2005
I: Content-Type: text/calendar
I:
I: BEGIN:VCALENDAR
I: VERSION:2.0
I: PRODID:-//someone's prodid
I: CMD;ID=xyz12346:ABORT
I: END:VCALENDAR
I: Content-Type: text/calendar I: I: BEGIN:VCALENDAR I: VERSION:2.0 I: PRODID:-//someone's prodid I: CMD;ID=xyz12346:ABORT I: END:VCALENDAR
# Which would result in a 2.0.3 reply.
# Which would result in a 2.0.3 reply.
L: Content-Type: text/calendar
L:
L: BEGIN:VCALENDAR
L: VERSION:2.0
L: PRODID:-//someone's prodid
L: CMD;ID=xyz12346:REPLY
L: BEGIN:VREPLY
L: REQUEST-STATUS:2.0.3;Aborted As Requested.
L: END:VREPLY
L: END:VCALENDAR
L: Content-Type: text/calendar L: L: BEGIN:VCALENDAR L: VERSION:2.0 L: PRODID:-//someone's prodid L: CMD;ID=xyz12346:REPLY L: BEGIN:VREPLY L: REQUEST-STATUS:2.0.3;Aborted As Requested. L: END:VREPLY L: END:VCALENDAR
If the "ACTION" value had been set to "ABORT", then the listner would send a "7.0" error on timeout in the reply to the command that initiated the command that timed out.
If the "ACTION" value had been set to "ABORT", then the listner would send a "7.0" error on timeout in the reply to the command that initiated the command that timed out.
10.2. ABORT Command
10.2. ABORT Command
CMD: ABORT
CMD: ABORT
Purpose: The "ABORT" command is sent to request that the named or the
only in-process command be aborted. Latency MUST not be supplied
with the "ABORT" command.
Purpose: The "ABORT" command is sent to request that the named or the only in-process command be aborted. Latency MUST not be supplied with the "ABORT" command.
Formal Definition: An "ABORT" command is defined by the following
notation:
Formal Definition: An "ABORT" command is defined by the following notation:
Royer, et al. Experimental [Page 88] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 88] RFC 4324 Calendar Access Protocol December 2005
abort-cmd = abortparam ":" "ABORT"
;
abortparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
abort-cmd = abortparam ":" "ABORT" ; abortparam = *( ; ; the following are optional, ; but MUST NOT occur more than once ; id-param / localize-param ; ; the following is optional, ; and MAY occur more than once ; / other-params )
The REPLY of any "ABORT" command is:
The REPLY of any "ABORT" command is:
abort-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops
abort-vreply
"END" ":" "VCALENDAR" CRLF
;
abort-vreply = "BEGIN" ":" "VREPLY" CRLF
rstatus
other-props
"END" ":" "VREPLY" CRLF
abort-reply = "BEGIN" ":" "VCALENDAR" CRLF calprops abort-vreply "END" ":" "VCALENDAR" CRLF ; abort-vreply = "BEGIN" ":" "VREPLY" CRLF rstatus other-props "END" ":" "VREPLY" CRLF
10.3. CONTINUE Command
10.3. CONTINUE Command
CMD: CONTINUE
CMD: CONTINUE
Purpose: The "CONTINUE" command is only sent after a "TIMEOUT"
command has been received to inform the other end of the session
to resume working on a command.
Purpose: The "CONTINUE" command is only sent after a "TIMEOUT" command has been received to inform the other end of the session to resume working on a command.
Formal Definition: A "CONTINUE" command is defined by the following
notation:
Formal Definition: A "CONTINUE" command is defined by the following notation:
continue-cmd = continueparam ":" "CONTINUE"
;
continueparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
continue-cmd = continueparam ":" "CONTINUE" ; continueparam = *( ; ; the following are optional, ; but MUST NOT occur more than once ; id-param / localize-param
Royer, et al. Experimental [Page 89] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 89] RFC 4324 Calendar Access Protocol December 2005
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following are optional,
; and MAY occur more than once
;
/ other-params
)
/ latency-param ; ; the following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. ; / action-param ; ; the following are optional, ; and MAY occur more than once ; / other-params )
The REPLY of any "CONTINUE" command is:
The REPLY of any "CONTINUE" command is:
continue-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops
continue-vreply
"END" ":" "VCALENDAR" CRLF
;
continue-vreply = "BEGIN" ":" "VREPLY" CRLF
rstatus
other-props
"END" ":" "VREPLY" CRLF
continue-reply = "BEGIN" ":" "VCALENDAR" CRLF calprops continue-vreply "END" ":" "VCALENDAR" CRLF ; continue-vreply = "BEGIN" ":" "VREPLY" CRLF rstatus other-props "END" ":" "VREPLY" CRLF
10.4. CREATE Command
10.4. CREATE Command
CMD: CREATE
CMD: CREATE
Purpose: The "CREATE" command is used to create one or more
iCalendar objects in the store in the "BOOKED" or "UNPROCESSED"
state.
Purpose: The "CREATE" command is used to create one or more iCalendar objects in the store in the "BOOKED" or "UNPROCESSED" state.
A CUA MAY send a "CREATE" command to a CS. The "CREATE" command
MUST be implemented by all CSs.
A CUA MAY send a "CREATE" command to a CS. The "CREATE" command MUST be implemented by all CSs.
The CS MUST NOT send a "CREATE" command to any CUA.
The CS MUST NOT send a "CREATE" command to any CUA.
Formal Definition: A "CREATE" command is defined by the following
notation and the hierarchy restrictions, as defined in Section
3.2:
Formal Definition: A "CREATE" command is defined by the following notation and the hierarchy restrictions, as defined in Section 3.2:
create-cmd = createparam ":" "CREATE"
;
createparam = *(
;
create-cmd = createparam ":" "CREATE" ; createparam = *( ;
Royer, et al. Experimental [Page 90] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 90] RFC 4324 Calendar Access Protocol December 2005
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
; the following are optional, ; but MUST NOT occur more than once ; id-param / localize-param / latency-param ; ; the following MUST occur exactly once and only ; when the latency-param has been supplied and ; MUST NOT be supplied if the latency-param is ; not supplied. ; / action-param ; ; the following is optional, ; and MAY occur more than once ; / other-params )
Response:
Response:
One iCalendar object per TARGET property MUST be returned.
One iCalendar object per TARGET property MUST be returned.
The REPLY of any "CREATE" command is limited to the restriction
tables defined in [iTIP] for iTIP objects, in addition to this
ABNF:
The REPLY of any "CREATE" command is limited to the restriction tables defined in [iTIP] for iTIP objects, in addition to this ABNF:
Royer, et al. Experimental [Page 91] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 91] RFC 4324 Calendar Access Protocol December 2005
create-reply = "BEGIN" ":" "VCALENDAR" CRLF
creply-props
1*(create-vreply)
"END" ":" "VCALENDAR" CRLF
create-reply = "BEGIN" ":" "VCALENDAR" CRLF creply-props 1*(create-vreply) "END" ":" "VCALENDAR" CRLF
;
create-vreply = "BEGIN" ":" "VREPLY" CRLF
created-id
rstatus
other-props
"END" ":" "VREPLY" CRLF
;
; Where the id is appropriate for the
; type of object created:
;
; VAGENDA = relcalid
; VALARM = sequence
; VCAR = carid
; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
; VQUERY = queryid
; VTIMEZONE = tzid
; x-comp = x-id
;
created-id = ( relcalid / carid / uid / queryid /
tzid / sequence / x-id)
;
tzid = ; As defined in [iCAL].
;
sequence = ; As defined in [iCAL].
;
uid = ; As defined in [iCAL].
;
x-id = ; An ID for an x-component.
;
creply-props = 4*(
; These are REQUIRED and MUST NOT occur
; more than once.
;
prodid /version / target / reply-cmd
;
; These are optional, and may occur more
; than once.
;
other-props )
; create-vreply = "BEGIN" ":" "VREPLY" CRLF created-id rstatus other-props "END" ":" "VREPLY" CRLF ; ; Where the id is appropriate for the ; type of object created: ; ; VAGENDA = relcalid ; VALARM = sequence ; VCAR = carid ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid ; VQUERY = queryid ; VTIMEZONE = tzid ; x-comp = x-id ; created-id = ( relcalid / carid / uid / queryid / tzid / sequence / x-id) ; tzid = ; As defined in [iCAL]. ; sequence = ; As defined in [iCAL]. ; uid = ; As defined in [iCAL]. ; x-id = ; An ID for an x-component. ; creply-props = 4*( ; These are REQUIRED and MUST NOT occur ; more than once. ; prodid /version / target / reply-cmd ; ; These are optional, and may occur more ; than once. ; other-props )
For a "CREATE" command, the "TARGET" property specifies the
containers where the components will be created.
For a "CREATE" command, the "TARGET" property specifies the containers where the components will be created.
Royer, et al. Experimental [Page 92] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 92] RFC 4324 Calendar Access Protocol December 2005
If the iCalendar object being created does not have a "METHOD"
property, then its state is "BOOKED" and it is not an [iTIP]
scheduling object. Use the "DELETE" command to set the state of
an object to the "DELETED" state (tagged for deletion). A CUA
cannot use the "CREATE" command to create an object in the
"DELETED" state.
If the iCalendar object being created does not have a "METHOD" property, then its state is "BOOKED" and it is not an [iTIP] scheduling object. Use the "DELETE" command to set the state of an object to the "DELETED" state (tagged for deletion). A CUA cannot use the "CREATE" command to create an object in the "DELETED" state.
If the intention is to book an [iTIP] object, then the "METHOD"
property MUST NOT be supplied. Otherwise, any [iTIP] object MUST
have a valid [iTIP] "METHOD" property value and it is a scheduling
request being deposited into the CS with its state set to
"UNPROCESSED".
If the intention is to book an [iTIP] object, then the "METHOD" property MUST NOT be supplied. Otherwise, any [iTIP] object MUST have a valid [iTIP] "METHOD" property value and it is a scheduling request being deposited into the CS with its state set to "UNPROCESSED".
Format Definition: ABNF for a "CREATE" object is:
Format Definition: ABNF for a "CREATE" object is:
create-object = "BEGIN" ":" "VCALENDAR" CRLF
; If 'calprops' contain the "METHOD" property
; then this 'create-object' component MUST
; conform to [iTIP] restrictions.
;
; calprops MUST include 'create-cmd'
;
calprops
other-props
1*(create-comp)
"END" ":" "VCALENDAR" CRLF
create-object = "BEGIN" ":" "VCALENDAR" CRLF ; If 'calprops' contain the "METHOD" property ; then this 'create-object' component MUST ; conform to [iTIP] restrictions. ; ; calprops MUST include 'create-cmd' ; calprops other-props 1*(create-comp) "END" ":" "VCALENDAR" CRLF
; NOTE: The 'VCALSTORE' component is not included in
; 'create-comp' as it is out of scope for CAP to create
; a new CS.
;
create-comp = agendac / carc / queryc
/ timezonec / freebusyc
/ eventc / todoc / journalc
/ iana-comp / x-comp
;
freebusyc = ; As defined in [iCAL].
;
eventc = ; As defined in [iCAL].
;
journalc = ; As defined in [iCAL].
;
timezonec = ; As defined in [iCAL].
;
todoc = ; As defined in [iCAL].
; NOTE: The 'VCALSTORE' component is not included in ; 'create-comp' as it is out of scope for CAP to create ; a new CS. ; create-comp = agendac / carc / queryc / timezonec / freebusyc / eventc / todoc / journalc / iana-comp / x-comp ; freebusyc = ; As defined in [iCAL]. ; eventc = ; As defined in [iCAL]. ; journalc = ; As defined in [iCAL]. ; timezonec = ; As defined in [iCAL]. ; todoc = ; As defined in [iCAL].
In the following example, two new top level "VAGENDA" components are created. Note that the "CSID" value of the server is
In the following example, two new top level "VAGENDA" components are created. Note that the "CSID" value of the server is
Royer, et al. Experimental [Page 93] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 93] RFC 4324 Calendar Access Protocol December 2005
cal.example.com, which is where the new "VAGENDA" components are going to be created.
cal.example.com, which is where the new "VAGENDA" components are going to be created.
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: PRODID:-//someone's prodid
C: VERSION:2.0
C: CMD;ID=creation01:CREATE
C: TARGET:cal.example.com
C: BEGIN:VAGENDA <- data for 1st new calendar
C: CALID:relcalz1
C: NAME;LANGUAGE=en_US:Bill's Soccer Team
C: OWNER:bill
C: CALMASTER:mailto:bill@example.com
C: TZID:US/Pacific
C: END:VAGENDA
C: BEGIN:VAGENDA <- data for 2nd new calendar
C: CALID:relcalz2
C: NAME;LANGUAGE=EN-us:Mary's personal calendar
C: OWNER:mary
C: CALMASTER:mailto:mary@example.com
C: TZID:US/Pacific
C: END:VAGENDA
C: END:VCALENDAR
C: Content-Type: text/calendar C: C: BEGIN:VCALENDAR C: PRODID:-//someone's prodid C: VERSION:2.0 C: CMD;ID=creation01:CREATE C: TARGET:cal.example.com C: BEGIN:VAGENDA <- data for 1st new calendar C: CALID:relcalz1 C: NAME;LANGUAGE=en_US:Bill's Soccer Team C: OWNER:bill C: CALMASTER:mailto:bill@example.com C: TZID:US/Pacific C: END:VAGENDA C: BEGIN:VAGENDA <- data for 2nd new calendar C: CALID:relcalz2 C: NAME;LANGUAGE=EN-us:Mary's personal calendar C: OWNER:mary C: CALMASTER:mailto:mary@example.com C: TZID:US/Pacific C: END:VAGENDA C: END:VCALENDAR
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=creation01:REPLY
S: TARGET:cal.example.com
S: BEGIN:VREPLY <- Reply for 1st calendar create
S: CALID:relcalz1
S: REQUEST-STATUS:2.0
S: END:REPLY
S: BEGIN:VREPLY <- Reply for 2nd calendar create
S: CALID:relcalz2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
S: Content-Type: text/calendar S: S: BEGIN:VCALENDAR S: VERSION:2.0 S: PRODID:-//someone's prodid S: CMD;ID=creation01:REPLY S: TARGET:cal.example.com S: BEGIN:VREPLY <- Reply for 1st calendar create S: CALID:relcalz1 S: REQUEST-STATUS:2.0 S: END:REPLY S: BEGIN:VREPLY <- Reply for 2nd calendar create S: CALID:relcalz2 S: REQUEST-STATUS:2.0 S: END:VREPLY S: END:VCALENDAR
To create a new component in multiple containers, simply name all
of the containers in the "TARGET" in the create command. A new
"VEVENT" component is created in two TARGET components. In this
example, the "VEVENT" component is one new [iTIP] "REQUEST" to be
To create a new component in multiple containers, simply name all of the containers in the "TARGET" in the create command. A new "VEVENT" component is created in two TARGET components. In this example, the "VEVENT" component is one new [iTIP] "REQUEST" to be
Royer, et al. Experimental [Page 94] RFC 4324 Calendar Access Protocol December 2005
Royer, et al. Experimental [Page 94] RFC 4324 Calendar Access Protocol December 2005
stored in two calendars. The results would be iCalendar objects
that conform to the [iTIP] replies as defined in [iTIP].
stored in two calendars. The results would be iCalendar objects that conform to the [iTIP] replies as defined in [iTIP].
This example shows two [iTIP] "VEVENT" components being created in
each of the two supplied "TARGET" properties. As it contains the
"METHOD" property, they will be stored in the "UNPROCESSED" state:
This example shows two [iTIP] "VEVENT" components being created in each of the two supplied "TARGET" properties. As it contains the "METHOD" property, they will be stored in the "UNPROCESSED" state:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=creation02:CREATE
C: METHOD:REQUEST
C: TARGET:relcalz1
C: TARGET:relcalz2
C: BEGIN:VEVENT
C: DTSTART:20030307T180000Z
C: UID:FirstInThisExample-1
C: DTEND:20030307T190000Z
C: SUMMARY:Important Meeting
C: END:VEVENT
C: BEGIN:VEVENT
C: DTSTART:20040307T180000Z
C: UID:SecondInThisExample-2
C: DTEND:20040307T190000Z
C: SUMMARY:Important Meeting
C: END:VEVENT
C: END:VCALENDAR
C: コンテントタイプ: テキスト/カレンダーC: C: : VCALENDAR Cを始めてください: バージョン: 2.0C: PRODID:、-、だれかの//prodid C: CMD; IDはcreation02と等しいです: Cを作成してください: 方法: Cを要求してください: 目標: relcalz1C: 目標: relcalz2C: : VEVENT Cを始めてください: DTSTART: 20030307T180000Z C: UID: FirstInThisExample-1C: DTEND: 20030307T190000Z C: 概要: 重要なミーティングC: 終わり: VEVENT C: : VEVENT Cを始めてください: DTSTART: 20040307T180000Z C: UID: SecondInThisExample-2C: DTEND: 20040307T190000Z C: 概要: 重要なミーティングC: 終わり: VEVENT C: 終わり: VCALENDAR
The CS sends the "VREPLY" commands in separate MIME objects, one
per supplied "TARGET" property value.
CSは別々のMIME物、供給された「目標」資産価値あたり1つで"VREPLY"コマンドを送ります。
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=creation02:REPLY
S: TARGET:relcalz1 <- 1st TARGET listed.
S: BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET.
S: UID:FirstInThisExample-1
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET.
S: UID:SecondInThisExample-2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: バージョン: 2.0秒間: PRODID:、-、だれかの//prodid S: CMD; IDはcreation02: 回答Sと等しいです: TARGET: <relcalz1の最初のTARGETは記載しました。 S: BEGIN: REPLY<はVEVENTが最初のTARGETで作成する1番目を代わって答えます。 S: UID: FirstInThisExample-1秒間: 要求状態: 2.0秒間: 終わり: VREPLY S: BEGIN: REPLY<は最初のTARGETで2番目のVEVENTかごを代わって答えます。 S: UID: SecondInThisExample-2秒間: 要求状態: 2.0秒間: 終わり: VREPLY
Royer, et al. Experimental [Page 95] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [95ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
S: END:VCALENDAR
S: 終わり: VCALENDAR
And the second reply for the 2nd TARGET:
第2TARGETのための2番目の回答:
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=creation02:REPLY
S: TARGET:relcalz2 <- 2nd TARGET listed
S: BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET.
S: UID:FirstInThisExample-1
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET.
S: UID:SecondInThisExample-2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: バージョン: 2.0秒間: PRODID:、-、だれかの//prodid S: CMD; IDはcreation02: 回答Sと等しいです: TARGET: relcalz2の<第2TARGETはSを記載しました: BEGIN: REPLY<はVEVENTが第2TARGETで作成する1番目を代わって答えます。 S: UID: FirstInThisExample-1秒間: 要求状態: 2.0秒間: 終わり: VREPLY S: BEGIN: REPLY<は第2TARGETで2番目のVEVENTかごを代わって答えます。 S: UID: SecondInThisExample-2秒間: 要求状態: 2.0秒間: 終わり: VREPLY S: 終わり: VCALENDAR
10.5. DELETE Command
10.5. 削除コマンド
CMD: DELETE
CMD: 削除します。
Purpose: The "DELETE" command physically removes the QUERY result
from the store or marks it for deletion.
目的: 「削除」コマンドは、店から質問結果を物理的に取り除くか、または削除のためにそれをマークします。
A CUA MAY send a "DELETE" command to a CS. The "DELETE" command
MUST be implemented by all CSs.
CUAは「削除」コマンドをCsに送るかもしれません。 すべてのCSsが「削除」コマンドを実行しなければなりません。
The CS MUST NOT send a "DELETE" command to any CUA.
CSは「削除」コマンドをどんなクーアにも送ってはいけません。
Formal Definition: A "DELETE" command is defined by the following
notation:
公式の定義: 「削除」コマンドは以下の記法で定義されます:
delete-cmd = deleteparam ":" "DELETE"
;
deleteparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
/ option-param "MARK"
;
「cmdを削除している=deleteparam」:、」 「削除します」。 deleteparamが*と等しい、(; ; 以下は、一度より任意ですが、起こってはいけません; paramを局所化するか、潜在paramであるかオプションparamなイド-param/「マーク」
Royer, et al. Experimental [Page 96] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [96ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
; The following MUST occur exactly once and
; only when the latency-param has been supplied.
; It MUST NOT be supplied if the latency-param
; is not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
; そして、以下がまさに一度起こらなければならない、。 潜在-paramを供給したときだけ。 ; 潜在-paramであるならそれを供給してはいけません。 供給されません。 ; /動作-param。 ; 以下は任意です。 そして、一度より起こるかもしれません。 /もう一方-params)
The "DELETE" command is used to delete calendars or components.
The included "VQUERY" component(s) specifies the container(s) to
delete.
「削除」コマンドは、カレンダーかコンポーネントを削除するのに使用されます。 含まれている"VQUERY"コンポーネントは削除する容器を指定します。
To mark a component for delete without physically removing it,
include the "OPTIONS" parameter with its value set to the "MARK"
value in order to alter its state to "DELETED".
物理的にそれを取り除くインクルードなしでaがコンポーネントであるとマークするのが「削除されること」に状態を変更するために選択値群で「オプション」パラメタを「マーク」値に削除します。
When components are deleted, only the top-most component
"REQUEST-STATUS" properties are returned. No "REQUEST-STATUS"
properties are returned for components inside of the selected
components. There MUST be one "VREPLY" component returned for
each object that is deleted or marked for delete. Note that if no
"VREPLY" components are returned, then nothing matched and nothing
was deleted.
コンポーネントを削除するとき、最も先端コンポーネント「要求状態」資産だけを返します。 「要求状態」資産を全く選択されたコンポーネントのコンポーネント内部に返しません。 それが削除されるか、またはマークされる各物のために返された1つの"VREPLY"コンポーネントがあるに違いありません。削除します。 "VREPLY"コンポーネントを全く返さないなら何も合わないで、また削除されなかったことに注意してください。
Restriction Table for the "REPLY" command for any "DELETE"
command.
「回答」のための制限Tableはどんな「削除」コマンドのためにも命令します。
delete-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops ; MUST include 'reply-cmd'
*(delete-vreply)
"END" ":" "VCALENDAR" CRLF
;
delete-vreply = "BEGIN" ":" "VREPLY" CRLF
deleted-id
rstatus
"END" ":" "VREPLY" CRLF
;
; Where the id is appropriate for the
; type of object deleted:
;
; VAGENDA = relcalid
; VCAR = carid
; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
「回答を削除している=は「始まる」:、」 "VCALENDAR"CRLF calprops。 「インクルードは''*(-vreplyに、削除する)「終わり」を回答してcmdしなければなりませんか?」」 "VCALENDAR"CRLF。 「-vreplyに=「始まり」を削除してください」:、」 「「」 CRLF削除されたイドrstatusが「終わらせる」VREPLY」:」 "VREPLY"CRLF。 ; イドが適切である、。 物のタイプは削除しました: ; ; VAGENDAはrelcalidと等しいです。 VCARはcaridと等しいです。 VEVENT、VFREEBUSY、VJOURNAL、VTODO=uid
Royer, et al. Experimental [Page 97] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [97ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
; VQUERY = queryid
; ALARM = sequence
; VTIMEZONE = tzid
; x-comp = x-id
; An instance = uid recurid
;
deleted-id = ( relcalid / carid / uid / uid recurid
/ queryid / tzid / sequence / x-id )
; VQUERYはqueryidと等しいです。 ALARMは系列と等しいです。 VTIMEZONEはtzidと等しいです。 x-コンピュータはx-イドと等しいです。 例はuid recuridと等しいです。 削除されたイド=(relcalid / carid / uid / uid recurid / queryid / tzid /x系列/イド)
Example: to delete a "VEVENT" component with "UID" value of
"abcd12345" from the calendar "relcalid-22" from the current CS:
例: "abcd12345"の"UID"値でカレンダーから"VEVENT"コンポーネントを削除する、「22インチをrelcalidする、現在のCs:、」
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: TARGET:relcalid-22
C: CMD;ID:"random but unique per CUA":DELETE
C: BEGIN:VQUERY
C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345'
C: END:VQUERY
C: END:VCALENDAR
C: コンテントタイプ: テキスト/カレンダーC: C: : VCALENDAR Cを始めてください: 目標: relcalid-22C: CMD; ID: 「無作為ですが、ユニーク1クーアあたり」: DELETE C: : VQUERY Cを始めてください: 質問: UIDが'abcd12345'Cと等しいVAGENDAからVEVENTを選択してください: 終わり: VQUERY C: 終わり: VCALENDAR
S: BEGIN:VCALENDAR
S: TARGET:relcalid-22
S: CMD;ID:"random but unique per CUA":REPLY
S: BEGIN:VREPLY
S: UID:abcd12345
S: : VCALENDAR Sを始めてください: 目標: relcalid-22秒間: CMD; ID: 「無作為ですが、ユニーク1クーアあたり」: REPLY S: : VREPLY Sを始めてください: UID: abcd12345
S: REQUEST-STATUS:3.0
S: END:VREPLY
S: END:VCALENDAR
S: 要求状態: 3.0秒間: 終わり: VREPLY S: 終わり: VCALENDAR
One or more iCalendar objects will be returned that contain
"REQUEST-STATUS" properties for the deleted components. More than
one component could have been deleted. Any booked component and
any number of unprocessed [iTIP] scheduling components that
matched the QUERY value in the above example will be returned.
Each unique "METHOD" property value that was deleted from the
store MUST be in a separate iCalendar object. This is because
only one "METHOD" property is allowed in a single "VCALENDAR"
BEGIN/END block.
削除されたコンポーネントのための「要求状態」の特性を含むあるiCalendar物を返すでしょう。 1つ以上のコンポーネントが削除されたかもしれません。 どんな予約しているコンポーネントと上記の例のQUERY値に合っていたいろいろな未加工の[iTIP]スケジューリングコンポーネントも返すでしょう。 店から削除されたそれぞれのユニークな「方法」資産価値が別々のiCalendar物にあるに違いありません。 これは特性が単一の"VCALENDAR"に許容されている1「方法」だけ、が/端ブロックを始めるからです。
10.6. GENERATE-UID Command
10.6. UIDを発生させているコマンド
CMD: GENERATE-UID
CMD: UIDを発生させます。
Purpose: The "GENERATE-UID" command returns one or more unique
identifiers that MUST be globally unique.
目的: 「UIDを発生させる、」 コマンドは1つ以上のグローバルにユニークでなければならないユニークな識別子を返します。
Royer, et al. Experimental [Page 98] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [98ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
The "GENERATE-UID" command MAY be sent to any CS. The "GENERATE-
UID" command MUST be implemented by all CSs.
「UIDを発生させる、」 どんなCsにもコマンドを送るかもしれません。 すべてのCSsが「UIDを発生させてください」というコマンドを実行しなければなりません。
The "GENERATE-UID" command MUST NOT be sent to a CUA.
「UIDを発生させる、」 コマンドをクーアに送ってはいけません。
Formal Definition: A "GENERATE-UID" command is defined by the
following notation:
公式の定義: 「UIDを発生させる、」 コマンドは以下の記法で定義されます:
generate-uid-cmd = genuidparam ":" "GENERATE-UID"
;
genuidparam = *(
;
; The following are optional,
; but MUST NOT occur more than once.
;
id-param
/ localize-param
/ latency-param
;
; The following MUST occur exactly once and
; only when the latency-param has been supplied.
; It MUST NOT be supplied if the latency-param
; is not supplied.
;
/ action-param
;
; The following is optional,
; and MAY occur more than once.
;
/ other-params
;
; The following MUST be supplied exactly once.
; The value specifies the number of UIDs to
; be returned.
;
/ option-param posint1
)
「uid-cmdを発生させている=genuidparam」:、」 「UIDを発生させる、」、。 genuidparamは*と等しいです。( ; ; 以下は任意です。 しかし、NOTは一度より起こらなければなりませんか? ; paramをイド-param/局所化している/潜在-param。 ; そして、以下がまさに一度起こらなければならない、。 潜在-paramを供給したときだけ。 ; 潜在-paramであるならそれを供給してはいけません。 供給されません。 ; /動作-param。 ; 以下は任意です。 そして、一度より起こるかもしれません。 ; /他のparams。 ; まさに一度以下を供給しなければなりません。 ; 値がUIDsの数を指定する、。 返してください。 ; /オプション-param posint1)
Response:
応答:
gen-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops ; Which MUST include 'reply-cmd'
1*(gen-vreply)
"END" ":" "VCALENDAR" CRLF
「回答に情報を得ている=は「始まる」:、」 "VCALENDAR"CRLF calprops。 「どれが'回答-cmd'1*(-vreplyに、情報を得る)「終わり」」を含まなければなりませんか?」 "VCALENDAR"CRLF
gen-vreply = "BEGIN" ":" "VREPLY" CRLF
1*(uid)
rstatus
「-vreplyに=「始まり」に情報を得てください」:、」 "VREPLY"CRLF1*(uid)rstatus
Royer, et al. Experimental [Page 99] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [99ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
"END" ":" "VREPLY" CRLF
{%%%IS THIS RIGHT%%%?]
「「終わってください」」:、」 "VREPLY"CRLF、%、%%、この正しい%が%%であるか、]
Example:
例:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=unique-per-cua-124;OPTIONS=5:GENERATE-UID
C: END:VCALENDAR
C: : VCALENDAR Cを始めてください: バージョン: 2.0C: PRODID:、-、だれかの//prodid C: CMD;、ID=ユニークである、-、cua-124; オプション=5: UIDを発生させているC: 終わり: VCALENDAR
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD;ID=unique-per-cua-124:REPLY
S: BEGIN:VREPLY
S: UID:20011121T120000Z-12340@cal.example.com
S: UID:20011121T120000Z-12341@cal.example.com
S: UID:20011121T120000Z-12342@cal.example.com
S: UID:20011121T120000Z-12343@cal.example.com
S: UID:20011121T120000Z-12344@cal.example.com
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: バージョン: 2.0秒間: PRODID:、-、だれかの//prodid S: CMD;、ID=ユニークである、-、cua-124: 回答S: : VREPLY Sを始めてください: UID: 20011121T120000Z-12340@cal.example.com S: UID: 20011121T120000Z-12341@cal.example.com S: UID: 20011121T120000Z-12342@cal.example.com S: UID: 20011121T120000Z-12343@cal.example.com S: UID: 20011121T120000Z-12344@cal.example.com S: 要求状態: 2.0秒間: 終わり: VREPLY S: 終わり: VCALENDAR
10.7. GET-CAPABILITY Command
10.7. 能力を得ているコマンド
CMD: GET-CAPABILITY
CMD: 能力を得ます。
Purpose: The "GET-CAPABILITY" command returns the capabilities of the
other end point of the session.
目的: 「能力を得る、」 コマンドはセッションのもう片方のエンドポイントの能力を返します。
A CUA MUST send a "GET-CAPABILITY" command to a CS after the
initial connection. A CS MUST send a "GET-CAPABILITY" command to
a CUA after the initial connection. The "GET-CAPABILITY" command
and reply MUST be implemented by all CSs and CUAs.
クーアがaを送らなければならない、「能力を得る、」 初期の接続の後にCsに命令してください。 CSがaを送らなければならない、「能力を得る、」 初期の接続の後にクーアに命令してください。 「能力を得る、」 すべてのCSsとCUAsはコマンドと回答を実行しなければなりません。
Formal Definition: A "GET-CAPABILITY" command is defined by the
following notation:
公式の定義: 「能力を得る、」 コマンドは以下の記法で定義されます:
get-capability-cmd = capabilityparam ":" "GET-CAPABILITY"
「能力cmdを手に入れている=capabilityparam」:、」 「能力を得る、」
capabilityparam = *(
capabilityparamが*と等しい、(
; the following are optional,
; but MUST NOT occur more than once
; 以下は任意です。 しかし、NOTは一度より起こらなければなりませんか?
Royer, et al. Experimental [Page 100] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [100ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
;
id-param / localize-param / latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
; paramをイド-param/局所化している/潜在-param。 ; 以下がまさに一度起こらなければならない、唯一です。 そして、潜在paramが供給された、。 潜在-paramが供給するなら、供給してはいけません。 供給されません。 ; /動作-param。 ; 以下は任意です。 そして、一度より起こるかもしれません。 /もう一方-params)
Response:
応答:
The "GET-CAPABILITY" command returns information about the
implementation at the other end of the session. The values
returned may differ depending on current user identify and the
security level of the connection.
「能力を得る、」 コマンドはセッションのもう一方の端のときに実現の情報を返します。 ユーザが特定する電流と接続のセキュリティー・レベルによって、返された値は異なるかもしれません。
Client implementations SHOULD NOT require any capability element
beyond those defined in this specification or future RFC
publications. They MAY ignore any nonstandard, experimental
capability elements. The "GET-CAPABILITY" reply may return
different results, depending on the UPN and if the UPN is
authenticated.
クライアント実現SHOULD NOTはこの仕様か将来のRFC刊行物で定義されたものを超えた能力要素を必要とします。 彼らはどんな標準的でなくて、実験している能力要素も無視するかもしれません。 「能力を得る、」 UPNとUPNが認証されるかどうかによって、回答は異なった結果を返すかもしれません。
When sending a reply to a "GET-CAPABILITY" command, all of these
MUST be supplied. The following properties are returned in
response to a "GET-CAPABILITY" command:
aに返信する、「能力を得る、」 コマンド、これらのすべてを供給しなければなりません。 aに対応して以下の資産を返す、「能力を得る、」 コマンド:
cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF
; The following properties may be in any order.
;
rodid
version
reply-cmd
other-props
「キャップ-vreplyは「始まってください」と等しい」:、」 "VCALENDAR"CRLF。 以下の特性は順不同であるかもしれません。 ; rodidのバージョンの回答-cmdの他の支柱
"BEGIN" ":" "VREPLY" CRLF
; The following properties may be in any order.
;
cap-version
car-level
components
「「始まる」:、」 "VREPLY"CRLF。 以下の特性は順不同であるかもしれません。 ; キャップバージョン車レベルコンポーネント
Royer, et al. Experimental [Page 101] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [101ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
stores-expanded
maxdate
mindate
itip-version
max-comp-size
multipart
query-level
recur-accepted
recur-expand
recur-limit
other-props
"END" ":" "VREPLY" CRLF
"END" ":" "VCALENDAR" CRLF
「店で拡張しているmaxdate mindate itip-バージョン最大コンピュータサイズ複合質問レベル、再発、-、受諾、再発、-広がってください、再発、-、限界、他の支柱が「終わる」、」、:、」 「「」 CRLFが「終わらせる」VREPLY」:」 "VCALENDAR"CRLF
Example:
例:
I: Content-Type: text/calendar
I:
I: BEGIN:VCALENDAR
I: VERSION:2.0
I: PRODID:-//someone's prodid
I: CMD;ID=unique-per-cua-125:GET-CAPABILITY
I: END:VCALENDAR
私: コンテントタイプ: テキスト/カレンダーI: 私: : VCALENDAR Iを始めてください: バージョン: 2.0 私、: PRODID:、-、だれかの//prodid I: CMD;、ID=ユニークである、-、cua-125: 能力を得ている私: 終わり: VCALENDAR
L: Content-Type: text/calendar
L:
L: BEGIN:VCALENDAR
L: VERSION:2.0
L: PRODID:-//someone's prodid
L: CMD;ID=unique-per-cua-125:REPLY
L: BEGIN:VREPLY
L: CAP-VERSION:1.0
L: PRODID:The CS prodid
L: QUERY-LEVEL:CAL-QL-1
L: CAR-LEVEL:CAR-FULL-1
L: MAXDATE:99991231T235959Z
L: MINDATE:00000101T000000Z
L: MAX-COMPONENT-SIZE:0
L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR,
L: VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY
L: ITIP-VERSION:2446
L: RECUR-ACCEPTED:TRUE
L: コンテントタイプ: テキスト/カレンダーL: L: : VCALENDAR Lを始めてください: バージョン: 2.0 L、: PRODID:、-、だれかの//prodid L: CMD;、ID=ユニークである、-、cua-125: 回答L: : VREPLY Lを始めてください: キャップバージョン: 1.0 L、: PRODID: CS prodid L: 質問レベル: カル-QL-1 L: 車レベル: 車完全な1のL: MAXDATE: 99991231T235959Z L: MINDATE: 00000101T000000Z L: マックスコンポーネントサイズ: 0 L、: コンポーネント: VCALENDAR、VTODO、VJOURNAL、VEVENT、VCAR、L: VALARM、VFREEBUSY、VTIMEZONE、規格、日光、VREPLY L: ITIP-バージョン: 2446年のL: 再発、-受け入れた、:、本当
Royer, et al. Experimental [Page 102] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [102ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
L: RECUR-EXPAND:TRUE
L: RECUR-LIMIT:0
L: STORES-EXPANDED:FALSE
L: X-INET-PRIVATE-COMMANDS:1.0
L: END:VREPLY
L: END:VCALENDAR
L: 再発、-広がってください、: 本当のL: 再発、-、限界、: 0、L: : 誤ったLを店で広げます: X-INETの個人的なコマンド: 1.0 L、: 終わり: VREPLY L: 終わり: VCALENDAR
10.8. IDENTIFY Command
10.8. 特定コマンド
CMD: IDENTIFY
CMD: 特定します。
Purpose: The "IDENTIFY" command allows the CUA to set a new identity
to be used for calendar access.
目的: 「特定」コマンドで、クーアは、新しいアイデンティティにカレンダーアクセサリーに使用されるように設定できます。
A CUA MAY send an "IDENTIFY" command to a CS. The "IDENTIFY"
command MUST be implemented by all CSs. A CS implementation MAY
reject all "IDENTIFY" commands.
CUAは「特定」コマンドをCsに送るかもしれません。 すべてのCSsが「特定」コマンドを実行しなければなりません。 CS実現はすべての「特定」コマンドを拒絶するかもしれません。
The CS MUST NOT send an "IDENTIFY" command to any CUA.
CSは「特定」コマンドをどんなクーアにも送ってはいけません。
Formal Definition: An "IDENTIFY" command is defined by the following
notation:
公式の定義: 「特定」コマンドは以下の記法で定義されます:
identify-cmd = identifyparam ":" "IDENTIFY"
;
identifyparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
;
; The value is the UPN of the requested
; identity. If option is not supplied it is
「cmdを特定している=identifyparam」:、」 「特定します」。 そして、identifyparamが*と等しい、(; ; 以下は任意です; しかし、一度より多く; paramを局所化するか、潜在イド-param/param;で起こってはいけません;、以下、まさに一度起こらなければならない、唯一、潜在-paramを供給した、; 潜在paramがあります; 供給していないなら; /動作-param;、供給してはいけません;、以下、一度より任意であり、起こるかもしれません; /もう一方-params、値は要求のUPNです; アイデンティティ、オプションが供給されないなら、それはそうです。
Royer, et al. Experimental [Page 103] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [103ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
; a request to return to the original
; authenticated identity.
;
/ option-param upn
)
; オリジナルに戻るという要求。 アイデンティティを認証しました。 ; /オプション-param upn)
Response:
応答:
A "REQUEST-STATUS" property wrapped in a "VREPLY" component with
only one of the following request-status codes:
特性が"VREPLY"コンポーネントで1だけで包装した以下の要求ステータスコードの「要求状態」:
2.0 Successful.
2.0 うまくいきます。
6.4 Identity not permitted. VCAR restriction.
6.4 アイデンティティは可能にしませんでした。 VCAR制限。
The CS determines, through an internal mechanism, if the credentials supplied at authentication permit the operation as the selected identity. If they do, the session assumes the new identity; otherwise, a security error is returned.
CSは、内部のメカニズムを通して認証で供給された信任状が選択されたアイデンティティとして操作を可能にするかどうか決定します。 そうするなら、セッションは新しいアイデンティティを仮定します。 さもなければ、セキュリティ誤りは返されます。
Example:
例:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY
C: END:VCALENDAR
C: コンテントタイプ: テキスト/カレンダーC: C: : VCALENDAR Cを始めてください: バージョン: 2.0C: PRODID:、-、だれかの//prodid C: CMD;、ID=ユニークである、-cua-999単位で; オプションはnewUserIdと等しいです: Cを特定してください: 終わり: VCALENDAR
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: BEGIN:VREPLY
S: REQUEST-STATUS:2.0;Request Approved
S: END:VREPLY
S: END:VCALENDAR
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: バージョン: 2.0秒間: PRODID:、-、だれかの//prodid S: : VREPLY Sを始めてください: 要求状態: 2.0; 要求はSを承認しました: 終わり: VREPLY S: 終わり: VCALENDAR
Or if denied:
または、否定されるなら:
Royer, et al. Experimental [Page 104] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [104ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: PRODID:-//someone's prodid
S: VERSION:2.0
S: BEGIN:VREPLY
S: REQUEST-STATUS:6.4;Request Denied
S: END:VREPLY
S: END:VCALENDAR
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: PRODID:、-、だれかの//prodid S: バージョン: 2.0秒間: : VREPLY Sを始めてください: 要求状態: 6.4; 要求はSを否定しました: 終わり: VREPLY S: 終わり: VCALENDAR
For the CUA to return to its original authenticated identity, the
OPTIONS parameter is omitted:
CUAがオリジナルの認証されたアイデンティティに戻るように、OPTIONSパラメタは省略されます:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD;ID=unique-per-cua-995:IDENTIFY
C: END:VCALENDAR
C: コンテントタイプ: テキスト/カレンダーC: C: : VCALENDAR Cを始めてください: バージョン: 2.0C: PRODID:、-、だれかの//prodid C: CMD;、ID=ユニークである、-cua-995単位で: Cを特定してください: 終わり: VCALENDAR
The CS may accept (2.0) or deny (6.4) the request to return to the original identity.
CSは(2.0)を受け入れるか、または(6.4) オリジナルのアイデンティティに戻るという要求を否定するかもしれません。
If a CS considers the "IDENTIFY" command an attempt to violate security, the CS MAY terminate the [BEEP] session without any further notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply.
CSが、「特定」コマンドがセキュリティに違反する試みであると考えるなら、「要求状態」6.4回答を送った後に、Csはクーアへの少しもさらなる予告なしで[ビープ音]セッションを終えるかもしれません。
10.9. MODIFY Command
10.9. 変更コマンド
CMD: MODIFY
CMD: 変更します。
Purpose: The "MODIFY" command is used to modify existing components.
目的: 「変更」コマンドは、既存のコンポーネントを変更するのに使用されます。
A CUA MAY send a "MODIFY" command to a CS. The "MODIFY" command
MUST be implemented by all CSs.
CUAは「変更」コマンドをCsに送るかもしれません。 すべてのCSsが「変更」コマンドを実行しなければなりません。
The CS MUST NOT send a "MODIFY" command to any CUA.
CSは「変更」コマンドをどんなクーアにも送ってはいけません。
Formal Definition: A "MODIFY" command is defined by the following
notation:
公式の定義: 「変更」コマンドは以下の記法で定義されます:
modify-cmd = modifyparam ":" "MODIFY"
;
modifyparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
「cmdを変更している=modifyparam」:、」 「変更します」。 modifyparamが*と等しい、(;、;以下は任意です; しかし、NOTが一度より起こらなければならない
Royer, et al. Experimental [Page 105] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [105ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
; paramをイド-param/局所化している/潜在-param。 ; 以下がまさに一度起こらなければならない、唯一です。 そして、潜在paramが供給された、。 潜在-paramが供給するなら、供給してはいけません。 供給されません。 ; /動作-param。 ; 以下は任意です。 そして、一度より起こるかもしれません。 /もう一方-params)
The "MODIFY" command is used to modify existing components. The
TARGET property specifies the calendars that contain the
components that are going to be modified.
「変更」コマンドは、既存のコンポーネントを変更するのに使用されます。 TARGETの特性は変更されたコンポーネントを含むカレンダーを指定します。
The format of the request is three components inside of
"VCALENDAR" component:
要求の形式は"VCALENDAR"コンポーネントの3コンポーネント内部です:
BEGIN:VCALENDAR
BEGIN:VQUERY
END:VQUERY
BEGIN:XXX
END:XXX
BEGIN:XXX
END:XXX
END:VCALENDAR
始まってください: VCALENDARは始まります: VQUERYは終わります: VQUERYは始まります: XXXは終わります: XXXは始まります: XXXは終わります: XXXは: VCALENDARを終わらせます。
The "VQUERY" component selects the components that are to be
modified.
"VQUERY"コンポーネントは変更されていることになっているコンポーネントを選択します。
The "XXX" above is a named component type (VEVENT, VTODO, ...).
Both the old and new components MUST be of the same type.
上の"XXX"は命名されたコンポーネント型(VEVENT、VTODO)です。 同じタイプには両方の古くて新しいコンポーネントがあるに違いありません。
The old-values is a component and the contents of that component
are going to change and may contain information that helps
uniquely identify the original component (SEQUENCE in the example
below). If the CS cannot find a component that matches the QUERY
and does not have at least all of the OLD-VALUES, then a 6.1 error
is returned.
古い値がコンポーネントであり、そのコンポーネントの内容は、変化して、オリジナルのコンポーネント(以下の例のSEQUENCE)を特定するのを唯一助ける情報を含むかもしれません。 CSがQUERYに合っているコンポーネントは見つけることができないで、少なくともOLD-VALUESのすべてを持っていないなら、6.1誤りは返されます。
Royer, et al. Experimental [Page 106] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [106ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
The new-values is a component of the same type as old-values and
new-values contains the new data for each selected component. Any
data that is in old-values and not in new-values is deleted from
the selected component. Any values in new-values that was not in
old-values is added to the component.
新しい値は古い値と新しい値と同じタイプの成分がそれぞれの選択されたコンポーネントのための新しいデータを含んでいるということです。 どんなデータも新しい値で削除されるのではなく、選択されたコンポーネントから古い値で削除されます。 それがいなかった新しい値の古い値では、コンポーネントに加えられますいずれも、評価する。
In this example, the "VEVENT" component with a "UID" property
value of 'unique-58' has the "LOCATION" property and "LAST-
MODIFIED" properties changed, the "VALARM" component with the
"SEQUENCE" property with a value of "3" has its "TRIGGER" property
disabled, the "X-LOCAL" property is removed from the "VEVENT"
component, and a "COMMENT" property is added.
この例では、'ユニークな58'の"UID"資産価値がある"VEVENT"コンポーネントは「3インチで「引き金」の特性を無効にします、そして、「X地方」の資産は"VEVENT"コンポーネントから取り外されます、そして、「コメント」の特性は言い足される」値と共に特性と「最後に変更された」特性が変えた「位置」、「系列」の特性がある"VALARM"コンポーネントを持っています。
Because "SEQUENCE" property is used to locate the "VALARM"
component in this example, both the old-values and the new-values
contain the "SEQUENCE" property with a value of "3". If the
"SEQUENCE" property were to be left out of new-values, it would
have been deleted.
「系列」の特性がこの例で"VALARM"コンポーネントの場所を見つけるのに使用されるので、古い値と新しい値の両方が「3インチ」の値がある「系列」の特性を含んでいます。 「系列」の特性が新しい値から残されることであったなら、それは削除されたでしょう。
Example:
例:
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: TARGET:my-cal
C: CMD:ID=unique-mod:MODIFY
C: BEGIN:VQUERY <- Query to select data set.
C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58'
C: END:VQUERY
C: BEGIN:VEVENT <- Start of old data.
C: LOCATION:building 3
C: LAST-MODIFIED:20020101T123456Z
C: X-LOCAL:some private stuff
C: BEGIN:VALARM
C: SEQUENCE:3
C: TRIGGER;RELATED=END:PT5M
C: END:VALARM
C: END:VEVENT <- End of old data.
C: BEGIN:VEVENT <- Start of new data.
C: LOCATION:building 4
C: LAST-MODIFIED:20020202T010203Z
C: COMMENT:Ignore global trigger.
C: BEGIN:VALARM
C: SEQUENCE:3
C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M
C: END:VALARM
C: コンテントタイプ: テキスト/カレンダーC: C: : VCALENDAR Cを始めてください: バージョン: 2.0C: PRODID:、-、だれかの//prodid C: 目標:、私、-、cal、C: CMD: IDはユニークなモッズと等しいです: Cを変更してください: BEGIN: VQUERY<データセットを選択するために、質問します。 C: 質問: UIDが'ユニークな58'Cと等しいVEVENTからの*を選択してください: 終わり: VQUERY C: BEGIN:VEVENT<古いデータの始まり。 C: 位置: 建てている3C: 最後に: 20020101T123456Z Cを変更します: X-LOCAL: ある個人的なものC: : VALARM Cを始めてください: 系列: 3C: 引き金; 終わり: =PT5M Cは関係づけました: 終わり: VALARM C: END:VEVENT<古いデータの終わり。 C: BEGIN:VEVENT<新しいデータの始まり。 C: 位置: 建てている4C: 最後に: 20020202T010203Z Cを変更します: COMMENT: グローバルな引き金を無視してください。 C: : VALARM Cを始めてください: 系列: 3C: 引き金; 以下を= 虚偽で可能にするのは終わり: =PT5M Cを関係づけました: 終わり: VALARM
Royer, et al. Experimental [Page 107] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [107ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
C: END:VEVENT <- End of new data.
C: END:VCALENDAR
C: END:VEVENT<新しいデータの終わり。 C: 終わり: VCALENDAR
The "X-LOCAL" property was not supplied in the new-values, so it
was deleted. The "LOCATION" property value was altered, as was
the "LAST-MODIFIED" value. The "VALARM" component with a
"SEQUENCE" property value of "3" had its "TRIGGER" property
disabled, and the "SEQUENCE" property value did not change so it
was not effected. The "COMMENT" property was added.
「X地方」の資産が新しい値で供給されなかったので、それは削除されました。 「位置」資産価値は「最後、変更された」値のように変更されました。 「3インチで「引き金」の特性を無効にして、「系列」資産価値が変化しなかったので、作用しなかった」、「系列」資産価値がある"VALARM"コンポーネント。 「コメント」の特性は加えられました。
When it comes to inline ATTACHMENTs, the CUA only needs to
uniquely identify the contents of the ATTACHMENT value in the
old-values in order to delete them. When the CS compares the
attachment data, it is compared in its binary form. The
ATTACHMENT value supplied by the CUA MUST be valid encoded
information.
インラインATTACHMENTsのこととなると、CUAは、それらを削除するために唯一古い値におけるATTACHMENT価値のコンテンツを特定する必要があるだけです。 CSが付属データを比較すると、それは二部形式で比較されます。 クーアによって供給されたATTACHMENT値は有効なコード化された情報でなければなりません。
For example, to delete the same huge inline attachment from every
VEVENT in 'my-cal' that has an "ATTACH" property value with the
例えば中であらゆるVEVENTから同じ巨大なインライン付属を削除する、'、私、-、cal、'それには、「付いてください」という資産価値があります。
old-values:
古い値:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//someone's prodid
TARGET:my-cal
CMD:MODIFY
BEGIN:VQUERY
QUERY:SELECT ATTACH FROM VEVENT
END:VQUERY
BEGIN:VEVENT
ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
MIICajCCAdOgAwIBAgICbeUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
...< remainder of attachment data NOT supplied >....
END:VEVENT
BEGIN:VEVENT
END:VEVENT
END:VCALENDAR
BEGIN:VCALENDAR VERSION:2.0PRODID:、-、だれかの//prodid TARGET:、私、-、cal、CMD:MODIFY BEGIN:VQUERY QUERY:SELECT ATTACH FROM VEVENT END:VQUERY BEGIN: VEVENT ATTACH; FMTTYPEはイメージ/基本的な; ENCODING=BASE64;VALUE=BINARYと等しいです: 付属データのMIICajCCAdOgAwIBAgICbeUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE…<残りは>を供給しませんでした… : VEVENTが始まる終わり: VEVENTエンド: VEVENTエンド: VCALENDAR
Here the new-values is empty, so everything in the old-values is deleted.
ここで、新しい値が空であるので、古い値におけるすべてが削除されます。
Furthermore, the following additional restrictions apply:
その上、以下の追加制限は適用されます:
1. One cannot change the "UID" property of a component.
1. 1つはコンポーネントの"UID"資産を変えることができません。
Royer, et al. Experimental [Page 108] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [108ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
2. If a contained component is changed inside of a selected
component, and that contained component has multiple instances,
then old-values MUST contain information that uniquely
identifies the instance or instances that are changing. It is
valid to change more than one. All contained components that
match old-values will be modified. In the first modify example
above, if "SEQUENCE" properties were to be deleted from both the
old-values and new-values, then all "TRIGGER" properties that
matched the old-values in all "VALARM" components in the
selected "VEVENT" components would be disabled.
2. 含まれたコンポーネントが選択されたコンポーネントの変えられた内部であり、その含まれたコンポーネントに複数の例があるなら、古い値は唯一例を特定する情報か変化する例を含まなければなりません。 1つ以上を変えるのは有効です。 古い値に合っているすべての含まれたコンポーネントが変更されるでしょう。 1番目では、上記の例を変更してください、「系列」の特性が選択された"VEVENT"コンポーネントで古い値と新しい値の両方から削除されて、次に、すべてすべての"VALARM"コンポーネントで古い値に合っていた特性の「引き金となること」は障害があるだろうということであったなら。
3. The result of the modify MUST be a valid iCalendar object.
3. なる、有効なiCalendarが物であったに違いないなら、変更します。
Response:
応答:
A "VCALENDAR" component is returned with one ore more "REQUEST- STATUS" property values.
1つの鉱石より多くの「要求状態」特性の値と共に"VCALENDAR"コンポーネントを返します。
If any error occurred:
何か誤りが発生したなら:
No component will be changed at all. That is, it will appear just
as it was prior to the modify and the CAP server SHOULD return a
"REQUEST-STATUS" property for each error that occurred. There
MUST be at least one error reported.
コンポーネントを全く変えないでしょう。 ちょうどそれのように見えるために望む前、変更、そして、SHOULDが発生した各誤りによって「要求状態」資産を返すCAPサーバ。 報告された少なくとも1つの誤りがあるに違いありません。
If multiple components are selected, then what uniquely identified the component MUST be returned (UID, QUERYID, ...) if the component contains a unique identifier. If it does not, sufficient information to uniquely identify the modified components MUST be returned in the reply.
複数のコンポーネントを選択するなら、コンポーネントがユニークな識別子を含んでいるなら、唯一コンポーネントを特定したものを返さなければなりません(UID、QUERYID)。 そうしないなら、回答で唯一変更されたコンポーネントを特定できるくらいの情報を返さなければなりません。
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: TARGET:relcalid
S: CMD;ID=delete#1:REPLY
S: BEGIN:VREPLY
S: BEGIN:VEVENT
S: UID:123
S: REQUEST-STATUS:2.0
S: END:VEVENT
S: END:VREPLY
S: END:VCALENDAR
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: 目標: relcalid S: CMD; ID=は#1: 回答Sを削除します: : VREPLY Sを始めてください: : VEVENT Sを始めてください: UID: 123秒間: 要求状態: 2.0秒間: 終わり: VEVENT S: 終わり: VREPLY S: 終わり: VCALENDAR
Royer, et al. Experimental [Page 109] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [109ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
10.10. MOVE Command
10.10. 動きコマンド
CMD: MOVE
CMD: 移動
Purpose: The "MOVE" command is used to move components within the CS.
目的: 「動き」コマンドは、Csの中でコンポーネントを動かすのに使用されます。
A CUA MAY send a "MOVE" command to a CS. The "MOVE" command MUST
be implemented by all CSs.
CUAは「動き」コマンドをCsに送るかもしれません。 すべてのCSsが「動き」コマンドを実行しなければなりません。
The CS MUST NOT send a "MOVE" command to any CUA.
CSは「動き」コマンドをどんなクーアにも送ってはいけません。
Formal Definition: A "MOVE" command is defined by the following
notation:
公式の定義: 「動き」コマンドは以下の記法で定義されます:
move-cmd = moveparam ":" "MOVE"
;
moveparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
;
)
「移動-cmdはmoveparamと等しい」:、」 「動いてください」。 moveparamは*と等しいです。( ; ; 以下は任意です。 しかし、NOTは一度より起こらなければなりません。 paramをイド-param/局所化している/潜在-param。 ; 以下がまさに一度起こらなければならない、唯一です。 そして、潜在paramが供給された、。 潜在-paramが供給するなら、供給してはいけません。 供給されません。 ; /動作-param。 ; 以下は任意です。 そして、一度より起こるかもしれません。 /他のparams。 )
Response:
応答:
The REQUEST-STATUS in a VCALENDAR object.
VCALENDARのREQUEST-STATUSは反対します。
The content of each "result" is subject to the result restriction
table defined below.
それぞれの「結果」の内容は以下で定義された結果制限テーブルを受けることがあります。
The access control on the "VAGENDA" component, after it has been
moved to its new location in the calstore, MUST be at least as
それがcalstoreの新しい位置に動かされて、あったに違いない後に少なくとも"VAGENDA"コンポーネントにおけるコントロールにアクセスします。
Royer, et al. Experimental [Page 110] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [110ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
secure as it was prior to the move. If the CS is not able to
ensure the same level of security, a permission-denied "REQUEST-
STATUS" property value MUST be returned, and the "MOVE" command
MUST NOT be performed.
移動の前に、それがあったとき、安全にします。 CSが同じレベルのセキュリティを確実にすることができないなら、許可で否定された「要求状態」資産価値を返さなければなりません、そして、「動き」コマンドは実行されてはいけません。
The "TARGET" property value specifies the new location, and the
"VQUERY" component specifies the old location.
「目標」資産価値は新しい位置を指定します、そして、"VQUERY"コンポーネントは古い位置を指定します。
Restriction Table for the "REPLY" command of any "MOVE" command.
どんな「移動」の「回答」コマンドのための制限Tableも命令します。
move-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops
1*(move-vreply)
"END" ":" "VCALENDAR" CRLF
「移動回答は「始まってください」と等しい」:、」 「「」 CRLF calprops1*(-vreplyに、動く)が「終わらせる」VCALENDAR」:」 "VCALENDAR"CRLF
move-vreply = "BEGIN" ":" "VREPLY" CRLF
move-id
rstatus
"END" ":" "VREPLY" CRLF
「移動-vreplyは「始まってください」と等しい」:、」 「「」 CRLF移動イドrstatusが「終わらせる」VREPLY」:」 "VREPLY"CRLF
; Where the id is appropriate for the
; type of object moved:
;
; VAGENDA = relcalid
; VCAR = carid
; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
; VQUERY = queryid
; ALARM = sequence
; An instance = uid recurid
; x-comp = x-id
;
move-id = ( relcalid / carid / uid / uid recurid
/ queryid / tzid / sequence / x-id)
; イドが適切である、。 物のタイプは移りました: ; ; VAGENDAはrelcalidと等しいです。 VCARはcaridと等しいです。 VEVENT、VFREEBUSY、VJOURNAL、VTODOはuidと等しいです。 VQUERYはqueryidと等しいです。 ALARMは系列と等しいです。 例はuid recuridと等しいです。 x-コンピュータはx-イドと等しいです。 移動イド=(relcalid / carid / uid / uid recurid / queryid / tzid /x系列/イド)
Example: moving the VAGENDA Nellis to Area-51
例: VAGENDA NellisをArea-51に動かします。
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD:MOVE
C: TARGET:Area-51
C: BEGIN:VQUERY
C: QUERY: SELECT *.* FROM VAGENDA WHERE CALID='Nellis'
C: END:VQUERY
C: END:VCALENDAR
C: コンテントタイプ: テキスト/カレンダーC: C: : VCALENDAR Cを始めてください: バージョン: 2.0C: PRODID:、-、だれかの//prodid C: CMD: 移動C: 目標: 領域-51C: : VQUERY Cを始めてください: 以下について質問してください。 *CALIDが'Nellis'Cと等しいVAGENDAからの*を選択してください: 終わり: VQUERY C: 終わり: VCALENDAR
Royer, et al. Experimental [Page 111] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [111ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: TARGET:Area-51
S: BEGIN:VREPLY
S: CALID:Nellis
S: REQUEST-STATUS: 2.0
S: END:VREPLY
S: END:VCALENDAR
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: バージョン: 2.0秒間: PRODID:、-、だれかの//prodid S: 目標: 領域51秒間: : VREPLY Sを始めてください: CALID: Nellis S: 要求状態: 2.0秒間: 終わり: VREPLY S: 終わり: VCALENDAR
10.11. REPLY Response to a Command
10.11. コマンドへの回答応答
CMD: REPLY
CMD: 返信
Purpose: The "REPLY" value to the "CMD" property is used to return
the results of all other commands to the CUA.
目的: "CMD"の特性への「回答」値は、他のすべてのコマンドの結果をクーアに返すのに使用されます。
A CUA MUST send a "REPLY" command to a CS for any command a CS MAY
send to the CUA. The "REPLY" command MUST be implemented by all
CUAs that support getting the "GET-CAPABILITY" command.
クーアはCsがクーアに送るどんなコマンドのためにも「回答」コマンドをCsに送らなければなりません。 得るのを支持するすべてのCUAsが「回答」コマンドを実行しなければならない、「能力を得る、」 命令してください。
A CS MUST send a "REPLY" command to a CUA for any command a CUA
MAY send to the CS. The "REPLY" command MUST be implemented by
all CSs.
CSはクーアがCsに送るどんなコマンドのためにも「回答」コマンドをクーアに送らなければなりません。 すべてのCSsが「回答」コマンドを実行しなければなりません。
Formal Definition: A "REPLY" command is defined by the following
notation:
公式の定義: 「回答」コマンドは以下の記法で定義されます:
reply-cmd = replyparam ":" "REPLY"
;
replyparam = *(
;
; The 'id' parameter value MUST be exactly the
; same as the value sent in the original
; CMD property. If the original CMD did
; not have an 'id' parameter, then the 'id'
; MUST NOT be supplied in the REPLY.
;
id-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
「回答-cmdはreplyparamと等しい」:、」 「返答してください」。 replyparamは*と等しいです。( ; ; 'イド'パラメタ価値がまさにそうであるに違いない、。 値と同じことはオリジナルを送りました。 CMDの特性。 オリジナルのCMDがそうしたなら。 次に、'イド'パラメタ、'イド'を持ってください。 REPLYで供給してはいけません。 ; イド-param。 ; 以下は任意です。 そして、一度より起こるかもしれません。 /他のparams)
Royer, et al. Experimental [Page 112] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [112ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
10.12. SEARCH Command
10.12. 検索命令
CMD: SEARCH
CMD: 検索
Purpose: The "SEARCH" command is used to return selected components
to the CUA.
目的: 「検索」コマンドは、選択されたコンポーネントをクーアに返すのに使用されます。
A CUA MAY send a "SEARCH" command to a CS. The "SEARCH" command
MUST be implemented by all CSs.
CUAは「検索」コマンドをCsに送るかもしれません。 すべてのCSsが「検索」コマンドを実行しなければなりません。
The CS MUST NOT send a "SEARCH" command to any CUA.
CSは「検索」コマンドをどんなクーアにも送ってはいけません。
Formal Definition: A "SEARCH" command is defined by the following
notation:
公式の定義: 「検索」コマンドは以下の記法で定義されます:
search-cmd = searchparam ":" "SEARCH"
;
searchparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
;
; the following MUST occur exactly once and only
; when the latency-param has been supplied and
; MUST NOT be supplied if the latency-param is
; not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params
)
「検索-cmdはsearchparamと等しい」:、」 「探してください」。 searchparamは*と等しいです。( ; ; 以下は任意です。 しかし、NOTは一度より起こらなければなりません。 paramをイド-param/局所化している/潜在-param。 ; 以下がまさに一度起こらなければならない、唯一です。 そして、潜在paramが供給された、。 潜在-paramが供給するなら、供給してはいけません。 供給されません。 ; /動作-param。 ; 以下は任意です。 そして、一度より起こるかもしれません。 /他のparams)
The format of the request is the search command (search-cmd)
followed by one or more (query) "VQUERY" components
要求の形式は1つ以上の(質問)"VQUERY"コンポーネントがいうことになった検索命令(検索-cmd)です。
Response:
応答:
The data in each result set contains one or more iCalendar
components composed of all the selected results enclosed in a
single "VREPLY" component per "QUERY".
それぞれの結果セットにおけるデータは「質問」あたり1つのただ一つの"VREPLY"コンポーネントに同封されたすべての選択された結果で構成された1つ以上のiCalendarの部品を含んでいます。
Royer, et al. Experimental [Page 113] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [113ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Only "REQUEST-STATUS" property and the properties mentioned in the
"SELECT" clause of the QUERY are included in the components. Each
"VCALENDAR" component is tagged with the "TARGET" property.
「要求状態」の特性と質問の「選んだ」節で言及された特性だけがコンポーネントに含まれています。 それぞれの"VCALENDAR"コンポーネントは「目標」の特性でタグ付けをされます。
Searching for objects
物を捜し求めます。
In the example below, objects on March 10,1999 between 080000Z and
190000Z are read. In this case only four properties for each
object are returned. Two calendars are specified. Only booked
(vs. scheduled) entries are to be returned (this example only
selected VEVENT objects are to be returned):
以下の例では、080000Zと190000Zの間の1999年3月10日の物は読まれます。 この場合、各物あたり4つの資産だけを返します。 2つのカレンダーが指定されます。 予約している(予定にされるに対する)エントリーだけが返されることになっています(この例は物が返されることになっているVEVENTを選択しただけです):
C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//someone's prodid
C: CMD:SEARCH
C: TARGET:relcal2
C: TARGET:relcal3
C: BEGIN:VQUERY
C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
C: FROM VEVENT
C: WHERE DTEND >= '19990310T080000Z'
C: AND DTSTART <= '19990310T190000Z'
C: AND STATE() = 'BOOKED'
C: END:VQUERY
C: END:VCALENDAR
C: コンテントタイプ: テキスト/カレンダーC: C: : VCALENDAR Cを始めてください: バージョン: 2.0C: PRODID:、-、だれかの//prodid C: CMD: 検索C: 目標: relcal2C: 目標: relcal3C: : VQUERY Cを始めてください: 質問: UID C、DTSTART、DTEND、概要を選択してください: VEVENT Cから: DTEND>が'19990310T080000Z'Cと等しいところ: そして、DTSTART<は'19990310T190000Z'Cと等しいです: そして、状態()=はCを'予約しました': 終わり: VQUERY C: 終わり: VCALENDAR
The return values are subject to VCAR filtering. That is, if the
request contains properties to which the UPN does not have access,
those properties will not appear in the return values. If the UPN
has access to at least one property of the component, but has been
denied access to all properties called out in the request, the
response will contain a single "REQUEST-STATUS" property
indicating the error.
リターン値はVCARフィルタリングを受けることがあります。 すなわち、要求がUPNがアクセスを持っていない特性を含んでいると、それらの特性はリターン値に現れないでしょう。 UPNはコンポーネントの少なくとも1つの特性に近づく手段を持っていますが、要求に呼び出されたすべての特性へのアクセスを拒絶されたなら、応答は誤りを示すただ一つの「要求状態」の特性を含むでしょう。
Here the request was successful, however one of the "VEVENT"
components contents were not accessible (4.1).
ここに、要求がうまくいった、しかしながら、"VEVENT"コンポーネントコンテンツの1つはアクセスしやすい(4.1)ではありません。
Royer, et al. Experimental [Page 114] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [114ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: TARGET:relcalid
S: CMD:REPLY
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: BEGIN:VREPLY
S: BEGIN:VEVENT
S: REQUEST-STATUS:4.1
S: END:VEVENT
S: BEGIN:VEVENT
S: REQUEST-STATUS:2.0
S: UID:123
S: DTEND:19990310T080000Z
S: DSTART:19990310T190000Z
S: SUMMARY: Big meeting
S: END:VEVENT
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: 目標: relcalid S: CMD: 回答S: バージョン: 2.0秒間: PRODID:、-、だれかの//prodid S: : VREPLY Sを始めてください: : VEVENT Sを始めてください: 要求状態: 4.1秒間: 終わり: VEVENT S: : VEVENT Sを始めてください: 要求状態: 2.0秒間: UID: 123秒間: DTEND: 19990310T080000Z S: DSTART: 19990310T190000Z S: 概要: 大きいミーティングS: 終わり: VEVENT
S: END:VREPLY
S: END:VCALENDAR
S: 終わり: VREPLY S: 終わり: VCALENDAR
If the UPN has no access to any components at all, the response
will simply be an empty data set. The response will look the same
if the particular components do not exist.
UPNが全くどんなコンポーネントにも近づく手段を持っていないと、応答は単に空のデータセットになるでしょう。 特定のコンポーネントが存在していないなら、応答は同じに見えるでしょう。
S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:-//someone's prodid
S: CMD:REPLY
S: TARGET:ralcalid
S: BEGIN:VREPLY
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR
S: コンテントタイプ: テキスト/カレンダーS: S: : VCALENDAR Sを始めてください: バージョン: 2.0秒間: PRODID:、-、だれかの//prodid S: CMD: 回答S: 目標: ralcalid S: : VREPLY Sを始めてください: 要求状態: 2.0秒間: 終わり: VREPLY S: 終わり: VCALENDAR
If there are multiple targets, each iCalendar reply is contained
within its own iCalendar object.
マルチターゲットがあれば、それぞれのiCalendar回答はそれ自身のiCalendar物の中に含まれています。
10.12.1. Searching for VFREEBUSY
10.12.1. VFREEBUSYを捜し求めます。
If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the "VFREEBUSY" component in the "COMPONENTS" value in a reply to the "GET-CAPABILITY" command, then it is the CS's responsibility (and not the CUA's responsibility) to provide the correct "VFREEBUSY" information for a calendar.
CSがセットする、「再発、-広がってください、」 「本当」への特性、中のaの「コンポーネント」値が答える"VFREEBUSY"コンポーネントを含んでいる、「能力を得る、」 コマンド、そして、カレンダーのための正しい"VFREEBUSY"情報を提供するのは、Cs sの責任(そして、クーアの責任でない)です。
Royer, et al. Experimental [Page 115] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [115ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return success and not store the "VFREEBUSY" component as the results would never be used.
CUAが「作成」"VFREEBUSY"を発行するなら、結果が決して使用されないように、そのようなCsは、成功を返して、"VFREEBUSY"コンポーネントを格納してはいけません。
Such a CS MUST dynamically create the results of a search for "VFREEBUSY" components at search time when searching for STATE() = 'BOOKED' items.
そのようなCSは状態()=を捜し求めると項目が'予約された'検索時にダイナミックに"VFREEBUSY"コンポーネントの検索の結果を作成しなければなりません。
If a CUA searches for "VFREEBUSY" components with STATE() = 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components.
状態()=が'未加工'でCUAが"VFREEBUSY"コンポーネントを捜し求めるなら、そのようなCsはコンポーネントなしで"VREPLY"を返さなければなりません。
If a CUA searches for "VFREEBUSY" components without specifying the STATE, such a CS MUST return the same result as if STATE()='BOOKED' had been specified.
CUAが状態を指定しないで"VFREEBUSY"コンポーネントを捜し求めるなら、まるで=が'予約した'状態()が指定されたかのようにそのようなCsは同じ結果を返さなければなりません。
For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE" and have the "VFREEBUSY" component in the "COMPONENTS" value in the "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on the CS. These CSs then MUST return a "VFREEBUSY" component calculated from the stored components. If no "VFREEBUSY" information is available for the "TARGET" calendar, then a "VFREEBUSY" with no blocked out time will be returned with a success code. A CUA sets the "VFREEBUSY" time on a/those calendars by creating a "VFREEBUSY" component without a "METHOD" creating a "BOOKED" entry.
「能力」を設定するCSs、「再発、-広がってください、」 特性、「虚偽」、「能力」回答における「コンポーネント」値で"VFREEBUSY"コンポーネントを持ってください、そして、クーアはCsの"VFREEBUSY"情報を格納してもよいです。 そして、これらのCSsは格納されたコンポーネントから計算された"VFREEBUSY"コンポーネントを返さなければなりません。 どんな"VFREEBUSY"情報も「目標」カレンダーに利用可能でないなら、いいえが遮断されている"VFREEBUSY"時間は成功コードと共に返されるでしょう。 CUAは/では、aを作成しながら「方法」なしで"VFREEBUSY"コンポーネントを作成するのによるそれらのカレンダーがエントリーを「予約した」"VFREEBUSY"時を決めます。
If a CS does not set the "VFREEBUSY" value in the "COMPONENTS" "CAPABILITY" value, the CS does not support the "VFREEBUSY" component and all creation and searching for a "VFREEBUSY" component MUST fail. Examples of calendars that may be in this category are public event calendars that will never require scheduling with other UPNs.
CSが「コンポーネント」「能力」値に"VFREEBUSY"値をはめ込まないなら、Csは"VFREEBUSY"コンポーネントを支えません、そして、万物と"VFREEBUSY"コンポーネントを捜し求めるのは失敗しなければなりません。 このカテゴリにあるかもしれないカレンダーに関する例は他のUPNsと共に計画をするのを決して必要としない公共イベントカレンダーです。
10.13. SET-LOCALE Command
10.13. セット現場コマンド
CMD: SET-LOCALE
CMD: セット現場
Purpose: The "SET-LOCALE" command is used to select the locale that
will be used in error codes that are used in the "REQUEST-STATUS"
property.
目的: 「セット現場」コマンドは、「要求状態」所有地で使用されるエラーコードに使用される現場を選択するのに使用されます。
A CUA MAY send a "SET-LOCALE" command to a CS. The SET-LOCALE
command MUST be implemented by all CSs.
CUAは「セット現場」コマンドをCsに送るかもしれません。 すべてのCSsがSET-LOCALEコマンドを実行しなければなりません。
The CS MUST NOT send a "SET-LOCALE" command to any CUA.
CSは「セット現場」コマンドをどんなクーアにも送ってはいけません。
Formal Definition: A "SET-LOCALE" command is defined by the following
notation:
公式の定義: 「セット現場」コマンドは以下の記法で定義されます:
setlocale-cmd = setlocaleparam ":" "SET-LOCALE"
「setlocale-cmdはsetlocaleparamと等しい」:、」 「セット現場」
Royer, et al. Experimental [Page 116] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [116ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
;
setlocaleparam = *(
;
; the following are optional,
; but MUST NOT occur more than once
;
id-param
/ localize-param
/ latency-param
/ setlocale-option
;
; the following MUST occur exactly once and only
; only when the latency-param has been supplied.
; It MUST NOT be supplied if the latency-param
; is not supplied.
;
/ action-param
;
; the following is optional,
; and MAY occur more than once
;
/ other-params )
; setlocaleparamは*と等しいです。( ; ; 以下は任意です。 しかし、NOTは一度より起こらなければなりません。 paramを局所化している/潜在param / setlocaleイド-param/オプション。 ; 以下がまさに一度起こらなければならない、唯一です。 潜在-paramを供給したときだけ。 ; 潜在-paramであるならそれを供給してはいけません。 供給されません。 ; /動作-param。 ; 以下は任意です。 そして、一度より起こるかもしれません。 /他のparams)
setlocale-option = option-param newlocale
;
newlocale = ; Any locale supplied in the initial [BEEP]
; "greeting" "localize" parameter and
; and any charset supported by the CS
; and listed in the DEFAULT-CHARSET property
; of the VCALSTORE
setlocale-オプションはオプション-param newlocaleと等しいです。 newlocale=。 初期の[BEEP]で供給されたどんな現場も。 そして、「集中してください」という「挨拶」パラメタ、。 CSによって支持されたどんなcharsetも。 DEFAULT-CHARSET所有地では、記載されています。 VCALSTOREについて
Examples:
例:
CMD:OPTIONS=en_US.UTF-8:SET-LOCALE
CMD:OPTIONS=th_TH.ISO8859-11:SET-LOCALE
CMD:OPTIONS=es_MX.ISO8859-1:SET-LOCALE
CMD: オプションがアン_US.UTF-8: セット現場CMD: オプション=と等しい、_TH.ISO8859-11: セット現場CMD: オプションはes_MX.ISO8859-1: セット現場と第等しいです。
Restriction Table for the "REPLY" command of any "SET-LOCALE"
command.
どんな「セット現場」の「回答」コマンドのための制限Tableも命令します。
setlocale-reply = "BEGIN" ":" "VCALENDAR" CRLF
calprops
1*(setlocale-vreply)
"END" ":" "VCALENDAR" CRLF
「setlocale-回答は「始まってください」と等しい」:、」 「「」 CRLF calprops1*(setlocale-vreply)が「終わらせる」VCALENDAR」:」 "VCALENDAR"CRLF
setlocale-vreply = "BEGIN" ":" "VREPLY" CRLF
rstatus
"END" ":" "VREPLY" CRLF
「setlocale-vreplyは「始まってください」と等しい」:、」 「「」 CRLF rstatusが「終わらせる」VREPLY」:」 "VREPLY"CRLF
Royer, et al. Experimental [Page 117] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [117ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
10.14. TIMEOUT Command
10.14. タイムアウトコマンド
CMD: TIMEOUT
CMD: タイムアウト
Purpose: The "TIMEOUT" command is only sent after a command has been
sent with a latency value set. When received, it means the
command could not be completed in the time allowed.
目的: 潜在選択値群でコマンドを送った後に「タイムアウト」コマンドを送るだけです。 受け取ると、それは、コマンドが日限で終了できなかったことを意味します。
Formal Definition: A "TIMEOUT" command is defined by the following
notation:
公式の定義: 「タイムアウト」コマンドは以下の記法で定義されます:
timeout-cmd = timeoutparam ":" "TIMEOUT"
「タイムアウト-cmdはtimeoutparamと等しい」:、」 「タイムアウト」
timeoutparam = *(
; the following are optional,
; but MUST NOT occur more than once
id-param
/ localize-param
/ other-params
)
timeoutparamは*と等しいです。(;以下は任意です; しかし、一度paramをイド-param/局所化している/他のparamsより起こってはいけない )
10.15. Response Codes
10.15. 応答コード
Numeric response codes are returned using the "REQUEST-STATUS" property.
数値応答コードは、「要求状態」の特性を使用することで返されます。
The format of these codes is described in [iCAL] and extended in [iTIP] and [iMIP]. The following describes new codes added to this set and how existing codes apply to CAP.
これらのコードの形式は、[iCAL]で説明されて[iTIP]と[iMIP]で拡張されています。 以下はこのセットに追加された新法と既存のコードがどう適用されるかをCAPに説明します。
At the application layer, response codes are returned as the value of a "REQUEST-STATUS" property. The value type of this property is modified from that defined in [iCAL], in order to make the accompanying "REQUEST-STATUS" property text optional.
応用層では、応答コードは「要求状態」属性の価値として返されます。 この特性の値のタイプは[iCAL]で定義されたそれから変更されます、「要求状態」という付随の特性のテキストを任意にするように。
Code Description
--------------------------------------------------------------
2.0 Success. The parameters vary with the
operation and are specified.
コード記述-------------------------------------------------------------- 2.0 成功。 パラメタは、操作に従って異なって、指定されます。
2.0.3 In response to the client issuing an
"abort" reply, this reply code indicates
that any command currently underway was
successfully aborted.
2.0.3 「アボート」回答を発行するクライアントに対応して、この回答コードは、現在進行中のどんなコマンドも首尾よく中止されたのを示します。
3.1.4 Capability not supported.
3.1.4 支持されなかった能力。
4.1 Calendar store access denied.
4.1 カレンダー店アクセス拒否。
Royer, et al. Experimental [Page 118] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [118ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
6.1 Container not found.
見つけられなかった6.1容器。
6.2 Attempt to create or modify an object
that would overlap another object
in either of the following two circumstances:
6.2 以下の2つの事情のどちらかで別の物を重ね合わせる物を作成するか、または変更するのを試みてください:
(a) One of the objects has a TRANSP
property set to OPAQUE-NOCONFLICT or
TRANSPARENT-NOCONFLICT.
(a) 物の1つで、OPAQUE-NOCONFLICTかTRANSPARENT-NOCONFLICTにTRANSPの特性を設定します。
(b) The calendar's ALLOW-CONFLICT
property is set to FALSE.
(b) カレンダーのALLOW-CONFLICTの特性はFALSEに設定されます。
6.3 Bad args.
6.3 悪いargs。
6.4 Permission denied - VCAR restriction.
A VCAR exists and the CS will not perform
the operation.
許可が否定した6.4--VCAR制限。 VCARは存在しています、そして、CSは操作を実行しないでしょう。
7.0 A timeout has occurred. The server was
unable to complete the operation in the
requested time.
7.0 タイムアウトは起こりました。 サーバは要求された時間で操作を完了できませんでした。
8.0 A failure has occurred in the CS
that prevents the operation from
succeeding.
8.0 失敗は操作が成功するのを防ぐCSに起こりました。
8.1 A query was performed and the query is
too complex for the CS. The operation
was not performed.
8.1 質問は実行されて、CSには、質問は複雑過ぎます。 操作は実行されませんでした。
8.2 Used to signal that an iCalendar object has
exceeded the server's size limit
8.2は、以前はよくiCalendar物がサーバのサイズ限界を超えていたのを示していました。
8.3 A DATETIME value was too far in the future
to be represented on this Calendar.
8.3 DATETIME値はこのCalendarにであることができない未来にはるかに表されました。
8.4 A DATETIME value was too far in the past
to be represented on this Calendar.
8.4 DATETIME値はこのCalendarにであることができない過去にはるかに表されました。
8.5 An attempt was made to create a new
object, but the unique UID specified is
already in use.
8.5 新しい物を作成するのを試みをしましたが、指定されたユニークなUIDは既に使用中です。
9.0 An unrecognized command was received.
Or an unsupported command was received.
9.0 認識されていないコマンドを受け取りました。 または、サポートされないコマンドを受け取りました。
Royer, et al. Experimental [Page 119] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [119ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
10.4 The operation has not been performed
because it would cause the resources
(memory, disk, CPU, etc) to exceed the
allocated quota.
--------------------------------------------------------------
10.4 リソース(メモリ、ディスク、CPUなど)はそれで割り当てられた割当てを超えているでしょう、したがって、操作が実行されていません。 --------------------------------------------------------------
11. Object Registration
11. 物の登録
This section provides the process for registration of new or modified properties, parameters, commands, or other modifications, additions, or deletions to objects.
このセクションは新しいか変更された特性、パラメタ、コマンド、他の変更、追加、または削除の登録のための過程を物に供給します。
11.1. Registration of New and Modified Entities
11.1. 新しくて変更された実体の登録
New objects are registered by the publication of an IETF Request for Comment (RFC). Changes to objects are registered by the publication of a revision to the RFC in a new RFC.
新しい物はComment(RFC)のためにIETF Requestの公表によって登録されます。 物への変化は改正の公表によって新しいRFCのRFCに登録されます。
11.2. Post the Item Definition
11.2. 項目定義を掲示してください。
The object description MUST be posted to the new object discussion list: ietf-calendar@imc.org.
新しい物の議論リストに物の記述を掲示しなければなりません: ietf-calendar@imc.org 。
11.3. Allow a Comment Period
11.3. コメントの期間を許容してください。
Discussion on a new object MUST be allowed to take place on the list for a minimum of two weeks. Consensus MUST be reached on the object before proceeding to the next step.
新しい物についての議論に最低2週間リストで行われさせなければなりません。 次のステップに進む前に、物の上にコンセンサスに達しなければなりません。
11.4. Release a New RFC
11.4. 新しいRFCをリリースしてください。
The new object will be submitted for publication like any other Internet Draft requesting RFC status.
公表のためにRFC状態を要求するいかなる他のインターネットDraftのようにも新しい物を提出するでしょう。
12. BEEP and CAP
12. ビープ音とキャップ
12.1. BEEP Profile Registration
12.1. ビープ音プロフィール登録
BEEP replies will be one-to-one (1:1 MSG/RPY) if possible, and one-
to-many (1:many MSG/ANS) when the "TARGET" property value changes.
No more than one "TARGET" property value is allowed per reply.
できれば、回答が1〜1つが(1:1MSG/RPY)であったなら望んでいるBEEP、および1、-、多く、(1: 多くのMSG/ANS) 「目標」資産価値が変化すると。 1「目標」の資産価値は回答単位で許容されています。
Profile Identification: specify a [URI] that authoritatively
identifies this profile.
識別の輪郭を描いてください: 厳然とこのプロフィールを特定する[URI]を指定してください。
http://iana.org/beep/cap/1.0
http://iana.org/beep/cap/1.0
Message Exchanged during Channel Creation:
メッセージはチャンネル創造の間、交換しました:
Royer, et al. Experimental [Page 120] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [120ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
CUAs SHOULD supply the BEEP "localize" attributes in the BEEP
"greeting" messages.
CUAs SHOULDはBEEP「挨拶」メッセージの「集中してください」というBEEP属性を供給します。
CSs SHOULD supply the BEEP "localize" attributes in the BEEP
"greeting" messages.
CSs SHOULDはBEEP「挨拶」メッセージの「集中してください」というBEEP属性を供給します。
CUAs SHOULD supply the BEEP "serverName" attribute at channel
creation time to the CS, so that, if the CS is performing virtual
hosting, the CS can determine the intended virtual host. CSs that
do not support virtual hosting may ignore the BEEP "serverName"
attribute.
CUAs SHOULDはチャンネル創造時間にBEEP"serverName"属性をCSに供給します、CSが仮想の接待を実行しているなら、CSが意図している事実上のホストを決定できるように。 仮想の接待を支持しないCSsはBEEP"serverName"属性を無視するかもしれません。
Messages starting one-to-one exchanges:
始めが1〜1に以下を交換するというメッセージ
The initial message, after authentication in each direction, MUST
be a single "text/calendar" object containing a CAP "CAPABILITY"
CMD. It must not be part of a MIME multipart message.
各方向への認証の後に初期のメッセージはCAP「能力」CMDを含む単一の「テキスト/カレンダー」物であるに違いありません。 それはMIMEの複合メッセージの一部であるはずがありません。
After the initial message, a BEEP "MSG" may contain one or more
MIME objects (at least one of which MUST be "text/calendar"), and
each "text/calendar" MIME object MUST contain a CAP "CMD"
property.
初期のメッセージの後に、BEEP「エムエスジー」は1個以上のMIME物(少なくともそれの1つは「テキスト/カレンダー」であるに違いない)を含むかもしれません、そして、それぞれの「テキスト/カレンダー」MIME物はキャップ"CMD"の特性を含まなければなりません。
Multiple iCalendar objects may be sent in a single BEEP message
either by representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
ただ一つのテキスト/カレンダーMIME物の中にただ一つのBEEPメッセージでMIMEの複合の、または、複雑な部分の中に含まれた別々のMIMEテキスト/カレンダー一部としてそれらを表すか、簡単な連結で複数のiCalendar物を送るかもしれません。
In either case, all iCalendar objects that are transmitted
together must have the same TARGET property.
どちらの場合ではも、一緒に伝えられるすべてのiCalendar物が同じTARGETの特性を持たなければなりません。
The sending of multipart MIME entities over BEEP is not permitted
for CAP unless the other endpoint has indicated its ability to
accept them via the appropriate CAPABILITY.
もう片方の終点が適切なCAPABILITYを通してそれらを受け入れる性能を示していない場合、BEEPの上の複合MIME実体の発信はCAPのために受入れられません。
Messages in positive replies:
積極的な返事におけるメッセージ:
After the initial message, a BEEP "RPY" may contain one or more
MIME objects (at least one of which MUST be "text/calendar"), and
each "text/calendar" MIME object MUST contain a CAP "CMD"
property. All "text/calendar" MIME objects in a single BEEP "RPY"
messages MUST have the same "TARGET" property value.
初期のメッセージの後に、BEEP"RPY"は1個以上のMIME物(少なくともそれの1つは「テキスト/カレンダー」であるに違いない)を含むかもしれません、そして、それぞれの「テキスト/カレンダー」MIME物はキャップ"CMD"の特性を含まなければなりません。 単一のBEEP"RPY"メッセージのすべての「テキスト/カレンダー」MIME物には、同じ「目標」資産価値がなければなりません。
Multiple iCalendar objects may be sent in a single BEEP message by
either representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
どちらかは、MIMEの複合の、または、複雑な部分以内か簡単な連結で含まれた別々のMIMEテキスト/カレンダー一部としてただ一つのテキスト/カレンダーMIME物の中にそれらを表しながら、ただ一つのBEEPメッセージで複数のiCalendar物を送るかもしれません。
Royer, et al. Experimental [Page 121] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [121ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
In either case, all iCalendar objects transmitted together must
have the same TARGET property.
どちらの場合ではも、一緒に伝えられたすべてのiCalendar物が同じTARGETの特性を持たなければなりません。
Sending multipart MIME entities over BEEP is not permitted for CAP
unless the other endpoint has indicated its ability to accept them
via the appropriate CAPABILITY.
もう片方の終点が適切なCAPABILITYを通してそれらを受け入れる性能を示していない場合、複合MIME実体をBEEPの上に送るのはCAPのために受入れられません。
Messages in negative replies:
否定的な返事におけるメッセージ:
Will contain any valid "text/calendar" MIME object that contains
CAP "REQUEST-STATUS" property and a CAP "CMD" property with a
property value of "REPLY". And where the CS has determined the
requested operation to be a fatal error. And when the CS has
performed NO operation that effected the contents of any part of
the CS or any calendar controlled by the CS.
CAP「要求状態」の特性と「回答」の資産価値があるキャップ"CMD"の特性を含むどんな有効な「テキスト/カレンダー」MIME物も含むでしょう。 そして、どこで、CSは、要求された操作が致命的な誤りであることを決定したか。 そして、CSがいつ何かCSの部分のコンテンツに作用した操作を全く実行していないか、そして、どんなカレンダーもCSによって制御されました。
Messages in one-to-many exchanges:
多くへの1回の交換におけるメッセージ:
After the initial message then a BEEP "MSG" may contain one or
more MIME objects at least one of which MUST be "text/calendar"
and each "text/calendar" MIME object MUST contain a CAP "CMD"
property.
次に、初期のメッセージの後にBEEP「エムエスジー」は少なくともそれの1つが「テキスト/カレンダー」であるに違いない1個以上のMIME物を含むかもしれません、そして、それぞれの「テキスト/カレンダー」MIME物はキャップ"CMD"の特性を含まなければなりません。
The BEEP "MSG" messages can only contain MIME "multipart" MIME
objects if the other endpoint has received a CAP "CAPABILITY"
indicating the other endpoint supports multipart MIME objects.
This does not prevent the endpoint from sending multiple [iCAL]
'icalobject' objects in a single BEEP "MSG" so long as all of them
have the same "TARGET" property value.
もう片方の終点が複合MIME物を支えるのを示しながらもう片方の終点がキャップ「能力」を受けたなら、「エムエスジー」メッセージが含むことができるだけであるBEEPは「複合」のMIME物をまねます。 これは、それら皆、に同じ「目標」資産価値がある限り、終点が単一のBEEP「エムエスジー」で複数の[iCAL]'icalobject'物を送るのを防ぎません。
Multiple iCalendar objects may be sent in a single BEEP message by
either representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
どちらかは、MIMEの複合の、または、複雑な部分以内か簡単な連結で含まれた別々のMIMEテキスト/カレンダー一部としてただ一つのテキスト/カレンダーMIME物の中にそれらを表しながら、ただ一つのBEEPメッセージで複数のiCalendar物を送るかもしれません。
In either case, all iCalendar objects transmitted together must
have the same TARGET property.
どちらの場合ではも、一緒に伝えられたすべてのiCalendar物が同じTARGETの特性を持たなければなりません。
The sending of multipart MIME entities over BEEP is not permitted
for CAP unless the other endpoint has indicated its ability to
accept them via the appropriate CAPABILITY.
もう片方の終点が適切なCAPABILITYを通してそれらを受け入れる性能を示していない場合、BEEPの上の複合MIME実体の発信はCAPのために受入れられません。
Message Syntax:
メッセージ構文:
They are CAP "text/calendar" MIME objects as specified in this
memo.
このメモでそれらは指定されるとしてCAP「テキスト/カレンダー」MIME物です。
Royer, et al. Experimental [Page 122] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [122ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Message Semantics:
メッセージ意味論:
As defined in this memo.
このメモで定義されるように。
12.2. BEEP Exchange Styles
12.2. ビープ音交換様式
[BEEP] defines three styles of message exchange:
[BEEP]は3つのスタイルの交換処理を定義します:
MSG/ANS,ANS,...,NUL - For one to many exchanges.
エムエスジー/ANS、ANS…NUL--多くの交換へのFor1。
MSG/RPY - For one to one exchanges.
MSG/RPY--1回の交換へのFor1。
MSG/ERR - For requests the cannot be processed due to an error.
要求のためのMSG/ERR、誤りのため処理できません。
A CAP request targeted at more than one container MAY use a one- to- many exchange with a distinct answer associated with each target. A CAP request targeted at a single container MAY use a one-to-one exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when an error condition prevents the execution of the request on all the targeted calendars.
1個以上の容器をターゲットにしたCAP要求が1つを使用するかもしれない、-、異なった答えが交際した状態で、多くが各目標を交換します。 単一の容器をターゲットにしたCAP要求は1〜1回の交換か多くへの1回の交換を使用するかもしれません。 エラー条件がすべての狙っているカレンダーにおける要求の実行を防ぐと、"MSG/ERR"は使用されるだけであるかもしれません。
12.3. BEEP Connection Details
12.3. ビープ音接続の詳細
All CAP communications must be done securely, so the initial greeting includes the TLS profile.
すべてのCAPコミュニケーションがしっかりと完了していなければならないので、初期の挨拶はTLSプロフィールを含んでいます。
L: <wait for incoming connection>
L: 入って来る接続>のための<待ち
I: <open connection>
私: <のオープンな接続>。
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
L: RPY0 0.0110、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: <挨拶>L: <プロフィールuriは' http://iana.org/beep/TLS '/>Lと等しいです: </挨拶>L: 終わり
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting/>
I: END
私: RPY0 0.052、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <挨拶/>I: 終わり
At this point, the connection is secure. The TLS profile 'resets' the connection, so it resends the greetings, advertises the CAP profiles that are supported, and replies with the profile selected (only one profile exists at this time):
ここに、接続は安全です。 TLSプロフィールが接続を'リセットし'て、挨拶を再送するので、支えられるCAPプロフィールの広告を出して、プロフィールが選択されている状態で、返答します(1個のプロフィールだけがこのとき、存在します):
Royer, et al. Experimental [Page 123] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [123ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
L: <wait for incoming connection>
L: 入って来る接続>のための<待ち
I: <open connection>
私: <のオープンな接続>。
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/cap/1.0'/>
L: </greeting>
L: END
L: RPY0 0.0110、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: <挨拶>L: <プロフィールuriは' http://iana.org/beep/cap/1.0 '/>Lと等しいです: </挨拶>L: 終わり
I: RPY 0 0 . 0 110
I: Content-Type: application/beep+xml
I:
I: <greeting>
I: <profile uri='http://iana.org/beep/cap/1.0'/>
I: </greeting>
I: END
私: RPY0 0.0110、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <挨拶>I: ' http://iana.org/beep/cap/1.0 '/><プロフィールuri=I: </挨拶>I: 終わり
Each channel must be authenticated before work can start, but starting a channel involves authentication. Any SASL profile may be included, for example:
仕事が始まることができる前に各チャンネルを認証しなければなりませんが、チャンネルを始動するのは認証にかかわります。 例えば、どんなSASLプロフィールも含まれるかもしれません:
<profile uri='http://iana.org/beep/SASL/OTP'/>
<profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
<profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
' http://iana.org/beep/SASL/DIGEST-MD5 '/><プロフィール' http://iana.org/beep/SASL/OTP '/><プロフィール<プロフィールuri=uri=uriは' http://iana.org/beep/SASL/ANONYMOUS '/>と等しいです。
Example of anonymous channel:
匿名のチャンネルに関する例:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
C: </start>
C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/ANONYMOUS '/>Cと等しいです: </スタート>。
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
S: END
S: 87秒間のRPY0 1.221: コンテントタイプ: + アプリケーション/ビープ音xml S: S: <プロフィールuriは' http://iana.org/beep/SASL/ANONYMOUS '/>Sと等しいです: 終わり
Example of DIGEST-MD5 channel:
DIGEST-MD5チャンネルに関する例:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
C: </start>
C: <スタート番号は'1'>Cと等しいです:、' <プロフィールuriは' http://iana.org/beep/SASL/DIGEST-MD5 '/>Cと等しいです: </スタート>。
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S: 87秒間のRPY0 1.221: コンテントタイプ: アプリケーション/ビープ音+xml
Royer, et al. Experimental [Page 124] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [124ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
S:
S: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
S: END
S: S: <プロフィールuriは' http://iana.org/beep/SASL/DIGEST-MD5 '/>Sと等しいです: 終わり
Piggybacking the "CAPABILITY" command.
「能力」コマンドを背負います。
The "CAPABILITY" reply may be included during channel start (see RFC3080, section 2.3.1.2), as BEEP allows the start command to include the initial data transfer. This reduces the number of round trips to initiate a CAP session.
RFC3080、スタートコマンドが含むビープ音としての.2が)許容するセクション2.3.1を見てください。「能力」回答がチャンネル始めの間、含まれるかもしれない、(初期のデータ転送。 これは、CAPセッションを開始するために周遊旅行の数を減少させます。
13. IANA Considerations
13. IANA問題
This memo defines IANA-registered extensions to the attributes defined by iCalendar, as defined in [iCAL], and [iTIP].
このメモは[iCAL]、および[iTIP]で定義されるようにiCalendarによって定義された属性とIANAによって登録された拡大を定義します。
IANA registration proposals for iCalendar and [iTIP] are to be mailed to the registration agent for the "text/calendar" [MIME] content- type, <MAILTO: ietf-calendar@imc.org> using the format defined in section 7 of [iCAL].
iCalendarと[iTIP]のためのIANA登録提案は「テキスト/カレンダー」[MIME]満足しているタイプのために登録エージェントに郵送することです、<MAILTO: ietf-calendar@imc.org 、gt;、[iCAL]のセクション7で定義された書式を使用します。
The the IANA has registered the profile specified in Section 12.1, and has selected an IANA-specific URI: http://iana.org/beep/cap/1.0.
IANAはセクション12.1で指定されたプロフィールを登録して、IANA特有のURIを選択しました: http://iana.org/beep/cap/1.0 。
14. Security Considerations
14. セキュリティ問題
Access rights should be granted cautiously. Without careful planning, it is possible to open up access to a greater degree than desired.
用心深くアクセス権を与えるべきです。 綿密な計画がなければ、望まれているより大きい程度へのアクセスを開けるのは可能です。
The "IDENTIFY" command should be carefully implemented. If it is done incorrectly, UPNs may gain access as other, unintended, UPNs. The "IDENTIFY" command may not chain; that is, the identity is always validated against the original UPN and not the new UPN.
「特定」コマンドは慎重に実行されるべきです。 UPNs、不当に完了しているなら、UPNsは他であって、故意でないとしてアクセスを得るかもしれません。 「特定」コマンドは鎖を作らないかもしれません。 すなわち、アイデンティティはいつも新しいUPNではなく、オリジナルのUPNに対して有効にされます。
Since CAP is a profile of [BEEP], consult [BEEP]'s Section 9 for a discussion of BEEP-specific security issues.
CAPが[BEEP]のプロフィールであるので、BEEP特有の安全保障問題の議論のために[BEEP]のセクション9に相談してください。
There are risks of allowing anonymous UPNs to deposit REQUEST and REFRESH objects (calendar spam and denial-of-service, for example). Implementations should consider methods to restrict anonymous requests to within acceptable usages.
匿名のUPNsがREQUESTとREFRESH物(例えば、カレンダースパムとサービスの否定)を預けるのを許容するリスクがあります。 実現は匿名の要求を許容できる用法に制限する方法を考えるべきです。
CS implementations might consider automatically creating VCARs that allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY objects for those UIDs if they otherwise do not have access rather then opening up world access. And they may also consider allowing COUNTER objects for those ATTENDEEs.
CS実現は、自動的にそうでなければ、彼らにアクセスがむしろその時ないなら予約している物のCAP ATTENDEEsにそれらのUIDsのために世界アクセサリーを開けながらREFRESHとREPLY物を預けさせるVCARsを作成すると考えるかもしれません。 そして、また、彼らは、それらのATTENDEEsのためにCOUNTERに物を許容すると考えるかもしれません。
Royer, et al. Experimental [Page 125] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [125ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
When an object is booked by a CUA ,the CS reply may wish to include warning messages to the CUA for ATTENDEEs that have CAP urls that do not have local UPNs as those ATTENDEES may be unable to REPLY or REFRESH. Some CSs may wish this to be an error.
物がCUAによって予約しているとき、CS回答はREPLYかREFRESHにATTENDEESであることができないかもしれないのでそれらの地方のUPNsを持っていないCAP urlsを持っているATTENDEEsのためのCUAに警告メッセージを含めたがっているかもしれません。 いくつかのCSsが、これに誤りであって欲しいかもしれません。
Although service provisioning is a policy matter, at a minimum, all implementations must provide the following tuning profiles:
サービスの食糧を供給するのは方針問題ですが、最小限で、すべての実現が以下の調律プロフィールを提供しなければなりません:
o for authentication: http://iana.org/beep/SASL/DIGEST-MD5
o 認証のために: http://iana.org/beep/SASL/DIGEST-MD5
o for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
o 秘密性のために: http://iana.org/beep/TLS (TLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用します)
o for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates)
o 両方のために: http://iana.org/beep/TLS (クライアントサイド証明書を支えるTLS_RSA_WITH_3DES_EDE_CBC_SHA暗号を使用します)
Royer, et al. Experimental [Page 126] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [126ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Appendix A. Acknowledgements
付録A.承認
The following individuals were major contributors to the drafting and discussion of this memo, and they are greatly appreciated:
以下の個人は、草稿への一流の貢献者とこのメモの議論でした、そして、彼らは大いに感謝しています:
Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag, Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan, Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan Kohn, Dan Winship, Darryl Champagne, David C. Thewlis, David Nicol, David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin, Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand, Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray, Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke, Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle, Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max Froumentin, Micah Gorrell, Michael Fair, Mike Higginbottom, Mike Hixson, Murata Makoto, Natalia Syracuse, Nathaniel Borenstein, Ned Freed, Olivier Gutknecht, Patrice Lapierre, Patrice Scattolin, Paul Hoffman, Paul Sharpe, Payod Deshpande, Pekka Pessi, Peter Thompson, Preston Stephenson, Prometeo Sandino Roman Corral, Ralph Patterson, Robert Lusardi, Robert Ransdell, Rob Siemborski, Satyanarayana Vempati, Satya Vempati, Scott Hollenbeck, Seamus Garvey, Shannon Clark, Shriram Vishwanathan, Steve Coya, Steve Mansour, Steve Miller, Steve Vinter, Stuart Guthrie, Suchet Singh Khalsa, Ted Hardie, Tim Hare, Timo Sirainen, Vicky Oliver, Paul Hill, and Yael Shaham-Gafni.
アラン・デイヴィース、アンドレア・カンピ、アンドレCourtemanche、アンドリュー・デイヴィソン、コマツナギSrivastava、ArentJan Banck、アルノードQuillaudベンジャミンSonntag、バーナードDesruisseaux、バートランドGuiheneuf、ボブ・マホニー、ボブ・モーガン、ブルース・カーン、クリスDudding、クリスOlds、クリストファーアップル、Cortlandtは避寒します、クレイグ・ジョンソン、サイラスDaboo、ダモン・チャップリン、ダン・ヒックマン、ダン・コーン、ダン・ウィンシップ、ダリルChampagne、デヴィッド・C.シューリス、デヴィッド・ニコル、デヴィッドNusbaum、デヴィッド西洋Derik Stenerson、エリックR; プラモンドン、フランク・ドーソン、フランクNitsch、ゲーリー・フレディリック、ゲーリーMcGath、ジルFortin、グラハム・ギルモア、グレッグ・バーンズ、グレッグFitzPatrick、ハラルドAlvestrand、Harrie Hazewinkel、ヘルガ・ヘス、ジェーガンGarimella、ジェイ・パーカー、ジム・レイ、ジム・スミス、ヨルク・ライヒェルト、ジョンBerthels、ジョン・スミス、ジョンStracke; ジョナサンレノックス、JP Rosevear、カレン・チュウ、ケイティーキャップParlante、Keesクック、ケン・クロフォード、気ウォン、ラース・エッゲルト、Lata Kannan、ローレンス・グリーンフィールド・リビー・ミラー、リサDusseault、リンドン・ネーレンバーグ、マークディヴィッドソン、マークパターソン、マークスミス、マークスワンソン、マークタール、マーシャル・ローズ、マルティjnバンビアース、マーチン・ジャクソン、マッチアスLaabs、マックスFroumentin、ミカGorrell、マイケルFair、マイクHigginbottom、マイクHixson、誠ムラタ、ナタリア・シラクサ、ナザニエルBorenstein、ネッド・フリード、オリビエGutknecht、パトリス・ラピエール、パトリスScattolin、ポール・ホフマン、ポール・シャープ、Payod Deshpande、ペッカPessi、ピータートンプソン、プレストンスティーヴンソン、PrometeoサンディノのローマCorral; ラルフ・パターソン、ロバートLusardi(ロバートRansdell)はSiemborski、Satyanarayana Vempati、Satya Vempati、スコットHollenbeck、シェイマスGarvey、シャノン・クラーク、Shriramウィシュワナタン、スティーブCoya、スティーブ・マンスール、スティーブ・ミラー、スティーブ・ビンテル、スチュアート・ガスリー、スーシェシンKhalsa、テッド・ハーディー、ティムHare、ティモSirainen、ビッキー・オリバー、ポール・ヒル、およびYael Shaham-Gafniから略奪します。
Appendix B. References
付録B.参照
Appendix B.1. Normative References
付録B.1。 引用規格
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[鳴ります] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081,
March 2001.
M. [BEEPTCP]ローズ、RFC3081、「TCPへのビープ音コアを写像すること」での3月2001日
[BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596-
00244-0, O'Reilly & Associates, Inc.
ローズ、M.、「ビープ音、決定的なガイド」の[BEEPGUIDE]ISBN0-596- 00244-0、オライリー、および仲間Inc.
Royer, et al. Experimental [Page 127] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [127ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
[GUIDE] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet
Calendaring", RFC 3283, June 2002.
[誘導します] 2002年6月のマホニーとB.とBabics、G.とA.Taler、「インターネットCalendaringへのガイド」RFC3283。
[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、1998年11月。
[iTIP] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson,
"iCalendar Transport-Independent Interoperability
Protocol (iTIP) Scheduling Events, BusyTime, To-dos and
Journal Entries", RFC 2446, November 1998.
[iTIP] シルバーバーグ、S.、マンスール、S.、ドーソン、F.、およびR.ホプソン、「出来事、BusyTime、大騒ぎ、および仕訳記入の計画をするiCalendarの輸送から独立している相互運用性プロトコル(iTIP)」、RFC2446(1998年11月)。
[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、1998年11月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[MIME]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。
Appendix B.2. Informative References
付録B.2。 有益な参照
[CHARREG] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", RFC 2278, January 1998.
解放された[CHARREG]とN.とJ.ポステル、「IANA Charset登録手順」、RFC2278、1998年1月。
[CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and
Languages", RFC 2277, January 1998.
[CHARPOL] Alvestrand、H.、「文字コードと言語に関するIETF方針」、RFC2277、1998年1月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka
ANSI X3.135-1992, aka FIPS PUB 127-2
[SQL92]「データベース言語SQL」、ANSI/ISO/IEC9075: 1992、通称ANSI X3.135-1992、通称FIPS PUB127-2
[SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1
to ISO/IEC 9075: 1992, also adopted as Amendment 1 to
ANSI X3.135.1992
[SQLCOM]ANSI/ISO/IEC9075: 1992/TC-1-1995、Technical間違い1からISO/IEC9075: また、Amendment1としてANSI X3.135.1992に採用された1992
[URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November
1999.
1999年11月の[URLGUIDE]MasinterとL.とAlvestrandとH.とZigmond、D.とR.Petke、「新しいURL Schemesのためのガイドライン」RFC2718。
Royer, et al. Experimental [Page 128] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [128ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005.
[URI]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC3986、2005年1月。
[URL] Berners-Lee, T, Masinter, L., and M. McCahil, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[URL] バーナーズ・リーとTとMasinter、L.とM.McCahil、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[X509CRL] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[X509CRL] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
Royer, et al. Experimental [Page 129] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [129ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Authors' Addresses
作者のアドレス
Doug Royer IntelliCal, LLC 267 Kentlands Blvd. #3041 Gaithersburg, MD 20878 US
ダグロワイエーIntelliCal、LLC267Kentlands Blvd. #3041 MD20878ゲイザースバーグ(米国)
Phone: +1-866-594-8574 Fax: +1-866-594-8574 EMail: Doug@IntelliCal.com URI: http://Royer.com
以下に電話をしてください。 +1-866-594-8574 Fax: +1-866-594-8574 メールしてください: Doug@IntelliCal.com ユリ: http://Royer.com
George Babics Oracle 600 Blvd. de Maisonneuve West Suite 1900 Montreal, Quebec H3A 3J2 CA
ジョージBabicsオラクル600のBlvd.のdeのメゾンヌーブの西Suite1900モントリオール、ケベックH3A 3J2 CA
Phone: +1-514-905-8694 EMail: george.babics@oracle.com
以下に電話をしてください。 +1-514-905-8694 メールしてください: george.babics@oracle.com
Steve Mansour eBay 2145 Hamilton Avenue San Jose, CA 95125 USA
スティーブマンスールeBay2145ハミルトン・Avenueカリフォルニア95125サンノゼ(米国)
Phone: +1-408-376-8817 EMail: smansour@ebay.com
以下に電話をしてください。 +1-408-376-8817 メールしてください: smansour@ebay.com
Royer, et al. Experimental [Page 130] RFC 4324 Calendar Access Protocol December 2005
ロワイエー、他 [130ページ]実験的なRFC4324カレンダーアクセス・プロトコル2005年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Royer, et al. Experimental [Page 131]
ロワイエー、他 実験的[131ページ]
一覧
スポンサーリンク
