iCalendar：ぐうたログ：So-net blog

	ブログをはじめるログイン

タイムゾーン識別子の続き　 [iCalendar]

前回の続きです。

「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」型の説を参照とのことです。

とりあえず、この節は完了。

2012-05-08 01:00 nice!(0) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

タイムゾーン識別子　 [iCalendar]

さて、今回はTZIDプロパティパラメータを見てみます。以前も軽く見たことがある様ですね。ちなみに、TZIDについては、こちらでも軽く見たとおり、タイムゾーンコンポーネントのプロパティとしての説明もある様です。合わせて見といたほうがいいかもしれません。

表記は次の通り。

tzidparam = "TZID" "=" [tzidprefix] paramtext
tzidprefix = "/"

・・・例では「TZID=America/New_York」みたいな書き方をされてるんですが、上記の記述と合わない気がしますね・・。Errataにも見当たらないんですが、どうなんでしょう・・・？

このパラメータは下記のプロパティで「DATE-TIME」か「TIME」型のUTCでも「floating time」でも無い値を設定する際は記載しなければならないそうです（MUST）。・・・なんか、当たり前で意味不明な気もしますね？？

DTSTART
DTEND
DUE
EXDATE
RDATE

このプロパティパラメータはプロパティに適用する「VTIMEZONE」カレンダーコンポーネントを指定するテキストを記載するとのこと。「VTIMEZONE」の説明をちらっと見たところ、確かに定義に対するラベルの様なのを書く項目があります。こちらもたどっておく必要がありますね・・。過去に見たかな・・？

・・・と、まだ途中なんですが、ちょっと時間が無くなったので、つづく。

2012-05-01 01:00 nice!(0) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

時間の種類の抽出　 [iCalendar]

とりあえず、どっから行けばいいかなぁと考えて、型から見て行くことにしました。DATE、DATE-TIME、DURATION、PERIOD、TIME、UTC-OFFSET辺りが該当しますでしょうか・・。

ちなみに以前、型について見たのはこちらです。この回の内容を見ていると、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」を見ようと思います。

2012-04-24 01:00 nice!(0) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

時間について　 [iCalendar]

長々と続けてRFC5545を一通りなめたことになっていますが、あちこちで「後で見る」としていた時間関係の話が残っています。普通にローカルタイムベースで考えると話は単純なのですが、昔、Zaurus向けにスケジューラアプリを作成した際、Zaurusの中でも複数の時間表記があって、整合性を取るのに苦労した気がします・・。と言うことで、ちゃんと押さえたいと思った次第であります・・。

*

さて、どう進めましょうか・・。まずは、目次から時間に関係のありそうな項目を書き連ねて行きましょうか。

とまあ、羅列するとこんな感じでしょうか・・。抜けがあるかもしれませんが、このあたりを足がかりに時間関係の仕様を追っていくことにします。

2012-04-17 01:00 nice!(0) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

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」は記載可能。

以上、やっと一通りなめ終わりました～っ！　どんだけかかっとんやと言う感じですが、まだ終わってません・・・。次回からは後回しにしていた、日付、時間関係の話題でも・・・。

2012-04-10 01:00 nice!(0) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

IANAに登録されているコンポーネント - IANAについて　 [iCalendar]

8.2はIANAへの新規要素の登録に関する手続きが書かれている様ですが、とりあえず、仕様の把握には関係なさげなので飛ばします。

で、コンポーネントについて。次のものが登録されている様です。

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でも見て行くことにします。

2012-04-03 01:00 nice!(0) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

iCalendarのMedia Type - IANAについて　 [iCalendar]

続いては、IANAについてです。結構ボリュームがあるので、一つ一つ見て行きます。今回は「8.1. iCalendar Media Type Registration」です。

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

2012-03-27 20:00 nice!(0) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

国際化とセキュリティを考える　 [iCalendar]

長々とコンポーネントプロパティを見てましたが、今回は一気に、6. Internationalization Considerations と7. Security Considerations を見て行きます。

まずは「国際化」について。と言うより、「多言語対応」と言う感じですけどね。2点だけ。

アプリケーションはiCalendarストリームをUTF-8で生成すること（MUST）
アプリケーションはUTF-8もしくは、US-ASCIIで生成されたiCalendarストリームを処理できること（MUST）

続いて、セキュリティについてです。カレンダー情報やスケジュール情報はプライバシーにかかわる情報なので、伝送プロトコルは下記の様な脅威に対するガードの能力を持っているものを使うこと。

盗聴
再生（コピー？？）
メッセージ挿入
削除
改変
中間者攻撃（man-in-the-middle attacks）

