configureとか [SQLite]
先週の最後に落とした「sqlite-src-3071200.zip」の方を解凍してみたところ、ばらのソースが一式入っていました。入っていた「README」を読んだところ、「configure」して、「make」しろとのこと。こちらはこのドキュメントにビルド方法が書かれていますね・・。
*
「configure」スクリプトは、「autoconf 2.61」と「libtool」を使用するとのこと。「autoconf」はずっと以前にちらっと出てきましたね。その記事によると、configureを作るためにautoconfを使ってるとのことですが、今回は逆ですか・・。それはさておき、「configure」がうまく動かない時は「Makefile.linux-gcc」を使えとのこと。
「configure」とか「autotools」とかは以前調べた様な気がするんですが、頭に残って無い上に記事も見つかりませんね・・・。
ちなみに、Linux向けバイナリは makefile で作成されていて、configure は使って無いとか。詳しくは「publish.sh」スクリプトを見ろとか・・。それはそうと、Amalgamationの方法が見つかりませんね・・。非公開なんでしょうか・・。
どうしようかな・・。
*
「configure」スクリプトは、「autoconf 2.61」と「libtool」を使用するとのこと。「autoconf」はずっと以前にちらっと出てきましたね。その記事によると、configureを作るためにautoconfを使ってるとのことですが、今回は逆ですか・・。それはさておき、「configure」がうまく動かない時は「Makefile.linux-gcc」を使えとのこと。
「configure」とか「autotools」とかは以前調べた様な気がするんですが、頭に残って無い上に記事も見つかりませんね・・・。
ちなみに、Linux向けバイナリは makefile で作成されていて、configure は使って無いとか。詳しくは「publish.sh」スクリプトを見ろとか・・。それはそうと、Amalgamationの方法が見つかりませんね・・。非公開なんでしょうか・・。
どうしようかな・・。
SQLiteのアーカイブを開梱してみる [SQLite]
前回から、SQLiteを見て行くことにしましたが、ダウンロードサイトから「sqlite-amalgamation-3071100.zip」を落として解凍したところ・・・、ソースコードのみ。
configureファイルとか、makefileとかをどんな感じにしてるのか見たかったのに、無いの？？？と思ってよく見たところ、下にある「sqlite-autoconf-3071100.tar.gz」にソースとそのあたりのスクリプトファイルが含まれている様でした。後、Tcl（TEA）のための拡張も入ってるとか。
*
解凍したところ、ソースファイル以外にもたくさんファイルが入ってますね。まず、「README」を読んでみましょう。構成としては、「sqlite3.c」が本体のソースで、一ファイルになっている様です。インストール方法については「INSTALL」を読めとのことです。
ソースについては、扱いはその方が楽でしょうが、保守が大変そうですねぇ・・・。と思っていたところ、こちらのページに実際には96ファイルのCソースで構成されているとの記載がありました。何らかの方法で一つのファイル「sqlite3.c」にまとめている様です。その方法も興味ありますねぇ・・・。よく見たら、このファイルは4.5MBくらいのサイズがあります・・。このファイルはSQLiteのコア部分と、「FT3」「RTREE」と言う拡張を含んでいる様ですね。
で、そのAPIはヘッダファイル「sqlite3.h」に含まれているとのこと。でも、アーカイブに含まれているソース「sqlite3.c」にはそのヘッダファイルの中身も含まれているらしいです。「sqlite3.c」しか手に入らない状況で、「sqlite.h」も欲しいと言う場合には、「sqlite3.c」から該当部分をコピペして「sqlite3.h」を自前で作ることも可能だとか・・。ビルド時はこの「sqlite3.c」を使った方が速いだろうとのことです。
*
ソースツリーが欲しいなと思っていたところ、ダウンロードページの下の方に「Leagcy Source Code Distribution Formats」として、配布されていました。奨励はされていない様ですが・・。結合（amalgamation?）の仕方が知りたいんですが、ここにその情報は入ってますかねぇ・・・。
つづく。
configureファイルとか、makefileとかをどんな感じにしてるのか見たかったのに、無いの？？？と思ってよく見たところ、下にある「sqlite-autoconf-3071100.tar.gz」にソースとそのあたりのスクリプトファイルが含まれている様でした。後、Tcl（TEA）のための拡張も入ってるとか。
*
解凍したところ、ソースファイル以外にもたくさんファイルが入ってますね。まず、「README」を読んでみましょう。構成としては、「sqlite3.c」が本体のソースで、一ファイルになっている様です。インストール方法については「INSTALL」を読めとのことです。
ソースについては、扱いはその方が楽でしょうが、保守が大変そうですねぇ・・・。と思っていたところ、こちらのページに実際には96ファイルのCソースで構成されているとの記載がありました。何らかの方法で一つのファイル「sqlite3.c」にまとめている様です。その方法も興味ありますねぇ・・・。よく見たら、このファイルは4.5MBくらいのサイズがあります・・。このファイルはSQLiteのコア部分と、「FT3」「RTREE」と言う拡張を含んでいる様ですね。
で、そのAPIはヘッダファイル「sqlite3.h」に含まれているとのこと。でも、アーカイブに含まれているソース「sqlite3.c」にはそのヘッダファイルの中身も含まれているらしいです。「sqlite3.c」しか手に入らない状況で、「sqlite.h」も欲しいと言う場合には、「sqlite3.c」から該当部分をコピペして「sqlite3.h」を自前で作ることも可能だとか・・。ビルド時はこの「sqlite3.c」を使った方が速いだろうとのことです。
*
ソースツリーが欲しいなと思っていたところ、ダウンロードページの下の方に「Leagcy Source Code Distribution Formats」として、配布されていました。奨励はされていない様ですが・・。結合（amalgamation?）の仕方が知りたいんですが、ここにその情報は入ってますかねぇ・・・。
つづく。
SQLiteを見てみる [SQLite]
延々とiCalendarの仕様を見てきましたが、一応前回で一通りは見れたのかなと思ってます。まだ、見ようと思ってたところがあった様な気もしますが、まあ、必要になった時に見ることにしましょう。
で、なんでiCalendarの仕様を見てたかと言うと、何となくライブラリを作成してみたいなぁと思っていたのでした。が、仕様を見始めたのが、一年以上前。と言うことで、仕事ならいないことにされそうな速度ですね。
まあ、こんなペースなので、まあ完成なんて、夢物語みたいなものですが、そもそも汎用ライブラリ的なものを作ったことが無いため、お手本としてSQLiteがどんな感じでできているのかと言うのを見たいと思います。・・・・これも、一年以上かかったりするかもしれませんが。。 ま、おそらくSQLight関連のサイトはたくさんあると思うので、その辺も参考にしましょう。
とりあえず、公式サイトからダウンロードしときます。ドキュメントも充実している様ですね。
と言うことで、また延々と続けて行きます。（たぶん）
で、なんでiCalendarの仕様を見てたかと言うと、何となくライブラリを作成してみたいなぁと思っていたのでした。が、仕様を見始めたのが、一年以上前。と言うことで、仕事ならいないことにされそうな速度ですね。
まあ、こんなペースなので、まあ完成なんて、夢物語みたいなものですが、そもそも汎用ライブラリ的なものを作ったことが無いため、お手本としてSQLiteがどんな感じでできているのかと言うのを見たいと思います。・・・・これも、一年以上かかったりするかもしれませんが。。 ま、おそらくSQLight関連のサイトはたくさんあると思うので、その辺も参考にしましょう。
とりあえず、公式サイトからダウンロードしときます。ドキュメントも充実している様ですね。
と言うことで、また延々と続けて行きます。（たぶん）
タイムゾーン識別子の続き [iCalendar]
前回の続きです。
「TZID」プロパティパラメータで、適用する「VTIMEZONE」カレンダーコンポーネントを特定すると言うことでしたが、そのため、個々の「VTIMEZONE」カレンダーコンポーネントはiCalendarオブジェクト内でそれぞれユニークな「TZID」パラメータを設定しなければならないとのこと（MUST）。スコープは「iCalendarオブジェクト内」なんですね。他のパラメータも含めて、スコープは把握する必要がありますねぇ・・。
「VTIMEZONE」がiCalendarオブジェクト内で特定できなかった場合、時間はローカル時刻となり、不定（と言うか、ちゃんと理解できない）な状況になる様です・・・。ローカル時刻として扱うという明確な記載も無いですね・・。と言うことで、ここはりカバー無しの様ですね。
プリフィックスとして「SOLIDUS」キャラクタ（「/」スラッシュのことの様子）がある場合、この「TZID」はタイムゾーンレジストリにグローバルに定義されている固有のIDであることを示す。
また、本仕様では、「TZID」に関する命名規則は定義しないとのこと。実装の際はこちらのパブリックドメインのタイムゾーンデータベースなど、既存の仕様にならうといいかもとか。
使用例を下記に示す。
「TZID」プロパティパラメータはDATEプロパティやUTC表記のDATE-TIME, TIMEプロパティにはは使用しないこと（MUST NOT）。
「VTIMEZONE」カレンダーコンポーネントがiCalendarオブジェクト内に定義されていない場合は、「TZID」プロパティが設定されていないローカルタイムのDATE-TIME、TIME値は「floating time」として解釈される。
詳しくは、「DATE-TIME」「TIME」型の説を参照とのことです。
とりあえず、この節は完了。
「TZID」プロパティパラメータで、適用する「VTIMEZONE」カレンダーコンポーネントを特定すると言うことでしたが、そのため、個々の「VTIMEZONE」カレンダーコンポーネントはiCalendarオブジェクト内でそれぞれユニークな「TZID」パラメータを設定しなければならないとのこと（MUST）。スコープは「iCalendarオブジェクト内」なんですね。他のパラメータも含めて、スコープは把握する必要がありますねぇ・・。
「VTIMEZONE」がiCalendarオブジェクト内で特定できなかった場合、時間はローカル時刻となり、不定（と言うか、ちゃんと理解できない）な状況になる様です・・・。ローカル時刻として扱うという明確な記載も無いですね・・。と言うことで、ここはりカバー無しの様ですね。
プリフィックスとして「SOLIDUS」キャラクタ（「/」スラッシュのことの様子）がある場合、この「TZID」はタイムゾーンレジストリにグローバルに定義されている固有のIDであることを示す。
また、本仕様では、「TZID」に関する命名規則は定義しないとのこと。実装の際はこちらのパブリックドメインのタイムゾーンデータベースなど、既存の仕様にならうといいかもとか。
使用例を下記に示す。
|
DTSTART;TZID=America/New_York:19980119T020000 DTEND;TZID=America/New_York:19980119T030000 |
「TZID」プロパティパラメータはDATEプロパティやUTC表記のDATE-TIME, TIMEプロパティにはは使用しないこと（MUST NOT）。
「VTIMEZONE」カレンダーコンポーネントがiCalendarオブジェクト内に定義されていない場合は、「TZID」プロパティが設定されていないローカルタイムのDATE-TIME、TIME値は「floating time」として解釈される。
詳しくは、「DATE-TIME」「TIME」型の説を参照とのことです。
とりあえず、この節は完了。
タイムゾーン識別子 [iCalendar]
さて、今回はTZIDプロパティパラメータを見てみます。以前も軽く見たことがある様ですね。ちなみに、TZIDについては、こちらでも軽く見たとおり、タイムゾーンコンポーネントのプロパティとしての説明もある様です。合わせて見といたほうがいいかもしれません。
表記は次の通り。
・・・例では「TZID=America/New_York」みたいな書き方をされてるんですが、上記の記述と合わない気がしますね・・。Errataにも見当たらないんですが、どうなんでしょう・・・？
このパラメータは下記のプロパティで「DATE-TIME」か「TIME」型のUTCでも「floating time」でも無い値を設定する際は記載しなければならないそうです（MUST）。・・・なんか、当たり前で意味不明な気もしますね？？
このプロパティパラメータはプロパティに適用する「VTIMEZONE」カレンダーコンポーネントを指定するテキストを記載するとのこと。「VTIMEZONE」の説明をちらっと見たところ、確かに定義に対するラベルの様なのを書く項目があります。こちらもたどっておく必要がありますね・・。過去に見たかな・・？
・・・と、まだ途中なんですが、ちょっと時間が無くなったので、つづく。
表記は次の通り。
|
tzidparam = "TZID" "=" [tzidprefix] paramtext tzidprefix = "/" |
・・・例では「TZID=America/New_York」みたいな書き方をされてるんですが、上記の記述と合わない気がしますね・・。Errataにも見当たらないんですが、どうなんでしょう・・・？
このパラメータは下記のプロパティで「DATE-TIME」か「TIME」型のUTCでも「floating time」でも無い値を設定する際は記載しなければならないそうです（MUST）。・・・なんか、当たり前で意味不明な気もしますね？？
- DTSTART
- DTEND
- DUE
- EXDATE
- RDATE
このプロパティパラメータはプロパティに適用する「VTIMEZONE」カレンダーコンポーネントを指定するテキストを記載するとのこと。「VTIMEZONE」の説明をちらっと見たところ、確かに定義に対するラベルの様なのを書く項目があります。こちらもたどっておく必要がありますね・・。過去に見たかな・・？
・・・と、まだ途中なんですが、ちょっと時間が無くなったので、つづく。
時間の種類の抽出 [iCalendar]
とりあえず、どっから行けばいいかなぁと考えて、型から見て行くことにしました。DATE、DATE-TIME、DURATION、PERIOD、TIME、UTC-OFFSET辺りが該当しますでしょうか・・。
ちなみに以前、型について見たのはこちらです。この回の内容を見ていると、DATE-TIME型の表記方法で全てが見れる様な気がします。以下の3つが定義されていますね。
それぞれについて見て行こうかと思いますが、その前に一点、DATE-TIME値にUTCオフセットは使用するなとのこと（MUST NOT）。
それでは、見て行きます。
【ローカル時刻】
表記は単純に「19980118T230000」で1998年1月18日午後11時を示します。で、このタイプのものは「Floating time」と呼ばれ、いずれのタイムゾーンにも紐付けられないとのことです。と言うことで、どのタイムゾーンに入ってもこの表記で書かれた時間は変わらないとのこと。例えば、ローカル時刻で毎日11:00AM～1:00PMと定義されているイベントはその人が日本にいようが、アメリカにいようがどこにいようと毎日11:00AM～1:00PMのイベントになるとのこと。下記の縛りがあります。
「VTIMEZONE」カレンダーコンポーネントがiCalendarオブジェクト内にない限り「Floating time」として扱うこととのことです。
【UTC時刻】
そもそも「UTC」って何と思って調べたところ、Universal Time, Coordinatedの略で、「協定世界時」だそうです。
表記はローカル時刻のフォーマットの末尾に「Z」を付加するとのこと。「19980119T070000Z」でUTC時刻の1998年1月19日の午前7時となるようです。時刻表記はたぶん24時間表記ですね。と思って、一応3.3.12 Timeの節を確認したところ、時間は「0-23」で表記する様です。
で、UTC時刻を使う場合は「TZID」プロパティパラメータ（タイムゾーンの指定）は付加してはならない（MUST NOT）とのことです。
【タイムゾーン指定のローカル時刻】
「TZID」プロパティパラメータを使用して、タイムゾーンを指定した形で日時を表記するものです。「TZID=America/New_York:19980119T020000」で、ニューヨークでの1998年1月19日午前2時を表します。
この表記の場合、サマータイム（daylight time）から標準時刻（standard time）への変更時に同じ時刻が一回以上（2回？）発生する場合がありますが、DATE-TIME値は最初に発生する時点を指すとのことです。逆に標準時刻（standard time）からサマータイム（daylight time）への変更時には指定した時刻が1度も発生しない可能性があります。この場合は、ローカル時刻でギャップが生じる前にUTCオフセットを用いて解釈しますとのこと。
また、うるう秒は時刻表記内の秒の箇所に「60」で表記しなければならい（MUST）。うるう秒をサポートしていない実装は「60」秒を「59」秒として扱うべき（SHOULD）。
以上が、DATE-TIME型について記載されていた内容です。TIME型にも同じ様な説明がありそうだったので、また見とこうと思います。後、「TZID」プロパティがテキストでの記載となっています。このあたり、どういう値が定義されているのか見ときたいですね。
と言うことで、次回は「TZID」を見ようと思います。
ちなみに以前、型について見たのはこちらです。この回の内容を見ていると、DATE-TIME型の表記方法で全てが見れる様な気がします。以下の3つが定義されていますね。
- ローカル時刻
- UTC時刻
- タイムゾーン指定のローカル時刻
それぞれについて見て行こうかと思いますが、その前に一点、DATE-TIME値にUTCオフセットは使用するなとのこと（MUST NOT）。
それでは、見て行きます。
【ローカル時刻】
表記は単純に「19980118T230000」で1998年1月18日午後11時を示します。で、このタイプのものは「Floating time」と呼ばれ、いずれのタイムゾーンにも紐付けられないとのことです。と言うことで、どのタイムゾーンに入ってもこの表記で書かれた時間は変わらないとのこと。例えば、ローカル時刻で毎日11:00AM～1:00PMと定義されているイベントはその人が日本にいようが、アメリカにいようがどこにいようと毎日11:00AM～1:00PMのイベントになるとのこと。下記の縛りがあります。
- ローカル時刻で記載されたiCalendarオブジェクトを受けた場合は、相手がいずれのタイムゾーンにいたとしても、その時刻で解釈するべき（SHOULD）。
- 「Floating time」はそれを使用するのが妥当な場合のみ使用されるべき（SHOULD）。
- 固定的な時間でやり取りする際は、UTC時刻かタイムゾーン付きのローカル時刻でやり取りしなければならない（MUST）。
「VTIMEZONE」カレンダーコンポーネントがiCalendarオブジェクト内にない限り「Floating time」として扱うこととのことです。
【UTC時刻】
そもそも「UTC」って何と思って調べたところ、Universal Time, Coordinatedの略で、「協定世界時」だそうです。
表記はローカル時刻のフォーマットの末尾に「Z」を付加するとのこと。「19980119T070000Z」でUTC時刻の1998年1月19日の午前7時となるようです。時刻表記はたぶん24時間表記ですね。と思って、一応3.3.12 Timeの節を確認したところ、時間は「0-23」で表記する様です。
で、UTC時刻を使う場合は「TZID」プロパティパラメータ（タイムゾーンの指定）は付加してはならない（MUST NOT）とのことです。
【タイムゾーン指定のローカル時刻】
「TZID」プロパティパラメータを使用して、タイムゾーンを指定した形で日時を表記するものです。「TZID=America/New_York:19980119T020000」で、ニューヨークでの1998年1月19日午前2時を表します。
この表記の場合、サマータイム（daylight time）から標準時刻（standard time）への変更時に同じ時刻が一回以上（2回？）発生する場合がありますが、DATE-TIME値は最初に発生する時点を指すとのことです。逆に標準時刻（standard time）からサマータイム（daylight time）への変更時には指定した時刻が1度も発生しない可能性があります。この場合は、ローカル時刻でギャップが生じる前にUTCオフセットを用いて解釈しますとのこと。
また、うるう秒は時刻表記内の秒の箇所に「60」で表記しなければならい（MUST）。うるう秒をサポートしていない実装は「60」秒を「59」秒として扱うべき（SHOULD）。
以上が、DATE-TIME型について記載されていた内容です。TIME型にも同じ様な説明がありそうだったので、また見とこうと思います。後、「TZID」プロパティがテキストでの記載となっています。このあたり、どういう値が定義されているのか見ときたいですね。
と言うことで、次回は「TZID」を見ようと思います。
時間について [iCalendar]
長々と続けてRFC5545を一通りなめたことになっていますが、あちこちで「後で見る」としていた時間関係の話が残っています。普通にローカルタイムベースで考えると話は単純なのですが、昔、Zaurus向けにスケジューラアプリを作成した際、Zaurusの中でも複数の時間表記があって、整合性を取るのに苦労した気がします・・。と言うことで、ちゃんと押さえたいと思った次第であります・・。
*
さて、どう進めましょうか・・。まずは、目次から時間に関係のありそうな項目を書き連ねて行きましょうか。
とまあ、羅列するとこんな感じでしょうか・・。抜けがあるかもしれませんが、このあたりを足がかりに時間関係の仕様を追っていくことにします。
*
さて、どう進めましょうか・・。まずは、目次から時間に関係のありそうな項目を書き連ねて行きましょうか。
- 3.2.9 Free/Busy Time Type
- 3.2.19 Time Zone Identifier
- 3.3.4 Date
- 3.3.5 Date-Time
- 3.3.6 Duration
- 3.3.9 Period of Time
- 3.3.12 Time
- 3.3.14 UTC Offset
- 3.6.5 Time Zone Component
- 3.8.2 Date and Time Component Propaties
- 3.8.2.1 Date-Time Completed
- 3.8.2.2 Date-Time End
- 3.8.2.3 Date-Time Due
- 3.8.2.4 Date-Time Start
- 3.8.2.5 Duration
- 3.8.2.6 Free/Busy Time
- 3.8.2.7 Time Transparency
- 3.8.3 Time Zone Component Propaties
- 3,8.3.1 Time Zone Identifier
- 3.8.3.2 Time Zone Name
- 3.8.3.3 Time Zone Offset From
- 3.8.3.4 Time Zone Offset To
- 3.8.3.5 Time Zone URL
- 3.8.5.1 Exception Date-Times
- 3.8.5.2 Recurrence Date-Times
- 3.8.6.3 Trigger
- 3.8.7.1 Date-Time Created
- 3.8.7.2 Date-Time Stamp
- 3.8.7.3 Last Modified
とまあ、羅列するとこんな感じでしょうか・・。抜けがあるかもしれませんが、このあたりを足がかりに時間関係の仕様を追っていくことにします。
RFC2445との差分 [iCalendar]
ざ~っと見るのも最後になりますが、Appendix Aで、RFC2445との差分です。本ブログでは、RFC5545を見て行きましたが、まだ、メジャーなのはRFC2445なんですかね？その辺よく把握してません・・。まあ、とりあえず差分を見て行きましょう。
まず最初は新規に発生した制限事項から。
続いては、削除された制限事項について。
奨励されない点は下記の通り。
以上、やっと一通りなめ終わりました～っ！ どんだけかかっとんやと言う感じですが、まだ終わってません・・・。次回からは後回しにしていた、日付、時間関係の話題でも・・・。
まず最初は新規に発生した制限事項から。
- 「DTSTART」プロパティは繰り返しのルールが記述されていれば、そのルールに合致しているべき（SHOULD）
- 「RRULE」プロパティは一つのコンポーネントに複数は記述しないべき（SHOULD NOT）。
- 「BYHOUR」「BYMINUTE」「BYSECONDE」ルールは「DTSTART」プロパティが「DATE」値で記載されている時は「RRULE」プロパティに記載してはいけない（MUST NOT）。
- 「DTEND」もしくは「DUE」プロパティは「DTSTART」プロパティの型と一致しなければならない（MUST）。
- 「DURATION」プロパティは「VFREEBUSY」コンポーネントに記載されなくてもよい（制限事項？？）
- MIMEの通信に置いて、「charset」コンテントタイプパラメータの使用は必須。
続いては、削除された制限事項について。
- 「DTSTART」「DTEND」プロパティは繰り返し規則に使われた場合、ローカルタイムとタイムゾーンを記載する必要はない。
奨励されない点は下記の通り。
- 「EXRULE」プロパティはコンポーネント内に記載されなくてもよい。
- 「THISANDPRIOR」値は「RANGE」パラメータに使用されなくてもよい。
- 「PROCEDURE」値は「ACTION」プロパティに使用されなくてもよい。
- 「RECUR」型はCOMMAで区切られた値のリストによる複数の値を許容しない。
- 「x-name」部分は、「RECUR」型のプロパティの記載に使用されない。代わりに「x-param」は記載可能。
以上、やっと一通りなめ終わりました～っ！ どんだけかかっとんやと言う感じですが、まだ終わってません・・・。次回からは後回しにしていた、日付、時間関係の話題でも・・・。
IANAに登録されているコンポーネント - IANAについて [iCalendar]
8.2はIANAへの新規要素の登録に関する手続きが書かれている様ですが、とりあえず、仕様の把握には関係なさげなので飛ばします。
で、コンポーネントについて。次のものが登録されている様です。
・・・と言うのを続けようかと思いましたが、RFCを見ればわかるので、あまり意味がありませんね・・・。
次回はAppendixでも見て行くことにします。
で、コンポーネントについて。次のものが登録されている様です。
| VCALENDAR | RFC 5545 Section 3.4 |
| VEVENT | RFC 5545 Section 3.6.1 |
| VTODO | RFC 5545 Section 3.6.2 |
| VJORNAL | RFC 5545 Section 3.6.3 |
| VFREEBUSY | RFC 5545 Section 3.6.4 |
| VTIMEZONE | RFC 5545 Section 3.6.5 |
| VALARM | RFC 5545 Section 3.6.5 |
| STANDARD | RFC 5545 Section 3.6.5 |
| DAYLIGHT | RFC 5545 Section 3.6.5 |
・・・と言うのを続けようかと思いましたが、RFCを見ればわかるので、あまり意味がありませんね・・・。
次回はAppendixでも見て行くことにします。
iCalendarのMedia Type - IANAについて [iCalendar]
続いては、IANAについてです。結構ボリュームがあるので、一つ一つ見て行きます。今回は「8.1. iCalendar Media Type Registration」です。
MIME content type の「text/calnedar」として登録されています。詳細は下記の通り。
と言う感じですが、まとまって無いですねぇ・・・。まあ、いいか・・。
【参考】
・UTF-8 - Wikipedia
MIME content type の「text/calnedar」として登録されています。詳細は下記の通り。
| Type name | text | |
| Subtype name | calendar | |
| Required parameters | none | |
| Optional parameters | charset | RFC2046でtextメディアタイプのサブタイプとして定義されている。このリビジョンのiCalendarがサポートしているのは「UTF-8」。ただし、「UTF-8」と「US-ASCII」で記述されたiCalendarストリームを受容すること（MUST）。 |
| method | iCalendarオブジェクトの配送方法やカレンダー、スケジュール情報の配送形式に利用される。iCalendarオブジェクトを構成するプロパティと値の制限されたセットの識別にも用いられる。パラメータはボディ部分に含まれる情報の解釈の基準となる。個々のmethodの定義が明確にその方法で利用されない限り、情報の特定の部分のみの取り出しや要求には使用すべきでない（SHOULD NOT）。特定のmethod定義により明確に制限されない限り、「text/calendar」コンテントタイプは「Calendaring and Scheduling Core Object Specification」で許容される任意のプロパティを含むことができる。iCalendarストリーム内のiCalendarオブジェクトが全て同じ値に設定された「METHOD」コンポーネントプロパティを含む場合、かつその場合のみ、「method」パラメータはiCalendarストリーム内のiCalendarオブジェクトの「METHOD」コンポーネントプロパティと同じ値にセットされなければならない（MUST）。値にはIANA-registered iCalendar object metodを設定する。 | |
| component | ボディ部分に含まれるiClendarカレンダーコンポーネントの型を伝える。iCalendarオブジェクトが一つ以上のコンポーネントタイプを含む場合、複数のコンポーネントパラメータが設定されなければならない（MUST）。コンポーネントパラメータは「VEVENT」「VTODO」「VJOURNAL」「VFREEBUSY」「VTIMEZONE」と、IANA定義のもの（iana-token）、独自定義のもの（x-name）となっています。 | |
| optinfo | ボディ部分にあるiCalendarオブジェクトについてのオプション情報を配送する。オプション情報はiCalendarオブジェクトによって記載された情報と矛盾しないこと（MUST）（？）。パラメータ値は文字列。 | |
| Encoding | 8ビットキャラクタを含むことが可能。iCalendarオブジェクトが7ビットに制限された地域で伝送される時は、「quoted-printable」もしくは「base64」の仕様が必要。BACKSLASHでエスケープすることも可能。 | |
| Security | 7章参照 | |
| Interoperability | 本メディアタイプは異なるシステムで情報をやり取りするための共通フォーマットを定義するよう意図されている。古くは「VCAL」に由来する。 | |
| Published Specification | 本仕様 | |
| Applecation | 本メディアタイプはインターネット上のカレンダー、スケジュールアプリで使用されるようデザインされている。iTIP[2446bis]、iMIP[2447bis]、CalDAV[RFC4791]で使用される。 | |
| Additional Information | Magic number | None |
| File extension |
「ics」：カレンダー、スケジュール情報用 「ifb」：FREE/BUSYタイム情報用 | |
| Mac file type code |
「iCal」：カレンダー、スケジュール情報用 「iFBf」：FREE/BUSYタイム情報用 | |
| Person & email address to contact for further information | 本仕様の「Author's Address」参照 | |
| Intended usage | COMMON | |
| Restrictions on usage | 特になし | |
| Author | 本仕様の「Author's Address」参照 | |
| Change controller | IETF | |
と言う感じですが、まとまって無いですねぇ・・・。まあ、いいか・・。
【参考】
・UTF-8 - Wikipedia
