RFC 4079 - A Presence Architecture for the Distribution of GEOPRIV Location Objects 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4079
タイトル : RFC 4079 - Geoprivロケーションオブジェクトの配布のための存在アーキテクチャ
翻訳編集 : 自動生成

[要約] RFC 4079は、GEOPRIV位置オブジェクトの配布のための存在アーキテクチャについての要約です。その目的は、位置情報のプライバシーを保護しながら、位置情報の配布を効率的に行うことです。

Network Working Group                                        J. Peterson
Request for Comments: 4079                                       NeuStar
Category: Informational                                        July 2005

A Presence Architecture for the Distribution of GEOPRIV Location Objects

Geoprivロケーションオブジェクトの配布のための存在アーキテクチャ

Status of This Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

Abstract

概要

GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV.

GEOPRIVは、「プロトコルを使用する」という概念を定義します。これは、GEOPRIVロケーションオブジェクトを運ぶプロトコルです。Geoprivは、サブスクリプションと非同期通知の概念を必要とする場所オブジェクトの配布のためのさまざまなシナリオも定義しています。このドキュメントでは、存在の概念に関するいくつかの既存のIETF作業を調べ、存在するアーキテクチャがGeoprivアーキテクチャにどのようにマップされるかを示し、さらに、存在用に開発されたツールを再利用してGeoprivの標準化と実装を簡素化できることを示しています。

Table of Contents

   1. Introduction ....................................................2
   2. Framework Analysis ..............................................2
   3. Presence Architecture for GEOPRIV ...............................3
   4. GEOPRIV Extensions to PIDF ......................................5
   5. Security Considerations .........................................5
   6. Acknowledgements ................................................5
   7. Informative References ..........................................6

1. Introduction

1. はじめに

GEOPRIV is a standard for the transmission of location information and privacy policies over the Internet. Location information is a description of a particular spatial location, which may be represented as coordinates (via longitude, latitude, and so on), as civil addresses (such as postal addresses), or in other ways. GEOPRIV focuses on the privacy and security issues, from both a technology perspective and a policy perspective, of sharing location information over the Internet; it essentially defines a secure container class capable of carrying both location information and policy data governing the distribution of this information. GEOPRIV also defines the concept of a 'using protocol' -- a protocol that carries the GEOPRIV location object.

Geoprivは、インターネット上の位置情報とプライバシーポリシーの送信の標準です。位置情報は、特定の空間的位置の説明であり、座標（経度、緯度などを介して）、市民住所（郵便アドレスなど）として、またはその他の方法として表される場合があります。Geoprivは、インターネット上で位置情報を共有するというテクノロジーの観点と政策の観点から、プライバシーとセキュリティの問題に焦点を当てています。本質的に、この情報の分布を管理する位置情報とポリシーデータの両方を運ぶことができる安全なコンテナクラスを定義します。Geoprivは、GeoPrivロケーションオブジェクトを運ぶプロトコルである「プロトコルを使用する」という概念も定義しています。

Presence is a service defined in RFC2778 [2] that allows users of a communications service to monitor one another's availability and disposition in order to make decisions about communicating. Presence information is highly dynamic, and it generally characterizes whether a user is online or offline, busy or idle, away from communications devices or nearby, and the like.

存在は、RFC2778 [2]で定義されているサービスであり、通信サービスのユーザーが通信に関する決定を下すために互いの可用性と気質を監視できるようにします。存在情報は非常に動的であり、一般に、ユーザーがオンラインまたはオフラインであるか、忙しいかアイドル状態であるか、通信デバイスや近くから離れているかなどを特徴付けます。

This document shows the applicability of presence to GEOPRIV and shows that a presence protocol could be a suitable using protocol for GEOPRIV. This document is not intended to demonstrate that presence is the only method by which GEOPRIV location objects might be distributed. However, there are numerous applications of GEOPRIV that depend on the fundamental subscription/notification architecture that also underlies presence.

