So-net無料ブログ作成

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

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

MIME content type の「text/calnedar」として登録されています。詳細は下記の通り。

Type nametext
Subtype namecalendar
Required parametersnone
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でエスケープすることも可能。
Security7章参照
Interoperability 本メディアタイプは異なるシステムで情報をやり取りするための共通フォーマットを定義するよう意図されている。古くは「VCAL」に由来する。
Published Specification本仕様
Applecation 本メディアタイプはインターネット上のカレンダー、スケジュールアプリで使用されるようデザインされている。iTIP[2446bis]、iMIP[2447bis]、CalDAV[RFC4791]で使用される。
Additional Information Magic numberNone
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 usageCOMMON
Restrictions on usage特になし
Author本仕様の「Author's Address」参照
Change controllerIETF


と言う感じですが、まとまって無いですねぇ・・・。まあ、いいか・・。


【参考】
UTF-8 - Wikipedia




ioPLAZA【アイ・オー・データ直販サイト】

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

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

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

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


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



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



次回は、IANAについて。






奨励事項 [iCalendar]

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

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


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


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





コンポーネントプロパティ一覧の続き(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 CodeLonger Return Status Description
1.xx準備完了(Preliminary success)。初期段階は成功しているが、完了はしていないことを示す。
2.xx成功(Successful)。要求が完全に成功したことを示す。
3.xxクライアント側エラー(Client Error)。要求は成功していない。要求の書式か構文のエラーで、修正するまで、再要求はするべきでない。
4.xxスケジューリングエラー(Scheduling Error)。要求は成功していない。カレンダー、スケジューラサービス側のエラーで、要求に不具合があったわけではない。



コンポーネントプロパティについては、これで終わりです。ようやく、仕様書も終盤に来ましたねぇ・・。


つづく。





ブログを作る(無料) powered by So-netブログ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。