RFC 5333 - IANA Registration of Enumservices for Internet Calendaring 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5333
タイトル : RFC 5333 - インターネットカレンダーのためのEnumservicesのIANA登録
翻訳編集 : 自動生成

[要約] RFC 5333は、インターネットカレンダリングのためのEnumservicesのIANA登録に関するものです。このRFCの目的は、カレンダリングサービスの統一的な識別子の登録と管理を提供することです。

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

インターネットカレンダーのためのEnumservicesのIANA登録

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メッセージベースの相互運用性プロトコル）を使用してスケジュールするためのEnumservicesに焦点を当て、CalDAV（WebDAVへのカレンダー拡張機能）を使用してインターネットカレンダー情報にアクセスします。

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権とライセンス通知

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.

このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。

1. Introduction

1. はじめに

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]）は、DNS（ドメイン名システム、RFC 1034 [2]）を使用して「12025550100」などの電話番号をURIS（ユニフォームリソース識別子、RFCに翻訳するシステムです。3986 [3]）、「mailto：user@example.com」など。列挙は主に、電話番号に依存するシステムの相互接続を促進するために存在します。ここでの列挙登録は、たとえば、アドレス帳でユーザーの無料/ビジーステータスを確認したり、ユーザーの電話番号から彼または彼女との会議を提案するために、電話を許可するために使用できます。

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.

このドキュメントは、E.164番号に関連付けられたインターネットカレンダー情報のスケジュールとアクセスのためのEnumservicesを登録します。

2. Enumservice Registrations

2. Enumservice登録

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]で定義されているように、次のテンプレートは、このドキュメントで指定されているencervicesの登録に必要な情報をカバーしています。

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名： "ICALSCHED" Enumservice Type： "ICAL-sched" Enumservice Subtypes： "Mailto" URIスキーム： 'MailTo：'機能仕様：このEnumserviceは、特定されたリソースが使用される関連するURIによって対処できることを示します。IMIP [6]プロトコルを使用したインターネットメールを介してインターネットカレンダーを使用してスケジュールするため。セキュリティ上の考慮事項：セクション4を参照してください。意図された使用法：共通著者：Rohan Mahy（rohan@ekabal.com）

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 name： "ical-access" enumserviceタイプ： "ical-access" enumservice subtypes： "http" uriスキーム： 'http：' functional仕様：識別されたリソースが、関連するURIが関連するURIによって対処できることを示します。インターネットカレンダーのためのCalDAV [7]プロトコルを使用して、ユーザーのカレンダー（たとえば無料/ビジーステータス）にアクセスするため。セキュリティ上の考慮事項：セクション4を参照してください。意図された使用法：共通著者：Rohan Mahy（rohan@ekabal.com）

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 name： "ical-access" enumserviceタイプ： "ical-access" enumservice subtypes： "https" uriスキーム： 'https：' functional仕様：識別されたリソースが、関連するURIが関連するURIによって対処できることを示します。インターネットカレンダーのためのCalDAV [7]プロトコルを使用して、ユーザーのカレンダー（たとえば無料/ビジーステータス）にアクセスするため。セキュリティ上の考慮事項：セクション4を参照してください。意図された使用法：共通著者：Rohan Mahy（rohan@ekabal.com）

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]は、タイプ文字列にダッシュ「 - 」を明確に許可しているため、「 - 」を使用することは実用的な方法と見なされます。

3. Examples

3. 例

$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.55.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 20 100 "u" "E2U+ical-sched:mailto" \ "!^.*$!mailto:alice@example.com!" .

$ origin 3.2.1.0.5.5.5.55.2.1.2.1.e164.arpa。@ naptr 20 100 "u" "e2u ical-sched：mailto" \ "！^。*$！mailto：alice@example.com！"。

4. Security Considerations

4. セキュリティに関する考慮事項

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の構造に応じて、ターゲットのフルネームまたは雇用主が明らかになる可能性があります。匿名のURISを使用すると、このリスクが軽減されます。

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を使用しているため、現在の形式では不安定なプロトコルであるため、クエリに返された回答が本物であることを確認するメカニズムはありません。列挙のDNSへの依存性に特有の脅威の分析は、RFC 3761 [1]で提供されており、DNS自体に対する脅威の徹底的な分析はRFC 3833 [14]でカバーされています。これらの問題の多くは、リゾルバーがDNSSEC（DNS Security、RFC 4035 [9]）を介して利用可能なゾーンでenumクエリに対する回答の信頼性を検証するときに防止されます。

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スキームと組み合わせて使用されるカレンダープロトコルは、現在、これらの要件を満たしています。「HTTPS：」スキームを使用したCalDAVの使用は、TLS（Transport Layer Security、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 Recordsが公開されているにもかかわらず、この情報を使用して保護されていないカレンダーリソースを明らかにすることは、実際にはありそうにありません。

5. IANA Considerations

5. IANAの考慮事項

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].

このドキュメントでは、このドキュメントのセクション2およびRFC 3761 [1]の定義に従って、「ICAL-SCHED」および「ICAL-ACCESS」Enamservicesの登録を要求します。

6. References

6. 参考文献

6.1. Normative References

6.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。and 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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Dawson、F。and 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.、Mansour、S.、Dawson、F。、およびR. Hopson、「Icalendar Transport Indoptent Interoperability Protocol（ITIP）スケジューリングイベント、Busytime、To-Dos、Journalエントリ」、RFC 2446、1998年11月。

[6] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2447, November 1998.

[6] Dawson、F.、Mansour、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、「WebDav（CalDav）への拡張カレンダー」、RFC 4791、2007年3月。

[8] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[8] Dusseault、L。、「Web分散オーサリングおよびバージョン（WebDav）のHTTP拡張機能」、RFC 4918、2007年6月。

[9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[9] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。

6.2. Informative References

6.2. 参考引用

[10] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet Calendaring", RFC 3283, June 2002.

[10] Mahoney、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。

[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[12] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。

[13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[13] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。

[15] Daboo, C. and B. Desruisseaux, "CalDAV Scheduling Extensions to WebDAV", Work in Progress, August 2009.

[15] Daboo、C。およびB. Desruisseaux、「CaldavのWebdavへの拡張スケジューリング」、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] Bradner、S.、Conroy、L。、およびK. Fujiwara、「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.

このドキュメントをレビューしてくれたLisa DusseaultとAlexander Mayrhoferに感謝します。

Authors' Addresses

著者のアドレス

Rohan Mahy Unaffiliated

Rohan Mahyは関係ありません

   EMail: rohan@ekabal.com

Bernie Hoeneisen Swisscom CH-8000 Zuerich Switzerland

   EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen@swisscom.com)
   URI:   http://www.swisscom.com/