このドキュメントは、Geoprivへの存在の適用性を示しており、存在プロトコルがGeoprivのプロトコルを使用して適切なものになる可能性があることを示しています。このドキュメントは、存在がGeoprivの位置オブジェクトを配信する唯一の方法であることを実証することを意図していません。ただし、存在の根底にある基本的なサブスクリプション/通知アーキテクチャに依存するGeoPrivには多数のアプリケーションがあります。

2. Framework Analysis

2. フレームワーク分析

The GEOPRIV framework [1] defines four primary network entities: a Location Generator, a Location Server, a Location Recipient, and a Rule Holder. Three interfaces between these entities are defined, including a publication interface and a notification interface.

GEOPRIVフレームワーク[1]は、ロケーションジェネレーター、ロケーションサーバー、ロケーション受信者、およびルールホルダーの4つの主要なネットワークエンティティを定義しています。公開インターフェイスと通知インターフェイスなど、これらのエンティティ間の3つのインターフェイスが定義されています。

GEOPRIV specifies that a 'using protocol' is employed to transport location objects from one place to another. If the publication interface and notification interface are network connections, then a using protocol would be responsible for the transmission of the location object. Location Recipients may request that a Location Server provide them with GEOPRIV location information concerning a particular Target. The Location Generator publishes Location Information to a Location Server, which, in coordination with policies set by the Rule Maker, distributes the location information to Location Recipients as necessary.

Geoprivは、「プロトコルを使用する」が場所から別の場所に位置オブジェクトを輸送するために使用されることを指定します。公開インターフェイスと通知インターフェイスがネットワーク接続である場合、使用中のプロトコルがロケーションオブジェクトの送信に責任を負います。場所の受信者は、ロケーションサーバーに特定のターゲットに関するGeoPrivの位置情報を提供するように要求する場合があります。Location Generatorは、ロケーションサーバーに位置情報を公開します。これは、ルールメーカーによって設定されたポリシーと調整して、必要に応じて位置情報をロケーション受信者に配布します。

The GEOPRIV requirements document shows three scenarios for the use of the GEOPRIV protocol. In some of these scenarios (such as the third), a Location Recipient sends some kind of message to the Location Server to request the periodic transmission of location information. The location of a GEOPRIV Target is likely to vary over time (if the Target is a person, or something similarly mobile), and consequently the concept of a persistent subscription to the location of a Target resulting in periodic notification is valuable to GEOPRIV. In other scenarios, a Location Recipient may request a one-time notification of the geographical location of the Target.

GEOPRIV要件ドキュメントには、GEOPRIVプロトコルを使用するための3つのシナリオが表示されます。これらのシナリオのいくつか（3番目など）では、ロケーションの受信者がロケーションサーバーに何らかのメッセージを送信して、位置情報の定期的な送信を要求します。GEOPRIVターゲットの位置は時間とともに変化する可能性があります（ターゲットが個人である場合、または同様にモバイルである場合）。その結果、定期的な通知をもたらすターゲットの位置に対する永続的なサブスクリプションの概念は、GEOPRIVにとって価値があります。他のシナリオでは、場所の受信者は、ターゲットの地理的位置の1回限りの通知を要求する場合があります。

GEOPRIV places few requirements on using protocols. However, it is clear from the description above that there must be some mechanism allowing Location Recipients to establish a persistent subscription in order to receive regular notification of the geographical location of a Target as their location changes over time. There must also be a way for Location Generators to publish location information to a Location Server that applies further policies for distribution.

Geoprivは、プロトコルの使用に関する要件がほとんどありません。ただし、上記の説明から、場所の受信者が永続的なサブスクリプションを確立できるようにするメカニズムが必要であることは明らかです。また、ロケーションジェネレーターが配布のためにさらなるポリシーを適用するロケーションサーバーに位置情報を公開する方法も必要です。

This document adopts a model in which the using protocol is responsible for requesting subscriptions, handling publications, and sending notifications. There are other models for GEOPRIV in which these operations might be built into location objects themselves. However, there is a significant amount of pre-existing work in the IETF related to managing publications, subscriptions, and notifications for data sets that vary over time. In fact, these concepts all correspond exactly to architectures for presence that have been developed in support of real-time communications applications such as instant messaging, voice and video sessions.

