[要約] RFC 4661は、イベント通知フィルタリングのためのXMLベースのフォーマットを定義しています。このRFCの目的は、イベント通知の効率的なフィルタリングと処理を可能にすることです。
Network Working Group H. Khartabil
Request for Comments: 4661 Telio
Category: Standards Track E. Leppanen
M. Lonnfors
J. Costa-Requena
Nokia
September 2006
An Extensible Markup Language (XML)-Based Format for Event Notification Filtering
イベント通知フィルタリング用の拡張可能なマークアップ言語（XML）ベースの形式
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 Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document.
SIPイベント通知フレームワークでは、サブスクリプションのセッション開始プロトコル（SIP）の使用と、リソースの状態の変更の通知について説明します。このドキュメントでは、イベント通知情報のフィルタリングを達成できるメカニズムについては説明していません。フィルタリングは、配信される優先通知情報を定義し、その情報を配信するトリガーを指定するためのメカニズムです。これを有効にするには、サブスクライバーが通知を送信するリソースの状態の変更とそれらの通知を含めるものを説明できるようにするために、形式が必要です。このドキュメントでは、XMLドキュメントの形式の形式を提示します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Structure of XML-Encoded Simple-Filter . . . . . . . . . . . . 4
3.1. MIME Type for Simple-Filter Document . . . . . . . . . . 4
3.2. The <filter-set> Root Element . . . . . . . . . . . . . 4
3.3. The <ns-bindings> Element . . . . . . . . . . . . . . . 4
3.4. The <filter> Element . . . . . . . . . . . . . . . . . . 5
3.5. The <what> Element . . . . . . . . . . . . . . . . . . . 6
3.5.1. The <include> Element . . . . . . . . . . . . . 6
3.5.2. The <exclude> Element . . . . . . . . . . . . . 7
3.5.3. The 'type' Attribute . . . . . . . . . . . . . . 7
3.6. The <trigger> Element . . . . . . . . . . . . . . . . . 8
3.6.1. The <changed> Element . . . . . . . . . . . . . 8
3.6.2. The <added> Element . . . . . . . . . . . . . . 9
3.6.3. The <removed> Element . . . . . . . . . . . . . 10
4. XML Schema Extensibility . . . . . . . . . . . . . . . . . . . 10
5. Syntax for Referencing XML Items and Making Logical
Expressions . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Filter Criteria Using <what> Element . . . . . . . . . . 12
6.2. Filter Criteria Using <trigger> Element . . . . . . . . 13
6.3. Filter Criteria Using <what> and <trigger> Elements . . 13
6.4. Content Filter Using Namespaces . . . . . . . . . . . . 14
6.5. Content Filter Using Only <include> Elements . . . . . . 14
6.6. Two Content Filters as Filter Criteria . . . . . . . . . 15
7. XML Schema for Filter Criteria . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. application/simple-filter+xml MIME TYPE . . . . . . . . 19
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:simple-filter . . . . . . . . . . . 20
9.3. Schema Registration . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21
The SIP event notification framework [2] describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.
SIPイベント通知フレームワーク[2]では、サブスクリプションのセッション開始プロトコル（SIP）の使用と、リソースの状態の変更の通知について説明します。このドキュメントでは、イベント通知情報のフィルタリングを達成できるメカニズムについては説明していません。
Filtering is a mechanism for defining the preferred notification information, referred to as content, to be delivered and for specifying the rules for when that information should be delivered.
フィルタリングは、コンテンツと呼ばれる優先通知情報を配信するメカニズム、およびその情報をいつ配信するかのルールを指定するためのメカニズムです。
The filtering mechanism is expected to be particularly valuable and primarily applicable to users of mobile wireless access devices. The characteristics of the devices typically include high latency, low bandwidth, low data processing capabilities, small display, and limited battery power. Such devices can benefit from the ability to filter the amount of information generated at the source of the event notification. However, implementers need to be aware of the computational burden on the source of the event notification. This is discussed further in Section 8.
フィルタリングメカニズムは特に価値があり、主にモバイルワイヤレスアクセスデバイスのユーザーに適用できると予想されます。デバイスの特性には、通常、高レイテンシ、低帯域幅、低データ処理機能、小さなディスプレイ、および限られたバッテリー電源が含まれます。このようなデバイスは、イベント通知のソースで生成された情報の量をフィルタリングする機能の恩恵を受けることができます。ただし、実装者は、イベント通知のソースの計算負担に注意する必要があります。これについては、セクション8でさらに説明します。
The structure of the filter criteria is described using the XML schema. The filter criteria is presented as an XML document. The XML document contains the user's preference as to when notifications are to be sent to it and what they are to contain. The scope of the "when" part is triggering.
フィルター基準の構造は、XMLスキーマを使用して説明されています。フィルター基準はXMLドキュメントとして提示されます。XMLドキュメントには、通知がいつ送信されるか、およびそれらが何を含めるかについてのユーザーの好みが含まれています。「When」部分の範囲がトリガーされています。
The triggering is defined as enabling a subscriber to specify triggering rules for notifications where the criteria are based on changes of the event package [2] specific state information, e.g., for the presence information document [15], the change in the value of the <status> element.
トリガーは、サブスクライバーがイベントパッケージ[2]特定の状態情報の変更に基づく通知のトリガールールを指定できるように定義されています。<ステータス>要素。
The functionality of the filtering regarding the SIP event notifications is specified in [3].
SIPイベント通知に関するフィルタリングの機能は、[3]で指定されています。
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワード「必須」、「必須」、「必須」、「必要」、「しない」、「そうではない」、「必要」、「推奨」、「5月」、および「オプション」RFC 2119 [1]に記載されているように解釈され、準拠した実装の要件レベルを示します。
Throughout the document, the "resulting XML document" refers to the final XML document that carries state information to be delivered to the subscriber after the filters have been applied to it.
ドキュメント全体を通して、「結果のXMLドキュメント」は、フィルターが適用された後にサブスクライバーに状態情報を配信する最終XMLドキュメントを指します。
"Content" refers to the XML document that appears in a notification reflecting the state of a resource.
「コンテンツ」とは、リソースの状態を反映した通知に表示されるXMLドキュメントを指します。
A simple-filter is an XML document [8] that MUST be well formed and MUST be valid according to schemas, including extension schemas, available to the validater, and applicable to the XML document. The simple-filter documents MUST be based on XML 1.0 and MUST be encoded using UTF-8.
シンプルフィルターはXMLドキュメント[8]であり、適切に形成されている必要があり、拡張スキーマを含むスキーマに従って有効である必要があります。シンプルフィルタードキュメントはXML 1.0に基づいている必要があり、UTF-8を使用してエンコードする必要があります。
The namespace identifier for elements defined by this specification is a URN [5], which uses the namespace identifier 'ietf' defined by [6] and extended by [4]. This urn is: urn:ietf:params:xml:ns:simple-filter.
この仕様で定義された要素の名前空間識別子は、[6]で定義され、[4]で拡張された名前空間識別子「IETF」を使用するuRN [5]です。このurnは：urn：ietf：params：xml：ns：simple-filterです。
This namespace declaration indicates the namespace on which the filter criteria are based.
この名前空間宣言は、フィルター基準の基礎となる名前空間を示します。
The MIME type for the simple-filter document is "application/ simple-filter+xml". Any transport protocol (SIP [12], for example) used to carry the filters that also carries payload type information MUST identify the payload as MIME type "application/simple-filter+xml" (for example, a Content-Type header field).
シンプルフィルタードキュメントのMIMEタイプは「アプリケーション/シンプルフィルターXML」です。また、ペイロードタイプの情報を運ぶフィルターを運ぶために使用されるトランスポートプロトコル（SIP [12]）は、ペイロードをMIMEタイプ「アプリケーション/シンプルフィルターXML」（たとえば、コンテンツタイプのヘッダーフィールド）として識別する必要があります。
The root element of the filter criteria is <filter-set>.
フィルター基準のルート要素は<フィルターセット>です。
The <filter-set> element contains the namespace definition mentioned above. With the optional 'package' attribute, it is possible to define the package to which the filter criteria is applied. This might be especially useful in cases where the XML document containing the filter criteria is separated from the events that make use of it or from the protocol that usually carries it.
<filter-set>要素には、上記の名前空間定義が含まれています。オプションの「パッケージ」属性を使用すると、フィルター基準が適用されるパッケージを定義することができます。これは、フィルター基準を含むXMLドキュメントが、それを利用するイベントまたは通常それを運ぶプロトコルから分離されている場合に特に役立つかもしれません。
The <filter-set> element may contain one <ns-bindings> element.
<filter-set>要素には、1つの<ns-bindings>要素が含まれている場合があります。
The <filter-set> element contains one or more <filter> elements.
<filter-set>要素には、1つ以上の<filter>要素が含まれています。
The <ns-bindings> element is used to bind namespaces to local prefixes used in expressions that select elements or attributes using the syntax in Section 5. Those prefixes apply to the <include>, <exclude>, <changed>, <added>, and <removed> elements.
<ns-bindings>要素は、セクション5の構文を使用して要素または属性を選択する式で使用されるローカルプレフィックスに名前空間をバインドするために使用されます。これらのプレフィックスは、<cluding>、<exclude>、<changed>、<added>に適用されます。、および<削除>要素。
The <ns-bindings> element contains one or more <ns-binding> elements. Each <ns-binding> element has a 'prefix' attribute. The value of the 'prefix' attribute is a prefix used to qualify the elements pointed to by the expression. The <ns-binding> element also has a 'urn' attribute that identifies the namespace that the prefix represents.
<ns-bindings>要素には、1つ以上の<ns結合>要素が含まれています。各<nsバインディング>要素には、「プレフィックス」属性があります。「プレフィックス」属性の値は、式によって指し示される要素を認定するために使用されるプレフィックスです。<ns-binding>要素には、プレフィックスが表す名前空間を識別する「urn」属性もあります。
The <filter> element is used to specify the content of an individual filter.
<filter>要素は、個々のフィルターの内容を指定するために使用されます。
The <filter> element has an 'id' attribute. The value of the 'id' attribute MUST be unique within the <filter-set> element. The <filter> MAY have a 'uri' attribute. The value of the 'uri' attribute is the URI of the resource to which the filter applies. The <filter> MAY have a 'domain' attribute. The value of the 'domain' attribute is the domain of the resources to which the filter applies. The 'uri' attribute and the 'domain' attribute MUST NOT appear together in the <filter>.
<filter>要素には「id」属性があります。「ID」属性の値は、<filter-set>要素内で一意でなければなりません。<filter>には「uri」属性がある場合があります。「URI」属性の値は、フィルターが適用されるリソースのURIです。<filter>には「ドメイン」属性がある場合があります。「ドメイン」属性の値は、フィルターが適用されるリソースのドメインです。「uri」属性と「ドメイン」属性は、<filter>に一緒に表示されてはなりません。
The URI of the resource is useful in cases where the 'event list' extension [17] is used with a package. Since a subscription to an event package may be addressed to an event list, the 'uri' attribute allows the subscriber to define a filter specific to an individual resource within that list. That resource may be another list. The 'uri' attribute may, of course, carry the URI of the list itself. If the <filter> does not contain the 'uri' attribute, the filter applies to the resource identified in the subscription request.
リソースのURIは、「イベントリスト」拡張子[17]がパッケージで使用される場合に役立ちます。イベントパッケージのサブスクリプションはイベントリストに宛てられる可能性があるため、「URI」属性により、サブスクライバーはそのリスト内の個々のリソースに固有のフィルターを定義できます。そのリソースは別のリストかもしれません。「URI」属性は、もちろん、リスト自体のURIを運ぶことがあります。<filter>に「uri」属性が含まれていない場合、フィルターはサブスクリプションリクエストで識別されたリソースに適用されます。
The 'domain' attribute carries a domain. In this case, the filter applies to resources whose URI has a domain part matching that domain. This can be used when a subscription is for a resource that is an event list with many resources from differing domains.
「ドメイン」属性にはドメインが含まれます。この場合、フィルターは、URIがそのドメインに一致するドメインパーツを持つリソースに適用されます。これは、サブスクリプションが異なるドメインから多くのリソースを備えたイベントリストであるリソース用である場合に使用できます。
URI matching is done according to the matching rules defined for a particular scheme. When matching domains, the user part of the URI is ignored for matching purposes.
URIマッチングは、特定のスキームで定義されたマッチングルールに従って行われます。一致するドメインの場合、URIのユーザー部分は一致する目的で無視されます。
The <filter> MAY have a 'remove' attribute that together with the 'id' attribute indicates the existing filter to be removed. The value of the 'remove' attribute is of the type "Boolean". The default value is "false".
<filter>には、「ID」属性とともに既存のフィルターが削除されることを示す「削除」属性がある場合があります。「削除」属性の値は、「ブール」のタイプです。デフォルト値は「false」です。
The <filter> MAY have an 'enabled' attribute that indicates whether a filter is enabled or disabled. The value of the 'enabled' attribute is of the type "Boolean". The default value is "true".
<filter>には、フィルターが有効になっているか無効かを示す「有効」属性がある場合があります。「有効」属性の値は、「boolean」タイプのものです。デフォルト値は「true」です。
The <filter> element MAY contain a <what> element and MAY contain one or more <trigger> elements, but it MUST contain either the <what> element or the <trigger> element when the filter is being enabled for the first time. When a filter is disabled by setting the 'enabled' attribute to "false", the <what> and <trigger> elements MAY be omitted. Similarly, when a filter is re-enabled by setting the 'enabled' attribute to "true", the <what> and <trigger> elements MAY be omitted.
<filter>要素には<what>要素が含まれ、1つ以上の<trigger>要素が含まれる場合がありますが、フィルターが初めて有効になったときに<what>要素または<トリガー>要素のいずれかを含める必要があります。「有効」属性を「false」に設定してフィルターが無効になっている場合、<what>および<trigger>要素は省略される場合があります。同様に、「Enabled」属性を「True」に設定することによりフィルターが再度有効になっている場合、<what>および<trigger>要素は省略される場合があります。
Filter contents can be changed by changing the contents in the <what> and <trigger> elements and maintaining the value of the filter 'id' attribute.
フィルターの内容は、<what> and <trigger>要素の内容を変更し、フィルター「ID」属性の値を維持することで変更できます。
The <what> element is used to specify the content to be delivered to the user. It does not specify the exact content but the rules that are used to construct that information.
<what>要素は、ユーザーに配信されるコンテンツを指定するために使用されます。正確なコンテンツを指定するのではなく、その情報を作成するために使用されるルールを指定します。
The <what> element may contain one or more <include> elements and one or more <exclude> elements. When more than one <include> element has been defined, the results are additive. That is, each <include> element adds an element or attribute to the resulting XML document. When more than one <exclude> element has been defined, each <exclude> element value depletes the contents of the resulting XML document.
<what>要素には、1つ以上の<cluded>要素と1つ以上の<exclude>要素が含まれる場合があります。複数の<cluent>要素が定義されている場合、結果は加算的です。つまり、各<cluding>要素は、結果のXMLドキュメントに要素または属性を追加します。複数の<exclude>要素が定義されている場合、各<exclude>要素値は、結果のXMLドキュメントの内容を枯渇させます。
The <include> element is used to select the content to be delivered. Its value can identify an XML element, an attribute, or a namespace of an XML document to be filtered. This is indicated using the 'type' attribute.
<clusing>要素は、配信されるコンテンツを選択するために使用されます。その値は、フィルタリングされるXMLドキュメントのXML要素、属性、または名前空間を識別できます。これは、「タイプ」属性を使用して示されます。
Note that the resulting XML document MUST be valid. Therefore, in addition to including the elements identified with the <include> element value, all other mandatory XML elements and/or attributes must be incorporated in the resulting XML document in order to make it valid. This, in practice, means that a subscriber defining a filter only needs to <include> optional elements and/or attributes, but may <include> mandatory elements and/or attributes as well. There are also cases where a filter selects an attribute that belongs to an optional element. In this case, the optional element needs to appear in the resulting XML document.
結果のXMLドキュメントは有効でなければならないことに注意してください。したがって、<clusing>要素値で識別された要素を含めることに加えて、他のすべての必須XML要素および/または属性を、有効にするために、結果のXMLドキュメントに組み込む必要があります。これは、実際には、フィルターを定義するサブスクライバーがオプションの要素や属性を<cluding> <cludingするだけでなく、必須要素や属性も<clusedする必要があることを意味します。フィルターがオプションの要素に属する属性を選択する場合もあります。この場合、オプションの要素は、結果のXMLドキュメントに表示される必要があります。
The syntax defined in Section 5 (see the definition of "selection") MUST be used. The following example selects the <basic> element defined in the PIDF [13]. This results in the selection of the <basic> element as well as all the ancestors, i.e., <status> and <tuple>.
セクション5で定義されている構文（「選択」の定義を参照）を使用する必要があります。次の例では、PIDF [13]で定義されている<basic>要素を選択します。これにより、<basic>要素とすべての先祖、つまり<status> and <tuple>の選択が行われます。
<include type="xpath">/presence/tuple/status/basic</include>.
<include type = "xpath">/constiture/tuple/status/basic </include>。
The <exclude> element is used to define exceptions to the set of XML elements and/or attributes selected by the <include> elements. Thus, XML elements (including their lower-level "child" elements) and/or attributes defined by the <exclude> element are not delivered. This is most useful when an <include> element identifies a namespace.
<exclude>要素は、<clusing>要素によって選択されたXML要素および/または属性のセットの例外を定義するために使用されます。したがって、XML要素（低レベルの「子」要素を含む）および<exclude>要素によって定義された属性は提供されません。これは、<clusing>要素が名前空間を識別する場合に最も便利です。
The <exclude> element has the optional 'type' attribute (see the definition of the 'type' in Section 3.5.3).
<exclude>要素には、オプションの「タイプ」属性があります（セクション3.5.3の「タイプ」の定義を参照）。
Note that the resulting XML document MUST be valid. Therefore, if the step in applying the <exclude> element value to an XML document results in an invalid document according to the schema, that step MUST be reversed, resulting in the elements and/or attributes being re-introduced into the resulting XML document with their previous values in order to make it valid. This, in practice, means that a subscriber defining a filter only needs to <exclude> optional elements and/or attributes, but SHOULD NOT <exclude> mandatory elements and/or attributes.
結果のXMLドキュメントは有効でなければならないことに注意してください。したがって、XMLドキュメントに<exclude>要素値を適用するステップがスキーマに従って無効なドキュメントになった場合、そのステップを逆にする必要があり、結果のXMLドキュメントに再導入されます。それを有効にするための以前の値で。これは、実際には、フィルターを定義するサブスクライバーは、オプションの要素や属性を<clude>除外するだけではないことを意味しますが、必須要素や属性を<除外してはなりません。
The syntax MUST follow Section 5.
構文はセクション5に従う必要があります。
The 'type' attribute is used to describe the value of the <include> and <exclude> elements. The following values are pre-defined: "xpath" and "namespace". The 'type' attribute is optional, and, if omitted, the default value is "xpath".
「タイプ」属性は、<cluding>および<exclude>要素の値を記述するために使用されます。次の値は、「XPath」と「名前空間」の事前に定義されています。「タイプ」属性はオプションであり、省略された場合、デフォルト値は「XPath」です。
The "xpath" value is used when the <include> or <exclude> element contains a value following the syntax in Section 5 that selects an element or an attribute.
「XPath」値は、要素または属性を選択するセクション5の構文に従って値を<cluding>または<clude>要素に含む場合に使用されます。
The "namespace" value is used when the <include> or <exclude> element contains a value of a namespace. The value is the URI of the namespace. The resulting XML document is comprised of the elements defined within the namespace.
「名前空間」値は、<cluding>または<exclude>要素に名前空間の値が含まれている場合に使用されます。値は名前空間のURIです。結果のXMLドキュメントは、名前空間内で定義された要素で構成されています。
The <trigger> element is used to identify the package-specific changes that a resource has to encounter before the content is delivered to the subscriber. It can appear more than once in a <filter> element. Multiple appearances of this element denote the "OR" operation. This means that updates to a resource that satisfy any of the <trigger> elements criteria constitute the content to be delivered.
<trigger>要素は、コンテンツがサブスクライバーに配信される前にリソースが遭遇しなければならないパッケージ固有の変更を識別するために使用されます。<filter>要素に複数回表示できます。この要素の複数の外観は、「または」操作を示します。これは、<trigger>要素>要素基準のいずれかを満たすリソースを更新し、配信されるコンテンツを構成することを意味します。
The <trigger> element MAY contain the <changed>, <added>, or <removed> elements, but it MUST contain at least one of the three elements. Any combination of the 3 elements is possible. Multiple appearances of those elements within a <trigger> element denotes the "AND" operation. This means that updates to a resource that satisfy ALL of the <changed>, <added>, and <removed> elements' criteria within the <trigger> element constitute the content to be delivered.
<trigger>要素には<thanged>、<added>、または<削除>要素が含まれている場合がありますが、3つの要素のうち少なくとも1つを含める必要があります。3つの要素の任意の組み合わせが可能です。<trigger>要素内のこれらの要素の複数の外観は、「および」操作を示します。これは、<trigger>要素内の<trigger>要素内のすべての<Changed>、<added>、および<removed>要素を満たすリソースを更新することが、配信されるコンテンツを構成することを意味します。
The <changed> element is used to identify the XML element or attribute, from the package-specific XML document, whose value MUST change from that of the "previous XML document", in order to activate the trigger and cause the content to be delivered. Previous XML document" in this context refers to the raw version of the most recent XML document that was sent to the subscriber, before the filters were applied to it. The XML element or attribute MUST be expressed using the syntax defined in Section 5 for the "reference" ABNF.
<Changed>要素は、トリガーをアクティブにしてコンテンツを配信するために、パッケージ固有のXMLドキュメントからXML要素または属性を識別するために使用されます。。以前のXMLドキュメント「この文脈では、フィルターが適用される前にサブスクライバーに送信された最新のXMLドキュメントの生バージョンを指します。XML要素または属性は、セクション5で定義された構文を使用して表現する必要があります。「参照」abnf。
The <changed> element MAY contain the 'from' attribute, the 'to' attribute, the 'by' attribute, or any combination of the three. The absence of all of those attributes means a change of any sort to the value of the element or attribute activates the trigger. An update to the element or attribute value with an identical value is not a change.
<Chanded>要素には、「From」属性、「 'to」属性、「by」属性、または3つの任意の組み合わせが含まれます。これらすべての属性がないことは、あらゆる種類の要素または属性の値に変更がトリガーをアクティブにすることを意味します。同一の値を持つ要素または属性値の更新は変更ではありません。
Comparison of a change is done according to the element or attribute's lexical rules.
変更の比較は、要素または属性の語彙規則に従って行われます。
A trigger is active when the XML element or attribute identified with the <changed> element has changed from the value indicated by this attribute to a different value.
<chanded>要素で識別されたXML要素または属性が、この属性によって示された値から異なる値に変更された場合、トリガーがアクティブになります。
A trigger is active when the XML element or attribute identified with the <changed> element has changed to the value indicated by this attribute from a different value.
<chanded>要素で識別されたXML要素または属性が、この属性によって示されている値に異なる値から変更された場合、トリガーがアクティブになります。
A trigger is active when the XML element or attribute identified with the <changed> element has changed by at least the amount indicated by this attribute from a different value. That is, the 'by' attribute applies only to numerical values and indicates a delta with respect to the current value that an attribute or element (identified in the <changed> element) needs to change before it is selected. For example, if the 'by' attribute is set to 2 and the current value of the element/attribute is 6, the element/attribute is selected when it reaches (or exceeds) the value 8 or when it decreases to 4 or a lower value.
<Changed>要素で識別されたXML要素または属性が、少なくともこの属性で示される量によって異なる値から変更された場合、トリガーがアクティブになります。つまり、「by」属性は数値値にのみ適用され、選択する前に属性または要素（<Changed>要素で識別される）が変更する必要がある現在の値に関するデルタを示します。たとえば、「by」属性が2に設定され、要素/属性の現在の値が6に設定されている場合、要素/属性は値8に達する（または超えている）、または4または低い場合に減少したときに選択されます。価値。
Any combination of the 'from', 'to', and 'by' attributes in the <changed> element is possible. For example, if the 'from' attribute is combined with the 'to' attribute, it is interpreted to mean that the trigger is active when the XML element or attribute identified with the <changed> element has changed from the 'from' value to the 'to' value. Note that if the 'by' attribute is used in combination with the other attributes, the other attribute types MUST match the 'by' type of decimal.
「From」、 'to'、および「by」属性の任意の組み合わせが可能です。たとえば、「from」属性が「to」属性と組み合わされている場合、<変更>要素で識別されたxml要素または属性が「from」値から変更されたときにトリガーがアクティブであることを意味すると解釈されます。「to」値。「by」属性が他の属性と組み合わせて使用される場合、他の属性タイプは「by」タイプの小数と一致する必要があることに注意してください。
The <added> element triggers content delivery when the XML element it identifies has been added to the document being filtered (that is, this instance of that element appears in the current document, but not in the previous document). It can be used, for example, to learn of new services and/or capabilities subscribed to by the user, or services and/or capabilities that the user has now allowed the subscriber to see. The XML element or attribute MUST be expressed using the syntax defined in Section 5 for the "reference" ABNF.
<addited>要素は、識別するXML要素がフィルタリングされているドキュメントに追加されたときにコンテンツの配信をトリガーします（つまり、その要素のこのインスタンスは現在のドキュメントに表示されますが、前のドキュメントには表示されません）。たとえば、ユーザーがサブスクライバーに許可しているサービスや機能や機能がサブスクリブする新しいサービスや機能や機能を学ぶために使用できます。XML要素または属性は、「参照」ABNFのセクション5で定義された構文を使用して表現する必要があります。
Note that if a filter includes both the content filter (<what>) part and the <added> element, then the definitions of the <what> part SHOULD also cover the added elements. Otherwise, the content is delivered without the items defined in the <added> element.
フィルターにコンテンツフィルター（<what>）パーツと<追加>要素の両方が含まれている場合、<what>パーツの定義も追加された要素をカバーする必要があることに注意してください。それ以外の場合、コンテンツは、<addded>要素で定義されたアイテムなしで配信されます。
The <removed> element triggers content delivery when the XML element it identifies has been removed from the document being filtered (that is, this instance of that element appeared in the previous document, but not in this document). The XML element or attribute MUST be expressed using the syntax defined in Section 5 for the "reference" ABNF.
<削除>要素は、識別されるXML要素がフィルタリングされているドキュメントから削除されたときにコンテンツの配信をトリガーします（つまり、その要素のこのインスタンスは、このドキュメントではなく、前のドキュメントに表示されました）。XML要素または属性は、「参照」ABNFのセクション5で定義された構文を使用して表現する必要があります。
The simple-filter document is meant to be extended. An extension takes place by defining a new set of elements in a new namespace, governed by a new schema. Every extension MUST have an appropriate XML namespace assigned to it. The XML namespace of the extension MUST be different from the namespaces defined in this specification. The extension MUST NOT change the syntax or semantics of the schemas defined in this document. All XML tags and attributes that are part of the extension MUST be appropriately qualified so as to place them within that namespace and MUST be designed such that receivers can safely ignore such extensions.
シンプルフィルタードキュメントは拡張することを目的としています。拡張機能は、新しい名前の新しい名前空間で新しい要素のセットを定義することによって行われます。すべての拡張子には、適切なXMLネームスペースが割り当てられている必要があります。拡張機能のXML名空間は、この仕様で定義されている名前空間とは異なる必要があります。拡張機能は、このドキュメントで定義されているスキーマの構文またはセマンティクスを変更してはなりません。拡張機能の一部であるすべてのXMLタグと属性は、それらをその名前空間内に配置するために適切に適格でなければならず、受信機がそのような拡張機能を安全に無視できるように設計する必要があります。
This specification defines explicit places where new elements or attributes from an extension can be placed. These are explicitly indicated in the schemas by the <any> and <anyAttribute> elements. Extensions to this specification MUST specify where their elements can be placed within the document.
この仕様は、拡張機能からの新しい要素または属性を配置できる明示的な場所を定義します。これらは、<any>および<AnyAttribute>要素によってスキーマで明示的に示されています。この仕様の拡張は、要素をドキュメント内に配置できる場所を指定する必要があります。
As a result, a document that contains extensions will require multiple schemas in order to determine its validity - a schema defined in this document, along with those defined by extensions present in the document. Because extensions occur by adding new elements and attributes governed by new schemas, the schemas defined in this document are fixed and would only be changed by a revision to this specification. Such a revision, should it take place, would endeavor to allow documents compliant to the previous schema to remain compliant to the new one. As a result, the schemas defined here don't provide explicit schema versions, as this is not expected to be needed.
その結果、拡張機能を含むドキュメントには、その有効性を決定するために複数のスキーマが必要です。このドキュメントで定義されているスキーマと、ドキュメントに存在する拡張機能によって定義されているスキーマ。拡張機能は、新しいスキーマによって支配された新しい要素と属性を追加することによって発生するため、このドキュメントで定義されているスキーマは修正され、この仕様の改訂によってのみ変更されます。このような改訂が行われた場合、以前のスキーマに準拠した文書を新しいものに準拠させたままにするように努力します。その結果、ここで定義されているスキーマは、明示的なスキーマバージョンを提供しません。これは必要とされていないためです。
The ABNF [10] is used to describe the syntax for the expressions. The syntax is defined to be XPATH [9] compatible but has only a restricted set of capabilities of the XPATH. More information about the meaning of the items of the syntax can be found in [9]. The "abbreviated syntax" of the "node test" is used in the references ("reference"). The expression in the syntax relates to the predicate, comparison, and logical expressions of the XPATH. If an XPATH expression evaluates to more than one element at a certain step, the filter applies to all the elements that are evaluated. That is, if a filter including an element evaluates to 2 elements, both elements are included as a result.
ABNF [10]は、式の構文を記述するために使用されます。構文はXpath [9]互換性があると定義されていますが、Xpathの機能が制限されているだけです。構文の項目の意味に関する詳細については、[9]をご覧ください。「ノードテスト」の「略式構文」は、参照（「参照」）で使用されます。構文の式は、XPathの述語、比較、および論理式に関連しています。XPath式が特定のステップで複数の要素に評価される場合、フィルターは評価されるすべての要素に適用されます。つまり、要素を含むフィルターが2つの要素を評価する場合、結果として両方の要素が含まれています。
selection = reference [expression]
expression = "[" (elem-expr / attr-expr)
1*[oper (elem-expr / attr-expr)] "]"
elem-expr = (elem-path / "." / "..") compar value
elem-path = (element / "*") 1*["/" / "*" / element] ["*" / element]
attr-expr = [elem-path "/"] attribute compar value
reference = elem-reference / attr-reference
elem-reference = "/" 1*("/" / "/*" / ("/" element))
attr-reference = reference attribute
oper = "and" / "or"
compar = "=" / "<" / ">"
element = [ns] string
attribute = "@" [ns] string
ns = string ":"
string = <any sequence of data supported by XML in names of XML
element, and/or attribute or prefixes of namespaces>
value = <any sequence of data supported by XML as a value of the
XML element and/or attribute>
When identifying XML elements or attributes, the value may consist of two parts: the XML element/attribute selector and the condition (comparison and logical expressions). The XML element selector appears first followed by the condition part in square brackets. In the XML element selector part, the XML elements may be referenced by giving the full hierarchical path as: "/presence/tuple/status/basic", by denoting the selection to cover any hierarchical level by its name as: "//tuple/status/basic", or using the wildcard "*", denoting any value in a certain level as "/*/watcher".
XML要素または属性を識別する場合、値はXML要素/属性セレクターと条件（比較と論理式）の2つの部分で構成されている場合があります。XML要素セレクターが最初に表示され、次に四角い括弧内の条件パーツが続きます。XML要素セレクターパーツでは、XML要素は、完全な階層パスを「/存在/タプル/ステータス/基本」として提供することによって参照できます。/status/basic "、またはwildcard"*"を使用して、特定のレベルの値を「/*/watcher」として示します。
Example references are listed as follows:
参照の例は次のようにリストされています。
o Selecting an element by using an XML element as a condition: * //*[status/basic="open"] * /presence/tuple[*/basic="open"]
o XML要素を条件として使用して要素を選択します： * // * [status/basic = "open"] */conession/tuple [ */basic = "open"]
o Selecting an element by using XML attributes as a condition: * //watcher[@duration-subscribed<500] * /*/watcher[@event="rejected"]
o XML属性を条件として使用して要素の選択： * // Watcher [@duration-subscribed <500] * / * /watcher [@event = "redjected"]]
o Selecting an element by using two XML elements as a condition: * //tuple[status/basic="open" and type="device"]
o 2つのXML要素を条件として使用して要素を選択します： * // tuple [status/basic = "open"およびtype = "device"]]
o Selecting an attribute: * //watcher/@duration-subscribed
o 属性の選択： * // watcher/@duration-subscribed
In some cases, due to the design of the XML schema, the XPATH-like expression results in identification of more than one element with the same name (the XPATH expression may not have uniquely identified an element at every step). In those cases, all elements identified are selected.
場合によっては、XMLスキーマの設計により、Xpathのような式は同じ名前の複数の要素を識別することになります（XPath式は、すべてのステップで一意に識別されていない場合があります）。そのような場合、特定されたすべての要素が選択されます。
When evaluating XPATH location steps, namespace expansion follows XPATH 1.0 [9] semantics, i.e., if the QName does not have a prefix, then the namespace URI in the expanded name is null. With non-default namespaces, expansion is done according to the given <ns-bindings> definitions. When a default namespace is used in the document, the <ns-binding> element SHOULD be used to define an equal URI with some prefix in order to have a valid XPATH evaluation in location steps.
XPathの位置ステップを評価する場合、名前空間拡張はXpath 1.0 [9]セマンティクスに続きます。つまり、QNameにプレフィックスがない場合、拡張名の名前空間URIはnullです。非デフォルトの名前空間では、指定された<ns-bindings>定義に従って拡張が行われます。ドキュメントでデフォルトの名前空間が使用される場合、<nsバインディング>要素を使用して、位置ステップで有効なXPath評価を行うために、いくつかのプレフィックスを使用して等しいURIを定義する必要があります。
The XML Schema for the XML document examples is specified in Section 7.
XMLドキュメントの例のXMLスキーマは、セクション7で指定されています。
A user wishes to get to know his friend's availability and willingness for messaging (SMS, IM, and MMS) in order to know whether the friend is able to receive a message, the address to contact, and the type of the message to be used.
ユーザーは、友人がメッセージ、連絡先のアドレス、および使用するメッセージのタイプを受け取ることができるかどうかを知るために、友人のメッセージング（SMS、IM、およびMMS）の意欲を知りたいと考えています。。
This example shows how to define a content filter. The <basic> element as well as all parent elements are selected based on a condition defined by a logical expression. The condition is <class> elements that have a value "MMS", "SMS", or "IM".
この例は、コンテンツフィルターを定義する方法を示しています。<basic>要素とすべての親要素は、論理式で定義された条件に基づいて選択されます。条件は、値「MMS」、「SMS」、または「IM」を持つ<class>要素です。
The <class> element is defined in [14] as an extension to PIDF [13].
<class>要素は、[14]でpidf [13]の拡張として定義されています。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include type="xpath">
/pidf:presence/pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:status/pidf:basic
</include>
</what>
</filter>
</filter-set>
A user requires to be informed when his colleague becomes available by some communication means. The user gets the full presence state of the colleague when a certain PIDF [13] tuple <basic> status changes from "closed" to "open".
ユーザーは、同僚がコミュニケーション手段によって利用可能になったときに通知される必要があります。特定のPIDF [13] Tuple <basic>ステータスが「閉じている」から「オープン」に変化すると、ユーザーは同僚の完全な存在状態を取得します。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed from="CLOSED" to="OPEN">
/pidf:presence/pidf:tuple/pidf:status/pidf:basic
</changed>
</trigger>
</filter>
</filter-set>
A user wishes to get information about pending and waiting subscriptions in order to be able to authorise watchers to see his presence information.
ユーザーは、ウォッチャーに自分の存在情報を確認することを許可できるように、保留中の待機サブスクリプションに関する情報を取得したいと考えています。
The filter selects watcher information notifications [16] to be sent when a subscription status has changed to "pending" or "waiting". In the notification, only the watchers that have a status of "pending" or "waiting" are included.
フィルターは、サブスクリプションステータスが「保留中」または「待機」に変更されたときに、ウォッチャー情報通知[16]を選択します。通知では、「保留中」または「待機」のステータスを持つウォッチャーのみが含まれています。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="wi"
urn="urn:ietf:params:xml:ns:watcherinfo"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<what>
<include>
/wi:watcherinfo/wi:watcher-list/wi:watcher[@status="pending"
or @status="waiting"]
</include>
</what>
<trigger>
<changed to="pending">
/wi:watcherinfo/wi:watcher-list/wi:watcher/@status
</changed>
</trigger>
<trigger>
<changed to="waiting">
/wi:watcherinfo/wi:watcher-list/wi:watcher/@status
</changed>
</trigger>
</filter>
</filter-set>
A user turns her terminal on, and the terminal automatically fetches general presence status and information about communication means from a certain pre-defined set of her buddies.
ユーザーがターミナルをオンにし、端末は、特定の事前定義された仲間のセットから一般的な存在状態とコミュニケーション手段に関する情報を自動的に取得します。
The filter is defined to select XML elements belonging to the PIDF namespace.
フィルターは、PIDF名空間に属するXML要素を選択するように定義されています。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<filter id="123" uri="sip:buddylist@example.com">
<what>
<include type="namespace">
urn:ietf:params:xml:ns:pidf
</include>
</what>
</filter>
</filter-set>
A user wants to know if a group of his friends is available for gaming. He orders notifications about the current status and future changes of the game-specific presence information.
ユーザーは、友人のグループがゲームに利用できるかどうかを知りたいと思っています。彼は、ゲーム固有のプレゼンス情報の現在のステータスと将来の変更に関する通知を注文します。
This filter is defined to select the game-specific tuple to be delivered.
このフィルターは、配信されるゲーム固有のタプルを選択するために定義されています。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" >
<ns-bindings>
<ns-binding prefix="game-ext"
urn="urn:ietf:params:xml:ns:game-ext"/>
</ns-bindings>
<filter id="123">
<what>
<include>
/pidf:presence/pidf:tuple/
pidf:status[game-ext:label="game-X"]
</include>
</what>
</filter>
</filter-set>
The user is interested in getting up-to-date information about the communication means and contact addresses of his friends. The user also wants to get more information (e.g., location) about one of the friends in the list, named Bob. The PIDF element <note> is filtered out, i.e., excluded. The list was predefined as buddies@example.com.
ユーザーは、友人のコミュニケーション手段と連絡先住所に関する最新情報を入手することに興味があります。また、ユーザーは、リスト内の友人の1人、ボブという名前の1人について、より多くの情報（場所）を取得したいと考えています。PIDF要素<note>は除外されます。つまり、除外されます。リストはbuddies@example.comとして事前に定義されていました。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
<ns-binding prefix="rpid"
urn="urn:ietf:params:xml:ns:pidf:rpid"/>
</ns-bindings>
<filter id="8439" uri="sip:buddies@example.com">
<what>
<include>
/pidf:presence/pidf:tuple[rpid:class="service"]/pidf:status/
pidf:basic
</include>
</what>
</filter>
<filter id="999" uri="sip:bob@example.com">
<what>
<include type="namespace">
urn:ietf:params:xml:ns:pidf
</include>
<exclude>
/pidf:presence/pidf:tuple/pidf:note
</exclude>
</what>
</filter>
</filter-set>
XML Schema Implementation (Normative)
XMLスキーマ実装（規範）
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition for Filter Criteria.
</xs:documentation>
</xs:annotation>
<xs:element name="filter-set" type="FilterSetType"/>
<xs:complexType name="FilterSetType">
<xs:sequence>
<xs:element name="ns-bindings" type="NSBindings"
minOccurs="0" maxOccurs="1"/>
<xs:element name="filter" type="FilterType"
minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="package" type="xs:string" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="NSBindings">
<xs:sequence>
<xs:element name="ns-binding" type="NSBinding"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NSBinding">
<xs:attribute name="prefix" type="xs:string" use="required"/>
<xs:attribute name="urn" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="FilterType">
<xs:sequence>
<xs:element name="what" type="WhatType"
minOccurs="0" maxOccurs="1"/>
<xs:element name="trigger" type="TriggerType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="uri" type="xs:anyURI" use="optional"/>
<xs:attribute name="domain" type="xs:string" use="optional"/>
<xs:attribute name="remove" type="xs:boolean" use="optional"
default="false"/>
<xs:attribute name="enabled" type="xs:boolean" use="optional"
default="true"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="WhatType">
<xs:sequence>
<xs:element name="include" type="InclType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="exclude" type="ExclType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="InclType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="TypeType"
default="xpath" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ExclType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="TypeType"
default="xpath" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="TypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="xpath"/>
<xs:enumeration value="namespace"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="TriggerType">
<xs:sequence>
<xs:element name="changed" type="ChangedType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="added" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="removed" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ChangedType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="from" type="xs:anySimpleType"
use="optional"/>
<xs:attribute name="to" type="xs:anySimpleType"
use="optional"/>
<xs:attribute name="by" type="xs:decimal"
use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
The filters in the body in a SIP message have a significant effect on the ways in which the request is handled at a server. As a result, it is especially important that messages containing this extension be authenticated and authorised. Authentication can be achieved using the Digest Authentication mechanism described in [12]. The authorisation decision is based on the permissions that the resource (notifier) has given to the watcher. An example of such an auhorisation policy can be found in [18].
SIPメッセージのボディのフィルターは、リクエストがサーバーで処理される方法に大きな影響を及ぼします。その結果、この拡張機能を含むメッセージを認証および承認することが特に重要です。[12]で説明されているダイジェスト認証メカニズムを使用して、認証を実現できます。承認決定は、リソース（通知者）がウォッチャーに与えた権限に基づいています。このようなauhorisation Policyの例は、[18]に記載されています。
Requests can reveal sensitive information about a UA's capabilities. If this information is sensitive, it SHOULD be encrypted using SIP S/MIME capabilities [11].
リクエストは、UAの機能に関する機密情報を明らかにすることができます。この情報が敏感な場合は、SIP S/MIME機能[11]を使用して暗号化する必要があります。
All filtering-related security measures discussed in [2] MUST be followed along with package-specific security.
[2]で議論されているすべてのフィルタリング関連のセキュリティ対策には、パッケージ固有のセキュリティに従う必要があります。
This document registers a new MIME type, "application/ simple-filter+xml", and registers a new XML namespace.
このドキュメントは、新しいMIMEタイプ「Application/ Simple-Filter XML」を登録し、新しいXMLネームスペースを登録します。
This specification follows the guidelines of RFC3023 [7].
この仕様は、RFC3023のガイドラインに従います[7]。
MIME media type: application
MIMEメディアタイプ：アプリケーション
MIME subtype name: simple-filter+xml
MIMEサブタイプ名：シンプルフィルターXML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml, as specified in RFC 3023 [7].
オプションのパラメーター：RFC 3023 [7]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml, as specified in RFC 3023 [7].
Encodingの考慮事項：RFC 3023 [7]で指定されているように、アプリケーション/XMLの考慮事項をエンコードすることと同じ。
Security considerations: See section 10 of RFC 3023 [7] and section Section 8 of this document.
セキュリティ上の考慮事項：RFC 3023 [7]のセクション10およびこのドキュメントのセクション8を参照してください。
Interoperability considerations: none.
相互運用性の考慮事項：なし。
Published specification: This document.
公開された仕様：このドキュメント。
Applications that use this media type: This document type has been used to support the SIP-based Event notification framework and its packages.
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、SIPベースのイベント通知フレームワークとそのパッケージをサポートするために使用されています。
Additional information:
追加情報：
Magic number: None
マジックナンバー：なし
File extension: .cl or .xml
ファイル拡張子：.clまたは.xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Hisham Khartabil
(hisham.khartabil@telio.no)
Intended Usage: COMMON
意図された使用法：共通
Author/change controller: The IETF
著者/変更コントローラー：IETF
This section registers a new XML namespace, as per guidelines in the IETF XML Registry [4].
このセクションでは、IETF XMLレジストリ[4]のガイドラインに従って、新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:simple-filter.
URI：この名前空間のURIはurn：ietf：params：xml：ns：simple-filterです。
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no)
登録者の連絡先：IETF、シンプルワーキンググループ、Hisham Khartabil（hisham.khartabil@telio.no）
This section registers a new XML schema per the procedures in [4].
このセクションでは、[4]の手順ごとに新しいXMLスキーマを登録します。
URI: urn:ietf:params:xml:ns:simple-filter
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no).
登録者の連絡先：IETF、シンプルワーキンググループ、Hisham Khartabil（hisham.khartabil@telio.no）。
The XML for this schema can be found as the sole content of Section 7.
このスキーマのXMLは、セクション7の唯一の内容として見つけることができます。
The authors would like to thank Jonathan Rosenberg, Henning Schulzrinne, Tim Moran, Jari Urpalainen, Sreenivas Addagatla, Miguel-Angel Garcia Martin, Mary Barnes, Paul Kyzivat, Robert Sparks, and Elwyn Davies for their valuable input and comments.
著者は、Jonathan Rosenberg、Henning Schulzrinne、Tim Moran、Jari Urpalainen、Sreenivas Addagatla、Miguel-Angel Garcia Martin、Mary Barnes、Paul Kyzivat、Robert Sparks、Elwyn Daviesの貴重なインプットとコメントに感謝します。
[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] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach、A。B.、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[3] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 2006.
[3] Khartabil、H.、Leppanen、E.、Lonnfors、M。、およびJ. Costa-Requena、「イベント通知フィルタリングの機能的説明」、RFC 4660、2006年9月。
[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] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[6] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[7] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[8] Bray, T., "Exensible Markup Language (XML) 1.0 (Second Edition)", W3C CR CR-xml11-20011006, October 2000.
[8] Bray、T。、「Exensible Markup Language（XML）1.0（第2版）」、W3C CR CR-XML11-20011006、2000年10月。
[9] Clark, J., "XML Path Language (XPath) Version 1.0", W3C REC REC-xpath-19991116, November 1999.
[9] クラーク、J。、「XMLパス言語（XPATH）バージョン1.0」、W3C REC REC-XPATH-1991116、1999年11月。
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[10] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[11] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[12] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[12] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[13] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[13] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[14] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID -- Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[14] Schulzrinne、H.、Gurbani、V.、Kyzivat、P。、およびJ. Rosenberg、「rpid -Rich Expention拡張存在情報データ形式（PIDF）」、RFC 4480、2006年7月。
[15] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[15] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[16] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[16] Rosenberg、J。、「ウォッチャー情報用の拡張可能なマークアップ言語（XML）ベースの形式」、RFC 3858、2004年8月。
[17] Roach, A. B., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4663, September 2006.
[17] Roach、A。B.、Campbell、B。、およびJ. Rosenberg、「リソースリストのセッション開始プロトコル（SIP）イベント通知拡張機能」、RFC 4663、2006年9月。
[18] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.
[18] Rosenberg、J。、「プレゼンス認証ルール」、2006年6月、進行中の作業。
Authors' Addresses
著者のアドレス
Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway
Hisham Khartabil Telio P.O.ボックス1203 Vika Oslo Norway
Phone: +47 2167 3544
EMail: hisham.khartabil@telio.no
Eva Leppanen Nokia P.O BOX 785 Tampere Finland
Eva Leppanen Nokia P.O Box 785 Tampere Finland
Phone: +358 7180 77066
EMail: eva-maria.leppanen@nokia.com
Mikko Lonnfors Nokia P.O BOX 321 Helsinki Finland
Mikko Lonfors Nokia P.O Box 321 Helsinki Finland
Phone: + 358 71800 8000
EMail: mikko.lonnfors@nokia.com
Jose Costa-Requena Nokia P.O. Box 321 FIN-00045 NOKIA GROUP FINLAND
Jose Costa-Requena Nokia P.O.Box 321 Fin-00045 Nokia Group Finland
Phone: +358 71800 8000
EMail: jose.costa-requena@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。