<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"



Khartabil, et al.           Standards Track                    [Page 25]

RFC 4660          Functional Description of Filtering     September 2006


               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>

   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

   Content-Type: application/watcherinfo+xml
   Content-Length: ...

   <?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>





Khartabil, et al.           Standards Track                    [Page 26]

RFC 4660          Functional Description of Filtering     September 2006


8.  Security Considerations

   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].

   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.

   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.

   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.

   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


9.  IANA Considerations

   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.

10.  Acknowledgements

   The authors would like to thank George Foti, Tim Moran, Sreenivas
   Addagatla, Juha Kalliokulju, Jari Urpalainen, and Mary Barnes for
   their valuable input.

11.  References

11.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [3]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [4]  Roach, A.B., Campbell, B., and J. Rosenberg, "A Session
        Initiation Protocol (SIP) Event Notification Extension for
        Resource Lists", RFC 4663, September 2006.

   [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.

   [6]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Message Specification", RFC 3851, July
        2004.

11.2.  Informative References

   [7]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
        J. Peterson, "Presence Information Data Format (PIDF)", RFC
        3863, August 2004.

   [8]  Rosenberg, J., "A Presence Event Package for the Session
        Initiation Protocol (SIP)", RFC 3856, August 2004.





Khartabil, et al.           Standards Track                    [Page 28]

RFC 4660          Functional Description of Filtering     September 2006


   [9]  Rosenberg, J., "An Extensible Markup Language (XML) Based Format
        for Watcher Information", RFC 3858, August 2004.

   [10] Rosenberg, J., "A Watcher Information Event Template-Package for
        the Session Initiation Protocol (SIP)", RFC 3857, August 2004.

   [11] Rosenberg, J., "Presence Authorization Rules", Work in Progress,
        June 2006.











































Khartabil, et al.           Standards Track                    [Page 29]

RFC 4660          Functional Description of Filtering     September 2006


Authors' Addresses

   Hisham Khartabil
   Telio
   P.O. Box 1203 Vika
   Oslo
   Norway

   Phone: +47 2167 3544
   EMail: hisham.khartabil@telio.no


   Eva Leppanen
   Nokia
   P.O BOX 785
   Tampere
   Finland

   Phone: +358 7180 77066
   EMail: eva-maria.leppanen@nokia.com


   Mikko Lonnfors
   Nokia
   P.O BOX 321
   Helsinki
   Finland

   Phone: + 358 71800 8000
   EMail: mikko.lonnfors@nokia.com


   Jose Costa-Requena
   Nokia
   P.O. Box 321
   FIN-00045 NOKIA GROUP
   FINLAND

   Phone: +358 71800 8000
   EMail: jose.costa-requena@nokia.com











Khartabil, et al.           Standards Track                    [Page 30]

RFC 4660          Functional Description of Filtering     September 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   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.

   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.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).