[要約] RFC 4745は、プライバシー設定を表現するためのドキュメント形式であり、プライバシーの保護と共有を容易にすることを目的としています。
Network Working Group H. Schulzrinne
Request for Comments: 4745 Columbia U.
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
J. Morris
CDT
J. Cuellar
Siemens
J. Polk
J. Rosenberg
Cisco
February 2007
Common Policy: A Document Format for Expressing Privacy Preferences
一般的なポリシー：プライバシーの好みを表現するためのドキュメント形式
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 Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains.
このドキュメントでは、アプリケーション固有のデータへのアクセスを制御する許可ポリシーのフレームワークを定義します。このフレームワークは、一般的な場所と存在固有の承認の側面を組み合わせています。XMLスキーマは、共通のポリシールールが表される言語を指定します。共通のポリシーフレームワークは、他のアプリケーションドメインに拡張できます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Modes of Operation ..............................................4
3.1. Passive Request-Response - PS as Server (Responder) ........5
3.2. Active Request-Response - PS as Client (Initiator) .........5
3.3. Event Notification .........................................5
4. Goals and Assumptions ...........................................6
5. Non-Goals .......................................................7
6. Basic Data Model and Processing .................................8
6.1. Identification of Rules ....................................9
6.2. Extensions .................................................9
7. Conditions .....................................................10
7.1. Identity Condition ........................................10
7.1.1. Overview ...........................................10
7.1.2. Matching One Entity ................................11
7.1.3. Matching Multiple Entities .........................11
7.2. Single Entity .............................................14
7.3. Sphere ....................................................15
7.4. Validity ..................................................16
8. Actions ........................................................17
9. Transformations ................................................18
10. Procedure for Combining Permissions ...........................18
10.1. Introduction .............................................18
10.2. Combining Rules (CRs) ....................................18
10.3. Example ..................................................19
11. Meta Policies .................................................21
12. Example .......................................................21
13. XML Schema Definition .........................................22
14. Security Considerations .......................................25
15. IANA Considerations ...........................................25
15.1. Common Policy Namespace Registration .....................25
15.2. Content-type Registration for
'application/auth-policy+xml' ............................26
15.3. Common Policy Schema Registration ........................27
16. References ....................................................27
16.1. Normative References .....................................27
16.2. Informative References ...................................28
Appendix A. Contributors ..........................................29
Appendix B. Acknowledgments .......................................29
This document defines a framework for creating authorization policies for access to application-specific data. This framework is the result of combining the common aspects of single authorization systems that more specifically control access to presence and location information and that previously had been developed separately. The benefit of combining these two authorization systems is two-fold. First, it allows building a system that enhances the value of presence with location information in a natural way and reuses the same underlying authorization mechanism. Second, it encourages a more generic authorization framework with mechanisms for extensibility. The applicability of the framework specified in this document is not limited to policies controlling access to presence and location information data, but can be extended to other application domains.
このドキュメントでは、アプリケーション固有のデータにアクセスするための承認ポリシーを作成するためのフレームワークを定義します。このフレームワークは、存在と位置情報へのアクセスをより具体的に制御し、以前は個別に開発されていた単一認証システムの共通の側面を組み合わせる結果です。これら2つの認証システムを組み合わせることの利点は2つあります。まず、位置情報を自然な方法で存在する価値を高めるシステムを構築し、同じ基礎となる認可メカニズムを再利用できます。第二に、拡張性のメカニズムを備えたより一般的な認証フレームワークを奨励します。このドキュメントで指定されたフレームワークの適用性は、存在および位置情報データへのアクセスを制御するポリシーに限定されませんが、他のアプリケーションドメインに拡張できます。
The general framework defined in this document is intended to be accompanied and enhanced by application-specific policies specified elsewhere. The common policy framework described here is enhanced by domain-specific policy documents, including presence [7] and location [8]. This relationship is shown in Figure 1.
このドキュメントで定義されている一般的なフレームワークは、他の場所で指定されたアプリケーション固有のポリシーによって添付され、強化されることを目的としています。ここで説明する一般的なポリシーフレームワークは、存在[7]や場所[8]を含むドメイン固有のポリシー文書によって強化されています。この関係を図1に示します。
+-----------------+
| |
| Common |
| Policy |
| |
+---+---------+---+
/|\ /|\
| |
+-------------------+ | | +-------------------+
| | | enhance | | |
| Location-specific | | | | Presence-specific |
| Policy |----+ +----| Policy |
| | | |
+-------------------+ +-------------------+
Figure 1: Common Policy Enhancements
図1：一般的なポリシー強化
This document starts with an introduction to the terminology in Section 2, an illustration of basic modes of operation in Section 3, a description of goals (see Section 4) and non-goals (see Section 5) of the policy framework, followed by the data model in Section 6. The structure of a rule, namely, conditions, actions, and transformations, is described in Sections 7, 8, and 9. The procedure for combining permissions is explained in Section 10 and used when conditions for more than one rule are satisfied. A short description of meta policies is given in Section 11. An example is provided in Section 12. The XML schema will be discussed in Section 13. IANA considerations in Section 15 follow security considerations in Section 14.
このドキュメントは、セクション2の用語の紹介、セクション3の基本的な操作モードの図、目標の説明（セクション4を参照）およびポリシーフレームワークの非ゴール（セクション5を参照）、続いて続いて始まり、それに続くセクション6のデータモデル。規則の構造、すなわち条件、アクション、および変換は、セクション7、8、および9で説明されています。許可を組み合わせる手順は、セクション10で説明され、複数の条件で使用されます。ルールは満足しています。メタポリシーの簡単な説明をセクション11に示します。例をセクション12に示します。XMLスキーマについては、セクション13で説明します。セクション15のIANAの考慮事項は、セクション14のセキュリティ上の考慮事項に従います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[1]に記載されているとおりに解釈される。
This document introduces the following terms:
このドキュメントでは、次の用語を紹介します。
PT - Presentity / Target: The PT is the entity about whom information has been requested.
PT-プレゼンティ /ターゲット：PTは、情報が要求されたエンティティです。
RM - Rule Maker: The RM is an entity that creates the authorization rules that restrict access to data items.
RM-ルールメーカー：RMは、データ項目へのアクセスを制限する承認ルールを作成するエンティティです。
PS - (Authorization) Policy Server: This entity has access to both the authorization policies and the data items. In location-specific applications, the entity PS is labeled as location server (LS).
PS-（承認）ポリシーサーバー：このエンティティは、承認ポリシーとデータ項目の両方にアクセスできます。場所固有のアプリケーションでは、エンティティPSはロケーションサーバー（LS）としてラベル付けされています。
WR - Watcher / Recipient: This entity requests access to data items of the PT. An access operation might be a read, a write, or any other operation.
WR-ウォッチャー /受信者：このエンティティは、PTのデータ項目へのアクセスを要求します。アクセス操作は、読み取り、書き込み、またはその他の操作です。
A policy is given by a 'rule set' that contains an unordered list of 'rules'. A 'rule' has a 'conditions', an 'actions', and a 'transformations' part.
ポリシーは、「ルール」の順序付けられていないリストを含む「ルールセット」によって与えられます。「ルール」には、「条件」、「アクション」、「変換」の部分があります。
The term 'permission' indicates the action and transformation components of a 'rule'.
「許可」という用語は、「ルール」のアクションと変換コンポーネントを示します。
The term 'using protocol' is defined in [9]. It refers to the protocol used to request access to and to return privacy-sensitive data items.
「プロトコルの使用」という用語は[9]で定義されています。これは、アクセスを要求し、プライバシーに敏感なデータ項目を返すために使用されるプロトコルを指します。
The abstract sequence of operations can roughly be described as follows. The PS receives a query for data items for a particular PT, via the using protocol. The using protocol (or more precisely, the authentication protocol) provides the identity of the requestor, either at the time of the query or at the subscription time. The authenticated identity of the WR, together with other information provided by the using protocol or generally available to the server, is then used for searching through the rule set. All matching rules are combined according to a permission combining algorithm described in Section 10. The combined rules are applied to the application data, resulting in the application of privacy based on the transformation policies. The resulting application data is returned to the WR.
操作の抽象シーケンスは、ほぼ次のように説明できます。PSは、使用中のプロトコルを介して、特定のPTのデータ項目のクエリを受け取ります。使用プロトコル（より正確には、認証プロトコル）は、クエリの時点またはサブスクリプション時のいずれかで、要求者のIDを提供します。WRの認証されたアイデンティティは、使用しているプロトコルによって提供される、または一般的にサーバーが利用できる他の情報とともに、ルールセットを検索するために使用されます。すべてのマッチングルールは、セクション10で説明されているアルゴリズムを組み合わせた許可に従って組み合わされます。複合ルールはアプリケーションデータに適用され、変換ポリシーに基づくプライバシーのアプリケーションが得られます。結果のアプリケーションデータはWRに返されます。
Three different modes of operation can be distinguished:
3つの異なる操作モードを区別できます。
In a passive request-response mode, the WR queries the PS for data items about the PT. Examples of protocols following this mode of operation include HTTP, FTP, LDAP, finger, and various remote procedure call (RPC) protocols, including Sun RPC, Distributed Computing Environment (DCE), Distributed Component Object Model (DCOM), common object request broker architecture (Corba), and Simple Object Access Protocol (SOAP). The PS uses the rule set to determine whether the WR is authorized to access the PT's information, refusing the request if necessary. Furthermore, the PS might filter information by removing elements or by reducing the resolution of elements.
パッシブリクエスト応答モードでは、WRはPTに関するデータ項目のPSをクエリします。この動作モードに続くプロトコルの例には、HTTP、FTP、LDAP、指、およびSun RPC、分散コンピューティング環境（DCE）、分散コンポーネントオブジェクトモデル（DCOM）、共通オブジェクトリクエストブローカーなど、さまざまなリモートプロシージャコール（RPC）プロトコルが含まれます。アーキテクチャ（CORBA）、およびSimple Object Access Protocol（SOAP）。PSはルールを使用して、WRがPTの情報にアクセスすることを許可されているかどうかを判断し、必要に応じてリクエストを拒否します。さらに、PSは、要素を削除するか、要素の解像度を減らすことにより、情報をフィルタリングする場合があります。
Alternatively, the PS may contact the WR and convey data items. Examples include HTTP, SIP session setup (INVITE request), H.323 session setup or SMTP.
あるいは、PSはWRに連絡してデータ項目を伝えることができます。例には、HTTP、SIPセッションのセットアップ（招待リクエスト）、H.323セッションセットアップ、またはSMTPが含まれます。
Event notification adds a subscription phase to the "Active Request-Response - PS as Client (Initiator)" mode of operation. A watcher or subscriber asks to be added to the notification list for a particular presentity or event. When the presentity changes state or the event occurs, the PS sends a message to the WR containing the updated state. (Presence is a special case of event notification; thus, we often use the term interchangeably.)
In addition, the subscriber may itself add a filter to the subscription, limiting the rate or content of the notifications. If an event, after filtering by the rule-maker-provided rules and by the subscriber-provided rules, only produces the same notification content that was sent previously, no event notification is sent.
さらに、サブスクライバー自体がサブスクリプションにフィルターを追加し、通知のレートまたはコンテンツを制限する場合があります。イベントが、ルールメーカーが提供するルールによってフィルタリングした後、サブスクライバーが提供するルールによってフィルタリングした場合、以前に送信された同じ通知コンテンツのみを生成する場合、イベント通知は送信されません。
A single PS may authorize access to data items in more than one mode. Rather than having different rule sets for different modes all three modes are supported with a one rule set schema. Specific instances of the rule set can omit elements that are only applicable to the subscription model.
単一のPSは、複数のモードでデータアイテムへのアクセスを許可する場合があります。異なるモードに対して異なるルールセットを持つのではなく、3つのモードすべてが1つのルールセットスキーマでサポートされています。ルールセットの特定のインスタンスは、サブスクリプションモデルにのみ適用できる要素を省略できます。
Below, we summarize our design goals and constraints.
以下に、設計の目標と制約を要約します。
Table representation:
テーブル表現：
Each rule must be representable as a row in a relational database. This design goal should allow efficient policy implementation by utilizing standard database optimization techniques.
各ルールは、リレーショナルデータベースの行として表現できる必要があります。この設計目標は、標準のデータベース最適化手法を利用することにより、効率的なポリシー実装を可能にするはずです。
Permit only:
Rules only provide permissions rather than denying them. Removing a rule can never increase permissions. Depending on the interpretation of 'deny' and 'permit' rules, the ordering of rules might matter, making updating rule sets more complicated since such update mechanisms would have to support insertion at specific locations in the rule set. Additionally, it would make distributed rule sets more complicated. Hence, only 'permit' actions are allowed that result in more efficient rule processing. This also implies that rule ordering is not important. Consequently, to make a policy decision requires processing all rules.
ルールは、それらを拒否するのではなく、権限のみを提供します。ルールを削除することは、許可を増やすことはできません。「拒否」および「許可」ルールの解釈に応じて、ルールの順序付けが重要になる可能性があり、そのような更新メカニズムはルールセットの特定の場所での挿入をサポートする必要があるため、ルールセットをより複雑にする可能性があります。さらに、分散ルールセットがより複雑になります。したがって、より効率的なルール処理をもたらす「許可」アクションのみが許可されます。これはまた、ルールの順序が重要ではないことを意味します。したがって、ポリシー決定を行うには、すべてのルールを処理する必要があります。
Additive permissions:
追加の権限：
A query for access to data items is matched against the rules in the rule database. If several rules match, then the overall permissions granted to the WR are the union of those permissions. A more detailed discussion is provided in Section 10.
データ項目へのアクセスのクエリは、ルールデータベースのルールと一致します。いくつかの規則が一致する場合、WRに付与された全体的な許可は、これらの権限の結合です。より詳細な説明は、セクション10に記載されています。
Upgradeable:
アップグレード可能：
It should be possible to add additional rules later, without breaking PSs that have not been upgraded. Any such upgrades must not degrade privacy constraints, but PSs not yet upgraded may reveal less information than the rule maker would have chosen.
Capability support:
機能サポート：
In addition to the previous goal, a RM should be able to determine which extensions are supported by the PS. The mechanism used to determine the capability of a PS is outside the scope of this specification.
以前の目標に加えて、RMはPSによってどの拡張機能がサポートされているかを決定できる必要があります。PSの機能を決定するために使用されるメカニズムは、この仕様の範囲外です。
Protocol-independent:
プロトコル独立：
The rule set supports constraints on both notifications or queries as well as subscriptions for event-based systems such as presence systems.
No false assurance:
虚偽の保証はありません：
It appears more dangerous to give the user the impression that the system will prevent disclosure automatically, but fail to do so with a significant probability of operator error or misunderstanding, than to force the user to explicitly invoke simpler rules. For example, rules based on weekday and time-of-day ranges seem particularly subject to misinterpretation and false assumptions on part of the RM. (For example, a non-technical RM would probably assume that the rules are based on the time zone of his current location, which may not be known to other components of the system.)
ユーザーが自動的に開示を防ぐという印象をユーザーに提供する方がより危険ですが、ユーザーがより単純なルールを明示的に呼び出すことを強制するよりも、オペレーターのエラーや誤解の大きな確率でそれを行うことはできません。たとえば、平日と時刻の範囲に基づくルールは、RMの一部での誤解と誤った仮定の対象と思われます。（たとえば、非技術的なRMは、おそらくルールが現在の場所のタイムゾーンに基づいていると仮定するでしょう。
We explicitly decided that a number of possibly worthwhile capabilities are beyond the scope of this first version. Future versions may include these capabilities, using the extension mechanism described in this document. Non-goals include:
多くの価値のある機能がこの最初のバージョンの範囲を超えていることを明示的に決定しました。将来のバージョンには、このドキュメントで説明されている拡張メカニズムを使用して、これらの機能が含まれる場合があります。ノンゴールは次のとおりです。
No external references:
外部参照はありません：
Attributes within specific rules cannot refer to external rule sets, databases, directories, or other network elements. Any such external reference would make simple database implementation difficult and hence they are not supported in this version.
No regular expressions:
Conditions are matched on equality or 'greater-than'-style comparisons, not regular expressions, partial matches such as the SQL LIKE operator (e.g., LIKE "%foo%"), or glob-style matches ("*@example.com"). Most of these are better expressed as explicit elements.
No repeat times:
繰り返しの時間はありません：
Repeat times (e.g., every day from 9 am to 4 pm) are difficult to make work correctly, due to the different time zones that PT, WR, PS, and RM may occupy. It appears that suggestions for including time intervals are often based on supporting work/non-work distinctions, which unfortunately are difficult to capture by time alone. Note that this feature must not be confused with the 'Validity' element that provides a mechanism to restrict the lifetime of a rule.
A rule set (or synonymously, a policy) consists of zero or more rules. The ordering of these rules is irrelevant. The rule set can be stored at the PS and conveyed from RM to PS as a single document, in subsets or as individual rules. A rule consists of three parts: conditions (see Section 7), actions (see Section 8), and transformations (see Section 9).
ルールセット（または同義語、ポリシー）は、ゼロ以上のルールで構成されています。これらの規則の順序は無関係です。ルールセットはPSに保存し、RMからPSに単一のドキュメント、サブセット、または個々のルールとして伝達することができます。ルールは、条件（セクション7を参照）、アクション（セクション8を参照）、および変換（セクション9を参照）の3つの部分で構成されています。
The conditions part is a set of expressions, each of which evaluates to either TRUE or FALSE. When a WR asks for information about a PT, the PS goes through each rule in the rule set. For each rule, it evaluates the expressions in the conditions part. If all of the expressions evaluate to TRUE, then the rule is applicable to this request. Generally, each expression specifies a condition based on some variable that is associated with the context of the request. These variables can include the identity of the WR, the domain of the WR, the time of day, or even external variables, such as the temperature or the mood of the PT.
条件の部分は一連の式であり、それぞれが真またはfalseのいずれかと評価されます。WRがPTに関する情報を要求すると、PSはルールセットの各ルールを通過します。各ルールについて、条件部分の式を評価します。すべての式がtrueに評価される場合、ルールはこの要求に適用されます。一般に、各式は、リクエストのコンテキストに関連付けられているいくつかの変数に基づく条件を指定します。これらの変数には、WRの同一性、WRのドメイン、時刻、またはPTの温度や気分などの外部変数を含めることができます。
Assuming that the rule is applicable to the request, the actions and transformations (commonly referred to as permissions) in the rule specify how the PS is supposed to handle this request. If the request is to view the location of the PT, or to view its presence, the typical action is "permit", which allows the request to proceed.
ルールが要求に適用できると仮定すると、ルールのアクションと変換（一般に許可と呼ばれます）は、PSがこのリクエストを処理する方法を指定します。リクエストがPTの場所を表示するか、その存在を表示する場合、典型的なアクションは「許可」であり、リクエストが続行できます。
Assuming the action allows the request to proceed, the transformations part of the rule specifies how the information about the PT -- their location information, their presence, etc. -- is modified before being presented to the WR. These transformations are in the form of positive permissions. That is, they always specify a piece of information that is allowed to be seen by the WR. When a PS processes a request, it takes the transformations specified across all rules that match, and creates the union of them. For computing this union, the data type, such as Integer, Boolean, Set, or the Undef data type, plays a role. The details of the algorithm for combining permissions is described in Section 10. The resulting union effectively represents a "mask" -- it defines what information is exposed to the WR. This mask is applied to the actual location or presence data for the PT, and the data that is permitted by the mask is shown to the WR. If the WR requests a subset of information only (such as city-level civic location data only, instead of the full civic location information), the information delivered to the WR MUST be the intersection of the permissions granted to the WR and the data requested by the WR.
アクションがリクエストを続行できると仮定すると、ルールの変換部分は、PTに関する情報（位置情報、存在など）がWRに提示される前に変更される方法を指定します。これらの変換は、正の許可の形であります。つまり、彼らは常にWRで見られることが許可されている情報を指定します。PSがリクエストを処理すると、一致するすべてのルールで指定された変換が行われ、それらの結合が作成されます。この組合を計算するために、整数、ブール、セット、またはUNDEFデータ型などのデータ型が役割を果たします。アクセス許可を組み合わせたアルゴリズムの詳細については、セクション10で説明します。結果の組合は、「マスク」を効果的に表します。このマスクは、PTの実際の位置または存在データに適用され、マスクで許可されるデータはWRに表示されます。WRが情報のサブセットのみを要求している場合（完全な市民の位置情報の代わりに、都市レベルの市民の位置データのみ）、WRに配信される情報は、WRに付与された許可と要求されたデータの交差点でなければなりませんWRによって。
Rules are encoded in XML. To this end, Section 13 contains an XML schema defining the Common Policy Markup Language. This, however, is purely an exchange format between RM and PS. The format does not imply that the RM or the PS use this format internally, e.g., in matching a query with the policy rules. The rules are designed so that a PS can translate the rules into a relational database table, with each rule represented by one row in the database. The database representation is by no means mandatory; we will use it as a convenient and widely-understood example of an internal representation. The database model has the advantage that operations on rows have tightly defined meanings. In addition, it appears plausible that larger-scale implementations will employ a backend database to store and query rules, as they can then benefit from existing optimized indexing, access control, scaling, and integrity constraint mechanisms. Smaller-scale implementations may well choose different implementations, e.g., a simple traversal of the set of rules.
ルールはXMLでエンコードされています。この目的のために、セクション13には、共通のポリシーマークアップ言語を定義するXMLスキーマが含まれています。ただし、これは純粋にRMとPSの間の交換形式です。この形式は、RMまたはPSがこの形式を内部的に使用していることを意味するものではありません。たとえば、クエリをポリシールールと一致させることです。ルールは、PSがルールをリレーショナルデータベーステーブルに変換できるように設計されており、各ルールはデータベースの1つの行で表されます。データベース表現は決して必須ではありません。内部表現の便利で広く理解されている例として使用します。データベースモデルには、行の操作が厳密に定義された意味を持っているという利点があります。さらに、既存の最適化されたインデックス、アクセス制御、スケーリング、および整合性制約メカニズムの恩恵を受ける可能性があるため、大規模な実装がバックエンドデータベースを使用してルールを保存および照会することができると考えられます。小規模な実装は、さまざまな実装を選択する場合があります。たとえば、一連のルールの単純なトラバーサルなどです。
Each rule is equipped with a parameter that identifies the rule. This rule identifier is an opaque token chosen by the RM. A RM MUST NOT use the same identifier for two rules that are available to the PS at the same time for a given PT. If more than one RM modifies the same rule set, then it needs to be ensured that a unique identifier is chosen for each rule. A RM can accomplish this goal by retrieving the already specified rule set and choosing a new identifier for a rule that is different from the existing rule set.
各ルールには、ルールを識別するパラメーターが装備されています。このルール識別子は、RMによって選択された不透明なトークンです。RMは、特定のPTに対して同時にPSが利用できる2つのルールに同じ識別子を使用してはなりません。複数のRMが同じルールセットを変更する場合、各ルールに対して一意の識別子が選択されるようにする必要があります。RMは、すでに指定されているルールセットを取得し、既存のルールセットとは異なるルールの新しい識別子を選択することにより、この目標を達成できます。
The policy framework defined in this document is meant to be extensible towards specific application domains. Such an extension is accomplished by defining conditions, actions, and transformations that are specific to the desired application domain. Each extension MUST define its own namespace.
このドキュメントで定義されているポリシーフレームワークは、特定のアプリケーションドメインに向けて拡張できることを意図しています。このような拡張は、目的のアプリケーションドメインに固有の条件、アクション、および変換を定義することによって達成されます。各拡張機能は、独自の名前空間を定義する必要があります。
Extensions cannot change the schema defined in this document, and this schema is not expected to change except via revision to this specification. Therefore, no versioning procedures for this schema or namespace are provided.
拡張機能は、このドキュメントで定義されているスキーマを変更することはできません。このスキーマは、この仕様の改訂を介して変更されるとは予想されません。したがって、このスキーマまたは名前空間のバージョン化手順は提供されていません。
The access to data items needs to be matched with the rule set stored at the PS. Each instance of a request has different attributes (e.g., the identity of the requestor) that are used for authorization. A rule in a rule set might have a number of conditions that need to be met before executing the remaining parts of a rule (i.e., actions and transformations). Details about rule matching are described in Section 10. This document specifies only a few conditions (i.e., identity, sphere, and validity). Further condition elements can be added via extensions to this document. If a child element of the <conditions> element is in a namespace that is not known or not supported, then this child element evaluates to FALSE.
データ項目へのアクセスは、PSに保存されているルールセットと一致する必要があります。リクエストの各インスタンスには、許可に使用される異なる属性（要求者の身元など）があります。ルールセットのルールには、ルールの残りの部分（つまり、アクションと変換）を実行する前に、満たす必要がある条件がいくつかある場合があります。ルールマッチングの詳細については、セクション10で説明します。このドキュメントは、いくつかの条件（つまり、アイデンティティ、球体、および妥当性）のみを指定しています。このドキュメントへの拡張を介して、さらなる条件要素を追加できます。<condition>要素の子要素が知られていないか、サポートされていない名前空間にある場合、この子要素はfalseに評価されます。
As noted in Section 5, conditions are matched on equality or "greater than" style comparisons, rather than regular expressions. Equality is determined according to the rules for the data type associated with the element in the schema given in Section 13, unless explicit comparison steps are included in this document. For xs:anyURI types, readers may wish to consult [2] for its discussion xs:anyURI, as well as the text in Section 13.
セクション5で述べたように、条件は、正規表現ではなく、平等または「より大きい」スタイルの比較に一致します。このドキュメントに明示的な比較手順が含まれていない限り、平等は、セクション13で与えられたスキーマの要素に関連付けられたデータ型のルールに従って決定されます。XS：Anyuriタイプの場合、読者はディスカッションXS：Anyuri、およびセクション13のテキストについて[2]に相談したい場合があります。
The identity condition restricts matching of a rule either to a single entity or a group of entities. Only authenticated entities can be matched; acceptable means of authentication are defined in protocol-specific documents. If the <identity> element is absent, identities are not considered, and thus, other conditions in the rule apply to any user, authenticated or not.
ID条件は、単一のエンティティまたはエンティティのグループのいずれかにルールを一致させることを制限します。認証されたエンティティのみを一致させることができます。許容可能な認証手段は、プロトコル固有のドキュメントで定義されています。<identity>要素がない場合、アイデンティティは考慮されないため、ルールの他の条件は、認証されているかどうかにかかわらず、ユーザーに適用されます。
The <identity> condition is considered TRUE if any of its child elements (e.g., the <one/> and the <many/> elements defined in this document) evaluate to TRUE, i.e., the results of the individual child element are combined using a logical OR.
<アイデンティティ>の条件は、その子要素のいずれか（たとえば、このドキュメントで定義されている<1/>および<多くの/>要素）のいずれかがtrue、つまり個々の子要素の結果を使用して組み合わせた場合にtrueと見なされます。論理的または。
If a child element of the <identity> element is in a namespace that is not known or not supported, then this child element evaluates to FALSE.
<idention>要素の子要素が知られていないか、サポートされていない名前空間にある場合、この子要素はfalseに評価されます。
The <one> element matches the authenticated identity (as contained in the 'id' attribute) of exactly one entity or user. For considerations regarding the 'id' attribute, refer to Section 7.2.
<one>要素は、正確に1つのエンティティまたはユーザーの認証されたアイデンティティ（「ID」属性に含まれる）と一致します。「ID」属性に関する考慮事項については、セクション7.2を参照してください。
An example is shown below:
例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:alice@example.com"/>
<one id="tel:+1-212-555-1234" />
<one id="mailto:bob@example.net" />
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
</ruleet>
This example matches if the authenticated identity of the WR is either sip:alice@example.com, tel:+1-212-555-1234, or mailto:bob@example.net.
この例は、WRの認証されたアイデンティティがsip：alice@example.com、tel：1-212-555-1234、またはmailto：bob@example.netのいずれかであるかどうかと一致します。
The <many> element is a mechanism to perform authorization decisions based on the domain part of the authenticated identity. As such, it allows matching a large and possibly unknown number of users within a domain.
<many>要素は、認証されたアイデンティティのドメイン部分に基づいて承認決定を実行するメカニズムです。そのため、ドメイン内の大部分が未知のユーザーの数を一致させることができます。
Furthermore, it is possible to include one or multiple <except> elements to exclude either individual users or users belonging to a specific domain. Excluding individual entities is implemented using a <except id="..."/> statement. The semantic of the 'id' attribute of the <except> element has the same meaning as the 'id' attribute of the <one> element (see Section 7.2). Excluding users belonging to a specific domain is implemented using the <except domain="..."/> element that excludes any user from the indicated domain.
さらに、特定のドメインに属する個々のユーザーまたはユーザーを除外するために、1つまたは複数の要素を除いて1つまたは複数の要素を含めることができます。個々のエンティティを除外して、id = "..."/>ステートメントを除き、a <を使用して実装されます。<1を除く>要素の「ID」属性のセマンティックは、<one>要素の「ID」属性と同じ意味を持ちます（セクション7.2を参照）。特定のドメインに属するユーザーを除外すると、指定されたドメインからユーザーを除外する<domain = "..."/>要素を使用して実装されます。
If multiple <except> elements are listed as child elements of the <many> element, then the result of each <except> element is combined using a logical OR.
複数の<を除く>要素が<many>要素の子要素としてリストされている場合、各<を除く>要素の結果は、論理または。
Common policy MUST either use UTF-8 or UTF-16 to store domain names in the 'domain' attribute. For non-IDNs (Internationalized Domain Names), lowercase ASCII SHOULD be used. For the comparison operation between the value stored in the 'domain' attribute and the domain value provided via the using protocol (referred to as "protocol domain identifier"), the following rules are applicable:
共通のポリシーは、UTF-8またはUTF-16を使用して、「ドメイン」属性にドメイン名を保存する必要があります。非IDN（国際化されたドメイン名）の場合、小文字ASCIIを使用する必要があります。「ドメイン」属性に保存されている値と、使用中のプロトコル（「プロトコルドメイン識別子」と呼ばれる）を介して提供されるドメイン値との比較操作の場合、次のルールが適用されます。
1. Translate percent-encoding for either string.
1. いずれかの文字列のパーセントエンコードを変換します。
2. Convert both domain strings using the ToASCII operation described in RFC 3490 [3].
2. RFC 3490 [3]に記載されているTOASCII操作を使用して、両方のドメイン文字列を変換します。
3. Compare the two domain strings for ASCII equality, for each label. If the string comparison for each label indicates equality, the comparison succeeds. Otherwise, the domains are not equal.
3. 各ラベルについて、ASCII平等の2つのドメイン文字列を比較します。各ラベルの文字列比較が平等を示している場合、比較は成功します。それ以外の場合、ドメインは等しくありません。
If the conversion fails in step (2), the domains are not equal.
The <many/> element without any child elements or attributes matches any authenticated user.
The following example shows such a rule that matches any authenticated user:
次の例は、認証されたユーザーに一致するようなルールを示しています。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r5">
<conditions>
<identity>
<many/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
</ruleet>
The <many> element enclosing one or more <except domain="..."/> elements matches any user from any domain except those enumerated. The <except id="..."/> element excludes particular users. The semantics of the 'id' attribute of the <except> element is described in Section 7.2. The results of the child elements of the <many> element are combined using a logical OR.
domain = "..."/>要素を除く1つ以上の<多くの要素は、列挙されているドメインを除く任意のドメインから任意のユーザーを一致させます。<id = "..."/>要素を除き、特定のユーザーは除外します。<例外>要素の「ID」属性のセマンティクスは、セクション7.2で説明されています。<many>要素の子要素の結果は、論理または。
An example is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<sphere value="work"/>
<identity>
<many>
<except domain="example.com"/>
<except domain="example.org"/>
<except id="sip:alice@bad.example.net"/>
<except id="sip:bob@good.example.net"/>
<except id="tel:+1-212-555-1234" />
<except id="sip:alice@example.com"/>
</many>
</identity>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
This example matches all users except any user in example.com, or any user in example.org or the particular users alice@bad.example.net, bob@good.example.net, and the user with the telephone number 'tel:+1-212-555-1234'. The last 'except' element is redundant since alice@example.com is already excluded through the first line.
この例では、example.comのユーザーを除くすべてのユーザー、またはexample.orgまたは特定のユーザーalice@bad.example.net、bob@good.example.net、および電話番号のユーザーを除くすべてのユーザーと一致します。1-212-555-1234 '。alice@example.comは最初の行から既に除外されているため、最後の「除」要素は冗長です。
The <many> element with a 'domain' attribute and zero or more <except id="..."/> elements matches any authenticated user from the indicated domain except those explicitly enumerated. The semantics of the 'id' attribute of the <except> element is described in Section 7.2.
「ドメイン」属性とゼロを備えた<many>要素は、ID = "..."/>要素を除き、明示的に列挙されたドメインを除き、指定されたドメインから認証されたユーザーを一致させます。<例外>要素の「ID」属性のセマンティクスは、セクション7.2で説明されています。
It is nonsensical to have domains in the 'id' attribute that do not match the value of the 'domain' attribute in the enclosing <many> element.
An example is shown below:
例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<many domain="example.com">
<except id="sip:alice@example.com"/>
<except id="sip:bob@example.com"/>
</many>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
</ruleet>
This example matches any user within example.com (such as carol@example.com) except alice@example.com and bob@example.com.
この例では、alice@example.comとbob@example.comを除き、Example.com（carol@example.comなど）内のユーザーと一致しています。
The 'id' attribute used in the <one> and in the <except> element refers to a single entity. In the subsequent text, we use the term 'single-user entity' as a placeholder for the <one> and the <except> element. The <except> element fulfills the purpose of excluding elements from the solution set.
<one>および<thing> elementで使用される「ID」属性は、単一のエンティティを指します。後続のテキストでは、「シングルユーザーエンティティ」という用語を<one>および<execrent>要素のプレースホルダーとして使用します。<例外>要素は、ソリューションセットから要素を除外する目的を満たします。
A single-user entity matches the authenticated identity (as contained in the 'id' attribute) of exactly one entity or user. If there is a match, the single-user entity is considered TRUE. The single-user entity MUST NOT contain a 'domain' attribute.
シングルユーザーエンティティは、正確に1つのエンティティまたはユーザーの認証されたアイデンティティ（「ID」属性に含まれる）と一致します。一致がある場合、シングルユーザーエンティティは真実と見なされます。シングルユーザーエンティティには、「ドメイン」属性を含めてはなりません。
The 'id' attribute contains an identity that MUST first be expressed as a URI. Applications using this framework must describe how the identities they are using can be expressed as URIs.
「ID」属性には、最初にURIとして表現する必要があるアイデンティティが含まれています。このフレームワークを使用するアプリケーションは、使用しているアイデンティティをURIとしてどのように表現できるかを説明する必要があります。
The <sphere> element belongs to the group of condition elements. It can be used to indicate a state (e.g., 'work', 'home', 'meeting', 'travel') the PT is currently in. A sphere condition matches only if the PT is currently in the state indicated. The state may be conveyed by manual configuration or by some protocol. For example, RPID [10] provides the ability to inform the PS of its current sphere. The application domain needs to describe in more detail how the sphere state is determined. Switching from one sphere to another causes a switch between different modes of visibility. As a result, different subsets of rules might be applicable.
<sphere>要素は、条件要素のグループに属します。状態（「作業」、「ホーム」、「会議」、「旅行」など）を示すために使用できます。PTは現在入っています。PTが現在示されている場合にのみ球体状態が一致します。状態は、手動構成または一部のプロトコルによって伝達される場合があります。たとえば、RPID [10]は、PSに現在の球体を通知する機能を提供します。アプリケーションドメインは、球体状態がどのように決定されるかをより詳細に説明する必要があります。ある球体から別の球体に切り替えると、可視性の異なるモード間のスイッチが生じます。その結果、ルールのさまざまなサブセットが適用される場合があります。
The content of the 'value' attribute of the <sphere> element MAY contain more than one token. The individual tokens MUST be separated by a blank character. A logical OR is used for the matching the tokens against the sphere settings of the PT. As an example, if the content of the 'value' attribute in the sphere attribute contains two tokens 'work' and 'home' then this part of the rule matches if the sphere for a particular PT is either 'work' OR 'home'. To compare the content of the 'value' attribute in the <sphere> element with the stored state information about the PT's sphere setting a case-insensitive string comparison MUST be used for each individual token. There is neither a registry for these values nor a language-specific indication of the sphere content. As such, the tokens are treated as opaque strings.
<sphere>要素の「値」属性の内容には、複数のトークンが含まれている場合があります。個々のトークンは、空白の文字で分離する必要があります。論理的またはPTの球体設定とトークンを一致させるために使用されます。例として、Sphere属性の「値」属性のコンテンツに2つのトークン「作業」と「ホーム」が含まれている場合、特定のPTの球体が「作業」または「ホーム」のいずれかである場合、ルールのこの部分は一致します。。<sphere>要素の「値」属性のコンテンツを、PTの球体に関する保存された状態情報と比較するには、個々のトークンにケースに依存しない文字列比較を使用する必要があります。これらの値のレジストリも、球体含有量の言語固有の兆候もありません。そのため、トークンは不透明な弦として扱われます。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2">
<conditions>
<sphere value="work"/>
<identity>
<one id="sip:andrew@example.com"/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="y6y55r2">
<conditions>
<sphere value="home"/>
<identity>
<one id="sip:allison@example.com"/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="z6y55r2">
<conditions>
<identity>
<one id="sip:john@doe.example.com"/>
</identity>
<sphere value="home work"/>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
The rule example above illustrates that the rule with the entity andrew@example.com matches if the sphere is been set to 'work'. In the second rule, the entity allison@example.com matches if the sphere is set to 'home'. The third rule also matches since the value in the sphere element also contains the token 'home'.
上記のルールの例は、球体が「動作」に設定されている場合、エンティティandrew@example.comのルールが一致することを示しています。2番目のルールでは、球体が「ホーム」に設定されている場合、エンティティallison@example.comは一致します。Sphere要素の値にはトークン「ホーム」も含まれているため、3番目のルールも一致します。
The <validity> element is the third condition element specified in this document. It expresses the rule validity period by two attributes, a starting and an ending time. The validity condition is TRUE if the current time is greater than or equal to at least one <from> child, but less than the <until> child after it. This represents a logical OR operation across each <from> and <until> pair. Times are expressed in XML dateTime format. A rule maker might not always have access to the PS to invalidate some rules that grant permissions. Hence, this mechanism allows invalidating granted permissions automatically without further interaction between the rule maker and the PS. The PS does not remove the rules; instead the rule maker has to clean them up.
<妥当性>要素は、このドキュメントで指定されている3番目の条件要素です。ルールの妥当性期間を2つの属性、開始時間と終了時間で表します。現在の時間が少なくとも1人の<from>子供よりも大きいが、その後の子供よりも少ない場合、有効性条件は真です。これは、各<from> and <ger>ペアにわたる論理または操作を表します。時間はXML DateTime形式で表されます。ルールメーカーは、許可を付与するいくつかのルールを無効にするために、常にPSにアクセスできるとは限りません。したがって、このメカニズムにより、ルールメーカーとPSの間のさらなる相互作用なしに、付与された権限を自動的に無効にすることができます。PSはルールを削除しません。代わりに、ルールメーカーはそれらをきれいにしなければなりません。
An example of a rule fragment is shown below:
ルールフラグメントの例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r3">
<conditions>
<validity>
<from>2003-08-15T10:20:00.000-05:00</from>
<until>2003-09-15T10:20:00.000-05:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
The <validity> element MUST have the <from> and <until> subelements in pairs. Multiple <from> and <until> elements might appear in pairs (i.e., without nesting of <from> and <until> elements). Using multiple <validity> elements as subelements of the <conditions> element is not useful since all subelements of the <conditions> element are combined as a logical AND.
<妥当性>要素には、<from> and <cter> sublementsがペアに含まれている必要があります。複数の<from>および<cter>要素は、ペアで表示される場合があります（つまり、<from> and <ctero>要素のネストなし）。<condition>要素のサブエレメントとして複数の<妥当性>要素を使用することは、<条件>要素のすべてのサブレメントが論理的であるために組み合わされているため、役に立ちません。
While conditions are the 'if'-part of rules, actions and transformations form their 'then'-part. The actions and transformations parts of a rule determine which operations the PS MUST execute after having received from a WR a data access request that matches all conditions of this rule. Actions and transformations only permit certain operations; there is no 'deny' functionality. Transformations exclusively specify PS-side operations that lead to a modification of the data items requested by the WR. Regarding location data items, for instance, a transformation could force the PS to lower the precision of the location information that is returned to the WR.
条件はルールの「if」部分であり、アクションと変換は「then」部分を形成します。アクションと変換ルールの部分は、このルールのすべての条件に一致するWR Aデータアクセス要求から受け取った後にPSが実行しなければならない操作を決定します。アクションと変換は、特定の操作のみを可能にします。「否定」機能はありません。変換は、WRが要求したデータ項目の変更につながるPSサイド操作のみを指定します。たとえば、位置データ項目に関して、変換により、PSはWRに返される位置情報の精度を下げることができます。
Actions, on the other hand, specify all remaining types of operations the PS is obliged to execute, i.e., all operations that are not of transformation type. Actions are defined by application-specific usages of this framework. The reader is referred to the corresponding extensions to see examples of such elements.
Two sub-parts follow the conditions part of a rule: transformations and actions. As defined in Section 8, transformations specify operations that the PS MUST execute and that modify the result that is returned to the WR. This functionality is particularly helpful in reducing the granularity of information provided to the WR, as, for example, required for location privacy. Transformations are defined by application-specific usages of this framework.
A simple transformation example is provided in Section 10.
セクション10には、単純な変換の例が記載されています。
This section describes how rules are selected and how actions and permissions are determined. When a PS receives a request for access to privacy-sensitive data, the request is matched against the rule set. A rule matches if all conditions contained as child elements in the <conditions> element of a rule evaluate to TRUE. Each type of condition defines when it is TRUE. All rules where the conditions match the request form the matching rule set. The permissions in the matching rule set are combined using a set of combining rules (CRs) described in Section 10.2.
このセクションでは、ルールがどのように選択され、アクションとアクションが決定されるかについて説明します。PSがプライバシーに敏感なデータへのアクセスのリクエストを受信すると、リクエストはルールセットと一致します。ルールのすべての条件が、ルールの<条件>要素の子要素として含まれるすべての条件がtrueを評価する場合に一致します。各タイプの条件は、それが真であるときに定義します。条件がリクエストと一致するすべてのルールは、マッチングルールセットを形成します。一致するルールセットの権限は、セクション10.2で説明されている一連の結合ルール（CRS）を使用して組み合わされます。
Each type of permission is combined across all matching rules. Each type of action or transformation is combined separately and independently. The combining rules generate a combined permission. The combining rules depend only on the data type of permission. If a particular permission type has no value in a rule, it assumes the lowest possible value for that permission for the purpose of computing the combined permission. That value is given by the data type for booleans (FALSE) and sets (empty set), and MUST be defined by any extension to the Common Policy for other data types.
各タイプの許可は、すべてのマッチングルールにわたって組み合わされています。各タイプのアクションまたは変換は、個別に独立して結合されます。組み合わせルールは、組み合わせた許可を生成します。結合ルールは、許可のデータ型のみに依存します。特定の許可タイプにルールに値がない場合、複合許可を計算する目的で、その許可に対して可能な限り最低値を想定しています。その値は、ブール付け（FALSE）およびセット（空のセット）のデータ型によって与えられ、他のデータ型の共通ポリシーの拡張によって定義する必要があります。
For boolean permissions, the resulting permission is TRUE if and only if at least one permission in the matching rule set has a value of TRUE and FALSE otherwise. For integer, real-valued and date-time permissions, the resulting permission is the maximum value across the permission values in the matching set of rules. For sets, it is the union of values across the permissions in the matching rule set.
ブールの許可の場合、一致するルールセットの少なくとも1つの許可が真の値とfalseの値を持っている場合にのみ、結果として得られる許可は真です。整数、実際の価値、および日付の許可の場合、結果の許可は、一致するルールセットの許可値全体にわたる最大値です。セットの場合、それは一致するルールセットの権限全体の値の結合です。
In the following example we illustrate the process of combining permissions. We will consider three conditions for our purpose, namely those of name identity (WR-ID), sphere, and validity (from,until). The ID column is used as a rule identifier. For editorial reasons we omit the domain part of the WR's identity.
次の例では、権限を組み合わせるプロセスを示します。私たちの目的のための3つの条件、すなわち名前のアイデンティティ（WR-ID）、球体、および妥当性（から）の3つの条件を検討します。ID列は、ルール識別子として使用されます。編集上の理由から、WRのIDのドメイン部分を省略します。
We use two actions in our example, namely X and Y. The values of X and Y are of data types Boolean and Integer, respectively.
例では、xとyの2つのアクションを使用します。xとyの値は、それぞれBooleanと整数のデータ型です。
The transformation, referred to as Z, uses values that can be set either to '+' (or 3), 'o' (or 2) or '-' (or 1). Permission Z allows us to show the granularity reduction whereby a value of '+' shows the corresponding information unrestricted, and '-' shows nothing. This permission might be related to location information or other presence attributes like mood. Internally, we use the data type Integer for computing the permission of this attribute.
Zと呼ばれる変換は、「（または3）、「O」（または2）、または「 - 」（または1）に設定できる値を使用します。許可Zを使用すると、「 'の値が対応する情報が無制限に表示され、「 - 」が何も表示されない粒度の削減を示すことができます。この許可は、位置情報または気分などのその他の存在属性に関連している可能性があります。内部的には、この属性の許可を計算するためにデータ型整数を使用します。
The label 'NULL' in the table indicates that no value is available for a particular cell.
テーブルのラベル「ヌル」は、特定のセルに値がないことを示しています。
Conditions Actions/Transformations
+---------------------------------+---------------------+
| Id WR-ID sphere from until | X Y Z |
+---------------------------------+---------------------+
| 1 bob home A1 A2 | TRUE 10 o |
| 2 alice work A1 A2 | FALSE 5 + |
| 3 bob work A1 A2 | TRUE 3 - |
| 4 tom work A1 A2 | TRUE 5 + |
| 5 bob work A1 A3 | NULL 12 o |
| 6 bob work B1 B2 | FALSE 10 - |
+---------------------------------+---------------------+
Again for editorial reasons, we use the following abbreviations for the two <validity> attributes 'from' and 'until':
再び編集上の理由で、「from 'from」からの2つの<有効性>属性に次の略語を使用します。
A1=2003-12-24T17:00:00+01:00
A2=2003-12-24T21:00:00+01:00
A3=2003-12-24T23:30:00+01:00
B1=2003-12-22T17:00:00+01:00
B2=2003-12-23T17:00:00+01:00
Note that B1 < B2 < A1 < A2 < A3.
B1 <B2 <A1 <A2 <A3。
The entity 'bob' acts as a WR and requests data items. The rule set consists of the six rules shown in the table and identified by the values 1 to 6 in the 'Id' column. The PS receives the query at 2003-12-24T17:15:00+01:00, which falls between A1 and A2. In our example, we assume that the sphere value of the PT is currently set to 'work'.
エンティティ「ボブ」はWRとして機能し、データ項目を要求します。ルールセットは、テーブルに示されており、「ID」列の値1〜6で識別される6つのルールで構成されています。PSは、2003-12-24T17：15：00 01:00にクエリを受け取ります。これはA1とA2の間にあります。この例では、PTの球体値が現在「動作」に設定されていると想定しています。
As a first step, it is necessary to determine which rules fire by evaluating the conditions part of each of them.
最初のステップとして、それぞれの条件の一部を評価することにより、どのルールが発砲するかを決定する必要があります。
Rule 1 does not match since the sphere condition does not match. Rule 2 does not match as the identity of the WR (here 'alice') does not equal 'bob'. Rule 3 matches since all conditions evaluate to TRUE. Rule 4 does not match as the identity of the WR (here 'tom') does not equal 'bob'. Rule 5 matches. Rule 6 does not match since the rule is not valid anymore.
球体の条件が一致しないため、ルール1は一致しません。ルール2は、WRのアイデンティティ（ここでは「アリス」）が「ボブ」に等しくないため、一致しません。すべての条件がTRUEに評価されるため、ルール3は一致します。ルール4は、WRのアイデンティティ（ここに「トム」）が「ボブ」に等しくないため、一致しません。ルール5の一致。ルールはもはや有効ではないため、ルール6は一致しません。
Only rules 3 and 5 fire. We use the actions and transformations part of these two rules to determine the combined permission, as shown below.
ルール3と5の火災のみ。以下に示すように、これら2つのルールのアクションと変換の一部を使用して、複合許可を決定します。
Actions/Transformations
+-----+-----------------------+
| Id | X Y Z |
+-----+-----------------------+
| 3 | TRUE 3 - |
| 5 | NULL 12 o |
+-----+-----------------------+
Each column is treated independently. The combined value of X is set to TRUE since the NULL value equals FALSE according to the description in Section 10.2. For the column with the name Y, we apply the maximum of 3 and 12, so that the combined value of Y is 12. For column Z, we again compute the maximum of 'o' and '-' (i.e., 2 and 1) which is 'o' (2).
The combined permission for all three columns is therefore:
Actions/Transformations
+-----------------------+
| X Y Z |
+-----------------------+
| TRUE 12 o |
+-----------------------+
Meta policies authorize a rule maker to insert, update, or delete a particular rule or an entire rule set. Some authorization policies are required to prevent unauthorized modification of rule sets. Meta policies are outside the scope of this document.
メタポリシーは、ルールメーカーが特定のルールまたはルールセット全体を挿入、更新、または削除することを許可します。ルールセットの不正な変更を防ぐには、一部の許可ポリシーが必要です。メタポリシーは、このドキュメントの範囲外です。
A simple implementation could restrict access to the rule set only to the PT but more sophisticated mechanisms could be useful. As an example of such policies, one could think of parents configuring the policies for their children.
単純な実装は、PTにのみ設定されたルールへのアクセスを制限する可能性がありますが、より洗練されたメカニズムが役立つ可能性があります。そのようなポリシーの例として、親が子供のポリシーを構成することを考えることができます。
This section gives an example of an XML document valid with respect to the XML schema defined in Section 13. Semantically richer examples can be found in documents that extend this schema with application-domain-specific data (e.g., location or presence information).
このセクションでは、セクション13で定義されているXMLスキーマに関して有効なXMLドキュメントの例を示します。意味的に豊富な例は、アプリケーションドメイン固有のデータ（例：場所または存在情報）でこのスキーマを拡張するドキュメントにあります。
Below a rule is shown with a condition that matches for a given authenticated identity (bob@example.com) and within a given time period. Additionally, the rule matches only if the target has set its sphere to 'work'.
ルールの下には、特定の認証されたID（bob@example.com）と特定の期間内に一致する条件で示されています。さらに、ルールは、ターゲットが球体を「動作」に設定した場合にのみ一致します。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:bob@example.com"/>
</identity>
<sphere value="work"/>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
This section provides the XML schema definition for the common policy markup language described in this document.
このセクションでは、このドキュメントで説明されている一般的なポリシーマークアップ言語のXMLスキーマ定義を提供します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:common-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- /ruleset -->
<xs:element name="ruleset">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="rule" type="cp:ruleType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- /ruleset/rule -->
<xs:complexType name="ruleType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="conditions"
type="cp:conditionsType" minOccurs="0"/>
<xs:element name="actions"
type="cp:extensibleType" minOccurs="0"/>
<xs:element name="transformations"
type="cp:extensibleType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //rule/conditions -->
<xs:complexType name="conditionsType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice maxOccurs="unbounded">
<xs:element name="identity"
type="cp:identityType" minOccurs="0"/>
<xs:element name="sphere"
type="cp:sphereType" minOccurs="0"/>
<xs:element name="validity"
type="cp:validityType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/identity -->
<xs:complexType name="identityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="one" type="cp:oneType"/>
<xs:element name="many" type="cp:manyType"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/one -->
<xs:complexType name="oneType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:sequence>
<xs:attribute name="id"
type="xs:anyURI" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/many -->
<xs:complexType name="manyType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="except" type="cp:exceptType"/>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:choice>
<xs:attribute name="domain"
use="optional" type="xs:string"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //many/except -->
<xs:complexType name="exceptType">
<xs:attribute name="domain" type="xs:string" use="optional"/>
<xs:attribute name="id" type="xs:anyURI" use="optional"/>
</xs:complexType>
<!-- //conditions/sphere -->
<xs:complexType name="sphereType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:attribute name="value"
type="xs:string" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/validity -->
<xs:complexType name="validityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="from" type="xs:dateTime"/>
<xs:element name="until" type="xs:dateTime"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //rule/actions or //rule/transformations -->
<xs:complexType name="extensibleType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
14. Security Considerations
This document describes a framework for policies. This framework is intended to be enhanced elsewhere by application-domain-specific data. Security considerations are to a great extent application-data dependent, and therefore need to be covered by documents that extend the framework defined in this specification. However, new action and transformation permissions along with their allowed values must be defined in a way so that the usage of the permissions combining rules of Section 10 does not lower the level of privacy protection. See Section 10 for more details on this privacy issue.
このドキュメントでは、ポリシーのフレームワークについて説明します。このフレームワークは、アプリケーションドメイン固有のデータによって他の場所で強化されることを目的としています。セキュリティ上の考慮事項は、アプリケーションデータに大きく依存するため、この仕様で定義されているフレームワークを拡張するドキュメントでカバーする必要があります。ただし、セクション10のルールを組み合わせた権限の使用がプライバシー保護のレベルを下げないように、許可された値とともに新しいアクションおよび変換許可をその方法で定義する必要があります。このプライバシー問題の詳細については、セクション10を参照してください。
This section registers a new XML namespace, a new XML schema, and a new MIME type. This section registers a new XML namespace per the procedures in [4].
このセクションでは、新しいXMLネームスペース、新しいXMLスキーマ、新しいMIMEタイプを登録します。このセクションでは、[4]の手順ごとに新しいXMLネームスペースを登録します。
URI: urn:ietf:params:xml:ns:common-policy
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu).
登録者の連絡先：IETF Geoprivワーキンググループ、Henning Schulzrinne（hgs geopriv@cs.columbia.edu）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Common Policy Namespace</title>
</head>
<body>
<h1>Namespace for Common Authorization Policies</h1>
<h2>urn:ietf:params:xml:ns:common-policy</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4745.txt">
RFC 4745</a>.</p>
</body>
</html>
END
This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [5] and guidelines in RFC 3023 [6].
この仕様は、RFC 4288 [5]の手順とRFC 3023 [6]のガイドラインに従って、新しいMIMEタイプの登録を要求します。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: auth-policy+xml
MIMEサブタイプ名：Auth-Policy XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: charset
オプションのパラメーター：charset
Indicates the character encoding of enclosed XML.
囲まれたXMLの文字エンコードを示します。
Encoding considerations:
考慮事項のエンコード：
Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [6], Section 3.2.
使用する文字エンコードに応じて、8ビット文字を使用できるXMLを使用します。RFC 3023 [6]、セクション3.2を参照してください。
Security considerations:
セキュリティ上の考慮事項：
This content type is designed to carry authorization policies. Appropriate precautions should be adopted to limit disclosure of this information. Please refer to Section 14 of RFC 4745 and to the security considerations described in Section 10 of RFC 3023 [6] for more information.
このコンテンツタイプは、承認ポリシーを搭載するように設計されています。この情報の開示を制限するために、適切な注意事項を採用する必要があります。詳細については、RFC 4745のセクション14およびRFC 3023 [6]のセクション10で説明されているセキュリティ上の考慮事項を参照してください。
Interoperability considerations: None
相互運用性の考慮事項：なし
Published specification: RFC 4745
公開された仕様：RFC 4745
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Presence- and location-based systems
存在および位置ベースのシステム
Additional information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .apxml
ファイル拡張子：.apxml
Macintosh file type code: 'TEXT'
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@siemens.com
個人および電子メールアドレス詳細情報：Hannes Tschofenig、hannes.tchofenig@siemens.com
Intended usage: LIMITED USE
意図された使用法：使用されています
Author:
This specification is a work item of the IETF GEOPRIV working group, with mailing list address <geopriv@ietf.org>.
この仕様は、メーリングリストアドレス<geopriv@ietf.org>を備えたIETF Geoprivワーキンググループの作業項目です。
Change controller:
Change Controller：
The IESG <iesg@ietf.org>
URI: urn:ietf:params:xml:schema:common-policy
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu).
XML: The XML schema to be registered is contained in Section 13. Its first line is
XML：登録するXMLスキーマはセクション13に含まれています。その最初の行は
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
</xs:schema>
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[2] Duerst、M。and M. Suignard、「Internationalized Resource Identiers（IRIS）」、RFC 3987、2005年1月。
[3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[3]
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[4] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[5] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[5] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6]
[7] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.
[7]
[8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, February 2006.
[8]
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[9]
[10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[10] Schulzrinne、H.、Gurbani、V.、Kyzivat、P。、およびJ. Rosenberg、「rpid：Rich Expention拡張情報データ形式（PIDF）」、RFC 4480、2006年7月。
We would like to thank Christian Guenther for his help with initial versions of this document.
このドキュメントの最初のバージョンで彼の助けをしてくれたChristian Guentherに感謝します。
This document is partially based on the discussions within the IETF GEOPRIV working group. Discussions at the Geopriv Interim Meeting 2003 in Washington, D.C., helped the working group to make progress on the authorization policies based on the discussions among the participants.
We particularly want to thank Allison Mankin <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon Peterson <jon.peterson@neustar.biz> for discussing a number of details with us. They helped us to improve the quality of this document. Allison, Ted, and Andrew also helped us to make good progress with the internationalization support of the identifier/ domain attributes.
特に、Allison Mankin <mankin@psg.com>、Randall Gellens <rg ietf@qualcomm.com>、Andrew Newton <anewton@ecotroph.net>、ted hardie <hardie@qualcomm.com>、およびJon Peterson <jon.peterson@neustar.biz>私たちといくつかの詳細について話し合いてくれて。彼らは私たちがこの文書の品質を向上させるのに役立ちました。アリソン、テッド、アンドリューは、識別子/ドメイン属性の国際化のサポートで良い進歩を遂げるのを助けました。
Furthermore, we would like to thank the IETF SIMPLE working group for their discussions of J. Rosenberg's draft on presence authorization policies. We would also like to thank Stefan Berg, Murugaraj Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki Niemi, Eva Maria Leppanen, Josip Matanovic, and Mark Baker for their comments. Martin Thomson helped us with the XML schema. Mark Baker provided a review of the media type. Scott Brim provided a review on behalf of the General Area Review Team.
さらに、J。ローゼンバーグのプレゼンス認可ポリシーのドラフトについて議論してくれたIETF Simple Working Groupに感謝します。また、Stefan Berg、Murugaraj Shanmugam、Christian Schmidt、Martin Thomson、Markus Isomaki、Aki niemi、Eva Maria Leppanen、Josip Matanovic、Mark Bakerにコメントに感謝します。マーティン・トムソンはXMLスキーマを手伝ってくれました。マーク・ベイカーはメディアタイプのレビューを提供しました。スコット・ブリムは、一般的なエリアレビューチームに代わってレビューを提供しました。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
ヘニングシュルツリンヌコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク州ニューヨーク10027 USA
Phone: +1 212 939 7042
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Hannes Tschofenig Siemens Networks GmbH＆Co KG Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA
ジョン・B・モリス、ジュニア民主主義技術センター1634 IストリートNW、スイート1100ワシントンDC 20006 USA
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ホルヘ・R・クエラ・シーメンス・オットー・ハーン・リング6ミュンヘン、ババリア81739ドイツ
EMail: Jorge.Cuellar@siemens.com
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
EMail: jmpolk@cisco.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, New York 07054 USA
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニューヨーク07054 USA
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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エディター機能の資金は現在、インターネット協会によって提供されています。