Network Working Group R. Mahy
Request for Comments: 5333 Unaffiliated
Category: Standards Track B. Hoeneisen
Swisscom
October 2009
IANA Registration of Enumservices for Internet Calendaring
Abstract
抽象
This document registers Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV).
この文書は、インターネットのカレンダー用Enumservicesを登録します。具体的には、この文書では、iMIPの（iCalendar形式のメッセージベースの相互運用性プロトコル）をスケジュールするためのCalDAVおよび管理（WebDAVへのカレンダー拡張機能）と、インターネット予定表情報にアクセスするためのEnumservicesに焦点を当てています。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンスに関するお知らせ
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS (Domain Name System, RFC 1034 [2]) to translate telephone numbers, such as '+12025550100', into URIs (Uniform Resource Identifiers, RFC 3986 [3]), such as 'mailto:user@example.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to identify resources. The ENUM registration here could be used to allow phones, for example, to check the free/busy status of a user in their address book or propose a meeting with him or her from the user's phone number.
ENUM（E.164番号マッピングは、RFC 3761 [1]）のURI（ユニフォームリソース識別子に、そのような '12025550100' と、DNS（ドメインネームシステム、RFC 1034 [2]）変換する電話番号を使用するシステムであります'：user@example.comのmailto' などRFC 3986 [3]）。 ENUMは、リソースを識別するためのURIを使用するものとの電話番号に依存しているシステムの相互接続を容易にするために、主に存在しています。ここでENUM登録は彼らのアドレス帳にユーザーの空き/予約済みの状態を確認したり、ユーザーの電話番号から彼または彼女との会談を提案するために、例えば、携帯電話を可能にするために使用することができます。
The Guide to Internet Calendaring [10] describes the relationship between various Internet calendaring specifications like this: "iCalendar [4] is the language used to describe calendar objects. iTIP [5] [iCalendar Transport-Independent Interoperability Protocol] describes a way to use the iCalendar language to do scheduling. iMIP [6] [iCalendar Message-Based Interoperability Protocol] describes how to do iTIP scheduling via e-mail".
インターネット予定表へのガイド[10]は、このような様々なインターネットカレンダー仕様との関係について説明します。「iCalendar形式は、[4]カレンダーオブジェクトを記述するために使用される言語であるとのiTIP [5] [iCalendarのトランスポートに依存しない相互運用性プロトコル]使用する方法を説明しスケジューリングを行うためのiCalendar言語。iMIPの[6] [iCalendar形式のメッセージベースの相互運用性プロトコル]「電子メールでのiTIPスケジューリングを行う方法について説明します。
Recently, another Standards Track protocol for calendar and scheduling access has appeared. CalDAV (Calendaring Extensions to WebDAV) [7] is a WebDAV (Web-based Distributed Authoring and Versioning) [8] based mechanism for manipulating Internet calendars, viewing free/busy lists, and via a planned scheduling extension [15], could be used for proposing calendar events as well in the future.
最近では、カレンダーやスケジュールのアクセスのための別の標準化過程プロトコルが登場しています。 CalDAVの管理（WebDAVにカレンダー機能拡張）[7]でのWebDAV（Web分散オーサリングとバージョン管理）フリー/ビジー状態のリストを表示して、インターネットのカレンダーを操作するための[8]ベースのメカニズム、および計画スケジューリング拡張を介した[15]、することができ将来的にだけでなくカレンダーイベントを提案するために使用。
The existing 'mailto:' URI scheme (defined in RFC 3986 [3]) is already used to address iMIP compatible Calendar Services. Likewise, the existing 'http:' and 'https:' URI schemes (defined in RFC 2616 [11] and RFC 2818 [12]) are already used to address CalDAV compatible Calendar Services.
既存の「のmailto：」URIスキーム（RFC 3986で定義された[3]）既にiMIPの互換性のあるカレンダーサービスに対処するために使用されます。同様に、既存の 'HTTP：' と 'HTTPS：' のURI（RFC 2616で定義された[11]およびRFC 2818 [12]）方式は、既にのCalDAV互換のカレンダーサービスに対処するために使用されます。
This document registers Enumservices for scheduling and accessing Internet calendaring information associated with an E.164 number.
この文書では、スケジューリングのためEnumservicesを登録し、E.164番号に関連付けられたインターネット予定表情報にアクセスします。
As defined in RFC 3761 [1], the following templates cover the information needed for the registration of the Enumservices specified in this document:
RFC 3761で定義されているように、[1]、以下のテンプレートは、この文書で指定されたEnumservicesの登録に必要な情報を網羅。
Enumservice Name: "ical-sched" Enumservice Type: "ical-sched" Enumservice Subtypes: "mailto" URI scheme(s): 'mailto:' Functional Specification: This Enumservice indicates that the resource identified can be addressed by the associated URI used for scheduling using Internet calendaring via Internet mail with the iMIP [6] protocol. Security considerations: See Section 4. Intended usage: COMMON Author: Rohan Mahy (rohan@ekabal.com)
Enumservice名称： "iCalの-schedの" Enumserviceタイプ： "iCalの-schedの" Enumserviceサブタイプ： "MAILTO" URIスキーム（S）： 'のmailto：' 機能仕様：このEnumserviceは、識別されたリソースが使用関連URIによって対処することができることを示していますiMIPの[6]プロトコルでインターネットメールを介してインターネットのカレンダーを使用してスケジューリングのため。セキュリティの考慮事項：COMMON著者：：ロハンマーイ（rohan@ekabal.com）第4節意図している用法を参照してください。
Enumservice Name: "ical-access" Enumservice Type: "ical-access" Enumservice Subtypes: "http" URI scheme(s): 'http:' Functional Specification: This Enumservice indicates that the resource identified can be addressed by the associated URI in order to access a user's calendar (for example free/busy status) using the CalDAV [7] protocol for Internet calendaring. Security considerations: See Section 4. Intended usage: COMMON Author: Rohan Mahy (rohan@ekabal.com)
Enumservice名：「iCalのアクセス」Enumserviceタイプ：「iCalのアクセス」Enumserviceサブタイプ：「HTTP」URIスキーム（S）：「HTTP：」機能仕様：このEnumserviceは特定されたリソースがで関連するURIによって対処可能であることを示していますインターネットカレンダーのためのCalDAV [7]プロトコルを使用して、ユーザのカレンダーにアクセスするために（例えば、フリー/ビジーステータス）。セキュリティの考慮事項：COMMON著者：：ロハンマーイ（rohan@ekabal.com）第4節意図している用法を参照してください。
Enumservice Name: "ical-access" Enumservice Type: "ical-access" Enumservice Subtypes: "https" URI scheme(s): 'https:' Functional Specification: This Enumservice indicates that the resource identified can be addressed by the associated URI in order to access a user's calendar (for example free/busy status) using the CalDAV [7] protocol for Internet calendaring. Security considerations: See Section 4. Intended usage: COMMON Author: Rohan Mahy (rohan@ekabal.com)
Enumservice名：「iCalのアクセス」Enumserviceタイプ：「iCalのアクセス」Enumserviceサブタイプ：「https」のURIスキーム（S）：「HTTPS：」機能仕様：このEnumserviceは特定されたリソースがで関連するURIによって対処可能であることを示していますインターネットカレンダーのためのCalDAV [7]プロトコルを使用して、ユーザのカレンダーにアクセスするために（例えば、フリー/ビジーステータス）。セキュリティの考慮事項：COMMON著者：：ロハンマーイ（rohan@ekabal.com）第4節意図している用法を参照してください。
Note: These Enumservices use a dash "-" in the Type strings. To allow for hierarchical concepts (as required in this case), some kind of boundary needs to be in place. Neither RFC 3761 [1] nor its intended successor [17] foresee the concept of sub-subtyping. The natural solution to address this requirement is the usage of dash "-" in Type strings, which is slightly contradictory to RFC 3761 [1]. However, its intended successors [16] [17] clearly allow a dash "-" in Type strings, so that using "-" is seen as a practical way forward.
注：これらのEnumservicesはダッシュを使用する「 - 」タイプ文字列に。 （この場合には必要に応じて）階層概念を可能にするため、境界のいくつかの種類が所定の位置にする必要があります。どちらのRFC 3761 [1]もその意図後継[17]サブサブタイプの概念を予見します。この要件に対処するための自然な解決策は、ダッシュの使用である「 - 」RFC 3761に少し矛盾しているタイプの文字列を、[1]。しかし、その意図した後継者[16] [17]が明らかにダッシュを許可する「 - 」タイプの文字列で、使用するように、「 - 」前進実用的な方法として見られています。
$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa. @ NAPTR 10 100 "u" "E2U+ical-access:https" \ "!^.*$!https://cal.example.com/home/alice/calendars/!" .
$ ORIGINの3.2.1.0.5.5.5.2.1.2.1.e164.arpa。 @ NAPTR 10 100 "U" "E2U + iCalのアクセス：https" を\ "^ * $のhttps：！。！//cal.example.com/home/alice/calendars/"！ 。
$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa. @ NAPTR 20 100 "u" "E2U+ical-sched:mailto" \ "!^.*$!mailto:alice@example.com!" .
$ ORIGINの3.2.1.0.5.5.5.2.1.2.1.e164.arpa。 @ NAPTR 20 100 "U" "E2U + iCalの-schedの：のmailtoを" \ "^ * $のmailto：！。！！alice@example.com" 。
The Domain Name System (DNS) does not make policy decisions about which records it provides to a DNS resolver. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered open to the public -- which is a cause for some privacy considerations.
ドメインネームシステム（DNS）は、DNSリゾルバに提供して記録するに関する政策決定を下すことはありません。すべてのDNSレコードはすべての回で、すべての照会者に利用可能であると想定しなければなりません。いくつかのプライバシーの配慮のための原因である - ENUMレコードセット内で提供される情報は、したがって、一般に公開されて考慮されなければなりません。
Revealing a calendaring URI by itself is unlikely to introduce many privacy concerns, although, depending on the structure of the URI, it might reveal the full name or employer of the target. The use of anonymous URIs mitigates this risk.
それ自体でカレンダーURIを明らかにすることは、URIの構造に応じて、それがターゲットのフルネームや雇用を明らかにするかもしれない、けれども、多くのプライバシーの問題を導入することはほとんどありません。匿名URIの使用は、このリスクを軽減します。
As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the answer returned to a query is authentic. An analysis of threats specific to the dependence of ENUM on the DNS is provided in RFC 3761 [1], and a thorough analysis of threats to the DNS itself is covered in RFC 3833 [14]. Many of these problems are prevented when the resolver verifies the authenticity of answers to its ENUM queries via DNSSEC (DNS Security, RFC 4035 [9]) in zones where it is available.
ENUMは、その現在の形式で安全でないプロトコルでDNSを使用するように、答えがクエリーに戻さが真正であることを確保するためのメカニズムはありません。 RFC 3761に設けられているDNSにENUMの依存性特定の脅威の分析[1]、及びDNS自体への脅威の徹底的な分析は、RFC 3833 [14]で覆われています。リゾルバはDNSSECを介してそのENUMクエリーに対する回答の信憑性を検証するときに、これらの問題の多くが回避される（DNSセキュリティ、RFC 4035 [9]）ゾーンでは入手可能です。
More serious security concerns are associated with potential attacks against an underlying calendaring system (for example, unauthorized modification or viewing). For this reason, iTIP discusses a number of security requirements (detailed in RFC 2446 [5]) that call for authentication, integrity and confidentiality properties, and similar measures to prevent such attacks. Any calendaring protocol used in conjunction with a URI scheme currently meets these requirements. The use of CalDAV with the 'https:' scheme makes use of TLS (Transport Layer Security, RFC 5246 [13]) to provide server authentication, confidentiality, and message integrity.
もっと深刻なセキュリティ上の懸念は、（例えば、不正な変更または閲覧）基本的なカレンダーシステムに対する潜在的な攻撃に関連しています。このような理由から、のiTIPは、認証、完全性と機密性の特性のために呼び出し（RFC 2446で詳述[5]）セキュリティ要件の数、および、そのような攻撃を防ぐために、同様の措置を説明します。 URIスキームに関連して使用される任意のカレンダープロトコルは、現在、これらの要件を満たしています。 CalDAVを使用する「HTTPSは：」スキームは、サーバ認証、機密性、およびメッセージの整合性を提供するために、TLSの使用（トランスポート層セキュリティ、RFC 5246 [13]）になります。
Unlike a traditional telephone number, the resource identified by an calendaring URI is often already guessable, and it often requires that users provide cryptographic credentials for authentication and authorization before calendar data can be exchanged. Despite the public availability of ENUM records, the use of this information to reveal an unprotected calendaring resource is unlikely in practice.
従来の電話番号とは異なり、カレンダーURIによって識別されるリソースは、多くの場合、すでに推測可能であり、それは多くの場合、カレンダーのデータを交換する前に、ユーザーが認証および承認のための暗号資格情報を提供する必要があります。 ENUMレコードの公共利用できるにもかかわらず、保護されていないカレンダーのリソースを明らかにするために、この情報を使用することは、実際にはほとんどありません。
This document requests registration of the "ical-sched" and "ical-access" Enumservices according to the definitions in Section 2 of this document and RFC 3761 [1].
この文書では、「iCalのスケジュール」および「iCalのアクセス」このドキュメントのセクション2およびRFC 3761で定義に従って列挙サービスの登録を要求する[1]。
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom、P.及びM. Mealling、 "ユニフォームリソース識別子にE.164（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）"、RFC 3761、2004年4月。
[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[2] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[4] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[4]ドーソン、F.とStenerson、D.、 "インターネットカレンダーおよびスケジューリング中核オブジェクト仕様（iCalendar形式）"、RFC 2445、1998年11月。
[5] 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.
[5] Silverberg、S.、マンスール、S.、ドーソン、F.、およびR. Hopson、 "iCalendarのトランスポートに依存しない相互運用プロトコル（のiTIP）スケジューリング・イベント、空き時間、およびジャーナルエントリ-DOSを"、RFC 2446年11月1998。
[6] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2447, November 1998.
[6]ドーソン、F.、マンスール、S.、およびS. Silverberg、 "iCalendarのメッセージベースの相互運用プロトコル（iMIPの）"、RFC 2447、1998年11月。
[7] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.
[7] Daboo、C.、Desruisseaux、B.、およびL. Dusseault、RFC 4791、2007年3月 "のWebDAV（CalDAVに）にカレンダー拡張機能"。
[8] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[8]、RFC 4918、2007年6月Dusseault、L.、 "Web分散オーサリングとバージョン管理（WebDAV）のためのHTTP拡張機能" を。
[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[9]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[10] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet Calendaring", RFC 3283, June 2002.
[10]マホーニー、B.、Babics、G.、およびA. Taler、 "インターネット予定表へのガイド"、RFC 3283、2002年6月。
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[11]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[12]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[13]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[14] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[14]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、2004年8月。
[15] Daboo, C. and B. Desruisseaux, "CalDAV Scheduling Extensions to WebDAV", Work in Progress, August 2009.
[15] Daboo、C.およびB. Desruisseaux、 "WebDAVのへのCalDAVスケジュール拡張機能"、進歩、2009年8月に作業。
[16] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Work in Progress, May 2009.
[16]ブラドナーの、S.、コンロイ、L.、およびK.藤原、 "統一資源識別子にE.164（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）"、進歩、2009年5月での作業。
[17] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template and IANA Considerations", Work in Progress, September 2009.
[17] Hoeneisen、B.、Mayrhofer、A.、およびJ. Livingood、 "EnumservicesのIANA登録：ガイド、テンプレート及びIANAの考慮事項"、進歩、2009年9月での作業。
Appendix A. Acknowledgments
付録A.謝辞
Thanks to Lisa Dusseault and Alexander Mayrhofer for reviewing this document.
この文書を検討するためのリサDusseaultとアレクサンダーMayrhoferに感謝します。
Authors' Addresses
著者のアドレス
Rohan Mahy Unaffiliated
ロハンマーイ無所属
EMail: rohan@ekabal.com
メールアドレス：rohan@ekabal.com
Bernie Hoeneisen Swisscom CH-8000 Zuerich Switzerland
バーニーHoeneisenスイスコムCH-8000チューリッヒスイス
EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen@swisscom.com) URI: http://www.swisscom.com/
Eメール：bernie@ietf.hoeneisen.ch（bernhard.hoeneisen@swisscom.com）URI：http://www.swisscom.com/