なお、本ドキュメントはデータのフォーマットとメディアタイプ「text/calendar」について定義しているだけなので、サービスやプロトコルとは独立しているとのこと。下記のプロトコルとかが使えるかもとか・・。

次回は、IANAについて。

2012-03-20 01:00 nice!(0) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

奨励事項　 [iCalendar]

続いて、「5. Recommended Practices」です。奨励事項が列挙されている様ですので、列挙しましょうかね・・。iCalendarオブジェクトの扱い方法です。

75オクテットを超える様なContent lineはfoldすべき（SHOULD）
繰り返しのコンポ―ネントに含まれる「RRULE」と「RDATE」プロパティの組み合わせが同じ開始日時（DATE-TIME）を示す複数のインスタンスを生成する時、それらは、合わせて、一つのインスタンスと見なすこと。
「ATTENDEE」プロパティに複数のメーリングリストを記載した結果、カレンダーユーザが同一のカレンダーコンポーネントに対して、複数の要求を受けた場合、カレンダーユーザはそのうち一つにのみ応答すること（SHOULD）。カレンダーユーザは、「ATTENDEE」プロパティの「MEMBER」パラメータで殿メーリングリストに所属しているのかを記載すること（SHOULD）。
実装では「SUMMARY」プロパティの値を255オクテットまで切り詰めることができるが、UTF-8のマルチバイト文字の途中で切らないこと（MUST NOT）。
実装で、秒がサポートされていない場合、「00」を時刻内の秒の位置に記載するべき（SHOULD）
「TZURL」値はファイルのURI型として記載しないこと（SHOULD NOT）。このURIは組織内では便利だが、インターネット上では問題になりえる。
「CATEGORIES」プロパティの英語の値として次を含むこと。カテゴリは任意の言語で記載可能。
- ANNIVERSARY
- APPOINTMENT
- BUSINESS
- EDUCATION
- HOLIDAY
- MEETING
- MISCELLANEOUS
- NON-WORKING HOURS
- NOT IN OFFICE
- PERSONAL
- PHONE CALL
- SICK DAY
- SPECIAL OCCASION
- TRAVEL
- VACATION
「RESOURCES」プロパティの英語の値に下記を含むこと。リソースは任意の言語で表記可能。
- CATERING
- CHAIRS
- COMPUTER PROJECTOR
- EASEL
- OVERHEAD PROJECTOR
- SPEAKER PHONE
- TABLE
- TV
- VCR
- VIDEO PHONE
- VEHICLE

1. の「75オクテット」って微妙ですね。多バイト文字の時とかって、どう扱うのでしょう・・。そう言えば、foldのルールで多バイト文字って考慮されてましたでしょうか・・。表示の際はfoldを戻すから、関係無いのか？と思いましたが、そうでもない気もしますねぇ・・。

と言うことで、実装時の奨励事項でした。

2012-03-13 01:00 nice!(2) コメント(0) トラックバック(0)
共通テーマ：パソコン・インターネット

コンポーネントプロパティ一覧の続き（Miscellaneous Component Properties~）　[iCalendar]

コンポーネントプロパティの最後の項目。「その他」です。

ざ~っとなめて行きます。

Miscellaneous Component Properties
IANA- (IANA Properties)	IANAに登録されているプロパティです。アプリは構文解析は出来ることを期待されるが、無視していいとのこと。
X- (Non-Standard Properties)	独自のプロパティ。デフォルトは「TEXT」型だが、他の型も可能。「X-」に続けて、定義した人が識別できる様な他の短いプリフィックスをつけることが奨励される。構文解析されることを期待するが、無視していい。
REQUEST-STATUS (Request Status)	スケジューリングの要求に対する status code の定義を行う。値は、「short return status component」、「longer return status description component」、「status-specific data component（オプション）」から成り、各コンポーネントはSEMICOLONで区分けされる。「short return status」は3組の整数（例えば、「3.1」や「3.1.1」）から成る。
	型	TEXT
	プロパティパラメータ	IANA、独自
	利用可能コンポーネントプロパティ	「VEVENT」「VTODO」「VJOURNAL」「VFREEBUSY」

最後の、REQUEST-STATUSは次の通りにあらかじめクラスが決められています。他のクラスを定義する際には登録が必要（？）。

Short Return Status Code	Longer Return Status Description
1.xx	準備完了（Preliminary success）。初期段階は成功しているが、完了はしていないことを示す。
2.xx	成功（Successful）。要求が完全に成功したことを示す。
3.xx	クライアント側エラー（Client Error）。要求は成功していない。要求の書式か構文のエラーで、修正するまで、再要求はするべきでない。
4.xx	スケジューリングエラー（Scheduling Error）。要求は成功していない。カレンダー、スケジューラサービス側のエラーで、要求に不具合があったわけではない。