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）IETFトラスト（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倍です。まず、それは自然な方法で位置情報を持つ存在の価値を高め、同じ基本認証メカニズムを再利用するシステムを構築することができます。第二に、それは拡張のためのメカニズムと、より汎用的な承認フレームワークを奨励しています。この文書で指定されたフレームワークの適用は存在および位置情報データへのアクセスを制御するポリシーに限定されるものではなく、他のアプリケーションドメインに拡張することができます。
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 IANA問題部14節15以下のセキュリティ問題にセクションで説明されるであろう。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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のためのデータ項目の照会を受け取ります。使用するプロトコル（またはより正確には、認証プロトコル）は、クエリの時または加入時にいずれか、要求者の身元を提供します。用いたプロトコルまたはサーバに一般的に利用可能なにより提供される他の情報と共に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、指、および共通オブジェクト要求ブローカサン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セッションセットアップ（INVITE要求）、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.)
イベント通知にサブスクリプションのフェーズを追加し、「アクティブリクエスト - レスポンス - クライアント（イニシエータ）としてPS」の動作モードを。ウォッチャ又は加入者は、特定のプレゼンティティまたはイベントの通知リストに追加することが求められます。プレゼンの変化状態やイベントが発生すると、PSは、更新された状態を含むWRにメッセージを送信します。 （プレゼンスは、イベント通知の特殊なケースであるため、私たちはしばしば互換用語を使用しています。）
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.
アップグレードされていないのPSを壊すことなく、後から追加ルールを追加することが可能でなければなりません。任意のそのようなアップグレードは、プライバシーの制約を低下させてはならないが、まだアップグレードされていないPSSは、ルールメーカーが選択しているだろうより少ない情報を公開してもよいです。
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.
条件は、そのような、またはglobスタイルのマッチ（「*@example.com（ 『％fooの％』 LIKE例えば、）SQL LIKE演算子として部分一致は、平等や「大なりthan'スタイルの比較ではなく、正規表現に一致しています「）。これらのほとんどは、よりよい明示的要素として表現されています。
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.
繰り返し回（午後4時まで午前9時から、例えば、毎日）によりPT、WR、PS、およびRMが占めることができる別のタイムゾーンに、正しく動作させることは困難です。時間間隔を含むための提案は、多くの場合、残念ながら一人の時間によって捕獲することが困難な作業/非作業の区別を、サポートに基づいていることが表示されます。この機能は、ルールの有効期間を制限するためのメカニズムを提供する「妥当性」要素と混同してはならないことに注意してください。
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に搬送することができます。ルールは、3つの部分からなる：条件（セクション7参照）、アクション（セクション8を参照）、および変換（9章を参照のこと）。
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.
条件部は、TRUEまたは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
等、その位置情報を、それらの存在、 - - WRに提示される前に変更されるアクションは、要求の続行を可能にすると仮定すると、ルールの変換部は、PTについての情報をどのように指定します。これらの変換は、正のアクセス権の形態です。つまり、彼らは常にWRで見られることを許可された情報の一部を指定します。 PSが要求を処理するときに、一致するすべてのルール間で指定された変換をとり、それらの和集合を作成します。この組合を計算するために、そのような整数、ブール、設定、または未定義のデータ型などのデータ型は、役割を果たしています。権限を組み合わせるためのアルゴリズムの詳細については、セクション10をもたらすと記載されています
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.
労働組合は、効果的に「マスク」を表している - それは情報がWRにさらされているものを定義します。このマスクは、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に利用可能である二つの規則のために同じ識別子を使用してはいけません。複数の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に記載されています。また、条件要素は、このドキュメントの拡張機能を経由して追加することができます。 <条件>の子要素は、要素が知られていないか、サポートされていない名前空間にある場合、この子要素は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の、ならびに部13にテキスト：anyURIのタイプ、読者はそのディスカッションXSのための[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.
アイデンティティの条件は、単一のエンティティまたはエンティティのグループにどちらかのルールのマッチングを制限します。唯一の認証されたエンティティは一致させることができます。認証の許容可能な手段は、プロトコル固有の文書で定義されています。 <アイデンティティ>要素が存在しない場合は、アイデンティティは考慮されていない、ため、ルール内の他の条件はすべてのユーザーに適用され、認証されたかではありません。
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.
<アイデンティティ>要素の子要素がサポートされていない知られているかされていない名前空間にある場合、この子要素は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.
<1>要素は、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">
<？xml version = "1.0" エンコード= "UTF-8"？> <ルールセットのxmlns = "壷：IETF：のparams：XML：NS：共通ポリシー">
<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>
</ルールセット>
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.
alice@example.com、TEL：+ 1-212-555-1234、またはMAILTO：bob@example.net WRの認証された識別情報がいずれかの一口であれば、この例では、一致しました。
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.
<多くの>要素は、認証されたアイデンティティのドメイン部分に基づいて承認決定を行うための仕組みです。このように、ドメイン内のユーザの大およびおそらく未知の数に一致することができます。
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.
また、特定のドメインに属する個々のユーザーまたはユーザーのいずれかを除外するための要素<除い>一つまたは複数を含むことが可能です。個々のエンティティを除外する<除き、ID =「...」/>ステートメントを使用して実装されています。要素<除く>の「ID」属性の意味は、<1>要素（セクション7.2を参照）の「ID」属性と同じ意味を持っています。特定のドメインに属する除くと、ユーザーは、指定されたドメインからすべてのユーザーを除外要素<ドメイン=「...」/以外>使用して実装されます。
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.
複数の<除く>要素は、<多数>要素の子要素、要素、論理を使用して、または組み合わせられる<除く>それぞれのその結果として表示されている場合。
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を使用する必要があります。 「ドメイン」属性と（「プロトコルドメイン識別子」と呼ぶ）を使用してプロトコルを介して提供される領域の値に格納された値との比較動作のために、以下の規則が適用されます。
2. Convert both domain strings using the ToASCII operation described in RFC 3490 [3].
2. RFC 3490に記載さもしToASCII操作を使用して、両方のドメインの文字列を変換[3]。
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.
変換は、ステップ（2）に失敗した場合、ドメインは等しくありません。
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">
<？xml version = "1.0" エンコード= "UTF-8"？> <ルールセットのxmlns = "壷：IETF：のparams：XML：NS：共通ポリシー">
<rule id="f3g44r5">
<conditions>
<identity>
<many/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
</ルールセット>
7.1.3.2. Matching Any Authenticated Identity Except Enumerated Domains/Identities
7.1.3.2。列挙型ドメイン/アイデンティティ以外の任意の認証されたIDをマッチング
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.
一つ以上を囲む<多くの>要素<ドメイン除いを=「...」/>要素が列挙されたものを除く任意のドメインの任意のユーザーに一致します。 <除き、ID = "..." />要素は、特定のユーザーを除外します。 <除く>要素の「ID」属性の意味は、7.2節に記述されています。 <多くの>要素の子要素の結果は論理和（OR）を使用して結合されています。
An example is shown below:
例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<？xml version = "1.0" エンコード= "UTF-8"？> <ルールセットのxmlns = "壷：IETF：のparams：XML：NS：共通ポリシー">
<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はすでに最初のラインを通って除外されているので、要素「を除いて」最後のは冗長です。
7.1.3.3. Matching Any Authenticated Identity within a Domain Except Enumerated Identities
7.1.3.3。列挙型アイデンティティを除いて、ドメイン内の任意の認証されたIDをマッチング
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.
要素<ID =「...」/除く> <多くの>「ドメイン」属性を持つ要素と0個以上は、明示的に列挙されたものを除き、指定されたドメインからの任意の認証されたユーザーに一致します。 <除く>要素の「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.
囲む<多くの>要素に「ドメイン」属性の値と一致しない「ID」属性でのドメインを持つことが無意味です。
An example is shown below:
例を以下に示します。
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<？xml version = "1.0" エンコード= "UTF-8"？> <ルールセットのxmlns = "壷：IETF：のparams：XML：NS：共通ポリシー">
<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>
</ルールセット>
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以外（例えばcarol@example.comなど）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.
<1>およびで使用「ID」属性は、<以外>要素は、単一のエンティティを指します。後続のテキストでは、<1>のプレースホルダとして用語「シングルユーザエンティティ」を使用し、要素<除きます>。 <除く>要素は、ソリューションセットから要素を排除する目的を果たします。
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」属性に含まれる）と一致します。一致がある場合は、シングルユーザエンティティがTRUEとみなされます。シングルユーザエンティティは、「ドメイン」属性を含めることはできません。
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.
<球>要素は、条件要素のグループに属します。 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.
<球>要素の「値」属性の内容は、複数のトークンを含むかもしれません。個々のトークンは空白文字で区切らなければなりません。論理OR PTの球の設定との照合トークンのために使用されます。例として、球属性の「値」属性の内容は、2つのトークンの仕事」と「家庭」を含んでいる場合、特定のPTのための球は「仕事」OR「ホーム」のどちらかであるならば、ルールのこの部分が一致します。各個々のトークンのために使用されなければならない、大文字と小文字を区別しない文字列比較を設定するPTの球についての記憶された状態情報と<球体>要素の「値」属性の内容を比較します。これらの値のレジストリでも球のコンテンツの言語固有の兆候もないがあります。そのため、トークンは、不透明な文字列として扱われます。
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<？xml version = "1.0" エンコード= "UTF-8"？> <ルールセットのxmlns = "壷：IETF：のparams：XML：NS：共通ポリシー">
<rule id="f3g44r2"> <conditions> <sphere value="work"/> <identity> <one id="sip:andrew@example.com"/> </identity> </conditions> <actions/> <transformations/> </rule>
<ルールID = "f3g44r2"> <条件> <球値= "仕事" /> <アイデンティティ> <1つのID = "一口：andrew@example.com" /> </アイデンティティ> </条件> <アクション/> <変換/> </ルール>
<rule id="y6y55r2"> <conditions> <sphere value="home"/> <identity> <one id="sip:allison@example.com"/> </identity> </conditions> <actions/> <transformations/> </rule>
<ルールID = "y6y55r2"> <条件> <球値= "ホーム" /> <アイデンティティ> <1つのID = "一口：allison@example.com" /> </アイデンティティ> </条件> <アクション/> <変換/> </ルール>
<rule id="z6y55r2"> <conditions> <identity> <one id="sip:john@doe.example.com"/> </identity> <sphere value="home work"/> </conditions> <actions/> <transformations/> </rule> </ruleset>
<ルールID = "z6y55r2"> <条件> <アイデンティティ> <1つのID = "一口：john@doe.example.com" /> </アイデンティティ> <球値= "在宅ワーク" /> </条件> <アクション/> <変換/> </ルール> </ルールセット>
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は一致します。球要素の値はまた、トークン「ホーム」を含んでいるので、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.
<妥当性>要素は、この文書で指定された第三の条件要素です。これは、2つの属性、開始と終了の時点で、ルールの有効期間を表しています。現在時刻がより大きいまたは子<から>少なくとも1に等しく、それの後に<まで>子よりも小さい場合、有効条件はTRUEです。これは、対<まで> <から>各横切る論理OR演算を表し、。タイムズは、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">
<？xml version = "1.0" エンコード= "UTF-8"？> <ルールセットのxmlns = "壷：IETF：のparams：XML：NS：共通ポリシー">
<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>
<ルールID = "f3g44r3"> <条件> <有効期間> 2003-08-15T10 <から>：20：00.000から05：00 </から> <まで> 2003-09-15T10：20：00.000から05：00 </まで> </妥当性> </条件> <アクション/> <変換/> </ルール> </ルールセット>
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.
<妥当性>要素は、ペアでのサブ要素<から>と<まで>を持たなければなりません。 <から>複数及び要素（すなわち、<から>のネストなしと要素<まで>）ペアで現れるかもしれない<まで>。 <条件>要素の全てのサブエレメントは、論理ANDとして組み合わされているので、<条件>要素のサブ要素として複数の<有効性>要素を使用することは有用ではありません。
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.
条件であるがthen'部分「ルールのif'-一部、アクションと変換は彼らの」を形成します。ルールのアクションおよび変換部PSはWRから、このルールのすべての条件に一致するデータアクセス要求を受信した後に実行しなければならない動作を決定。アクションと変換は唯一の特定の操作を許可します。 NO「拒否」機能はありません。変換は、もっぱらWRによって要求されたデータ項目の変更につながるPS側の操作を指定します。位置データ項目について、例えば、変換は、WRに戻される位置情報の精度を低下させるためにPSを強制することができました。
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.
アクションは、他の一方で、PSを実行するように義務付けられている動作の全ての残りのタイプ、変換タイプではない、すなわち、すべての操作を指定します。アクションは、このフレームワークのアプリケーション固有の用法で定義されています。読者は、このような要素の例を参照するために、対応する拡張機能と呼ばれます。
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.
変換とアクション：二つのサブパーツは、ルールの条件の一部に従ってください。セクション8で定義されるように、変換は、PSが実行する必要があり、それはWRに返された結果を変更する操作を指定します。この機能は、例えば、位置プライバシーのために必要として、WRに提供される情報の粒度を減らすのに特に有用です。変換は、このフレームワークのアプリケーション固有の用途によって規定されています。
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と評価された場合、ルールが一致しました。それが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.
ブール権限のため、得られた許可があればTRUEで、マッチング・ルール・セット内の少なくとも1つの許可は、そうでなければTRUEおよび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）、球、および有効性（まで、から）の、すなわち、それらを検討します。 ID列は、ルール識別子として使用されます。編集上の理由から、私たちはWRのアイデンティティのドメイン部分を省略します。
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のXとYの値を使用し、それぞれのデータ型ブールと整数です。
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.
「 - 」（又は1）変換、Zと称するは、いずれかの「+」（又は3）、「O」（又は2）又は設定可能な値を使用します。パーミッションZは、私たちは「+」の値は、対応する情報の無制限表示させる粒度の減少を表示することができ、そして「 - 」何も表示されません。この許可は、位置情報や他の存在の気分などの属性に関係している可能性があります。内部的には、我々は、この属性の許可を計算するためのデータ型の整数を使用します。
The label 'NULL' in the table indicates that no value is available for a particular cell.
テーブル内のラベル「NULL」がない値は、特定のセルのために利用できないことを示しています。
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':
再び編集の理由のために、私たちは「まで、」「から」属性と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
A1 = 2003-12-24T17：00：00 + 01：00 2 = 2003-12-24T21：00：00 + 01：00 I = 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
実体「ボブ」はWRとして動作し、データ項目を要求します。ルールセットは、6つのルールテーブルに示し、「ID」列に6に値1によって識別から成ります。 PSはでクエリを受信します
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'.
2003-12-24T17：15：00 + 01：A1とA2の間に入る00。この例では、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火を支配します。我々は、以下に示すように、合成許可を決定するために、これら二つのルールのアクション及び変換部を使用します。
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).
各列は独立して処理されます。 Xの合成値は、NULL値は、セクション10.2に記述に従ってFALSEに等しいので、TRUEに設定されています。 「 - 」（すなわち、2及び1 Yの合成値は、カラムZのための12となるように名前をYと列に対して、我々は、3と12の最大値を適用し、我々は再び「O」との最大値を計算します） 'O' である（2）。
The combined permission for all three columns is therefore:
すべての3つの列の組み合わせパーミッションはそのためです。
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'.
ルール下記認証アイデンティティ（bob@example.com）のために、与えられた時間内に一致する状態で示されています。また、ルールは、ターゲットが「仕事」にその球を設定している場合にのみ一致します。
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<？xml version = "1.0" エンコード= "UTF-8"？> <ルールセットのxmlns = "壷：IETF：のparams：XML：NS：共通ポリシー">
<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>
<ルールID = "f3g44r1"> <条件> <アイデンティティ> <1つのID = "SIP：bob@example.com" /> </アイデンティティ> <球体値= "仕事" /> <有効期間> <から> 2003- 12-24T17：00：00 + 01：00 </から> <まで> 2003-12-24T19：00：00 + 01：00 </まで> </有効期間> </条件> <アクション/> <変換/ > </ルール> </ルールセット>
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"/>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：共通政策" のxmlns：CP = "壷：IETF：のparams：XML ：NS：共通政策」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "非修飾"> < - /ルールセット - > <XS：！要素NAME = "ルールセット"> <XS：complexTypeの> <XS：complexContentを> <XS：制限ベース= "XS：anyType型"> <XS：配列> <XS：要素名= "ルール" タイプ= "CP：のRuleType" minOccurs属性= "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> </ XS：制限> </ XS：complexContentを> </ XS：complexTypeの> </ XS：！要素> < - /ルールセット/ルール - - > <XS：complexTypeの名= "のRuleType"> <XS：complexContentを> <XS：制限ベース= "XS：anyType型"> <XS：配列> <XS：要素名= "条件" タイプ= "CP：conditionsType" minOccurs = "0" /> <XS：要素名= "アクション" タイプ= "CP：extensibleType" のminOccurs = "0" /> <XS：要素名= "変換" タイプ= "CP：extensibleType" のminOccurs = "0 "/> </ XS：配列> <XS：属性名=" ID」タイプ= "XS：ID" 使用= "必須" /> </ XS：制限> </ XS：COMPL exContent> </ XS：complexTypeの> < - //ルール/条件 - > <XS：！complexTypeの名前= "conditionsType"> <XS：complexContentを> <XS：制限ベース= "XS：anyTypeの"> <XS：選択肢のmaxOccurs = "無制限"> <XS：要素名= "アイデンティティ" タイプ= "CP：たIdentityType" のminOccurs = "0" /> <XS：要素名= "球" タイプ= "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>
<XS：complexTypeの名前= "exceptType"> <XS：属性名= "ドメイン" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "ID" タイプ= "XS：anyURIの" 使用= "オプション" /> </ XS：complexTypeの> < - //条件/球 - > <XS：！complexTypeの名= "sphereType"> <XS：complexContentを> <XS：制限ベース= "XS：anyTypeを" > <XS：属性名= "値" タイプ= "XS：文字列" 使用は= "必要" /> </ XS：制限> </ XS：complexContentを> </ XS：！complexTypeの> < - //条件/妥当性 - > <XS：complexTypeの名= "validityType"> <XS：complexContentを> <XS：制限ベース= "XS：anyType型が"> <XS：配列のminOccurs = "1" のmaxOccurs = "無制限"> <XS：要素名前=タイプ= "XS：dateTimeの" "から" /> <XS：要素名=タイプ= "XS：dateTimeの" "まで" /> </ XS：配列> </ XS：制限> </ XS：complexContentを> </ XS：complexTypeの> <！ - //ルール/アクションまたは//ルール/変換 - > <XS：complexTypeの名= "extensibleType"> <XS：complexContentを> <XS：制限ベース= "XS：anyTypeを" > <XS：シーケンス> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列uence> </ XS：制限> </ XS：complexContentを> </ XS：complexTypeの> </ XS：スキーマ>
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
URI：URN：IETF：のparams：XML：NS：共通ポリシー
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu).
登録者連絡先：IETF GEOPRIVワーキンググループ、ヘニング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
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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" /> <タイトル>共通ポリシー名前空間</ TITLE> </ HEAD> <BODY> <H1>一般的な承認ポリシー</ H1> <H2> URNのための名前空間：IETF：のparams：XML：NS：コモンポリシー</ H2> <P> <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 3023でRFC 4288 [5]の手順およびガイドラインに従って、新しいMIMEタイプの登録を要求する[6]。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: auth-policy+xml
MIMEサブタイプ名：AUTH-政策+ xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: 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.
このコンテンツタイプは、認可ポリシーを運ぶように設計されています。適切な予防措置は、この情報の開示を制限するために採用されるべきです。詳細については、[6] RFC 4745のセクション14及びRFC 3023のセクション10に記載されたセキュリティ上の考慮事項を参照してください。
Interoperability considerations: None
相互運用性に関する注意事項：なし
Published specification: RFC 4745
公開された仕様：RFC 4745
Applications which use this media type:
このメディアタイプを使用するアプリケーション：
Presence- and location-based systems
Presence-及びロケーションベースのシステム
Additional information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .apxml
ファイル拡張子：.apxml
Macintosh file type code: 'TEXT'
Macintoshのファイルタイプコード：「TEXT」
Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@siemens.com
詳しくは、個人やメールアドレス：ハンネスTschofenig、Hannes.Tschofenig@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:
コントローラを変更します。
The IESG <iesg@ietf.org>
IESG <iesg@ietf.org>
URI: urn:ietf:params:xml:schema:common-policy
URI：URN：IETF：のparams：XML：スキーマ：共通ポリシー
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu).
登録者連絡先：IETF GEOPRIVワーキンググループ、ヘニング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"?>
<？xml version = "1.0" エンコード= "UTF-8"？>
and its last line is
そしてその最後の行があります
</xs:schema>
</ XS：スキーマ>
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[2] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[3] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、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]フリード、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]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[7] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.
[7]ローゼンバーグ、J.、 "プレゼンス認証ルール" は、進歩、2006年6月に作業。
[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] Schulzrinneと、H.、Tschofenig、H.、モリス、J.、クエリャル、J.、およびJ.ポーク、 "位置情報のためのプライバシー設定を表現するためのドキュメントフォーマット"、進歩、2006年2月に作業。
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[9]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。
[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.ローゼンバーグ、 "RPID：プレゼンス情報データフォーマット（PIDF）にリッチプレゼンスの拡張"、RFC 4480、2006年7月。
Appendix A. Contributors
付録A.協力者
We would like to thank Christian Guenther for his help with initial versions of this document.
私たちは、この文書の初期バージョンとの彼の助けのためのキリスト教のギュンターに感謝したいと思います。
Appendix B. Acknowledgments
付録B.謝辞
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.
このドキュメントは、部分的にIETF GEOPRIVワーキンググループ内での議論に基づいています。ワシントンD.C.でGeopriv中間会議2003での議論は、参加者間の議論に基づいて認可ポリシーの進捗状況を作るためのワーキンググループを助けました。
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.
私たちは、特にアリソンマンキン<mankin@psg.com>、ランドールGellens <rg+ietf@qualcomm.com>、アンドリュー・ニュートン<anewton@ecotroph.net>、テッドハーディー<hardie@qualcomm.com>、およびジョンピーターソンに感謝したいと思います<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ワーキンググループに感謝したいと思います。我々はまた、彼らのコメントのためにステファン・ベルク、Murugaraj Shanmugam、クリスチャン・シュミット、マーティン・トムソン、マルクスIsomaki、アキニエミ、エヴァ・マリア・Leppanen、ヨシップMatanovic、そしてマーク・ベイカーに感謝したいと思います。マーティン・トムソンは、XMLスキーマで私たちを助けました。マーク・ベイカーは、メディアタイプのレビューを提供します。スコット・ブリムは、一般的なエリアレビューチームを代表してレビューを提供しました。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027 USAのヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7042 EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
電話：+1 212 939 7042 Eメール：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
ハンネスTschofenigシーメンスネットワークス社＆CoのKGオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com
電子メール：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のためのジュニアセンターワシントンD.C. 20006 USA
EMail: jmorris@cdt.org URI: http://www.cdt.org
電子メール：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
メールアドレス：Jorge.Cuellar@siemens.com
James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームズ・ポークのCisco 2200東ブッシュ大統領ターンパイクリチャードソン、テキサス州75082 USA
EMail: jmpolk@cisco.com
メールアドレス：jmpolk@cisco.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, New York 07054 USA
ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、ニューヨーク07054 USA
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電子メール：jdrosen@cisco.com URI：http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。