このドキュメントは、使用プロトコルがサブスクリプションの要求、出版物の処理、通知の送信を担当するモデルを採用しています。これらの操作がロケーションオブジェクト自体に組み込まれる可能性のあるGeoprivには、他のモデルがあります。ただし、IETFには、長期にわたって異なるデータセットの出版物、サブスクリプション、および通知に関連するIETFには、かなりの量の既存の作業があります。実際、これらの概念はすべて、インスタントメッセージング、音声、ビデオセッションなどのリアルタイム通信アプリケーションをサポートして開発された存在のアーキテクチャに正確に対応しています。

Note that in some GEOPRIV scenarios, the Location Recipient does not actively request the location of a Target; rather, it receives an unsolicited notification of Target's location. This document focuses on the use of presence only for scenarios in which the Location Recipient actively solicits location information. However, it is possible that many of these base operations of the subscription/notification framework of presence could be reused for cases in which the Location Recipient is passive.

一部のGEOPRIVシナリオでは、場所の受信者がターゲットの場所を積極的に要求しないことに注意してください。むしろ、ターゲットの場所の未承諾通知を受け取ります。このドキュメントは、場所の受信者が位置情報を積極的に勧誘するシナリオのみの存在の使用に焦点を当てています。ただし、存在のサブスクリプション/通知フレームワークのこれらの基本操作の多くは、場所の受信者が受動的である場合に再利用できる可能性があります。

3. Presence Architecture for GEOPRIV

3. Geoprivの存在アーキテクチャ

The Common Profile for Presence [4] (CPP) defines a set of operations for delivery of presence information. These primarily consist of subscription operations and notification operations. A subscription creates a persistent connection between a 'watcher' (which corresponds to the Location Recipient of GEOPRIV) and a 'presentity' (which corresponds roughly to the GEOPRIV target). When a watcher subscribes to a presentity, a persistent connection is created;

存在感[4]（CPP）の共通プロファイルは、存在情報の提供のための一連の操作を定義します。これらは主にサブスクリプション操作と通知操作で構成されています。サブスクリプションは、「ウォッチャー」（Geoprivの場所の受信者に対応する）と「プレゼンテーション」（Geoprivターゲットにほぼ対応）との間に永続的な接続を作成します。ウォッチャーがプレゼンテーションを購読すると、永続的な接続が作成されます。

notifications of presence information will henceforth be sent to the watcher as the presence information changes. CPP also supports unsubscriptions (terminating the persistent subscription) and fetches (one-time requests for presence information that do not result in a persistent subscription).

プレゼンス情報の通知は、プレゼンス情報が変更されると、ウォッチャーに送信されます。CPPは、unsubscriptions（永続的なサブスクリプションの終了）とフェッチ（永続的なサブスクリプションにならない存在情報の1回限りのリクエスト）もサポートしています。

CPP provides a number of attributes of these operations that flesh out the presence system. There is a system for automatically expiring subscriptions if they are not refreshed at user-defined intervals (in order to eliminate stale subscriptions). There are transaction and subscription identifiers used to correlate messages, and a URI scheme ("pres:") is defined to identify watchers and presentities.

CPPは、存在システムを具体化するこれらの操作の多くの属性を提供します。ユーザー定義の間隔で更新されていない場合、サブスクリプションを自動的に期限切れにするシステムがあります（古いサブスクリプションを排除するため）。メッセージを相関させるために使用されるトランザクションとサブスクリプションの識別子があり、URIスキーム（ "pres："）がウォッチャーとプレゼンテーションを識別するために定義されています。

The IETF IMPP WG has also defined an XML data format for presence information, called the Presence Information Data Format [5] (PIDF). PIDF is a body that is carried by presence protocols and that contains presence information, including the current state of a presentity. PIDF is discussed in more detail in Section 4.

