RFC4660 日本語訳
4660 Functional Description of Event Notification Filtering. H.Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. September 2006. (Format: TXT=63886 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Khartabil
Request for Comments: 4660 Telio
Category: Standards Track E. Leppanen
M. Lonnfors
J. Costa-Requena
Nokia
September 2006
Network Working Group H. Khartabil Request for Comments: 4660 Telio Category: Standards Track E. Leppanen M. Lonnfors J. Costa-Requena Nokia September 2006
Functional Description of Event Notification Filtering
Functional Description of Event Notification Filtering
Status of This Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
Abstract
The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.
The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.
This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed.
This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed.
Khartabil, et al. Standards Track [Page 1] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 1] RFC 4660 Functional Description of Filtering September 2006
Table of Contents
Table of Contents
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Client Operation ................................................4
3.1. Transport Mechanism ........................................4
3.2. SUBSCRIBE Bodies ...........................................4
3.3. Subscriber Generating of SUBSCRIBE Requests ................4
3.3.1. Defining the Filtering Rules ........................4
3.3.2. Request-URI vs. Filter URI ..........................5
3.3.3. Changing Filters within a Dialog ....................5
3.3.4. Subscriber Interpreting of SIP Responses ............6
3.4. Subscriber Processing of NOTIFY Requests ...................6
4. Resource List Server Behaviour ..................................7
4.1. Request-URI vs. Filter URI .................................7
4.2. Changing Filters within a Dialog ...........................9
5. Server Operation ................................................9
5.1. NOTIFY Bodies ..............................................9
5.2. Notifier Processing of SUBSCRIBE Requests ..................9
5.2.1. Request-URI vs. Filter URI .........................10
5.2.2. Changing Filters within a Dialog ...................11
5.3. Notifier Generating of NOTIFY Requests ....................11
5.3.1. Generation of NOTIFY Contents ......................12
5.3.2. Handling of Notification Triggering Rules ..........13
5.4. Handling Abnormal Cases ...................................13
6. XML Document Validation ........................................14
7. Examples .......................................................14
7.1. Presence Specific Examples ................................14
7.1.1. Subscriber Requests Messaging-Related Information ..15
7.1.2. Subscriber Fetches Information about "Open"
Communication Means ................................16
7.1.3. Subscriber Requests Notifications When
Presentity's Status Changes ........................18
7.2. Watcher Information Specific Examples .....................21
7.2.1. Watcher Subscriber Makes Subscription to
Get All the Information about Active Watchers ......22
7.2.2. Watcher Subscriber Requests Information of
Watchers with Specific Subscription Duration
Conditions .........................................23
7.2.3. Watcher Subscriber Requests Specific
Watcher Info on Specific Triggers ..................24
8. Security Considerations ........................................27
9. IANA Considerations ............................................28
10. Acknowledgements ..............................................28
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................28
1. Introduction ....................................................3 2. Conventions .....................................................3 3. Client Operation ................................................4 3.1. Transport Mechanism ........................................4 3.2. SUBSCRIBE Bodies ...........................................4 3.3. Subscriber Generating of SUBSCRIBE Requests ................4 3.3.1. Defining the Filtering Rules ........................4 3.3.2. Request-URI vs. Filter URI ..........................5 3.3.3. Changing Filters within a Dialog ....................5 3.3.4. Subscriber Interpreting of SIP Responses ............6 3.4. Subscriber Processing of NOTIFY Requests ...................6 4. Resource List Server Behaviour ..................................7 4.1. Request-URI vs. Filter URI .................................7 4.2. Changing Filters within a Dialog ...........................9 5. Server Operation ................................................9 5.1. NOTIFY Bodies ..............................................9 5.2. Notifier Processing of SUBSCRIBE Requests ..................9 5.2.1. Request-URI vs. Filter URI .........................10 5.2.2. Changing Filters within a Dialog ...................11 5.3. Notifier Generating of NOTIFY Requests ....................11 5.3.1. Generation of NOTIFY Contents ......................12 5.3.2. Handling of Notification Triggering Rules ..........13 5.4. Handling Abnormal Cases ...................................13 6. XML Document Validation ........................................14 7. Examples .......................................................14 7.1. Presence Specific Examples ................................14 7.1.1. Subscriber Requests Messaging-Related Information ..15 7.1.2. Subscriber Fetches Information about "Open" Communication Means ................................16 7.1.3. Subscriber Requests Notifications When Presentity's Status Changes ........................18 7.2. Watcher Information Specific Examples .....................21 7.2.1. Watcher Subscriber Makes Subscription to Get All the Information about Active Watchers ......22 7.2.2. Watcher Subscriber Requests Information of Watchers with Specific Subscription Duration Conditions .........................................23 7.2.3. Watcher Subscriber Requests Specific Watcher Info on Specific Triggers ..................24 8. Security Considerations ........................................27 9. IANA Considerations ............................................28 10. Acknowledgements ..............................................28 11. References ....................................................28 11.1. Normative References .....................................28 11.2. Informative References ...................................28
Khartabil, et al. Standards Track [Page 2] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 2] RFC 4660 Functional Description of Filtering September 2006
1. Introduction
1. Introduction
SIP event notification is described in [3]. It defines a general framework for sending subscriptions and receiving notifications in SIP-based systems. It introduces the concept of event packages, which are concrete applications of the general event framework to a specific usage of events.
SIP event notification is described in [3]. It defines a general framework for sending subscriptions and receiving notifications in SIP-based systems. It introduces the concept of event packages, which are concrete applications of the general event framework to a specific usage of events.
Filtering is a mechanism for controlling the content of event notifications. Additionally, the subscriber may specify the rules for when a notification should be sent to it. The filtering mechanism is expected to be particularly valuable 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.
Filtering is a mechanism for controlling the content of event notifications. Additionally, the subscriber may specify the rules for when a notification should be sent to it. The filtering mechanism is expected to be particularly valuable 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.
It is stated in [3] that the notifier may send a NOTIFY at any time, but typically it is sent when the state of the resource changes. It also states that the notifications would contain the complete and current state of the resource authorized for a certain subscriber to see. The format of such resource state information is package specific. In this memo, we assume that the NOTIFY for any package contains an XML document.
It is stated in [3] that the notifier may send a NOTIFY at any time, but typically it is sent when the state of the resource changes. It also states that the notifications would contain the complete and current state of the resource authorized for a certain subscriber to see. The format of such resource state information is package specific. In this memo, we assume that the NOTIFY for any package contains an XML document.
This document, together with [5], presents a mechanism for filtering whereby a subscriber describes its preference of when notifications are to be sent to it and what they are to contain. It also describes how the notifier functions when generating notifications by taking into account filters and default functionality of the package/ service.
This document, together with [5], presents a mechanism for filtering whereby a subscriber describes its preference of when notifications are to be sent to it and what they are to contain. It also describes how the notifier functions when generating notifications by taking into account filters and default functionality of the package/ service.
The XML format for defining the filter is described in [5].
The XML format for defining the filter is described in [5].
2. Conventions
2. Conventions
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.
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.
"Content" refers to the XML document that appears in a notification reflecting the state of a resource.
"Content" refers to the XML document that appears in a notification reflecting the state of a resource.
Khartabil, et al. Standards Track [Page 3] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 3] RFC 4660 Functional Description of Filtering September 2006
3. Client Operation
3. Client Operation
3.1. Transport Mechanism
3.1. Transport Mechanism
Transportation of the filter to the server is achieved by inserting the XML document, as defined in [5], in the body of the SUBSCRIBE request. Alternatively, the XML document can be uploaded to the server using means outside the scope of this document.
Transportation of the filter to the server is achieved by inserting the XML document, as defined in [5], in the body of the SUBSCRIBE request. Alternatively, the XML document can be uploaded to the server using means outside the scope of this document.
3.2. SUBSCRIBE Bodies
3.2. SUBSCRIBE Bodies
SIP entities compliant with this specification MUST support the content type 'application/simple-filter+xml'.
SIP entities compliant with this specification MUST support the content type 'application/simple-filter+xml'.
3.3. Subscriber Generating of SUBSCRIBE Requests
3.3. Subscriber Generating of SUBSCRIBE Requests
This section presents additional functionality required from the subscriber when filters are used in the bodies of the SUBSCRIBE requests. Normal operations of services (e.g., as defined in [8], [10], and [4]) are otherwise followed.
This section presents additional functionality required from the subscriber when filters are used in the bodies of the SUBSCRIBE requests. Normal operations of services (e.g., as defined in [8], [10], and [4]) are otherwise followed.
As defined in [3], the SUBSCRIBE message MAY contain a body. This body would carry filtering information. Honouring those filters is at the discretion of the notifier and might depend on local policies.
As defined in [3], the SUBSCRIBE message MAY contain a body. This body would carry filtering information. Honouring those filters is at the discretion of the notifier and might depend on local policies.
No content in the body of a SUBSCRIBE indicates to the notifier that no filter is being requested, so the notifier is instructed to send all the NOTIFY requests using the notifier's own or service-specific policy. Note that, for example, in the list case [4], the filter might have been uploaded to the server beforehand (by means outside the scope of this document).
No content in the body of a SUBSCRIBE indicates to the notifier that no filter is being requested, so the notifier is instructed to send all the NOTIFY requests using the notifier's own or service-specific policy. Note that, for example, in the list case [4], the filter might have been uploaded to the server beforehand (by means outside the scope of this document).
If the body of the SUBSCRIBE includes the filter, the body MUST be of the MIME-Type 'application/simple-filter+xml'.
If the body of the SUBSCRIBE includes the filter, the body MUST be of the MIME-Type 'application/simple-filter+xml'.
3.3.1. Defining the Filtering Rules
3.3.1. Defining the Filtering Rules
Multiple filters MAY be included in one SUBSCRIBE. This is achieved by including multiple <filter> elements in the filter [5]. Each <filter> element may include a 'uri' attribute.
Multiple filters MAY be included in one SUBSCRIBE. This is achieved by including multiple <filter> elements in the filter [5]. Each <filter> element may include a 'uri' attribute.
A SUBSCRIBE request destined to a list URI [4] MAY include multiple filters specific to individual resources. This is achieved by including multiple <filter> elements with different URIs of resources in each of those elements. This resource specific resource-specific filter are processed first before any list specific list-specific filter, if any. The list specific list-specific filter may or may not include a URI.
A SUBSCRIBE request destined to a list URI [4] MAY include multiple filters specific to individual resources. This is achieved by including multiple <filter> elements with different URIs of resources in each of those elements. This resource specific resource-specific filter are processed first before any list specific list-specific filter, if any. The list specific list-specific filter may or may not include a URI.
Khartabil, et al. Standards Track [Page 4] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 4] RFC 4660 Functional Description of Filtering September 2006
Furthermore, regardless of whether the SUBSCRIBE is destined to a list URI, there can only be one filter applicable to a single resource or domain within a single SUBSCRIBE. That is, each filter within a subscription MUST uniquely identify one resource or one domain.
Furthermore, regardless of whether the SUBSCRIBE is destined to a list URI, there can only be one filter applicable to a single resource or domain within a single SUBSCRIBE. That is, each filter within a subscription MUST uniquely identify one resource or one domain.
A filter can be enabled and disabled using the 'enabled' attribute in the <filter> element, as described in [5].
A filter can be enabled and disabled using the 'enabled' attribute in the <filter> element, as described in [5].
3.3.2. Request-URI vs. Filter URI
3.3.2. Request-URI vs. Filter URI
The URI in the filter defines the target resource. For example, in the Presence service case, it is the presentity's presence information to which the filter is applied. The subscriber MAY choose to leave the URI in the filter undefined. If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI. Similarly, the subscriber MAY define a filter URI. If the Request-URI is a list URI [4], the filter URI MUST be the list URI, a sub-list URI, or resource whose URI is one of the URIs that result from a lookup, by a Resource List Server (RLS), on the Request-URI. If it is not, the filter may be ignored or may be rejected. URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).
The URI in the filter defines the target resource. For example, in the Presence service case, it is the presentity's presence information to which the filter is applied. The subscriber MAY choose to leave the URI in the filter undefined. If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI. Similarly, the subscriber MAY define a filter URI. If the Request-URI is a list URI [4], the filter URI MUST be the list URI, a sub-list URI, or resource whose URI is one of the URIs that result from a lookup, by a Resource List Server (RLS), on the Request-URI. If it is not, the filter may be ignored or may be rejected. URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).
A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain. This can be used when a subscription is for a resource that is an event list with many resources from differing domains. If an individual resource-specific filter is present along with the domain filter, this resource-specific filter overrides any domain-specific filter, if any.
A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain. This can be used when a subscription is for a resource that is an event list with many resources from differing domains. If an individual resource-specific filter is present along with the domain filter, this resource-specific filter overrides any domain-specific filter, if any.
3.3.3. Changing Filters within a Dialog
3.3.3. Changing Filters within a Dialog
The subscriber MAY reset or change the filter by re-issuing a new SUBSCRIBE request within the existing dialog. A SUBSCRIBE within the exiting dialog that does not contain a filter is assumed to maintain existing filters. This means that filters are persistent within a dialog and are only explicitly removed.
The subscriber MAY reset or change the filter by re-issuing a new SUBSCRIBE request within the existing dialog. A SUBSCRIBE within the exiting dialog that does not contain a filter is assumed to maintain existing filters. This means that filters are persistent within a dialog and are only explicitly removed.
A subscriber requiring removal of a filter may do so by using the 'remove="true"' attribute, as defined in [5].
A subscriber requiring removal of a filter may do so by using the 'remove="true"' attribute, as defined in [5].
In the case where the URI in the filter is that of a list, a subscriber may override the existing filter with a filter for an individual resource that is part of the list subscribed to earlier by
In the case where the URI in the filter is that of a list, a subscriber may override the existing filter with a filter for an individual resource that is part of the list subscribed to earlier by
Khartabil, et al. Standards Track [Page 5] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 5] RFC 4660 Functional Description of Filtering September 2006
issuing a new SUBSCRIBE within the existing dialog and including a filter, specific for that individual resource, using a new filter ID. The new filter need not include the original filter since a filter is only removed in the manner indicated above.
issuing a new SUBSCRIBE within the existing dialog and including a filter, specific for that individual resource, using a new filter ID. The new filter need not include the original filter since a filter is only removed in the manner indicated above.
A filter is replaced by the subscriber re-issuing the filter using the same filter ID and replacing the contents of the filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the server to assume that two filters are placed for the same resource.
A filter is replaced by the subscriber re-issuing the filter using the same filter ID and replacing the contents of the filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the server to assume that two filters are placed for the same resource.
Again, a filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].
Again, a filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].
3.3.4. Subscriber Interpreting of SIP Responses
3.3.4. Subscriber Interpreting of SIP Responses
The SUBSCRIBE request will be confirmed with a final response. A 200-class response indicates that the subscription has been accepted and that a NOTIFY will be sent immediately. A "200" response indicates that the subscription has been accepted and that the filter is accepted. A "202" response merely indicates that the subscription has been understood, that the content type has been accepted, and that authorization may or may not have been granted. A "202" response also indicates that the filter has not been accepted yet. The acceptance of the filter MAY arrive in a subsequent NOTIFY.
The SUBSCRIBE request will be confirmed with a final response. A 200-class response indicates that the subscription has been accepted and that a NOTIFY will be sent immediately. A "200" response indicates that the subscription has been accepted and that the filter is accepted. A "202" response merely indicates that the subscription has been understood, that the content type has been accepted, and that authorization may or may not have been granted. A "202" response also indicates that the filter has not been accepted yet. The acceptance of the filter MAY arrive in a subsequent NOTIFY.
A non-200 class final response indicates that no subscription or dialog has been created, and no subsequent NOTIFY message will be sent. All non-200 class final responses have the same meanings and handling as described in [2] and [3].
A non-200 class final response indicates that no subscription or dialog has been created, and no subsequent NOTIFY message will be sent. All non-200 class final responses have the same meanings and handling as described in [2] and [3].
Specifically, a "415" response indicates that the MIME type 'application/simple-filter+xml' is not understood by the notifier. A "488" response indicates that the content type (filter) is understood but some aspects of it were either not understood or not accepted.
Specifically, a "415" response indicates that the MIME type 'application/simple-filter+xml' is not understood by the notifier. A "488" response indicates that the content type (filter) is understood but some aspects of it were either not understood or not accepted.
3.4. Subscriber Processing of NOTIFY Requests
3.4. Subscriber Processing of NOTIFY Requests
If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that follows MAY contain a body that describes the present state of the resource after the filters have been applied.
If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that follows MAY contain a body that describes the present state of the resource after the filters have been applied.
If the NOTIFY indicates that a subscription has been terminated [3], the subscription is assumed to be terminated. Behaviour in such events is also described in [3].
If the NOTIFY indicates that a subscription has been terminated [3], the subscription is assumed to be terminated. Behaviour in such events is also described in [3].
If the subscription is indicated as active, NOTIFY requests are handled as described in package-specific documents and in [3].
If the subscription is indicated as active, NOTIFY requests are handled as described in package-specific documents and in [3].
Khartabil, et al. Standards Track [Page 6] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 6] RFC 4660 Functional Description of Filtering September 2006
4. Resource List Server Behaviour
4. Resource List Server Behaviour
The Resource List Server is defined in [4]. This section describes how such an entity behaves in the presence of a filter in a subscription to a list.
The Resource List Server is defined in [4]. This section describes how such an entity behaves in the presence of a filter in a subscription to a list.
4.1. Request-URI vs. Filter URI
4.1. Request-URI vs. Filter URI
If the URI is not defined within the filter, the filter applies to the resource list identified in the Request-URI of the SUBSCRIBE request. This results in the filters being applied to all the notifications that the RLS issues to this subscription. The same processing applies to a filter that defines a URI that matches the request-URI of the SUBSCRIBE request. That is, the filter applies to all notifications that the RLS issues to this subscription.
If the URI is not defined within the filter, the filter applies to the resource list identified in the Request-URI of the SUBSCRIBE request. This results in the filters being applied to all the notifications that the RLS issues to this subscription. The same processing applies to a filter that defines a URI that matches the request-URI of the SUBSCRIBE request. That is, the filter applies to all notifications that the RLS issues to this subscription.
If the URI indicated by the filter is for one resource whose URI is one of the URIs that result from a lookup by the RLS on the Request-URI, the filter for that particular resource is extracted and propagated in the SUBSCRIBE request sent to that resource. It is possible to have more than one filter in a SUBSCRIBE request body, and therefore a filter specific to a resource MUST be extracted and only that one is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@example.com", where "bob@example.com" is a resource belonging to that list, and the URI in a filter is "sip:bob@example.com", the filter specific for Bob is extracted and placed in the body of the SUBSCRIBE sent to "bob@example.com".
If the URI indicated by the filter is for one resource whose URI is one of the URIs that result from a lookup by the RLS on the Request-URI, the filter for that particular resource is extracted and propagated in the SUBSCRIBE request sent to that resource. It is possible to have more than one filter in a SUBSCRIBE request body, and therefore a filter specific to a resource MUST be extracted and only that one is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@example.com", where "bob@example.com" is a resource belonging to that list, and the URI in a filter is "sip:bob@example.com", the filter specific for Bob is extracted and placed in the body of the SUBSCRIBE sent to "bob@example.com".
If the URI indicated by the filter is for one resource whose URI is NOT under the RLS administrative control, the RLS propagates the filter to all the fanned out subscriptions. This is to accommodate the scenario where the subscriber knows that there are sub-lists in the event list that are under a different administrative domain from that where the original subscription was sent, and the subscriber wishes to set a filter for a resource in that sub-list.
If the URI indicated by the filter is for one resource whose URI is NOT under the RLS administrative control, the RLS propagates the filter to all the fanned out subscriptions. This is to accommodate the scenario where the subscriber knows that there are sub-lists in the event list that are under a different administrative domain from that where the original subscription was sent, and the subscriber wishes to set a filter for a resource in that sub-list.
If the URI indicated by the filter is for one resource whose URI is under the RLS administrative control but is not part of the resource list that the subscription was addressed to, the filter is not propagated. In this case, it is the RLS's responsibility to make sure that this filter is applied to notifications issued, if information about that resource is present.
If the URI indicated by the filter is for one resource whose URI is under the RLS administrative control but is not part of the resource list that the subscription was addressed to, the filter is not propagated. In this case, it is the RLS's responsibility to make sure that this filter is applied to notifications issued, if information about that resource is present.
Khartabil, et al. Standards Track [Page 7] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 7] RFC 4660 Functional Description of Filtering September 2006
For example: If we have 2 lists, each located on its own RLS:
For example: If we have 2 lists, each located on its own RLS:
List1 (list1@example.com) on RLS1 has: bob@example.com
List1 (list1@example.com) on RLS1 has: bob@example.com
list2@biloxi.com
list2@biloxi.com
List2 on RLS2 has: alice@biloxi.com sarah@example.com (Note: list2 is a resource in list1)
List2 on RLS2 has: alice@biloxi.com sarah@example.com (Note: list2 is a resource in list1)
RLS1 receives the following SUBSCRIBE request (the SUBSCRIBE is addressed to list1 and contains 2 filters: one for sarah@example.com and the other for alice@biloxi.com):
RLS1 receives the following SUBSCRIBE request (the SUBSCRIBE is addressed to list1 and contains 2 filters: one for sarah@example.com and the other for alice@biloxi.com):
SUBSCRIBE sip:List1@example.com SIP/2.0
...
<?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="999" uri="sip:sarah@example.com">
<what>
<include type="namespace">
urn:ietf:params:xml:ns:pidf</include>
<exclude>
//pidf:tuple/pidf:note</exclude>
</what>
</filter>
<filter id="8439" uri="sip:alice@biloxi.com">
<what>
<include>
//pidf:tuple/pidf:status/pidf:basic</include>
</what>
</filter>
</filter-set>
SUBSCRIBE sip:List1@example.com SIP/2.0 ... <?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="999" uri="sip:sarah@example.com"> <what> <include type="namespace"> urn:ietf:params:xml:ns:pidf</include> <exclude> //pidf:tuple/pidf:note</exclude> </what> </filter> <filter id="8439" uri="sip:alice@biloxi.com"> <what> <include> //pidf:tuple/pidf:status/pidf:basic</include> </what> </filter> </filter-set>
RLS1 fans out subscriptions to resources on list1. The text above suggests that if a filter is destined to a resource that is not part of the list and is outside the administrative domain of an RLS, then that filter is propagated. The rest are consumed. In our example, only the filter to alice@biloxi.com is propagated since biloxi.com is not under the administrative domain of RLS1. The filter to sarah@example.com is consumed, and RLS1 needs to apply that filter to notifications it receives.
RLS1 fans out subscriptions to resources on list1. The text above suggests that if a filter is destined to a resource that is not part of the list and is outside the administrative domain of an RLS, then that filter is propagated. The rest are consumed. In our example, only the filter to alice@biloxi.com is propagated since biloxi.com is not under the administrative domain of RLS1. The filter to sarah@example.com is consumed, and RLS1 needs to apply that filter to notifications it receives.
URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).
URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).
Khartabil, et al. Standards Track [Page 8] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 8] RFC 4660 Functional Description of Filtering September 2006
A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain, and the RLS MUST NOT apply filters to any notifications it sends. Instead, it MUST forward the filter with all fanned-out subscriptions to the notifiers.
A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain, and the RLS MUST NOT apply filters to any notifications it sends. Instead, it MUST forward the filter with all fanned-out subscriptions to the notifiers.
As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In such circumstances, an RLS MUST check that there are no filters addressed to the same resource or domain, and if there are, it MUST reject the SUBSCRIBE request with a "488" error response.
As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In such circumstances, an RLS MUST check that there are no filters addressed to the same resource or domain, and if there are, it MUST reject the SUBSCRIBE request with a "488" error response.
4.2. Changing Filters within a Dialog
4.2. Changing Filters within a Dialog
If an RLS receives a subscription refresh request with no filters specified (empty payload), the RLS assumes that the client does not wish to update the filters. If an RLS receives a subscription refresh with a filter containing the 'remove="true"' attribute, as defined in [5], the RLS assumes that the client is removing that filter identified by the filter ID.
If an RLS receives a subscription refresh request with no filters specified (empty payload), the RLS assumes that the client does not wish to update the filters. If an RLS receives a subscription refresh with a filter containing the 'remove="true"' attribute, as defined in [5], the RLS assumes that the client is removing that filter identified by the filter ID.
If an RLS receives a subscription refresh request with a filter that already exists (i.e., having the same filter ID), the RLS interprets it as a replacement of the existing filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the RLS to assume that two filters are in place for the same resource.
If an RLS receives a subscription refresh request with a filter that already exists (i.e., having the same filter ID), the RLS interprets it as a replacement of the existing filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the RLS to assume that two filters are in place for the same resource.
A filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].
A filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].
5. Server Operation
5. Server Operation
5.1. NOTIFY Bodies
5.1. NOTIFY Bodies
SIP entities compliant with this specification MUST support content-type 'application/simple-filter+xml'.
SIP entities compliant with this specification MUST support content-type 'application/simple-filter+xml'.
5.2. Notifier Processing of SUBSCRIBE Requests
5.2. Notifier Processing of SUBSCRIBE Requests
This section presents additional functionality required from the notifier when filters are used in the bodies of the SUBSCRIBE requests. Normal package-specific functionality is otherwise followed.
This section presents additional functionality required from the notifier when filters are used in the bodies of the SUBSCRIBE requests. Normal package-specific functionality is otherwise followed.
Khartabil, et al. Standards Track [Page 9] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 9] RFC 4660 Functional Description of Filtering September 2006
The notifier will examine the Content-Type header field and will return a 415 response if it does not understand the content type 'application/simple-filter+xml'.
The notifier will examine the Content-Type header field and will return a 415 response if it does not understand the content type 'application/simple-filter+xml'.
A 200-class response indicates that the subscription has been accepted, and the NOTIFY will be sent immediately. A "200" response indicates that the subscription has been accepted, the user is authorized, and the filter is accepted. A "202" response merely indicates that the subscription has been understood, but that the authorization may or may not have been granted. A "202" response also indicates that the filters have not been accepted yet. The acceptance of the filters MAY arrive in a subsequent NOTIFY.
A 200-class response indicates that the subscription has been accepted, and the NOTIFY will be sent immediately. A "200" response indicates that the subscription has been accepted, the user is authorized, and the filter is accepted. A "202" response merely indicates that the subscription has been understood, but that the authorization may or may not have been granted. A "202" response also indicates that the filters have not been accepted yet. The acceptance of the filters MAY arrive in a subsequent NOTIFY.
Procedures described in Section 5.4 are followed if an error is encountered.
Procedures described in Section 5.4 are followed if an error is encountered.
As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In such circumstances, a server MUST check that there are no filters addressed to the same resource or domain, and if they are, it MUST reject the SUBSCRIBE request with a "488" error response.
As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In such circumstances, a server MUST check that there are no filters addressed to the same resource or domain, and if they are, it MUST reject the SUBSCRIBE request with a "488" error response.
5.2.1. Request-URI vs. Filter URI
5.2.1. Request-URI vs. Filter URI
The subscriber may have chosen to leave the URI in the filter undefined. If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI.
The subscriber may have chosen to leave the URI in the filter undefined. If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI.
Similarly, the subscriber may have chosen to include a URI in the filter. In this case, the filter applies to all notifications sent with content associated with the resource with that URI for this subscription. If the Request-URI and the URI in the filter do not match, the filter may be ignored or rejected. URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).
Similarly, the subscriber may have chosen to include a URI in the filter. In this case, the filter applies to all notifications sent with content associated with the resource with that URI for this subscription. If the Request-URI and the URI in the filter do not match, the filter may be ignored or rejected. URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).
A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain. A notifier MUST ignore any filter using a 'domain' attribute containing a domain for which this notifier is not responsible. The notifier MUST NOT apply such a filter to any notification it sends. Notifiers belonging to the domain MUST apply the filter to all notifications it sends for that subscription, unless policy dictates otherwise.
A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain. A notifier MUST ignore any filter using a 'domain' attribute containing a domain for which this notifier is not responsible. The notifier MUST NOT apply such a filter to any notification it sends. Notifiers belonging to the domain MUST apply the filter to all notifications it sends for that subscription, unless policy dictates otherwise.
Khartabil, et al. Standards Track [Page 10] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 10] RFC 4660 Functional Description of Filtering September 2006
5.2.2. Changing Filters within a Dialog
5.2.2. Changing Filters within a Dialog
If a server receives a subscription refresh request with no filters specified (empty payload), it assumes that the client does not wish to update the filters. If it receives a subscription refresh with a filter containing the 'remove="true"' attribute, as defined in [5], the server assumes that the client is removing the filter identified by the filter ID.
If a server receives a subscription refresh request with no filters specified (empty payload), it assumes that the client does not wish to update the filters. If it receives a subscription refresh with a filter containing the 'remove="true"' attribute, as defined in [5], the server assumes that the client is removing the filter identified by the filter ID.
If the server receives a subscription refresh request with a filter that already exists (i.e., having the same filter ID), it interprets it as a replacement of the existing filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the server to assume that two filters are placed for the same resource.
If the server receives a subscription refresh request with a filter that already exists (i.e., having the same filter ID), it interprets it as a replacement of the existing filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the server to assume that two filters are placed for the same resource.
5.3. Notifier Generating of NOTIFY Requests
5.3. Notifier Generating of NOTIFY Requests
Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD retain the filter as long as the subscription persists. The filter MAY be incorporated within an existing subscription (in an active dialog) by sending a re-SUBSCRIBE that includes the filter in the body.
Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD retain the filter as long as the subscription persists. The filter MAY be incorporated within an existing subscription (in an active dialog) by sending a re-SUBSCRIBE that includes the filter in the body.
If the response sent to the SUBSCRIBE was a "202" and the "202" was chosen because the filter could not be accepted that time, the NOTIFY MAY be used to terminate the subscription if the filter is found unacceptable.
If the response sent to the SUBSCRIBE was a "202" and the "202" was chosen because the filter could not be accepted that time, the NOTIFY MAY be used to terminate the subscription if the filter is found unacceptable.
As described in [3], the NOTIFY message MAY contain a body that describes the state of the resource. This body is in one of the formats listed in the Accept header field of the SUBSCRIBE, or in the package-specific default if the Accept header field is omitted.
As described in [3], the NOTIFY message MAY contain a body that describes the state of the resource. This body is in one of the formats listed in the Accept header field of the SUBSCRIBE, or in the package-specific default if the Accept header field is omitted.
Based on the contents of a filter, the following processing occurs:
Based on the contents of a filter, the following processing occurs:
o A filter with only a <what> element will result in sending the
requested resource state information in that <what> element
whenever there is a change in the resource state.
o A filter with only a <what> element will result in sending the requested resource state information in that <what> element whenever there is a change in the resource state.
o A filter with only a <trigger> element will result in sending all
resource state information whenever there is a change in the
resource state that matches the triggers.
o A filter with only a <trigger> element will result in sending all resource state information whenever there is a change in the resource state that matches the triggers.
o A filter with <what> and <trigger> elements will result in sending
the requested resource state information in that <what> element
whenever there is a change in the resource state that matches the
triggers.
o A filter with <what> and <trigger> elements will result in sending the requested resource state information in that <what> element whenever there is a change in the resource state that matches the triggers.
Khartabil, et al. Standards Track [Page 11] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 11] RFC 4660 Functional Description of Filtering September 2006
When a filter is disabled (by setting the 'enabled' attribute to "false"), it means the same thing as the absence of that filter. That is, all state and state changes are reported by issuing a notification to the subscriber (assuming there are no other filters).
When a filter is disabled (by setting the 'enabled' attribute to "false"), it means the same thing as the absence of that filter. That is, all state and state changes are reported by issuing a notification to the subscriber (assuming there are no other filters).
When a filter is re-enabled (by setting the 'enabled' attribute to "true" or by omitting the 'enabled' attribute), the notifier behaves as if the filter has just been placed by the SUBSCRIBE request enabling it. Immediate NOTIFY rules, as stated in Section 5.3.1, apply.
When a filter is re-enabled (by setting the 'enabled' attribute to "true" or by omitting the 'enabled' attribute), the notifier behaves as if the filter has just been placed by the SUBSCRIBE request enabling it. Immediate NOTIFY rules, as stated in Section 5.3.1, apply.
5.3.1. Generation of NOTIFY Contents
5.3.1. Generation of NOTIFY Contents
If the NOTIFY being sent is the one sent immediately after a 2xx response to the original SUBSCRIBE, its contents MUST be populated according to the filter <what> element, unless the processing of the filters will take too long or the NOTIFY request is following a "202" response to the SUBSCRIBE request and is terminating the subscription. In the case that the filter is taking too long to process, the NOTIFY request being sent may be empty or may be populated with a pre-configured value as authorised to that subscriber. If applying the filter results in no content to be delivered, the NOTIFY MUST be sent with empty contents. If the filter contains <trigger> elements, the notifier ignores the trigger values when generating the first NOTIFY request.
If the NOTIFY being sent is the one sent immediately after a 2xx response to the original SUBSCRIBE, its contents MUST be populated according to the filter <what> element, unless the processing of the filters will take too long or the NOTIFY request is following a "202" response to the SUBSCRIBE request and is terminating the subscription. In the case that the filter is taking too long to process, the NOTIFY request being sent may be empty or may be populated with a pre-configured value as authorised to that subscriber. If applying the filter results in no content to be delivered, the NOTIFY MUST be sent with empty contents. If the filter contains <trigger> elements, the notifier ignores the trigger values when generating the first NOTIFY request.
The input to the content filter is a package-specific XML document (e.g., [7] and [9]) derived according to the package-specific specifications, (e.g., [8] and [10]).
The input to the content filter is a package-specific XML document (e.g., [7] and [9]) derived according to the package-specific specifications, (e.g., [8] and [10]).
The content is filtered according to the expressions in the <what> element of the filter. The expression indicates the delivered XML elements and/or attributes. Prefixes of the namespaces of the items of the XML document to be filtered must be expanded before applying the filter to the items.
The content is filtered according to the expressions in the <what> element of the filter. The expression indicates the delivered XML elements and/or attributes. Prefixes of the namespaces of the items of the XML document to be filtered must be expanded before applying the filter to the items.
The expression directly states the XML elements and attributes to be delivered in the NOTIFY, along with their values. In addition to the selected contents, the namespaces of all the selected items are also included in the NOTIFY. The XML elements and/or attributes indicated by the expression in the <what> element must be items that the subscriber is authorised to see. If they are not, the notifier policy dictates the behaviour of the notifier (which can ignore the filter, parts of the filter, or reject the filter completely). Implementers need to carefully consider such an implementation decision; the subscriber may not be aware of the authorised contents and therefore most likely will include a filter requesting unauthorised contents. It is therefore RECOMMENDED that notifiers
The expression directly states the XML elements and attributes to be delivered in the NOTIFY, along with their values. In addition to the selected contents, the namespaces of all the selected items are also included in the NOTIFY. The XML elements and/or attributes indicated by the expression in the <what> element must be items that the subscriber is authorised to see. If they are not, the notifier policy dictates the behaviour of the notifier (which can ignore the filter, parts of the filter, or reject the filter completely). Implementers need to carefully consider such an implementation decision; the subscriber may not be aware of the authorised contents and therefore most likely will include a filter requesting unauthorised contents. It is therefore RECOMMENDED that notifiers
Khartabil, et al. Standards Track [Page 12] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 12] RFC 4660 Functional Description of Filtering September 2006
just ignore the parts of the filter that are requesting unauthorised info (i.e., the filter in the <filter> element where the unauthorised contents are requested is ignored). If polite blocking is used by the notifier, the notifier may choose to deliver notifications containing bogus information in the unauthorised elements or attributes and applying the filter afterwards.
just ignore the parts of the filter that are requesting unauthorised info (i.e., the filter in the <filter> element where the unauthorised contents are requested is ignored). If polite blocking is used by the notifier, the notifier may choose to deliver notifications containing bogus information in the unauthorised elements or attributes and applying the filter afterwards.
The resultant XML document MUST be well formed and valid according to the XML schema. This means that all mandatory elements and attributes, along with their values, MUST be included in the XML document regardless of the expression. In other words, if the result of applying a filter on an XML document is a non-valid XML document, the notifier MUST add elements and attributes, along with their values, from the original XML document into the newly formulated one in order for it to be valid.
The resultant XML document MUST be well formed and valid according to the XML schema. This means that all mandatory elements and attributes, along with their values, MUST be included in the XML document regardless of the expression. In other words, if the result of applying a filter on an XML document is a non-valid XML document, the notifier MUST add elements and attributes, along with their values, from the original XML document into the newly formulated one in order for it to be valid.
5.3.2. Handling of Notification Triggering Rules
5.3.2. Handling of Notification Triggering Rules
There can be several <trigger> elements inside one <filter> element. If the criteria for any of the <trigger> elements are satisfied, a NOTIFY SHOULD be generated.
There can be several <trigger> elements inside one <filter> element. If the criteria for any of the <trigger> elements are satisfied, a NOTIFY SHOULD be generated.
The items (XML elements and/or attributes) indicated by the expression in the <changed> element, <added> element, or <removed> element must be items that the subscriber is authorised to access. If they are not, the notifier policy dictates the behaviour of the notifier (which can ignore the filter, parts of the filter, or reject the filter completely).
The items (XML elements and/or attributes) indicated by the expression in the <changed> element, <added> element, or <removed> element must be items that the subscriber is authorised to access. If they are not, the notifier policy dictates the behaviour of the notifier (which can ignore the filter, parts of the filter, or reject the filter completely).
5.4. Handling Abnormal Cases
5.4. Handling Abnormal Cases
In case of an invalid filter definition where the XML document of the filter is not aligned with the XML schema of the filter format [5], the notifier rejects the SUBSCRIBE request with a "488" response. A Warning header field in the response may give a better indication as to why the filters were not accepted. If the subscription was accepted with a "202" response but the invalid filter was discovered after that, a NOTIFY with a subscription-state of value 'terminated' is sent. An event-reason-value "badfilter", introduced here, of subexp-params [3] MAY be included.
In case of an invalid filter definition where the XML document of the filter is not aligned with the XML schema of the filter format [5], the notifier rejects the SUBSCRIBE request with a "488" response. A Warning header field in the response may give a better indication as to why the filters were not accepted. If the subscription was accepted with a "202" response but the invalid filter was discovered after that, a NOTIFY with a subscription-state of value 'terminated' is sent. An event-reason-value "badfilter", introduced here, of subexp-params [3] MAY be included.
In case of an erroneous expression in the filter definition, the notifier either ignores the filter definition or terminates the subscription.
In case of an erroneous expression in the filter definition, the notifier either ignores the filter definition or terminates the subscription.
If a <what> or <trigger> element is empty, the notifier proceeds as if the element did not exist.
If a <what> or <trigger> element is empty, the notifier proceeds as if the element did not exist.
Khartabil, et al. Standards Track [Page 13] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 13] RFC 4660 Functional Description of Filtering September 2006
6. XML Document Validation
6. XML Document Validation
The subscriber of the filter MUST ensure that the XML document inserted as the SUBSCRIBE request body is well formed and valid. The subscriber MUST NOT insert any extension elements or attributes into the XML document unless it has access to the extension schema and can validate the XML document. The XML document notifier MAY validate the XML document according to the schemas, including extension schemas, to which it has access that are applicable to this XML document.
The subscriber of the filter MUST ensure that the XML document inserted as the SUBSCRIBE request body is well formed and valid. The subscriber MUST NOT insert any extension elements or attributes into the XML document unless it has access to the extension schema and can validate the XML document. The XML document notifier MAY validate the XML document according to the schemas, including extension schemas, to which it has access that are applicable to this XML document.
7. Examples
7. Examples
The following sections include filtering examples for Presence and Watcher Information. The format of filter is according to [5].
The following sections include filtering examples for Presence and Watcher Information. The format of filter is according to [5].
7.1. Presence Specific Examples
7.1. Presence Specific Examples
This section describes three use cases where the presence information filtering solution is utilised [8]. In the first use case, the watcher is interested in getting messaging-specific information of a certain presentity. In the second use case, the watcher is interested in getting information about the communication means and contact addresses on which the presentity is currently available for communication. The third case shows how a presentity can request triggers to receive notifications.
This section describes three use cases where the presence information filtering solution is utilised [8]. In the first use case, the watcher is interested in getting messaging-specific information of a certain presentity. In the second use case, the watcher is interested in getting information about the communication means and contact addresses on which the presentity is currently available for communication. The third case shows how a presentity can request triggers to receive notifications.
Below is the presentity's presence information in PIDF [7]. It includes two tuples: one for the instant messaging and another for the voice-related information.
Below is the presentity's presence information in PIDF [7]. It includes two tuples: one for the instant messaging and another for the voice-related information.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="432sd"> <status> <basic>closed</basic> </status> <rpid:class>IM</rpid:class> <contact>im:presentity@example.com</contact> </tuple> <tuple id="thr76jk"> <status> <basic>open</basic> </status> <rpid:class>voice</rpid:class> <contact>tel:2224055555@example.com</contact>
Khartabil, et al. Standards Track [Page 14] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 14] RFC 4660 Functional Description of Filtering September 2006
</tuple>
</presence>
</tuple> </presence>
7.1.1. Subscriber Requests Messaging-Related Information
7.1.1. Subscriber Requests Messaging-Related Information
The subscriber initiates a subscription to the presentity's messaging (MMS, IM, and SMS) related presence information. The subscription includes the content limiting filter.
The subscriber initiates a subscription to the presentity's messaging (MMS, IM, and SMS) related presence information. The subscription includes the content limiting filter.
The filtered content is indicated with an expression. This expression selects the <basic> element and all the parent elements (i.e., the <status>, the <tuple>, and its root element), the <class> element, and the <contact> element. The filter matches if the <class> element contains "MMS", "SMS", or "IM".
The filtered content is indicated with an expression. This expression selects the <basic> element and all the parent elements (i.e., the <status>, the <tuple>, and its root element), the <class> element, and the <contact> element. The filter matches if the <class> element contains "MMS", "SMS", or "IM".
In this case, the notification includes the contents of the tuple that has the value "IM" in its <class> element.
In this case, the notification includes the contents of the tuple that has the value "IM" in its <class> element.
SUBSCRIBE request from the subscriber including filter:
SUBSCRIBE request from the subscriber including filter:
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
<?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:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:status/pidf:basic
</include>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/rpid:class
<?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:tuple[rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"]/pidf:status/pidf:basic </include> <include type="xpath"> //pidf:tuple[rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"]/rpid:class
Khartabil, et al. Standards Track [Page 15] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 15] RFC 4660 Functional Description of Filtering September 2006
</include>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:contact
</include>
</what>
</filter>
</filter-set>
</include> <include type="xpath"> //pidf:tuple[rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"]/pidf:contact </include> </what> </filter> </filter-set>
Notification to the subscriber:
Notification to the subscriber:
NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="432sd"> <status> <basic>closed</basic> </status> <rpid:class>IM</rpid:class> <contact>im:presentity@example.com</contact> </tuple> </presence>
7.1.2. Subscriber Fetches Information about "Open" Communication Means
7.1.2. Subscriber Fetches Information about "Open" Communication Means
The subscriber makes a subscription to the presentity's available communication means. The subscription includes the content-limiting filter.
The subscriber makes a subscription to the presentity's available communication means. The subscription includes the content-limiting filter.
The filtered content is indicated with an expression. This expression selects the <basic> element and all the parent elements (i.e., the <status>, the <tuple>, and its root element), the <class> element, and the <contact> element. The filter matches if the <basic> element's value is "open".
The filtered content is indicated with an expression. This expression selects the <basic> element and all the parent elements (i.e., the <status>, the <tuple>, and its root element), the <class> element, and the <contact> element. The filter matches if the <basic> element's value is "open".
Khartabil, et al. Standards Track [Page 16] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 16] RFC 4660 Functional Description of Filtering September 2006
In this case, the notification returns the contents of the tuple that has the value "open" inside the <status> element.
In this case, the notification returns the contents of the tuple that has the value "open" inside the <status> element.
SUBSCRIBE request from the subscriber including filter:
SUBSCRIBE request from the subscriber including filter:
SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
<?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:tuple/pidf:status[pidf:basic="open"]/pidf:basic
</include>
<include type="xpath">
//pidf:tuple[pidf:status/pidf:basic="open"]/rpid:class
</include>
<include type="xpath">
//pidf:tuple[pidf:status/pidf:basic="open"]/pidf:contact
</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="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:tuple/pidf:status[pidf:basic="open"]/pidf:basic </include> <include type="xpath"> //pidf:tuple[pidf:status/pidf:basic="open"]/rpid:class </include> <include type="xpath"> //pidf:tuple[pidf:status/pidf:basic="open"]/pidf:contact </include> </what> </filter> </filter-set>
Notification to the subscriber:
Notification to the subscriber:
NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence
NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence
Khartabil, et al. Standards Track [Page 17] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 17] RFC 4660 Functional Description of Filtering September 2006
Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="thr76jk"> <status> <basic>open</basic> </status> <rpid:class>voice</rpid:class> <contact>tel:2224055555@example.com</contact> </tuple> </presence>
7.1.3. Subscriber Requests Notifications When Presentity's Status
Changes
7.1.3. Subscriber Requests Notifications When Presentity's Status Changes
The subscriber subscribes to the presentity, specifying in the filter that it wants notifications only when the <basic> element has changed to value "open".
The subscriber subscribes to the presentity, specifying in the filter that it wants notifications only when the <basic> element has changed to value "open".
SUBSCRIBE request from the subscriber including filter:
SUBSCRIBE request from the subscriber including filter:
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
<?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
<?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
Khartabil, et al. Standards Track [Page 18] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 18] RFC 4660 Functional Description of Filtering September 2006
</changed>
</trigger>
</filter>
</filter-set>
</changed> </trigger> </filter> </filter-set>
At some point during the subscription, a second PIDF document is created with both tuples having a status of "closed":
At some point during the subscription, a second PIDF document is created with both tuples having a status of "closed":
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>closed</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="432sd"> <status> <basic>closed</basic> </status> <rpid:class>IM</rpid:class> <contact>im:presentity@example.com</contact> </tuple> <tuple id="thr76jk"> <status> <basic>closed</basic> </status> <rpid:class>voice</rpid:class> <contact>tel:2224055555@example.com</contact> </tuple> </presence>
A NOTIFY is not sent to the subscriber in this case.
A NOTIFY is not sent to the subscriber in this case.
Now, a third PIDF document is created when the IM status changes to "open":
Now, a third PIDF document is created when the IM status changes to "open":
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>open</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>closed</basic>
</status>
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="432sd"> <status> <basic>open</basic> </status> <rpid:class>IM</rpid:class> <contact>im:presentity@example.com</contact> </tuple> <tuple id="thr76jk"> <status> <basic>closed</basic> </status>
Khartabil, et al. Standards Track [Page 19] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 19] RFC 4660 Functional Description of Filtering September 2006
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
<rpid:class>voice</rpid:class> <contact>tel:2224055555@example.com</contact> </tuple> </presence>
Notification containing both tuples is sent to the subscriber in this case:
Notification containing both tuples is sent to the subscriber in this case:
NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:presentity@example.com">
<tuple id="432sd">
<status>
<basic>closed</basic>
</status>
<rpid:class>IM</rpid:class>
<contact>im:presentity@example.com</contact>
</tuple>
<tuple id="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="432sd"> <status> <basic>closed</basic> </status> <rpid:class>IM</rpid:class> <contact>im:presentity@example.com</contact> </tuple> <tuple id="thr76jk"> <status> <basic>open</basic> </status> <rpid:class>voice</rpid:class> <contact>tel:2224055555@example.com</contact> </tuple> </presence>
Khartabil, et al. Standards Track [Page 20] RFC 4660 Functional Description of Filtering September 2006
Khartabil, et al. Standards Track [Page 20] RFC 4660 Functional Description of Filtering September 2006
7.2. Watcher Information Specific Examples
7.2. Watcher Information Specific Examples
The examples in this section use the winfo template-package with the presence event package [10].
The examples in this section use the winfo template-package with the presence event package [10].
Watcher information to a Presentity:
Watcher information to a Presentity:
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="active"
id="sr8fdsj"
duration-subscribed="509"
expiration="20"
event="approved">sip:watcherA@example.com"</watcher>
<watcher status="pending"
id="sr8fdsj"
duration-subscribed="501"
expiration="100"
event="subscribe">sip:watcherB@example.com"</watcher>
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="500"
expiration="0"
event="rejected">sip:watcherC@example.com"</watcher>
<watcher status="active"
id="sr8fdsj"
duration-subscribed="20"
expiration="30"
event="approved">sip:watcherD@example.com"</watcher>
</watcher-list>
</watcherinfo>
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" state="full"> <watcher-list resource="sip:presentity@example.com" package="presence"> <watcher status="active" id="sr8fdsj" duration-subscribed="509" expiration="20" event="approved">sip:watcherA@example.com"</watcher> <watcher status="pending" id="sr8fdsj" duration-subscribed="501" expiration="100" event="subscribe">sip:watcherB@example.com"</watcher> <watcher status="terminated" id="sr8fdsj" duration-subscribed="500" expiration="0" event="rejected">sip:watcherC@example.com"</watcher> <watcher status="active" id="sr8fdsj" duration-subscribed="20" expiration="30" event="approved">sip:watcherD@example.com"</watcher> </watcher-list> </watcherinfo>
Khartabil, et al. Standards Track [Page 21] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[21ページ]RFC4660の機能的な記述
7.2.1. Watcher Subscriber Makes Subscription to Get All the Information
about Active Watchers
7.2.1. ウォッチャーの加入者は、アクティブなウォッチャーに関するすべての情報を得るために購読をします。
SUBSCRIBE request from the presentity including the filter:
登録、フィルタを含むpresentityから以下を要求してください。
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence.winfo Contact: sip:presentity@client.example.com Content-Type: application/simple-filter+xml Content-Length: ...
一口: 登録、 presentity@example.com Via: 一口/2.0/TCP client.example.com:5060; ブランチ=z9hG4bKxjfdsjfk To: <一口: presentity@example.com 、gt;、From: <一口: presentity@example.com 、gt;、; IDに電話をして、: 12341111にタグ付けをしてください: 32432udfidfjmk342 Cseq: 1が申し込まれる、期限が切れます: 3600年の出来事: Presence.winfo接触: 一口: presentity@client.example.com コンテントタイプ: 簡単なフィルタ+xml Contentのアプリケーション/長さ: ...
<?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[@package="presence"]/
wi:watcher[@status="active"]
</include>
</what>
</filter>
</filter-set>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチフィルタ..セット..等しい..つぼ..簡単..フィルタ..結合..拘束力がある..接頭語..つぼ..つぼ..結合..フィルタ..イド..等しい..一口..インクルード..ウォッチャー..リスト..等しい..存在..ウォッチャー..能動態..インクルード..フィルターにかける..フィルタ..セット
Notification to the subscriber:
加入者への通知:
NOTIFY sip:presentity@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: sip:presentity@example.com;tag:12341111 From: sip:presentity@example.com;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Contact: sip:presentity@server.example.com Event: Presence.winfo
NOTIFY一口: presentity@client.example.com SIP/2.0Via: 一口/2.0/TCP presence.example.com:5060; ブランチ=z9hG4bKxjfder To: 一口: presentity@example.com;tag :12341111From: 一口: presentity@example.com;tag :232321Call-ID: 32432udfidfjmk342 Cseq: 1 接触に通知してください: 一口: presentity@server.example.com Event: Presence.winfo
Content-Type: application/watcherinfo+xml Content-Length: ...
コンテントタイプ: アプリケーション/watcherinfo+xml Content長さ: ...
Khartabil, et al. Standards Track [Page 22] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[22ページ]RFC4660の機能的な記述
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="active"
id="sr8fdsj"
duration-subscribed="509"
expiration="20"
event="approved">sip:watcherA@example.com"</watcher>
<watcher status="active"
id="sr8fdsj"
duration-subscribed="20"
expiration="30"
event="approved">sip:watcherD@example.com"</watcher>
</watcher-list>
</watcherinfo>
<?xmlバージョン= 「1インチ?」「完全な「><ウォッチャーリストリソース=」一口: 「0インチの状態=」という><watcherinfo xmlns=「つぼ:ietf:params:xml:ナノ秒: watcherinfo」バージョン= presentity@example.com 」パッケージ=「存在「><ウォッチャー状態=」アクティブな」イド="sr8fdsj"持続時間で申し込まれた=「509」満了=「20インチの出来事=」は「>一口: watcherA@example 」を承認しました; 「com「</ウォッチャー><ウォッチャー状態=」アクティブな」イド="sr8fdsj"持続時間で申し込まれた=「20インチの満了=」の30インチの出来事が等しい、「「>一口: watcherD@example.com 」を承認する、lt;、/ウォッチャー></ウォッチャーリスト></watcherinfoな>、」
7.2.2. Watcher Subscriber Requests Information of Watchers with
Specific Subscription Duration Conditions
7.2.2. 特定の購読持続時間状態をもっているウォッチャーのウォッチャー加入者要求情報
SUBSCRIBE request from the presentity including the filter:
登録、フィルタを含むpresentityから以下を要求してください。
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com>;tag:12341111 From: <sip:presentity@example.com> Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 0 Event: Presence.winfo Contact: <sip:presentity@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
一口: 登録、 presentity@example.com Via: 一口/2.0/TCP client.example.com:5060; ブランチ=z9hG4bKxjfdsjfk To: <一口: presentity@example.com 、gt;、;: 12341111From:にタグ付けをしてください <一口: presentity@example.com 、gt;、呼び出しID: 32432udfidfjmk342 Cseq: 1が申し込まれる、期限が切れます: 0出来事: Presence.winfo接触: <一口: presentity@client.example.com 、gt;、コンテントタイプ: 簡単なフィルタ+xml Contentのアプリケーション/長さ: ...
<?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[@package="presence"]/
wi:watcher[@duration-subscribed>500]
</include>
</what>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチフィルタ..セット..等しい..つぼ..簡単..フィルタ..結合..拘束力がある..接頭語..つぼ..つぼ..結合..フィルタ..イド..等しい..一口..インクルード..ウォッチャー..リスト..等しい..存在..ウォッチャー..申し込む..インクルード
Khartabil, et al. Standards Track [Page 23] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[23ページ]RFC4660の機能的な記述
</filter>
</filter-set>
フィルタ></フィルタ</セット>。
Notification to the subscriber:
加入者への通知:
NOTIFY sip:presentity@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: sip:presentity@example.com;tag:12341111 From: sip:presentity@example.com;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Contact: sip:presentity@server.example.com Event: Presence.winfo
NOTIFY一口: presentity@client.example.com SIP/2.0Via: 一口/2.0/TCP presence.example.com:5060; ブランチ=z9hG4bKxjfder To: 一口: presentity@example.com;tag :12341111From: 一口: presentity@example.com;tag :232321Call-ID: 32432udfidfjmk342 Cseq: 1 接触に通知してください: 一口: presentity@server.example.com Event: Presence.winfo
Content-Type: application/watcherinfo+xml Content-Length: ...
コンテントタイプ: アプリケーション/watcherinfo+xml Content長さ: ...
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="active"
id="sr8fdsj"
duration-subscribed="509"
expiration="20"
event="approved">sip:watcherA@example.com"</watcher>
<watcher status="pending"
id="sr8fdsj"
duration-subscribed="501"
expiration="100"
event="subscribe">sip:watcherB@example.com"</watcher>
</watcher-list>
</watcherinfo>
<?xmlバージョン= 「1インチ?」「完全な「><ウォッチャーリストリソース=」一口: 「0インチの状態=」という><watcherinfo xmlns=「つぼ:ietf:params:xml:ナノ秒: watcherinfo」バージョン= presentity@example.com 」パッケージ=「存在「><ウォッチャー状態=」アクティブな」イド="sr8fdsj"持続時間で申し込まれた=「509」満了=「20インチの出来事=」は「>一口: watcherA@example 」を承認しました; 「未定のcom「</ウォッチャー><ウォッチャー状態=」」イドが"sr8fdsj"持続時間で申し込まれた=「501」満了=「100」出来事=と等しい、「「>一口: watcherB@example.com 」を申し込んでください、lt;、/ウォッチャー></ウォッチャーリスト></watcherinfoな>、」
7.2.3. Watcher Subscriber Requests Specific Watcher Info on Specific
Triggers
7.2.3. ウォッチャーの加入者は特定の引き金に関する特定のウォッチャーインフォメーションを要求します。
This filter selects watcher information notifications [9] to be sent when the pending subscription status has changed from "pending" to "terminated". In the notification, only the watchers that have a status of "terminated" and an event of "rejected" are included.
このフィルタは、未定の購読状態が送ったとき、「終えられること」に「未定」の状態で変えて、送るためにウォッチャー情報通知[9]を選択します。 通知では、「終えられること」の状態と「拒絶されること」の出来事を持っているウォッチャーだけが含まれています。
SUBSCRIBE request from the Watcher Subscriber including the filter:
登録、フィルタを含むWatcher Subscriberから以下を要求してください。
SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com>;tag:12341111
一口: 登録、 presentity@example.com Via: 一口/2.0/TCP client.example.com:5060; ブランチ=z9hG4bKxjfdsjfk To: <一口: presentity@example.com 、gt;、;: 12341111にタグ付けをしてください
Khartabil, et al. Standards Track [Page 24] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[24ページ]RFC4660の機能的な記述
From: <sip:presentity@example.com> Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 0 Event: Presence.winfo Contact: <sip:presentity@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...
From: <一口: presentity@example.com 、gt;、呼び出しID: 32432udfidfjmk342 Cseq: 1が申し込まれる、期限が切れます: 0出来事: Presence.winfo接触: <一口: presentity@client.example.com 、gt;、コンテントタイプ: 簡単なフィルタ+xml Contentのアプリケーション/長さ: ...
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-winfo-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[@package="presence"]/
wi:watcher[@status="terminated" and @event="rejected"]
</include>
</what>
<trigger>
<changed from="pending"
to="terminated">
//@status
</changed>
</trigger>
</filter>
</filter-set>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><フィルタセットxmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: 簡単なwinfoフィルタ、「>の<ナノ秒を拘束力がある接頭語=「wiな」つぼ=の「つぼ:ietf:params:xml:ナノ秒: watcherinfo」/>ナノ秒</結合><フィルタイド=「123」がuriする><ナノ秒結合が「一口: presentity@example.com 」と等しい、gt;、<、何という><インクルード>/wi:、」; watcherinfo/wi: watcher-list@package は「存在」/wiと等しいです: watcher@status =が「終わっ」て、@event=「拒絶された」</インクルード></が等しいように「未定」の=から変えられたすべての><引き金の><を終わらせた、「終わり、「> //@status 、lt;、/が、より></こぎれいな>フィルタ></フィルタ</セット>を変えた、」
At some point during the subscription, a second Winfo document is created due to some change:
購読の間の何らかの時点では、2番目のWinfoドキュメントはいくらかの変化のため作成されます:
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="active"
id="sr8fdsj"
duration-subscribed="509"
expiration="20"
event="approved">sip:watcherA@example.com"</watcher>
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="501"
expiration="100"
<?xmlバージョン= 「1インチ?」「完全な「><ウォッチャーリストリソース=」一口: 「0インチの状態=」という><watcherinfo xmlns=「つぼ:ietf:params:xml:ナノ秒: watcherinfo」バージョン= presentity@example.com 」パッケージ=「存在「><ウォッチャー状態=」能動態」イド="sr8fdsj"持続時間で申し込まれた=「509」満了=「20インチの出来事=」が「>一口: watcherA@example.com 」を承認した、lt;、/ウォッチャー><ウォッチャー状態=はイド="sr8fdsj"持続時間で申し込まれた=「501」満了=「100」を「終えました」。
Khartabil, et al. Standards Track [Page 25] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[25ページ]RFC4660の機能的な記述
event="rejected">sip:watcherB@example.com"</watcher>
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="500"
expiration="0"
event="rejected">sip:watcherC@example.com"</watcher>
<watcher status="active"
id="sr8fdsj"
duration-subscribed="20"
expiration="30"
event="approved">sip:watcherD@example.com"</watcher>
</watcher-list>
</watcherinfo>
出来事=、「「>一口: watcherB@example.com 」を拒絶する、lt;、「終えられた」イド="sr8fdsj"持続時間で申し込まれた=「500」満了=/ウォッチャー><ウォッチャー状態=「0インチの出来事=」が「>一口: watcherC@example.com 」を拒絶した、lt;、/ウォッチャー><ウォッチャー状態=「能動態」イド="sr8fdsj"持続時間で申し込まれた=「20インチの満了=」の30インチの出来事が等しい、「「>一口: watcherD@example.com 」を承認する、lt;、/ウォッチャー></ウォッチャーリスト></watcherinfoな>、」
Notification to the subscriber is created, taking into account the <trigger> and <what> elements:
どんな>要素の<引き金の>と<を考慮に入れて、加入者への通知は作成されます:
NOTIFY sip:presentity@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: sip:presentity@example.com;tag:12341111 From: sip:presentity@example.com;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Contact: sip:presentity@server.example.com Event: Presence.winfo
NOTIFY一口: presentity@client.example.com SIP/2.0Via: 一口/2.0/TCP presence.example.com:5060; ブランチ=z9hG4bKxjfder To: 一口: presentity@example.com;tag :12341111From: 一口: presentity@example.com;tag :232321Call-ID: 32432udfidfjmk342 Cseq: 1 接触に通知してください: 一口: presentity@server.example.com Event: Presence.winfo
Content-Type: application/watcherinfo+xml Content-Length: ...
コンテントタイプ: アプリケーション/watcherinfo+xml Content長さ: ...
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:presentity@example.com"
package="presence">
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="501"
expiration="100"
event="rejected">sip:watcherB@example.com"</watcher>
<watcher status="terminated"
id="sr8fdsj"
duration-subscribed="500"
expiration="0"
event="rejected">sip:watcherC@example.com"</watcher>
</watcher-list>
</watcherinfo>
<?xmlバージョン= 「1インチ?」「完全な「><ウォッチャーリストリソース=」一口: 「0インチの状態=」という><watcherinfo xmlns=「つぼ:ietf:params:xml:ナノ秒: watcherinfo」バージョン= presentity@example.com 」パッケージ=「存在「><ウォッチャー状態=」は終わった」イド="sr8fdsj"持続時間で申し込まれた=「501」満了が「100」出来事=と等しい、「「>一口: watcherB@example 。」拒絶されて、; 「com「</ウォッチャー><ウォッチャー状態=」は終わった」イド="sr8fdsj"持続時間で申し込まれた=「500」満了=「0インチの出来事=」が「>一口: watcherC@example.com 」を拒絶した、lt;、/ウォッチャー></ウォッチャーリスト></watcherinfoな>。
Khartabil, et al. Standards Track [Page 26] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[26ページ]RFC4660の機能的な記述
8. Security Considerations
8. セキュリティ問題
The presence of filters in the body of a SIP message has 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 authorized. Authentication can be achieved using the Digest Authentication mechanism described in [2]. The authorisation decision is based on the permissions that the resource (notifier) has given to the watcher. An example of such auhorisation policy can be found in [11].
SIPメッセージのボディーでのフィルタの存在は要求がサーバで扱われる方法に重要な影響を与えます。その結果、この拡大を含むメッセージが認証されて、認可されるのは、特に重要です。 [2]で説明されたDigest Authenticationメカニズムを使用することで認証を達成できます。 リソース(notifier)がウォッチャーに与えられていたという認可決定は許容に基づいています。 [11]でそのようなauhorisation方針に関する例を見つけることができます。
Processing of requests and looking up filters requires set operations and searches, which can require some amount of computation. This enables a DoS attack whereby a user can send requests with substantial numbers of messages with large contents, in the hopes of overloading the server. To counter this, the server can establish a limit on the number of occurrences of the <what>, <changed>, <added>, and <removed> elements that are allowed in the filters. A default limit of 40 is RECOMMENDED; however, servers may raise or lower the limit depending upon their specific engineered capacity.
要求とフィルタを見上げる処理は集合演算と検索を必要とします。(検索はいくらかの量の計算を必要とすることができます)。 これは大きいコンテンツがあるかなりの数のメッセージでユーザが要求を送ることができるDoS攻撃を可能にします、サーバを積みすぎるという望みで。これを打ち返すために、サーバは<の反復回数における限界を確立できます。どんな>、<は>を変えたか、そして、<は>を加えました、そして、<はフィルタに許容されている>要素を取り除きました。 40のデフォルト限界はRECOMMENDEDです。 しかしながら、サーバは、それらの特定の設計された容量に依存する限界を、上げるか、または下げるかもしれません。
Requests can reveal sensitive information about a User Agent's (UA's) capabilities. If this information is sensitive, it SHOULD be encrypted using SIP S/MIME capabilities [6]. All package-specific security measures MUST be followed.
要求はUserエージェントの(UA)の能力に関する機密情報を明らかにすることができます。 情報はこれであるなら機密であり、それはSHOULDです。SIP S/MIME能力[6]を使用することで、コード化されてください。 すべてのパッケージ特有の安全策に従わなければなりません。
Propagating filters in SUBSCRIBE requests to foreign domains reveals sensitive information about a user's resource lists. It is therefore required that an RLS does not forward a filter if that filter is addressed to a resource that is under the administrative domain of the RLS, but that is not on the resource list. Section 4.1 shows an example where such a scenario can occur.
フィルタを伝播する、登録、ユーザのリソースリストの機密の情報を外国ドメイン啓示に要求します。 したがって、そのフィルタがRLSの管理ドメインの下にありますが、リソースリストにないリソースは記述されるなら、RLSがフィルタを進めないのが必要です。 セクション4.1は、そのようなシナリオがどこに起こることができるかを例に示します。
Note that a filtered document located at a subscriber may project false reality. For example, if a subscriber asked to be notified when a resource has changed his presence state from "closed" to "open" but not from "open" to "closed", then the subscriber may afterwards be under the false impression that the resource's presence state is "open", even long after the resource has changed it to "closed". Therefore, subscribers need to be sure what they put in a filter, understand what they asked for, and be prepared to be out of sync with the real state of a resource.
加入者に位置するフィルターにかけることのドキュメントが誤った現実を映し出すかもしれないことに注意してください。 例えば、加入者が、リソースが彼の存在を変えたとき、通知されるように頼んだなら、「閉じられる」よりリソースの存在状態が「開いている」という間違った印象でいるように「戸外」にもかかわらず、加入者がその後そうするかもしれない少しの「戸外」から「閉じられない」までのその時にも述べないでください、リソースがそれを「閉じられること」に変えたずっと後にさえ。 したがって、加入者は、彼らがフィルタに何を置くかを確信していて、彼らが何を求めたかを理解して、リソースの実況と同期しているように準備される必要があります。
Khartabil, et al. Standards Track [Page 27] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[27ページ]RFC4660の機能的な記述
9. IANA Considerations
9. IANA問題
A new event-reason-value "badfilter" is defined to represent the event where the filter is not well formed and/or not accepted. No IANA registration is required for this value.
新しいイベント理由価値の"badfilter"は、フィルタがよく形成されない、またそして/または、受け入れられないところに出来事を表すために定義されます。 IANA登録は全くこの値に必要ではありません。
10. Acknowledgements
10. 承認
The authors would like to thank George Foti, Tim Moran, Sreenivas Addagatla, Juha Kalliokulju, Jari Urpalainen, and Mary Barnes for their valuable input.
作者は彼らの貴重な入力についてジョージFoti、ティム・モラン、Sreenivas Addagatla、ユハKalliokulju、ヤリUrpalainen、およびメアリ・バーンズに感謝したがっています。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] 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.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[4] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4663, September 2006.
[4] ローチ、A.B.、キャンベル、B.、およびJ.ローゼンバーグ、「リソースのためのセッション開始プロトコル(一口)イベント通知拡張子は記載します」、RFC4663、2006年9月。
[5] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena,
"An Extensible Markup Language (XML)-Based Format for Event
Notification Filtering", RFC 4661, September 2006.
[5]Khartabil、H.、Leppanen、E.、Lonnfors、M.、およびJ.コスタ-レケナ、「イベント通知フィルタリングのための拡張マークアップ言語の(XML)ベースの形式」、RFC4661(2006年9月)。
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[6]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
11.2. Informative References
11.2. 有益な参照
[7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004.
[7] 菅野、H.、藤本、S.、Klyne、G.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。
[8] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
Khartabil, et al. Standards Track [Page 28] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[28ページ]RFC4660の機能的な記述
[9] Rosenberg, J., "An Extensible Markup Language (XML) Based Format
for Watcher Information", RFC 3858, August 2004.
[9] ローゼンバーグ、J.、「拡張マークアップ言語(XML)はウォッチャー情報のための形式を基礎づけた」RFC3858、2004年8月。
[10] Rosenberg, J., "A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[10] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のためのウォッチャー情報イベントテンプレートパッケージ」、RFC3857、2004年8月。
[11] Rosenberg, J., "Presence Authorization Rules", Work in Progress,
June 2006.
[11] ローゼンバーグ、J.が進歩、2006年6月に働くのを「存在認可は統治します」。
Khartabil, et al. Standards Track [Page 29] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[29ページ]RFC4660の機能的な記述
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 30] RFC 4660 Functional Description of Filtering September 2006
Khartabil、他 2006年9月をフィルターにかける標準化過程[30ページ]RFC4660の機能的な記述
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 31]
Khartabil、他 標準化過程[31ページ]
一覧
スポンサーリンク
