RFC4661 日本語訳
4661 An Extensible Markup Language (XML)-Based Format for EventNotification Filtering. H. Khartabil, E. Leppanen, M. Lonnfors, J.Costa-Requena. September 2006. (Format: TXT=48890 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Khartabil
Request for Comments: 4661 Telio
Category: Standards Track E. Leppanen
M. Lonnfors
J. Costa-Requena
Nokia
September 2006
Khartabilがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4661年のTelioカテゴリ: 標準化過程E.Leppanen M.Lonnfors J.コスタ-レケナノキア2006年9月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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イベント通知フレームワークはリソースの状態への変化の購読と通知のためにSession Initiationプロトコル(SIP)の用法を説明します。 ドキュメントはイベント通知情報のフィルタリングを達成できるメカニズムについて説明しません。 フィルタリングは、提供される都合のよい通知情報を定義して、その情報を提供する引き金を指定するためのメカニズムです。 これを可能にするために、形式が加入者がそれとそれらの通知が含むことになっていることに通知を送るリソースの州の変化について説明するのを可能にするのに必要です。 このドキュメントはXMLドキュメントの形に形式を提示します。
Khartabil, et al. Standards Track [Page 1] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[1ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 構造、簡単なフィルタ.43.1をXMLコード化します。 簡単なフィルタドキュメント. . . . . . . . . . 4 3.2のためのMIMEの種類。 <フィルタで設定された>根の要素. . . . . . . . . . . . . 4 3.3。 <ナノ秒結合>、要素. . . . . . . . . . . . . . . 4 3.4 <フィルタ>要素. . . . . . . . . . . . . . . . . . 5 3.5。 <はどんな>要素. . . . . . . . . . . . . . . . . . . 6 3.5.1であるか。 <は>要素. . . . . . . . . . . . . 6 3.5.2を含んでいます。 <は>要素. . . . . . . . . . . . . 7 3.5.3を除きます。 'タイプ'は.73.6を結果と考えます。 <引き金の>要素. . . . . . . . . . . . . . . . . 8 3.6.1。 <は>要素. . . . . . . . . . . . . 8 3.6.2を変えました。 <は>要素. . . . . . . . . . . . . . 9 3.6.3を加えました。 <は>要素. . . . . . . . . . . . . 10 4を取り除きました。 XML図式伸展性. . . . . . . . . . . . . . . . . . . 10 5。 XMLの品目に参照をつけて、論理式. . . . . . . . . . . . . . . . . . . . . . . . . 10 6を作るための構文。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1。 どんな>要素. . . . . . . . . . 12 6.2の<を使用して、評価基準をフィルターにかけてください。 <を使用するフィルタ評価基準が>要素. . . . . . . . 13 6.3の引き金となります。 どんな>と<引き金の>要素. . 13 6.4の<を使用して、評価基準をフィルターにかけてください。 名前空間. . . . . . . . . . . . 14 6.5を使用する満足しているフィルタ。 唯一の内容フィルタ使用<が>要素. . . . . . 14 6.6を含んでいます。 2内容はフィルタとして評価基準. . . . . . . . . 15 7をフィルターにかけます。 フィルタ評価基準. . . . . . . . . . . . . . . . 16 8のためのXML図式。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 18 9。 IANA Considerations. . . . . . . . . . . . . . . . . . . . . 19 9.1簡単なアプリケーション/フィルタ+xml MIME TYPE. . . . . . . . 19 9.2。 つぼ:ietf:params:xml:ナノ秒間のURN Sub-名前空間Registration: 簡単なフィルタ.209.3。 図式登録. . . . . . . . . . . . . . . . . . 20 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 20 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1。 引用規格. . . . . . . . . . . . . . . . . . 20 11.2。 有益な参照. . . . . . . . . . . . . . . . . 21
Khartabil, et al. Standards Track [Page 2] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[2ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
1. Introduction
1. 序論
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]はリソースの状態への変化の購読と通知のためにSession Initiationプロトコル(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.
特に貴重であって、フィルタリングメカニズムが主としてモバイルワイヤレス・アクセスデバイスのユーザに適切であると予想されます。 デバイスの特性は高い潜在、低い帯域幅、低いデータ処理能力、小さいディスプレイ、および限られた電池残量を通常含んでいます。 そのようなデバイスはイベント通知の源で生成された情報量をフィルターにかける能力の利益を得ることができます。 しかしながら、implementersは、イベント通知の源でのコンピュータの負担を意識している必要があります。 セクション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ドキュメントはユーザの好みを含んでいます。 「いつ」部分の範囲は引き金となっているか。
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]特有の州の情報の変化に基づいている通知のための規則の引き金となりながら加入者が指定するのを可能にすると引き金となることは定義されます、例えば、存在情報ドキュメント[15]のために、<状態>要素の価値における変化。
The functionality of the filtering regarding the SIP event notifications is specified in [3].
SIPイベント通知に関するフィルタリングの機能性は[3]で指定されます。
2. Conventions
2. コンベンション
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.
'このドキュメント、キーワード'MUST'では、RFCで2119[1]について説明して、対応する実装のために要件レベルを示すとき、NOTと、'''REQUIRED'、'SHALL'、'SHALL NOT'、'SHOULD'、'SHOULD NOT'、'RECOMMENDED'、'5月'、およびOPTIONAL'を解釈することになっていなければなりませんか?
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ドキュメントを示します。
Khartabil, et al. Standards Track [Page 3] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[3ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
"Content" refers to the XML document that appears in a notification reflecting the state of a resource.
「内容」はリソースの状態を反映しながら通知に現れるXMLドキュメントを示します。
3. Structure of XML-Encoded Simple-Filter
3. 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.
簡単なフィルタは整形式でなければならない、拡大schemasを含むvalidaterに利用可能で、XMLドキュメントに適切なschemasによると、有効であるに違いないXMLドキュメント[8]です。 簡単なフィルタドキュメントをXML1.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.
この仕様で定義された要素のための名前空間識別子はURN[5]です。(そのURNは[6]によって定義されて、[4]によって広げられた名前空間識別子'ietf'を使用します)。 このつぼは以下の通りです。 つぼ:ietf:params:xml:ナノ秒: 簡単なフィルタです。
This namespace declaration indicates the namespace on which the filter criteria are based.
この名前空間宣言はフィルタ評価基準が基づいている名前空間を示します。
3.1. MIME Type for Simple-Filter Document
3.1. 簡単なフィルタドキュメントのためのMIMEの種類
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」(例えば、コンテントタイプヘッダーフィールド)であると認識しなければなりません。
3.2. The <filter-set> Root Element
3.2. <フィルタで設定された>根の要素
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.
<フィルタで設定された>要素は前記のように名前空間定義を含んでいます。 任意の'パッケージ'属性では、フィルタ評価基準がどれであるかに適用されたパッケージを定義するのは可能です。 これはフィルタ評価基準を含むXMLドキュメントが通常、それを運ぶプロトコルとそれを利用するイベント、または、切り離される場合で特に役に立つかもしれません。
The <filter-set> element may contain one <ns-bindings> element.
<の>要素が1<ナノ秒含むかもしれないセットをフィルターにかけるのである結合である>要素。
The <filter-set> element contains one or more <filter> elements.
<フィルタで設定された>要素は1つ以上の<フィルタ>要素を含んでいます。
3.3. The <ns-bindings> Element
3.3. <ナノ秒結合>、要素
The <ns-bindings> element is used to bind namespaces to local prefixes used in expressions that select elements or attributes using
>要素が使用されている<ナノ秒結合は使用することで要素か属性を選択する式に使用されるローカルの接頭語に名前空間を縛ります。
Khartabil, et al. Standards Track [Page 4] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[4ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
the syntax in Section 5. Those prefixes apply to the <include>, <exclude>, <changed>, <added>, and <removed> elements.
セクション5の構文。 それらの接頭語はインクルード>を<に当てはまります、そして、<は>を除きます、そして、<は>を変えました、そして、<は>を加えました、そして、<は>要素を移しました。
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.
<ナノ秒、-結合>要素は1<ナノ秒以上を拘束力がある>要素を含んでいます。 それぞれの<ナノ秒を拘束力がある>要素には、'接頭語'属性があります。 '接頭語'属性の値は式によって示された要素に資格を与えるのに使用される接頭語です。 また、<ナノ秒を拘束力がある>要素には、接頭語が表す名前空間を特定する'つぼ'属性があります。
3.4. The <filter> Element
3.4. <フィルタ>要素
The <filter> element is used to specify the content of an individual 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>.
<フィルタ>要素には、'イド'属性があります。 'イド'属性の値は<フィルタで設定された>要素の中でユニークであるに違いありません。 <フィルタ>には、'uri'属性があるかもしれません。 'uri'属性の値はフィルタが適用されるリソースのURIです。 <フィルタ>には、'ドメイン'属性があるかもしれません。 'ドメイン'属性の値はフィルタが適用されるリソースのドメインです。 'uri'属性と'ドメイン'属性は<フィルタ>に一緒に現れてはいけません。
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を運ぶかもしれません。 <フィルタ>が'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".
<フィルタ>には、'取り外してください'という取り除くために'イド'属性と共に既存のフィルタを示す属性があるかもしれません。 '取り外してください'という属性の値はタイプ「論理演算子」のものです。 デフォルト値は「誤っています」。
Khartabil, et al. Standards Track [Page 5] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[5ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
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".
<フィルタ>には、フィルタが可能にされるか、または損傷されるかを示す'可能にされた'属性があるかもしれません。 '可能にされた'属性の値はタイプ「論理演算子」のものです。 デフォルト値は「本当です」。
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.
<フィルタ>要素は、どんな>要素の<を含んでいるか、そして、1つ以上の<引き金の>要素を含むかもしれませんが、フィルタが初めて可能にされているとき、それはどんな>要素の<か<引き金の>要素のどちらかを含まなければなりません。 フィルタが'可能にされた'属性を「誤っていること」に設定することによって損傷されるとき、どんな>と<引き金の>要素の<は省略されるかもしれないか。 フィルタが'可能にされた'属性を「本当に」設定することによって再可能にされるとき、同様に、どんな>と<引き金の>要素の<は省略されるかもしれないか。
Filter contents can be changed by changing the contents in the <what> and <trigger> elements and maintaining the value of the filter 'id' attribute.
どんな>と<引き金の>要素の<でコンテンツを変えるか、そして、フィルタ'イド'属性の値を維持することによって、フィルタコンテンツを変えることができます。
3.5. The <what> Element
3.5. どんな>要素の<。
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.
どんな>要素の<は、ユーザに提供される内容を指定するのに使用されるか。 それは正確な内容を指定するのではなく、その情報を構成するのに使用される規則を指定します。
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.
より多くの<が>要素を含んでいます、そして、どんな>要素の<が1つを含むかもしれないか、そして、または1<が>要素を除きます。 1<が>を含んでいるとき、要素は定義されて、結果は付加的です。 すなわち各<は要素が、結果として起こるXMLへの要素か属性が記録すると言い足す>を含んでいます。 1<が>を除くとき、要素は定義されて、<が除くそれぞれが結果として起こるXMLドキュメントのコンテンツを使い果たします>要素が、評価する。
3.5.1. The <include> Element
3.5.1. <は>要素を含んでいます。
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.
<は、内容が提供されるのを選択するために使用される>要素を含んでいます。 値は、フィルターにかけられるために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ドキュメントが有効であるに違いないことに注意してください。 したがって、<と同一視された要素を含んでいることに加えて、>要素価値(他の義務的なXML要素、そして/または、属性が組み込むに違いない結果として起こるXMLがそれを有効にするように記録するすべて)を含めてください。 これは、実際にはフィルタを定義すると<に必要とするだけである加入者が>随意的な要素、そして/または、属性を入れることを意味しますが、<が>の義務的な要素、そして/または、また、属性を含んでいますように。 ケースもフィルタが随意的な要素に属す属性を選択するところにあります。 この場合、随意的な要素は、結果として起こるXMLドキュメントに現れる必要があります。
Khartabil, et al. Standards Track [Page 6] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[6ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
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]で定義された<の基本的な>要素を選択します。 これがすべての先祖と同様に<の基本的な>要素の選択をもたらして、すなわち、<は状態>と<tuple>です。
<include type="xpath">/presence/tuple/status/basic</include>.
<インクルードタイプが等しい、「xpath「>/presence/tuple/status/basic</インクルード>。」
3.5.2. The <exclude> Element
3.5.2. <は>要素を除きます。
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.
<はXML要素のセットへの例外を定義するために使用される>要素を除きます、そして、<によって選択された属性は>要素を含んでいます。 したがって、XML要素(それらの低レベル「子供」要素を含んでいる)、そして/または、<によって定義された属性は要素が提供されない>を除きます。 <インクルード>要素が名前空間を特定するとき、これは最も役に立ちます。
The <exclude> element has the optional 'type' attribute (see the definition of the 'type' in Section 3.5.3).
<は任意の'タイプ'が要素で結果と考える>を除きます(セクション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ドキュメント結果まで>要素価値を除いてください、それを有効にするようにそれらの前の値で結果として起こるXMLドキュメントに再取り入れられる要素、そして/または、属性をもたらして。 これは、実際にはフィルタを定義すると<に必要とするだけである加入者が>随意的な要素を除くことを意味します、そして、しかし、属性、SHOULD NOT<は>の義務的な要素、そして/または、属性を除きます。
The syntax MUST follow Section 5.
構文はセクション5に続かなければなりません。
3.5.3. The 'type' Attribute
3.5.3. 'タイプ'属性
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".
'タイプ'属性は<の値について説明するのに使用されて、インクルード>と<が>要素を除くということです。 以下の値は事前に定義されます: "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.
<が>を含んでいるか、または<が>要素を除くとき、要素か属性を選択するセクション5の構文に従って、使用される"xpath"値は値を含んでいます。
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.
<が>を含んでいるか、または<が>要素を除くとき、使用される「名前空間」値は名前空間の値を含んでいます。 値は名前空間のURIです。 結果として起こるXMLドキュメントは名前空間の中で定義された要素から成ります。
Khartabil, et al. Standards Track [Page 7] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[7ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
3.6. The <trigger> Element
3.6. <引き金の>要素
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.
<引き金の>要素は、内容が加入者に提供される前にリソースが遭遇しなければならないパッケージ特有の変化を特定するのに使用されます。 それは<フィルタ>要素で一度より多く見えることができます。 この要素の複数の外観が「OR」操作を指示します。 これは、リソースへの<引き金の>要素評価基準のいずれも満たすアップデートが提供される内容を構成することを意味します。
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.
<引き金の>要素は含むかもしれません。<が>を変えなければなりませんでしたか、<が>を加えなければなりませんでしたか、<は>要素を取り除きましたが、またはそれは少なくとも3つの要素の1つを含まなければなりません。 3つの要素のどんな組み合わせも可能です。 <引き金の>要素の中のそれらの要素の複数の外観が“AND"操作を指示します。 これは、リソースへの<のすべてを満たすアップデートが>を変えて、<が>を加えて、<が<引き金の>要素の中の要素の評価基準が提供されるために内容を構成する>を取り外したことを意味します。
3.6.1. The <changed> Element
3.6.1. <は>要素を変えました。
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.
<はXML要素か属性を特定するために使用される>要素を変えました、パッケージ特有のXMLドキュメントから、引き金を動かして、内容が提供されることを引き起こすために。(ドキュメントの値は「前のXMLドキュメント」のものから変化しなければなりません)。 「前のXMLドキュメント」はこのような関係においては加入者に送られた最新のXMLドキュメントの生のバージョンを示します、フィルタがそれに適用される前に。 「参照」ABNFのためにセクション5で定義された構文を使用して、XML要素か属性を表さなければなりません。
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.
<は>要素を変えました。'from'属性、'to'属性、'by'属性、または3つのもののどんな組み合わせも含むかもしれません。 それらの属性のすべての不在は、要素か属性の値へのどんな種類の変化も引き金を動かすことを意味します。 要素へのアップデートか同じ値がある属性値が変化ではありません。
Comparison of a change is done according to the element or attribute's lexical rules.
要素か属性の語彙規則によると、変化の比較をします。
3.6.1.1. The 'from' Attribute
3.6.1.1. 'from'属性
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.
XML要素か属性が変えられた>要素がこの属性によって示された値から異価に変えた<を同一視したとき、引き金はアクティブです。
Khartabil, et al. Standards Track [Page 8] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[8ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
3.6.1.2. The 'to' Attribute
3.6.1.2. 'to'属性
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.
XML要素か属性が変えられた>要素がこの属性によって異価から示された値に変えた<を同一視したとき、引き金はアクティブです。
3.6.1.3. The 'by' Attribute
3.6.1.3. 'by'属性
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.
XML要素か属性が少なくともこの属性によって異価から示された量に従って変えられた>要素が変えた<を同一視したとき、引き金はアクティブです。 それが選択される前に、すなわち、'by'属性は、属性か要素(特定されて、<では、>要素は変化していた)が変える必要がある現行価値に関して数値だけに適用して、デルタを示します。 達するとき、例えば、要素/属性が'by'属性が2に設定されて、要素/属性の現行価値が6であるなら、選択される、(超過、)、値8、いつ4まで減少するか、そして、または下側の値。
3.6.1.4. Combination of Attributes
3.6.1.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'タイプに合わなければならないことに注意してください。
3.6.2. The <added> Element
3.6.2. <は>要素を加えました。
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.
<は、それが特定するXML要素をフィルターにかけられるドキュメントに追加してあるとき(すなわち、その要素のこのインスタンスは、現在のドキュメントに現れますが、前のドキュメントに現れるというわけではありません)、>要素が内容物配送の引き金となると言い足しました。 例えば、ユーザ、サービス、そして/または、能力でユーザが現在加入者を見させたことを新種業務、そして/または、加入される能力を学ぶのにそれを使用できます。 「参照」ABNFのためにセクション5で定義された構文を使用して、XML要素か属性を表さなければなりません。
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.
フィルタが両方の満足しているフィルタを含んでいるならそれに注意してください、(<、何という>) 部分と<は>要素を加えて、次に、またSHOULDがカバーするすべての>部分の<の定義は加えられた要素であるか。 さもなければ、内容は配送して、<で定義された項目が>要素を加えたということです。
Khartabil, et al. Standards Track [Page 9] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[9ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
3.6.3. The <removed> Element
3.6.3. <は>要素を取り除きました。
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要素を取り除いたとき(すなわち、その要素のこのインスタンスは、前のドキュメントに現れましたが、本書では現れたというわけではありません)、<は>要素引き金の内容物配送を取り除きました。 「参照」ABNFのためにセクション5で定義された構文を使用して、XML要素か属性を表さなければなりません。
4. XML Schema Extensibility
4. XML図式伸展性
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名前空間はこの仕様に基づき定義された名前空間と異なっているに違いありません。 拡大は本書では定義されたschemasの構文か意味論を変えてはいけません。 すべての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.
この仕様は拡大からの新しい要素か属性を置くことができる明白な場所を定義します。 schemasで<によって示されて、これらは明らかにそうです。いずれも>と<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.
その結果、拡大を含むドキュメントは正当性を決定するために複数のschemasを必要とするでしょう--ドキュメントの現在の拡大で定義されたものと共に本書では定義された図式。 新しいschemasで新しい要素と属性を決定されたと言い足すことによって拡大が起こるので、本書では定義されたschemasを修理していて、この仕様への改正で変えるだけでしょう。 行われるなら、そのような改正は、前の図式への対応することのドキュメントが新しい方に言いなりになったままで残っているのを許容するよう努力するでしょう。 その結果、これは必要でないと予想されるとき、ここで定義されたschemasが明白な図式バージョンを提供しません。
5. Syntax for Referencing XML Items and Making Logical Expressions
5. XMLの品目に参照をつけて、論理式を作るための構文
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
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
Khartabil, et al. Standards Track [Page 10] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 10] RFC 4661 XML Based Format for Filtering September 2006
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.
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.
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
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
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>
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".
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".
Example references are listed as follows:
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 Selecting an element by using an XML element as a condition: * //*[status/basic="open"] * /presence/tuple[*/basic="open"]
o Selecting an element by using XML attributes as a condition:
* //watcher[@duration-subscribed<500]
* /*/watcher[@event="rejected"]
o Selecting an element by using XML attributes as a condition: * //watcher[@duration-subscribed<500] * /*/watcher[@event="rejected"]
Khartabil, et al. Standards Track [Page 11] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 11] RFC 4661 XML Based Format for Filtering September 2006
o Selecting an element by using two XML elements as a condition:
* //tuple[status/basic="open" and type="device"]
o Selecting an element by using two XML elements as a condition: * //tuple[status/basic="open" and type="device"]
o Selecting an attribute:
* //watcher/@duration-subscribed
o Selecting an attribute: * //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.
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.
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.
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.
6. Examples
6. Examples
The XML Schema for the XML document examples is specified in Section 7.
The XML Schema for the XML document examples is specified in Section 7.
6.1. Filter Criteria Using <what> Element
6.1. Filter Criteria Using <what> Element
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.
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.
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".
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".
The <class> element is defined in [14] as an extension to PIDF [13].
The <class> element is defined in [14] as an extension to 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">
<?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">
Khartabil, et al. Standards Track [Page 12] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 12] RFC 4661 XML Based Format for Filtering September 2006
<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>
<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>
6.2. Filter Criteria Using <trigger> Element
6.2. Filter Criteria Using <trigger> Element
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".
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".
<?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>
<?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>
6.3. Filter Criteria Using <what> and <trigger> Elements
6.3. Filter Criteria Using <what> and <trigger> Elements
A user wishes to get information about pending and waiting subscriptions in order to be able to authorise watchers to see his presence information.
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.
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.
<?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">
<?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">
Khartabil, et al. Standards Track [Page 13] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 13] RFC 4661 XML Based Format for Filtering September 2006
<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>
<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>
6.4. Content Filter Using Namespaces
6.4. Content Filter Using Namespaces
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.
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.
The filter is defined to select XML elements belonging to the PIDF namespace.
<?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>
<?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>
6.5. Content Filter Using Only <include> Elements
6.5. Content Filter Using Only <include> Elements
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.
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.
This filter is defined to select the game-specific tuple to be delivered.
Khartabil, et al. Standards Track [Page 14] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 14] RFC 4661 XML Based Format for Filtering September 2006
<?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>
<?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>
6.6. Two Content Filters as Filter Criteria
6.6. Two Content Filters as Filter Criteria
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.
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.
<?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>
<?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>
Khartabil, et al. Standards Track [Page 15] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 15] RFC 4661 XML Based Format for Filtering September 2006
</filter>
</filter-set>
</filter> </filter-set>
7. XML Schema for Filter Criteria
7. XML Schema for Filter Criteria
XML Schema Implementation (Normative)
XML Schema Implementation (Normative)
<?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">
<?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: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:annotation> <xs:documentation xml:lang="en"> XML Schema Definition for Filter Criteria. </xs:documentation> </xs:annotation>
<xs:element name="filter-set" type="FilterSetType"/>
<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="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="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="NSBinding"> <xs:attribute name="prefix" type="xs:string" use="required"/> <xs:attribute name="urn" type="xs:anyURI" use="required"/> </xs:complexType>
Khartabil, et al. Standards Track [Page 16] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 16] RFC 4661 XML Based Format for Filtering September 2006
<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="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="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="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 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>
Khartabil, et al. Standards Track [Page 17] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 17] RFC 4661 XML Based Format for Filtering September 2006
</xs:complexType>
</xs:complexType>
<xs:simpleType name="TypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="xpath"/>
<xs:enumeration value="namespace"/>
</xs:restriction>
</xs:simpleType>
<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="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: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>
</xs:schema>
8. Security Considerations
8. Security Considerations
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].
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].
Khartabil, et al. Standards Track [Page 18] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 18] RFC 4661 XML Based Format for Filtering September 2006
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].
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].
All filtering-related security measures discussed in [2] MUST be followed along with package-specific security.
All filtering-related security measures discussed in [2] MUST be followed along with package-specific security.
9. IANA Considerations
9. IANA Considerations
This document registers a new MIME type, "application/ simple-filter+xml", and registers a new XML namespace.
This document registers a new MIME type, "application/ simple-filter+xml", and registers a new XML namespace.
This specification follows the guidelines of RFC3023 [7].
This specification follows the guidelines of RFC3023 [7].
9.1. application/simple-filter+xml MIME TYPE
9.1. application/simple-filter+xml MIME TYPE
MIME media type: application
MIME media type: application
MIME subtype name: simple-filter+xml
MIME subtype name: simple-filter+xml
Mandatory parameters: none
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml, as specified in RFC 3023 [7].
Optional parameters: Same as charset parameter application/xml, as specified in RFC 3023 [7].
Encoding considerations: Same as encoding considerations of application/xml, as specified in RFC 3023 [7].
Encoding considerations: Same as encoding considerations of application/xml, as specified in RFC 3023 [7].
Security considerations: See section 10 of RFC 3023 [7] and section Section 8 of this document.
Security considerations: See section 10 of RFC 3023 [7] and section Section 8 of this document.
Interoperability considerations: none.
Interoperability considerations: none.
Published specification: This document.
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.
Applications that use this media type: This document type has been used to support the SIP-based Event notification framework and its packages.
Additional information:
Additional information:
Magic number: None
Magic number: None
File extension: .cl or .xml
File extension: .cl or .xml
Macintosh file type code: "TEXT"
Macintosh file type code: "TEXT"
Khartabil, et al. Standards Track [Page 19] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 19] RFC 4661 XML Based Format for Filtering September 2006
Personal and email address for further information: Hisham Khartabil (hisham.khartabil@telio.no)
Personal and email address for further information: Hisham Khartabil (hisham.khartabil@telio.no)
Intended Usage: COMMON
Intended Usage: COMMON
Author/change controller: The IETF
Author/change controller: The IETF
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:simple-filter
9.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:simple-filter
This section registers a new XML namespace, as per guidelines in the IETF XML Registry [4].
This section registers a new XML namespace, as per guidelines in the IETF XML Registry [4].
URI: The URI for this namespace is urn:ietf:params:xml:ns:simple-filter.
URI: The URI for this namespace is urn:ietf:params:xml:ns:simple-filter.
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no)
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no)
9.3. Schema Registration
9.3. Schema Registration
This section registers a new XML schema per the procedures in [4].
This section registers a new XML schema per the procedures in [4].
URI: urn:ietf:params:xml:ns:simple-filter
URI: urn:ietf:params:xml:ns:simple-filter
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no).
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no).
The XML for this schema can be found as the sole content of Section 7.
The XML for this schema can be found as the sole content of Section 7.
10. Acknowledgements
10. Acknowledgements
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.
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.
11. References
11. References
11.1. Normative References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
Khartabil, et al. Standards Track [Page 20] RFC 4661 XML Based Format for Filtering September 2006
Khartabil, et al. Standards Track [Page 20] RFC 4661 XML Based Format for Filtering September 2006
[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., and J. Costa- Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 2006.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[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 (Second Edition)", W3C CR CR-xml11-20011006, October 2000.
[9] Clark, J., "XML Path Language (XPath) Version 1.0", W3C REC
REC-xpath-19991116, November 1999.
[9] Clark, J., "XML Path Language (XPath) Version 1.0", W3C REC REC-xpath-19991116, November 1999.
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[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 Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
11.2. Informative References
11.2. Informative References
[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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[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., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[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., and J. Rosenberg, "RPID -- Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[15] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[15] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
[16] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004.
[16] ローゼンバーグ、J.、「拡張マークアップ言語(XML)はウォッチャー情報のための形式を基礎づけた」RFC3858、2004年8月。
Khartabil, et al. Standards Track [Page 21] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[21ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
[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] ローチ、A.B.、キャンベル、B.、およびJ.ローゼンバーグ、「リソースのためのセッション開始プロトコル(一口)イベント通知拡張子は記載します」、RFC4663、2006年9月。
[18] Rosenberg, J., "Presence Authorization Rules", Work in
Progress, June 2006.
[18] ローゼンバーグ、J.が進歩、2006年6月に働くのを「存在認可は統治します」。
Khartabil, et al. Standards Track [Page 22] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[22ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
Authors' Addresses
作者のアドレス
Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway
Hisham Khartabil Telio私書箱1203Vikaオスロノルウェー
Phone: +47 2167 3544 EMail: hisham.khartabil@telio.no
以下に電話をしてください。 +47 2167 3544はメールされます: hisham.khartabil@telio.no
Eva Leppanen Nokia P.O BOX 785 Tampere Finland
エバLeppanenノキアP.O箱785のタンペレフィンランド
Phone: +358 7180 77066 EMail: eva-maria.leppanen@nokia.com
以下に電話をしてください。 +358 7180 77066はメールされます: eva-maria.leppanen@nokia.com
Mikko Lonnfors Nokia P.O BOX 321 Helsinki Finland
ミッコLonnforsノキアP.O箱321のヘルシンキフィンランド
Phone: + 358 71800 8000 EMail: mikko.lonnfors@nokia.com
以下に電話をしてください。 + 71800 8000がメールする358: mikko.lonnfors@nokia.com
Jose Costa-Requena Nokia P.O. Box 321 FIN-00045 NOKIA GROUP FINLAND
ホセコスタ-レケナノキアP.O. Box321フィン-00045Nokia Groupフィンランド
Phone: +358 71800 8000 EMail: jose.costa-requena@nokia.com
以下に電話をしてください。 +358 71800 8000はメールされます: jose.costa-requena@nokia.com
Khartabil, et al. Standards Track [Page 23] RFC 4661 XML Based Format for Filtering September 2006
Khartabil、他 標準化過程[23ページ]RFC4661XMLは2006年9月をフィルターにかけるための形式を基礎づけました。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Khartabil, et al. Standards Track [Page 24]
Khartabil、他 標準化過程[24ページ]
一覧
スポンサーリンク