IETF IMPP WGは、プレゼンス情報データ形式[5]（PIDF）と呼ばれる存在情報のXMLデータ形式を定義しています。PIDFは、プレゼンスプロトコルによって運ばれる本体であり、現在のプレゼンテーションの状態を含む存在情報が含まれています。PIDFについては、セクション4で詳しく説明します。

At a high level, then, the presence architecture seems to have considerable applicability to the problem of delivering GEOPRIV information. However, the CPP framework is an abstract framework: it doesn't actually specify a protocol, instead it specifies a framework and a set of requirements to which presence protocols must conform. Also, CPP does not define any concept similar to a Location Server.

したがって、高レベルでは、存在するアーキテクチャは、Geopriv情報を提供する問題にかなりの適用性を持っているようです。ただし、CPPフレームワークは抽象的なフレームワークです。実際にはプロトコルを指定するのではなく、存在プロトコルが適合しなければならないフレームワークと一連の要件を指定します。また、CPPは、ロケーションサーバーに似た概念を定義していません。

However, the IETF has standardized protocols that instantiate this framework, such as SIMPLE [6] and XMPP [7]. XMPP and SIMPLE both have architectural elements comparable to a Location Server: points where presentities register their availability, and where policies for distributing presence can be managed. The presence community has also defined a policy protocol and schema set called XCAP [8] through which authorization policies can be provisioned in a presence server.

ただし、IETFには、Simple [6]やXMPP [7]など、このフレームワークをインスタンス化する標準化されたプロトコルがあります。XMPPとSimpleの両方には、ロケーションサーバーに匹敵するアーキテクチャ要素があります。プレゼンスコミュニティは、XCAP [8]と呼ばれるポリシープロトコルとスキーマセットも定義しました。

In summary, like GEOPRIV, presence requires an architecture for publication, subscription, and notification for a mutable set of data associated with a principal. Presence has already tackled many of the harder issues associated with subscription management, including subscription expiration, development of identifiers for principals, and defining document formats for presence information. Rather than reinvent work that has been done elsewhere in the IETF, GEOPRIV has reused this existing work by specifying presence protocols as GEOPRIV using protocols. Moreover, the existing foundational presence tools developed in IMPP, such as PIDF, have immediate applicability to the efforts underway in GEOPRIV to develop objects for sharing location information.

要約すると、Geoprivと同様に、存在には、プリンシパルに関連付けられたデータセットの出版、サブスクリプション、および通知のためのアーキテクチャが必要です。存在感は、サブスクリプションの有効期限、プリンシパルの識別子の開発、存在情報のドキュメント形式の定義など、サブスクリプション管理に関連する困難な問題の多くにすでに取り組んでいます。IETFの他の場所で行われた作業を再発明するのではなく、Geoprivは、プロトコルを使用してGeoPrivとして存在プロトコルを指定することにより、この既存の作業を再利用しました。さらに、PIDFなどのIMPPで開発された既存の基礎的存在ツールは、位置情報を共有するためのオブジェクトを開発するために進行中の努力に即座に適用されます。

4. GEOPRIV Extensions to PIDF

4. geopriv拡張機能への拡張

As was mentioned above, the presence architecture developed in the IETF IMPP WG has defined a format for presence information called PIDF. PIDF is an XML format that provides presence information about a presentity. Primarily, this consists of status information, but it also optionally includes contact addresses (a way of reaching the presentity), timestamps, and textual notes with arbitrary content.

上記のように、IETF IMPP WGで開発されたプレゼンスアーキテクチャは、PIDFと呼ばれる存在情報の形式を定義しています。PIDFは、プレゼンテーションに関する存在情報を提供するXML形式です。主に、これはステータス情報で構成されていますが、オプションでは、連絡先アドレス（プレゼントに到達する方法）、タイムスタンプ、および任意のコンテンツを含むテキストノートも含まれます。

PIDF is an extensible format. It defines an XML element for representing the status of a presentity (the status element), and it gives some guidance as to how this element might be extended. Although the authors of PIDF viewed geographical location as a potential category of presence information, baseline PIDF defines no format for location information.

