ICalendar
iCalendar（アイカレンダー）とはPIMソフトなどで使われるスケジュールの標準フォーマット。RFC 5545 （旧版 RFC 2445）で規定されている。「iCal」と略称されるが、アップルの同名カレンダー・プログラムもある（→iCal）ので注意が必要である。
iCalendarをサポートしたソフトウェアを使うことで、他のユーザーに対してミーティングの時間や予定を電子メール経由で知らせることが容易になり、メールの受信者もミーティングの日時を簡単に提案できるようになる。
iCalendarは多くの製品に実装、サポートされている。そのデータは従来の電子メールで交換され、仕様上、送信プロトコルに依存しないこととなっている。たとえばWebDAVサーバやSyncMLを使って共有や編集が行える。HTTPプロトコルしか使用しないシンプルなWebサーバは、iCalendarフォーマットのスケジュールデータを配付するために使われる。hCalendarを使えばWebページにiCalendarデータを埋め込むことができる。
iCalendarの仕様はオープンテキストのアニク・ガングリーを議長とする、Internet Engineering Task Forceのカレンダー・スケジュール作業部会によって定められた。仕様の記述はロータス社のフランク・ドーソン、マイクロソフトのデリック・ストナーソンによる。iCalendarの仕様はインターネットメール・コンソーシアム (IMC) によって規定されたvCalendarに依拠している。
iCalendarデータのMIMEタイプは「text/calendar」である。
このMIMEタイプを持つカレンダー・スケジュールデータファイルには、拡張子「ics」が付けられる。（Mac OSではタイプコード「iCal」）
「free and busy time」（空いた時間と予定のある時間）を含むデータには拡張子「ftb」が付与される。（Mac OSではタイプコード「iFBf」）
iCalendarデータはプレーンテキストで、デフォルトでUTF-8が使用される。別の文字コードを使うときは「charset」MIMEパラメータで指定することができる。各行は CR + LF (16進:0D0A) で改行され、各行75オクテットの文字数制限がある。次の行にまたぐ場合はスペース (16進:20) またはタブ (16進:09)で行を始めることで、前行からの続きであることを明示できる。データ項目内での改行をしたい場合は「バックスラッシュ + N」（UTF-8で5C6Eまたは5C4E、n）でコーディングする。
iCalendarの先頭には「カレンダー・スケジュール・コア・オブジェクト」が位置する。これはカレンダーとスケジュール情報の集合体である。最小単位は単一のiCalendarオブジェクトであり、これらが複数まとめられている。1行目は必ず「BEGIN:VCALENDAR」で始まる必要があり、最後は「END:VCALENDAR」で終わる。この行の間には「icalbody」と呼ばれる主データ記述が入る。主データ部は一連のカレンダー・プロパティおよびカレンダー・コンポーネントからなり、前者は全体の属性を記述、後者は具体的な用事や日程、日時などのタイムスケジュールが記述され、アラーム設定なども行われる。
RFC 2445によるシンプルなiCalendarオブジェクトのサンプルを以下に示す。内容は1997年7月14日-15日のパリ祭に関するものである。
この標準仕様には他にも以下に述べるような様々なコンポーネントが定義されている。Apple iCal やマイクロソフトのOutlookでは次のような追加記述子が使われる。
X-WR-RELCALIDは汎用一意識別子 (UID) である。
VEVENTコンポーネントはカレンダー上で予定されたイベントについて記述された属性の集合体である。これは具体的な用件だけでなく、「TRANSPARENT」（白紙）といった記述も可能である。アラームを定義する場合、VEVENT内部にVALARMコンポーネントが含まれる。また開始時刻を定義するDTSTARTプロパティと終了時刻を定義するDTENDプロパティを持つ。
記念日や毎日行うことのように何度も繰り返されるイベントもVEVENTで記述される。標準ではDATE-TIMEに日時が記述されるが、DTSTARTプロパティが日時データを持ち、DTENDプロパティは持たない。
予定をキャンセルするときもUIDはそのまま保持され、他のコンポーネントには がセットされる。
ToDO、つまりアクションアイテムや宿題事項のことが記述されるコンポーネント。下記はRFC 2445による1998年4月15日のToDoについて記述したサンプルである。
VJOURNALコンポーネントは日誌のように特定の日付にコメントを付けたり、作業内容や進捗の実績を記録するために利用される。実際のところ、iCalendarの実装でVJOURNALをサポートしているものはほとんど無い。プラムカナリーズ・チャープ・ソフトウェア社は、プロジェクトタスクの進捗管理ソリューションのデータフォーマットとしてVTODOとVJOURNALを採用している。また、KDEのシステム手帳、KOrganizerもVJOURNALをサポートしている。
下記はRFC 2445によるVJOURNALの記述サンプルである。
VFREEBUSYコンポーネントはフリー・ビジータイム……つまり空いた時間と予定のある時間を定義する。以下はRFC 2445による予定時間情報を記述したサンプルである。特定のURLに置かれる場合、拡張子は「ifb」となる。予定されたスケジュールに変更がかかった場合、UIDフィールドを利用して改訂版の割り当てが行われる。最初に予定が設定されたときに一意の識別子 (UID) が生成され、スケジュールに変更がかかったときも同じUIDで発行される。UIDの例としては、「とある大学の第2学期131学級の5回目の打ち合わせ」なら「Y2007S2C131M5@example.com」という具合になる。
iCalendarフォーマットはカレンダーベースのデータを記述するために設計されており、即座にこのデータをもって何かを記述するわけではないので、実際の運用には他の規約が必要となることがある。
付属規約であるiTIPプロトコル (RFC 5546) はカレンダーユーザー間でカレンダー・スケジュールデータを交換するための規約であり、最初に交換を提案した人が「オーガナイザ」と呼ばれることになる。この標準は「発行」「要求」「応答」「追加」「中止」「更新」「撤回」「撤回却下」といったメソッドを定義する。
他の付属規約にIMIPプロトコル (RFC 6047) がある。これは電子メールでの通信にiTIPを実装する手順に関する仕様である。
RFC 3283の「インターネット・カレンダー・ガイド」ではiCalendarと関連規格との様々な関係が述べられている。
iCalendarフォーマットはカレンダーデータの相互運用もサポートしている。使用頻度の高い、基本的な特徴はiCalendar実装時にサポートされ、互換性も高いのだが、拡張機能のようなものになると途端に実装度合いは低下してしまう。ほとんどのベンダーは「JOURNAL」をサポートしていないし、予定の繰り返しやスケジュール反復も相互運用に不自然な問題を抱えている。VTODOプロパティも2004年時点での相互運用は出来ない状態である。
iCalendarはイスラエルやサウジアラビアなどで運用されている非グレゴリオ暦ではカレンダーへの記入もままならない。それらの暦をグレゴリオ暦に一対一で置き換えることも様々な要因で困難を極める。例えばヘブライ暦では13月というものが存在する場合があるし、天皇が変わるたびに変化する日本の元号も問題である
RFC 4324の「カレンダーアクセスプロトコル」は最初の汎用スケジューリングデータ標準として普及を試みたが、その複雑な仕様により、実装されることなく終わった。現在GroupDAVやCalDAVといったiCalendarベースの実用的な通信プロトコルが、クライアント・サーバ双方のパッケージソフトに現れ、カレンダーアクセス標準としての地位を確保せんとしている。
IETFカレンダー・スケジュール作業部会は、過去の標準を参照し、カレンダー・スケジューリングコンソーシアム (Calconnect) のような他の作業部会とも連携を取りながら、iCalendar標準の改定プロセスに入っている。2004年設立のCalconnectは専門委員会により実装及び相互運用試験を行う機関であり、あらゆる団体、個人も加入が可能である。
vCalendar1.0はインターネットメール・コンソーシアム (IMC) によって公表されたiCalendarフォーマットの元となった規格である。以下がその例。
IMCはiCalendarリリース後、ベンダーがこれらのオープンフォーマットを採用して、vCalendar1.0とiCalendarの両方に互換性をもつソフトウェアを開発するよう呼びかけている。
iCalendarデータファイル生成のため、様々なプログラミング用ライブラリが公開されている。