PIDFは拡張可能な形式です。プレゼンテーションのステータス（ステータス要素）を表すためのXML要素を定義し、この要素をどのように拡張するかについてのガイダンスを提供します。PIDFの著者は、地理的位置を存在情報の潜在的なカテゴリと見なしましたが、ベースラインPIDFは位置情報の形式を定義していません。

PIDF meets the security requirements given in RFC2779 [3] (see especially sections 5.1, 5.2, and 5.3), which parallel those of the GEOPRIV location object given in the GEOPRIV requirements [1]. CPP and PIDF specify mechanisms for mutual authentication of participants in a presence exchange as well as for confidentiality and integrity properties for presence information.

PIDFは、RFC2779 [3]に記載されているセキュリティ要件を満たしています（特にセクション5.1、5.2、および5.3を参照）。これは、GEOPRIV要件[1]に与えられたGEOPRIVロケーションオブジェクトのオブジェクトと並行しています。CPPとPIDFは、存在交換における参加者の相互認証のメカニズムを指定し、存在情報の機密性と整合性の特性を指定します。

In short, many of the requirements of GEOPRIV objects map well onto the capabilities of PIDF.

要するに、GEOPRIVオブジェクトの要件の多くは、PIDFの機能に適切にマッピングされます。

5. Security Considerations

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

GEOPRIV information, like presence information, has very sensitive security requirements. The requirements of RFC2779 [3], which are instantiated by CPP, PIDF, and XCAP, in addition to the various derivative concrete presence protocols, such as XMPP and SIMPLE, map well onto the security requirements of the GEOPRIV protocol, as defined in the GEOPRIV requirements document and the GEOPRIV threat analysis [9] document. Specifically, the presence security requirements call for authentication of watchers, integrity and confidentiality properties, and similar measures to prevent abuse of presence information.

Geopriv情報は、プレゼンス情報と同様に、非常に敏感なセキュリティ要件を持っています。XMPPやシンプルなどのさまざまな微分コンクリートの存在プロトコルに加えて、CPP、PIDF、およびXCAPによってインスタンス化されたRFC2779 [3]の要件は、GEOPRIVプロトコルのセキュリティ要件に適しています。GEOPRIV要件文書とGeoPRIV脅威分析[9]ドキュメント。具体的には、存在感のあるセキュリティ要件では、ウォッチャーの認証、誠実さと機密性のプロパティ、および存在情報の乱用を防ぐための同様の措置が必要です。

6. Acknowledgements

6. 謝辞

Thanks to Randall Gellens, John Morris, Hannes Tschofenig, and Behcet Sarikaya for their comments.

Randall Gellens、John Morris、Hannes Tschofenig、およびBehcet Sarikayaのコメントに感謝します。

7. Informative References

7. 参考引用

[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "GEOPRIV requirements", RFC 3693, February 2004.

[1] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。

[2] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.

[2] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。

[3] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.

[3] Day、M.、Aggarwal、S。、およびJ. Vincent、「インスタントメッセージング /プレゼンスプロトコル要件」、RFC 2779、2000年2月。

[4] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.

[4] ピーターソン、J。、「存在のための共通プロファイル（CPP）」、RFC 3859、2004年8月。

[5] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.

[5] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。

[6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.

[6] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。

[7] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.

[7] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：インスタントメッセージングと存在」、RFC 3921、2004年10月。

[8] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Work in Progress, February 2004.

[8] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、2004年2月の作業。

[9] Danley, M., Morris, J., Mulligan, D., and J. Peterson, "Threat Analysis of the GEOPRIV Protocol", RFC 3694, February 2004.

[9] Danley、M.、Morris、J.、Mulligan、D。、およびJ. Peterson、「Geoprivプロトコルの脅威分析」、RFC 3694、2004年2月。

Author's Address

著者の連絡先

Jon Peterson NeuStar, Inc. 1800 Sutter St., Suite 570 Concord, CA 94520 USA

Jon Peterson Neustar、Inc。1800 Sutter St.、Suite 570 Concord、CA 94520 USA

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz/

Full Copyright Statement

完全な著作権声明

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。