[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-simple-xcap-auth-usage) 00 01 02 03 04 05 06 07 08 09 10 RFC 5025

SIMPLE                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: April 27, 2006                                 October 24, 2005


                      Presence Authorization Rules
                  draft-ietf-simple-presence-rules-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Authorization is a key function in presence systems.  Authorization
   policies, also known as authorization rules, specify what presence
   information can be given to which watchers, and when.  This
   specification defines an Extensible Markup Language (XML) document
   format for expressing presence authorization rules.  Such a document
   can be manipulated by clients using the XML Configuration Access
   Protocol (XCAP), although other techniques are permitted.





Rosenberg                Expires April 27, 2006                 [Page 1]


Internet-Draft           Presence Authorization             October 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Structure of Presence Authorization Documents  . . . . . . .   4
     3.1  Conditions . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.1  Identity . . . . . . . . . . . . . . . . . . . . . . .   5
         3.1.1.1  Acceptable Forms of Authentication . . . . . . . .   5
         3.1.1.2  Computing a URI for the Watcher  . . . . . . . . .   6
         3.1.1.3  Computing a SIP URI from the id attribute  . . . .   7
       3.1.2  Sphere . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2  Actions  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.1  Subscription Handling  . . . . . . . . . . . . . . . .   8
     3.3  Transformations  . . . . . . . . . . . . . . . . . . . . .  10
       3.3.1  Providing Access to Data Component Elements  . . . . .  10
         3.3.1.1  Device Information . . . . . . . . . . . . . . . .  10
         3.3.1.2  Person Information . . . . . . . . . . . . . . . .  11
         3.3.1.3  Service Information  . . . . . . . . . . . . . . .  12
       3.3.2  Providing Access to Presence Attributes  . . . . . . .  13
         3.3.2.1  Provide Activities . . . . . . . . . . . . . . . .  13
         3.3.2.2  Provide Class  . . . . . . . . . . . . . . . . . .  13
         3.3.2.3  Provide Device ID  . . . . . . . . . . . . . . . .  14
         3.3.2.4  Provide Mood . . . . . . . . . . . . . . . . . . .  14
         3.3.2.5  Provide Place-is . . . . . . . . . . . . . . . . .  14
         3.3.2.6  Provide Place-type . . . . . . . . . . . . . . . .  14
         3.3.2.7  Provide Privacy  . . . . . . . . . . . . . . . . .  14
         3.3.2.8  Provide Relationship . . . . . . . . . . . . . . .  14
         3.3.2.9  Provide Sphere . . . . . . . . . . . . . . . . . .  15
         3.3.2.10   Provide Status-Icon  . . . . . . . . . . . . . .  15
         3.3.2.11   Provide Time-Offset  . . . . . . . . . . . . . .  15
         3.3.2.12   Provide User-Input . . . . . . . . . . . . . . .  15
         3.3.2.13   Provide Note . . . . . . . . . . . . . . . . . .  16
         3.3.2.14   Provide Unknown Attribute  . . . . . . . . . . .  16
         3.3.2.15   Provide All Attributes . . . . . . . . . . . . .  17
   4.   When to Apply the Authorization Policies . . . . . . . . . .  17
   5.   Example Document . . . . . . . . . . . . . . . . . . . . . .  17
   6.   XML Schema . . . . . . . . . . . . . . . . . . . . . . . . .  18
   7.   Schema Extensibility . . . . . . . . . . . . . . . . . . . .  21
   8.   XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . .  21
     8.1  Application Unique ID  . . . . . . . . . . . . . . . . . .  21
     8.2  Structure of Permission Statements . . . . . . . . . . . .  21
     8.3  Additional Constraints . . . . . . . . . . . . . . . . . .  21
     8.4  Naming Conventions . . . . . . . . . . . . . . . . . . . .  21
     8.5  Authorization Policies . . . . . . . . . . . . . . . . . .  21
     8.6  XML Schema . . . . . . . . . . . . . . . . . . . . . . . .  22
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  22
   10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  22
     10.1   XCAP Application Usage ID  . . . . . . . . . . . . . . .  22



Rosenberg                Expires April 27, 2006                 [Page 2]


Internet-Draft           Presence Authorization             October 2005


     10.2   URN Sub-Namespace Registration . . . . . . . . . . . . .  22
     10.3   XML Schema Registrations . . . . . . . . . . . . . . . .  23
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  23
     11.1   Normative References . . . . . . . . . . . . . . . . . .  23
     11.2   Informative References . . . . . . . . . . . . . . . . .  25
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  25
        Intellectual Property and Copyright Statements . . . . . . .  27












































Rosenberg                Expires April 27, 2006                 [Page 3]


Internet-Draft           Presence Authorization             October 2005


1.  Introduction

   The Session Initiation Protocol (SIP) for Instant Messaging and
   Presence (SIMPLE) specifications allow a user, called a watcher, to
   subscribe to another user, called a presentity [20], in order to
   learn their presence information [23].  This subscription is handled
   by a presence agent.  However, presence information is sensitive, and
   a presence agent needs authorization from the presentity prior to
   handing out presence information.  As such, a presence authorization
   document format is needed.  This specification defines a format for
   such a document, called a presence authorization document.

   [12] specifies a framework for representing authorization policies,
   and is applicable to systems such as geo-location and presence.  This
   framework is used as the basis for presence authorization documents.
   In the framework, an authorization policy is a set of rules.  Each
   rule contains conditions, actions, and transformations.  The
   conditions specify under what conditions the rule is to be applied to
   presence server processing.  The actions element tells the server
   what actions to take.  The transformations element indicates how the
   presence data is to be manipulated before being presented to that
   watcher, and as such, defines a privacy filtering operation. [12]
   identifies a small number of specific conditions common to presence
   and location services, and leaves it to other specifications, such as
   this one, to fill in usage specific details.

   A presence authorization document can be manipulated by clients using
   several means.  One such mechanism is the XML Configuration Access
   Protocol (XCAP) [2].  This specification defines the details
   necessary for using XCAP to manage presence authorization documents.

2.  Terminology

   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.

3.  Structure of Presence Authorization Documents

   A presence authorization document is an XML document, formatted
   according to the schema defined in [12].  Presence authorization
   documents inherit the MIME type of common policy documents,
   application/auth-policy+xml.  As described in [12], this document is
   composed of three parts - conditions, actions, and transformations.
   Each action or transformation, which is also called a permission, has
   the property of being a positive grant of information to the watcher.
   As a result, there is a well-defined mechanism for combining actions



Rosenberg                Expires April 27, 2006                 [Page 4]


Internet-Draft           Presence Authorization             October 2005


   and transformations obtained from several sources.  This mechanism is
   privacy safe, since the lack of any action or transformation can only
   result in less information being presented to a watcher.

   This section defines the new conditions, actions and transformations
   defined by this specification.

3.1  Conditions

3.1.1  Identity

   Although the <identity> element is defined in [12], that
   specification indicates that the specific usages of the framework
   document need to define details that are protocol and usage specific.
   In particular, it is neccesary for a usage of the common policy
   framework to:

   o  Define acceptable means of authentication.

   o  Define the procedure for representing the identity of the WR
      (Watcher/Requestor) as a URI or IRI [18].

   o  Define the procedure for converting an identifier of the form
      user@domain, present in the 'id' attribute of the <one> and
      <except> elements; into a URI or IRI.

   This sub-section defines those details for systems based on [23].

3.1.1.1  Acceptable Forms of Authentication

   When used with SIP, a request is considered authenticated if one of
   the following techniques is used:

   SIP Digest: The presence agent has authenticated the watcher using
      SIP [9] digest authentication [8].  However, if the anonymous
      authentication described on page 194 of RFC 3261 [9] was used, the
      watcher is not considered authenticated.

   Asserted Identity: If a request contains a P-Asserted-ID header field
      [24] and the request is coming from a trusted element, the watcher
      is considered authenticated.

   Cryptographically Verified Identity: If a request contains an
      Identity header field as defined in [14], and it validates the
      From header field of the request, the request is considered to be
      authenticated.  Note that this is true even if the request
      contained a From header field of the form
      sip:anonymous@example.com.  As long as the signature verifies that



Rosenberg                Expires April 27, 2006                 [Page 5]


Internet-Draft           Presence Authorization             October 2005


      the request legitimately came from this identity, it is considered
      authenticated.


3.1.1.2  Computing a URI for the Watcher

   For requests that are authenticated using SIP Digest, the identity of
   the watcher is set equal to the user and domain part of the SIP
   Address of Record (AOR) for the user that has authenticated
   themselves.  For example, consider the following "user record" in a
   database:


   SIP AOR: sip:alice@example.com
   digest username: ali
   digest password: f779ajvvh8a6s6
   digest realm: example.com

   If the presence server receives a SUBSCRIBE request, challenges it
   with the realm set to "example.com", and the subsequent SUBSCRIBE
   contains an Authorization header field with a username of "ali" and a
   digest response generated with the password "f779ajvvh8a6s6", the
   identity used in matching operations is "sip:alice@example.com".

   For requests that are authenticated using RFC 3325 [24], the identity
   of the watcher is equal to the username and domain parts of the SIP
   URI in the P-Asserted-ID header field.  If there are multiple values
   for the P-Asserted-ID header field (there can be one sip URI and one
   tel URI [17]), then each of them is used for the comparisons outlined
   in [12], and if either of them match a <one> or <except> element, it
   is considered a match.

   For requests that are authenticated using the SIP Identity mechanism
   [14], identity of the WR is equal to the SIP URI in the From header
   field of the request, assuming that the signature in the Identity
   header field has been validated.

   In SIP systems, it is possible for a user to have aliases - that is,
   there are multiple SIP AOR "assigned" to a single user.  In terms of
   this specification, there is no relationship between those aliases.
   Each would look like a different user.  This will be the consequence
   for systems where the watcher is in a different domain than the
   presentity.  However, even if the watcher and presentity are in the
   same domain, and the presence server knows that there are aliases for
   the watcher, these aliases are not mapped to each other or used in
   any way.

   SIP also allows for anonymous requests.  If a request is anonymous



Rosenberg                Expires April 27, 2006                 [Page 6]


Internet-Draft           Presence Authorization             October 2005


   because the digest challenge/response used the "anonymous" username,
   the request is considered unauthenticated and will not match the
   <identity> condition.  If a request is anonymous because it contains
   a Privacy header field [19], but still contains a P-Asserted-ID
   header field, the identity in the P-Asserted-ID header field is still
   used in the authorization computations; the fact that the request was
   anonymous has no impact on the identity processing.  However, if the
   request had traversed a trust boundary and the P-Asserted-ID header
   field and the Privacy header field had been removed, the request will
   be considered unauthenticated when it arrives at the presence server,
   and thus not match the <identity> condition.  Finally, if a request
   contained an Identity header field that was validated, and the From
   header field contained a URI of the form sip:anonymous@example.com,
   then the watcher is considered authenticated, and it will have an
   identity equal to sip:anonymous@example.com.  Had such an identity
   been placed into a <one> or <except> element, there will be a match.

   It is important to note that SIP frequently uses both SIP URI and tel
   URI [17] as identifiers, and to make matters more confusing, a SIP
   URI can contain a phone number in its user part, in the same format
   that can be represented in a tel URI.  A WR identity that is a SIP
   URI with a phone number will NOT match the <one> and <except>
   conditions whose 'id' contains the same phone number, but whose
   'scheme' is tel.  The same is true in the reverse.  If the WR
   identity is a tel URI, this will not match a SIP URI in the <one> or
   <except> conditions.  URIs of different schemes are never equivalent.

3.1.1.3  Computing a SIP URI from the id attribute

   If the <one> or <except> condition doesn't contain a scheme,
   conversion of the value in the 'id' attribute to a SIP URI is done
   trivially.  If the characters in the 'id' attribute are valid
   characters for the user and hostpart components of the SIP URI, a
   'sip:' is appended to the contents of the 'id' attribute, and the
   result is the SIP URI.  If the characters in the 'id' attribute are
   not valid for the user and hostport components of the SIP URI,
   conversion is not possible.  This happens, for example, when the user
   portion of the 'id' attribute contain UTF-8 characters.

3.1.2  Sphere

   The <sphere> element is defined in [12].  However, each application
   making use of the common policy specification needs to determine how
   the presence server computes the value of the sphere to be used in
   the evaluation of the condition.

   To compute the value of <sphere>, the presence agent examines all
   published presence documents for the presentity.  If at least one of



Rosenberg                Expires April 27, 2006                 [Page 7]


Internet-Draft           Presence Authorization             October 2005


   them include the <sphere> element [13] as part of the person data
   component [15], and all of those containing the element have the same
   value for it, that is the value used for the sphere in common policy
   processing.  If, however, the <sphere> element was not present in any
   of the published documents, or it was present but had inconsistent
   values, its value is considered undefined in terms of common policy
   processing.

   Care must be taken in using <sphere> as a condition for determining
   the subscription handling.  Since the value of <sphere> changes
   dynamically, a state change can cause a subscription to be suddenly
   terminated.  The watcher has no way to know, aside from polling, when
   their subscription would be re-instated as the value of <sphere>
   changes.  For this reason, <sphere> is primarily useful for matching
   on rules that define transformations.

3.2  Actions

3.2.1  Subscription Handling

   The <sub-handling> element specifies the subscription authorization
   decision that the server should make.  It also specifies whether or
   not the presence document for the watcher should be constructed using
   "polite blocking" or not.  Usage of polite blocking and the
   subscription authorization decision are specified jointly since
   proper privacy handling requires a correlation between them.  As
   discussed in [12], since the combination algorithm runs independently
   for each permission, if correlations exist between permissions, they
   must be merged into a single variable.  That is what is done here.
   The <sub-handling> element is an enumerated Integer type.  The
   defined values are:

   block: This action tells the server to place the subscription in the
      rejected state.  It has the value of zero, and it represents the
      default value.  No value of the sub-handling element can ever be
      lower than this.  Strictly speaking, it is not necessary to every
      include an explicit block action, since the default in the absence
      of any action will be block.  However, it is included for
      completeness.

   confirm: This action tells the server to place the subscription in
      the "pending" state, and await input from the presentity to
      determine how to proceed.  It has a value of one.

   polite-block: This action tells the server to place the subscription
      into the "accepted" state, and to produce a presence document that
      indicates that the presentity is unavailable.  A reasonable
      document would exclude device and person information elements, and



Rosenberg                Expires April 27, 2006                 [Page 8]


Internet-Draft           Presence Authorization             October 2005


      include only a single service whose basic status is set to closed
      [3].  This action has a value of two.

   allow: This action tells the server to place the subscription into
      the "accepted" state.  This action has a value of three.

      NOTE WELL: Placing a value of block for this element does not
      guarantee that a subscription is denied!  If any matching rule has
      any other value for this element, the subscription will receive
      treatment based on the maximum of those other values.  This is
      based on the combining rules defined in [12].

   Future specifications can define additional values for this
   permission, allowing for the selection of other composition policies.

   The exact behavior of a presence server upon a change in the sub-
   handling value can be described by utilizing the subscription
   processing state machine in Figure 1 of RFC 3857 [10].  Each
   subscription is associated with a set of permissions that represents
   the combination of all permissions that apply to that subscription,
   using the combining rules in [12].

   If the sub-handling permission changes value to "block", this causes
   a "rejected" event to be generated into the subscription state
   machine for all affected subscriptions.  This will cause the state
   machine to move into the terminated state, resulting in the
   transmission of a NOTIFY to the watcher with a Subscription-State
   header field with value "terminated" and a reason of "rejected" [11],
   which terminates their subscription.  If a new subscription arrives
   later on, and the value of sub-handling that applies to that
   subscription is "block", the subscription processing follows the
   "subscribe, policy=reject" branch from the init state, and a 403
   response to the SUBSCRIBE is generated.

   If the sub-handling permission changes value to confirm, the
   processing depends on the states of the affected subscriptions.
   Unfortunately, the state machine in RFC 3857 does not define an event
   corresponding to an authorization decision of "pending".  If the
   subscription is in the active state, it moves back into the pending
   state.  This causes a NOTIFY to be sent, updating the Subscription-
   State [11] to "pending".  No reason is included in the Subscription-
   State header field (none are defined to handle this case).  No
   further documents are sent to this watcher.  There is no change in
   state if the subscription is in the pending, waiting or terminated
   states.  If a new subscription arrives later on, and the value of
   sub-handling that apples to that subscription is "pending", the
   subscription processing follows the "subscribe, no policy" branch
   from the init state, and a 202 response to the SUBSCRIBE is



Rosenberg                Expires April 27, 2006                 [Page 9]


Internet-Draft           Presence Authorization             October 2005


   generated, followed by a NOTIFY with Subscription-State of pending.
   No presence document is included in that NOTIFY.

   If the sub-handling permission changes value to "polite-block" or
   "allow", this causes an "approved" event to be generated into the
   state machine for all affected subscriptions.  This will cause the
   machine to move into the active state if it is currently in pending,
   resulting in the transmission of a NOTIFY with a Subscription-State
   header field of "active", and the inclusion of a presence document in
   that NOTIFY.  If a new subscription arrives later on, and the value
   of sub-handling that applies to that subscription is is "polite-
   block" or "allow", the subscription processing follows the
   "subscribe, policy=accept" branch from the init state, and a 200 OK
   response to the SUBSCRIBE is generated, followed by a NOTIFY with
   Subscription-State of "active" with a presence document in the body
   of the NOTIFY.

3.3  Transformations

   The transformations defined here are used to drive the behavior of
   the privacy filtering operation.  Each transformation defines the
   visibility a watcher is granted to a particular component of the
   presence document.  One group of transformations grant visibility to
   person, device and service data elements based on identifying
   information for those elements.  Another group of transformations
   provide access to particular data elements in the presence document.

3.3.1  Providing Access to Data Component Elements

   The transformations in this section provide access to person, device
   and service data component elements.  Once access has been granted to
   such an element, access to specific presence attributes for that
   element is controlled by the permissions defined in Section 3.3.2.

3.3.1.1  Device Information

   The <provide-devices> permission allows a watcher to see <device>
   information present in the presence document.  It is a set variable.
   Each member of the set provides a way to identify a device or group
   of devices.  This specification defines three types of elements in
   the set - <class>, which identifies a device occurrence by class,
   <device-id>, which identifies a device occurrence by device ID, and
   <occurrence-id>, which identifies a device occurrence by occurrence
   ID.  Each member of the set is identified by its type (class,
   device-id or occurrence-id) and value (value of the class, value of
   the device-id, or value of the occurrence-id).

   For example, consider the following <provide-devices> element:



Rosenberg                Expires April 27, 2006                [Page 10]


Internet-Draft           Presence Authorization             October 2005


   <provide-devices>
     <device-id>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</device-id>
     <class>biz</class>
   </provide-devices>

   This set has two members.  This is combined with a <provide-devices>
   element from a different rule:


   <provide-devices>
     <class>home</class>
     <class>biz</class>
   </provide-devices>

   The result of the set combination (using the union operation) is a
   set with four elements:


   <provide-devices>
     <class>home</class>
     <class>biz</class>
     <device-id>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</device-id>
   </provide-devices>

   The <provide-devices> element can also take on the special value
   <all-devices> which is a short-hand notation for all device
   occurrences present in the presence document.

   Permission is granted to see a particular device occurrence if one of
   the device identifiers in the set identifies that device occurrence.
   If a <class> permission is granted to the watcher, and the <class> of
   the device occurrence matches the value of the <class> permission
   based on case sensitive equality, the device occurrence is included
   in the presence document.  If a <device-id> permission is granted to
   the watcher, and the <device-id> of the device occurrence matches the
   value of the <device-id> permission based on URI equivalence, the
   device occurrence is included in the presence document.  If a
   <occurrence-id> permission is granted to the watcher, and the
   <occurrence-id> of the device occurrence matches the value of the
   <occurrence-id> permission based on case sensitive equality, the
   device occurrence is included in the presence document.  In addition,
   a device occurrence is included in the presence document if the <all-
   devices> permission was granted to the watcher.

3.3.1.2  Person Information

   The <provide-persons> permission allows a watcher to see the <person>
   information present in the presence document.  It is a set variable.



Rosenberg                Expires April 27, 2006                [Page 11]


Internet-Draft           Presence Authorization             October 2005


   Each member of the set provides a way to identify a person
   occurrence.  This specification defines two types of elements in the
   set - <class>, which identifies a person occurrence by class, and
   <occurrence-id>, which identifies an occurrence by its occurrence ID.
   Each member of the set is identified by its type (class or
   occurrence-id) and value (value of the class or value of the
   occurrence-id).  The <provide-persons> element can also take on the
   special value <all-persons> which is a short-hand notation for all
   person occurrences present in the presence document.  The set
   combination is done identically to the <provide-devices> element.

   Permission is granted to see a particular person occurrence if one of
   the person identifiers in the set identifies that person occurrence.
   If a <class> permission is granted to the watcher, and the <class> of
   the person occurrence matches the value of the <class> permission
   based on case sensitive equality, the person occurrence is included
   in the presence document.  If a <occurrence-id> permission is granted
   to the watcher, and the <occurrence-id> of the person occurrence
   matches the value of the <occurrence-id> permission based on case
   sensitive equality, the person occurrence is included in the presence
   document.  In addition, a person occurrence is included in the
   presence document if the <all-persons> permission was granted to the
   watcher.

3.3.1.3  Service Information

   The <provide-services> permission allows a watcher to see service
   information present in <tuple> elements in the presence document.
   Like <provide-devices>, it is a set variable.  Each member of the set
   provides a way to identify a service occurrence.  This specification
   defines four types of elements in the set - <class>, which identifies
   a service occurrence by class, <occurrence-id>, which identifies a
   service by its occurrence ID, <service-uri>, which identifies a
   service by its service URI, and <service-uri-scheme>, which
   identifies a service by its service URI scheme.  Each member of the
   set is identified by its type (class, occurrence-id, service-uri or
   service-uri-scheme) and value (value of the class, value of the
   occurrence-id, value of the service-uri or value of the service-uri-
   scheme ).  The <provide-services> element can also take on the
   special value <all-services> which is a short-hand notation for all
   service occurrences present in the presence document.  The set
   combination is done identically to the <provide-persons> element.

   Permission is granted to see a particular service occurrence if one
   of the service identifiers in the set identifies that service
   occurrence.  If a <class> permission is granted to the watcher, and
   the <class> of the service occurrence matches the value of the
   <class> permission based on case sensitive equality, the service



Rosenberg                Expires April 27, 2006                [Page 12]


Internet-Draft           Presence Authorization             October 2005


   occurrence is included in the presence document.  If a <service-uri>
   permission is granted to the watcher, and the <service-uri> of the
   service occurrence matches the value of the <service-uri> permission
   based on URI equivalence, the service occurrence is included in the
   presence document.  If a <occurrence-id> permission is granted to the
   watcher, and the <occurrence-id> of the service occurrence matches
   the value of the <occurrence-id> permission based on case sensitive
   equality, the service occurrence is included in the presence
   document.  If a <service-uri-scheme> permission is granted to the
   watcher, and the scheme of the service URI for the service occurrence
   matches the value of <service-uri-scheme> based on case sensitive
   equality, the service occurrence is included in the presence
   document.  In addition, a service occurrence is included in the
   presence document if the <all-services> permission was granted to the
   watcher.

3.3.2  Providing Access to Presence Attributes

   The permissions of Section 3.3.1 provide coarse grained access to
   presence data by allowing or blocking specific services or devices,
   and allowing or blocking person information.

   Once person, device or service information is included in the
   document, the permissions in this section define which presence
   attributes are reported there.  Certain information is always
   reported.  In particular, the <contact>, <service-class> [13],
   <basic> status and <timestamp> elements in all <tuple> elements, if
   present, are provided to watchers .  The <timestamp> element in all
   <person> elements, if present, is provided to watchers.  The
   <timestampt> and <device-id> elements in all <device> elements, if
   present, is provided to all watchers.

3.3.2.1  Provide Activities

   This permission controls access to the <activities> element defined
   in [13].  The name of the element providing this permission is
   <provide-activities>, and it is a boolean type.  If its value is
   TRUE, then the <activities> element in the person data element is
   reported to the watcher.  If FALSE, this presence attribute is
   removed if present.

3.3.2.2  Provide Class

   This permission controls access to the <class> element defined in
   [13].  The name of the element providing this permission is <provide-
   class>, and it is a boolean type.  If its value is TRUE, then the
   <class> element in the person, service or device data element is
   reported to the watcher.  If FALSE, this presence attribute is



Rosenberg                Expires April 27, 2006                [Page 13]


Internet-Draft           Presence Authorization             October 2005


   removed if present.

3.3.2.3  Provide Device ID

   This permission controls access to the <device-id> element defined in
   [13].  The name of the element providing this permission is <provide-
   device-id>, and it is a boolean type.  If its value is TRUE, then the
   <device-id> element in the service data element is reported to the
   watcher.  If FALSE, this presence attribute is removed if present.

3.3.2.4  Provide Mood

   This permission controls access to the <mood> element defined in
   [13].  The name of the element providing this permission is <provide-
   mood>, and it is a boolean type.  If its value is TRUE, then the
   <mood> element in the person data element is reported to the watcher.
   If FALSE, this presence attribute is removed if present.

3.3.2.5  Provide Place-is

   This permission controls access to the <place-is> element defined in
   [13].  The name of the element providing this permission is <provide-
   place-is>, and it is a boolean type.  If its value is TRUE, then the
   <place-is> element in the person data element is reported to the
   watcher.  If FALSE, this presence attribute is removed if present.

3.3.2.6  Provide Place-type

   This permission controls access to the <place-type> element defined
   in [13].  The name of the element providing this permission is
   <provide-place-type>, and it is a boolean type.  If its value is
   TRUE, then the <place-type> element in the person data element is
   reported to the watcher.  If FALSE, this presence attribute is
   removed if present.

3.3.2.7  Provide Privacy

   This permission controls access to the <privacy> element defined in
   [13].  The name of the element providing this permission is <provide-
   privacy>, and it is a boolean type.  If its value is TRUE, then the
   <privacy> element in the service data element is reported to the
   watcher.  If FALSE, this presence attribute is removed if present.

3.3.2.8  Provide Relationship

   This permission controls access to the <relationship> element defined
   in [13].  The name of the element providing this permission is
   <provide-relationship>, and it is a boolean type.  If its value is



Rosenberg                Expires April 27, 2006                [Page 14]


Internet-Draft           Presence Authorization             October 2005


   TRUE, then the <relationship> element in the service data element is
   reported to the watcher.  If FALSE, this presence attribute is
   removed if present.

3.3.2.9  Provide Sphere

   This permission controls access to the <sphere> element defined in
   [13].  The name of the element providing this permission is <provide-
   sphere>, and it is a boolean type.  If its value is TRUE, then the
   <sphere> element in the person data element is reported to the
   watcher.  If FALSE, this presence attribute is removed if present.

3.3.2.10  Provide Status-Icon

   This permission controls access to the <status-icon> element defined
   in [13].  The name of the element providing this permission is
   <provide-status-icon>, and it is a boolean type.  If its value is
   TRUE, then any <status-icon> element in the person or service data
   element is reported to the watcher.  If FALSE, this presence
   attribute is removed if present.

3.3.2.11  Provide Time-Offset

   This permission controls access to the <time-offset> element defined
   in [13].  The name of the element providing this permission is
   <provide-time-offset>, and it is a boolean type.  If its value is
   TRUE, then the <time-offset> element in the person data element is
   reported to the watcher.  If FALSE, this presence attribute is
   removed if present.

3.3.2.12  Provide User-Input

   This permission controls access to the <user-input> element defined
   in [13].  The name of the element providing this permission is
   <provide-user-input>, and it is an enumerated integer type.  Its
   value defines what information is provided to watchers:

   false: This value indicates that the <user-input> element is removed
      from the document.  It is assigned the numeric value of 0.

   bare: This value indicates that the <user-input> element is to be
      retained.  However, any "idle-threshold" and "since" attributes
      are to be removed.  This value is assigned the numeric value of 1.

   thresholds: This value indicates that the <user-input> element is to
      be retained.  However, only the "idle-threshold" attribute is to
      be retained.  This value is assigned to the numeric value of 2.




Rosenberg                Expires April 27, 2006                [Page 15]


Internet-Draft           Presence Authorization             October 2005


   full: This value indicates that the <user-input> element is to be
      retained, including any attributes.  This value is assigned to the
      numeric value of 3.


3.3.2.13  Provide Note

   This permission controls access to the <note> element defined in [3]
   for <tuple> and [15] for <person> and <device>.  The name of the
   element providing this permission is <provide-note>, and it is a
   boolean type.  If its value is TRUE, then the <note> elements in the
   person, service or device data elements are reported to the watcher.
   If FALSE, this presence attribute is removed if present.

3.3.2.14  Provide Unknown Attribute

   It is important that systems be allowed to include proprietary or new
   presence information, and that users be able to set permissions for
   that information, without requiring an upgrade of the presence server
   and authorization system.  For this reason, the <provide-unknown-
   attribute> permission is defined.  This permission indicates that the
   unknown presence attribute with the given name (supplied as mandatory
   attribute of the <provide-unknown-attribute> element) should be
   included in the document.  Its type is boolean.

   The value of the name attribute MUST be a qualified element name
   (meaning that the namespace prefix MUST be included), which will be
   matched to all unknown child elements of the PIDF <tuple>, <device>
   or <person< elements with the same qualified name.  The namespace
   bindings are taken from those in scope at the point in the document
   where the <provide-unknown-attribute> is present.  In this context,
   "unknown" means that the presence server is not aware of any schemas
   that define authorization policies for that element.  By definition,
   this will exclude the <provide-unknown-attribute> rule from being
   applied to any of the presence status extensions defined by RPID.

   Another consequence of this definition is that the interpretation of
   the <provide-unknown-attribute> element can change should the
   presence server be upgraded with a new schema that defines
   authorization rules for elements included in a <provide-unknown-
   attribute>.  The <provide-unknown-attribute> permissions for those
   elements will then be ignored, resulting in a removal of those
   elements from presence documents sent to watchers.  The system
   remains privacy safe, but behavior might not be as expected.
   Developers of systems which allow clients to set policies are advised
   to check the capabilities of the server, as defined in [22], before
   uploading a new authorization document, to make sure that the
   behavior will be as expected.



Rosenberg                Expires April 27, 2006                [Page 16]


Internet-Draft           Presence Authorization             October 2005


3.3.2.15  Provide All Attributes

   This permission grants access to all presence attributes in all of
   the person, device and tuple elements that are present in the
   document (the ones present in the document are determedined by the
   <provide-persons>, <provide-devices> and <provide-services>
   permissions).  It is effectively a macro that expands into a set of
   provide-activities, provide-class, provide-device-id, provide-mood,
   provide-place-is, provide-place-type, provide-privacy, provide-
   relationship, provide-sphere, provide-status-icon, provide-time-
   offset, provide-user-input, provide-note and provide-unknown-
   attribute permissions such that each presence attribute in the
   document has a permission for it.  This implies that, so long as an
   entire person, service or device occurrence is provided, every single
   presence attribute, including ones not known to the server and/or
   defined in future presence document extensions, is granted to the
   watcher.

4.  When to Apply the Authorization Policies

   This specification does not mandate at what point in the processing
   of presence data the privacy filtering aspects of the authorization
   policy are applied.  However, they must be applied such that the
   final presence document sent to the watcher is compliant to the
   privacy policy described in the document.  More concretely, if the
   document sent to a watcher is D, and the privacy filtering operation
   applied do a presence document x is F(x), then D MUST have the
   property that D = F(D).  A corollary of this is that F(F(D)) = D for
   all D.

   The subscription processing aspects of the document get applied by
   the server when it decides to accept or reject the subscription.

5.  Example Document

   The following presence authorization document specifies permissions
   for the user "user@example.com".














Rosenberg                Expires April 27, 2006                [Page 17]


Internet-Draft           Presence Authorization             October 2005


   <?xml version="1.0" encoding="UTF-8"?>
   <cr:ruleset xmlns="urn:ietf:params:xml:ns:pres-rules"
    xmlns:cr="urn:ietf:params:xml:ns:common-policy"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:new="urn:vendor-specific:foo-namespace"
    xsi:schemaLocation="urn:ietf:params:xml:ns:pres-rules pres-rules.xsd">
    <cr:rule id="1">
     <cr:conditions>
      <cr:identity>
       <cr:id entity="user@example.com"/>
      </cr:identity>
     </cr:conditions>
     <cr:actions>
      <sub-handling>allow</sub-handling>
     </cr:actions>
     <cr:transformations>
      <provide-services>
        <service-uri-scheme>sip</service-uri-scheme>
        <service-uri-scheme>mailto</service-uri-scheme>
      </provide-services>
      <provide-persons>
        <all-persons/>
         </provide-persons>
      <provide-activities>true</provide-activities>
      <provide-user-input>bare</provide-user-input>
       <provide-unknown-attribute name="new:foo">true</provide-unknown-attribute>
     </cr:transformations>
    </cr:rule>
   </cr:ruleset>




6.  XML Schema



   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:cr="urn:ietf:params:xml:ns:common-policy"
    xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
    targetNamespace="urn:ietf:params:xml:ns:pres-rules"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
    <xs:simpleType name="booleanPermission">
     <xs:restriction base="xs:boolean"/>
    </xs:simpleType>
    <xs:element name="service-uri-scheme" type="xs:token"/>



Rosenberg                Expires April 27, 2006                [Page 18]


Internet-Draft           Presence Authorization             October 2005


    <xs:element name="class" type="xs:token"/>
    <xs:element name="occurrence-id" type="xs:token"/>
    <xs:element name="service-uri" type="xs:anyURI"/>
    <xs:complexType name="provideServicePermission">
     <xs:choice>
      <xs:element name="all-services">
       <xs:complexType/>
      </xs:element>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:choice>
        <xs:element ref="pr:service-uri"/>
        <xs:element ref="pr:service-uri-scheme"/>
        <xs:element ref="pr:occurrence-id"/>
        <xs:element ref="pr:class"/>
        <xs:any namespace="##other"/>
       </xs:choice>
      </xs:sequence>
     </xs:choice>
    </xs:complexType>
    <xs:element name="provide-services"
     type="pr:provideServicePermission"/>
    <xs:element name="device-id" type="xs:anyURI"/>
    <xs:complexType name="provideDevicePermission">
     <xs:choice>
      <xs:element name="all-devices">
       <xs:complexType/>
      </xs:element>
      <xs:sequence>
       <xs:choice>
        <xs:element ref="pr:device-id"/>
        <xs:element ref="pr:occurrence-id"/>
        <xs:element ref="pr:class"/>
        <xs:any namespace="##other"/>
       </xs:choice>
      </xs:sequence>
     </xs:choice>
    </xs:complexType>
    <xs:element name="provide-devices"
     type="pr:provideDevicePermission"/>
    <xs:complexType name="providePersonPermission">
     <xs:choice>
      <xs:element name="all-persons">
       <xs:complexType/>
      </xs:element>
      <xs:sequence>
       <xs:choice>
        <xs:element ref="pr:occurrence-id"/>
        <xs:element ref="pr:class"/>



Rosenberg                Expires April 27, 2006                [Page 19]


Internet-Draft           Presence Authorization             October 2005


        <xs:any namespace="##other"/>
       </xs:choice>
      </xs:sequence>
     </xs:choice>
    </xs:complexType>
    <xs:element name="provide-persons" type="pr:providePersonPermission"/>
    <xs:element name="provide-activities" type="pr:booleanPermission"/>
    <xs:element name="provide-class" type="pr:booleanPermission"/>
    <xs:element name="provide-device-id" type="pr:booleanPermission"/>
    <xs:element name="provide-mood" type="pr:booleanPermission"/>
    <xs:element name="provide-place-is" type="pr:booleanPermission"/>
    <xs:element name="provide-place-type" type="pr:booleanPermission"/>
    <xs:element name="provide-privacy" type="pr:booleanPermission"/>
    <xs:element name="provide-relationship" type="pr:booleanPermission"/>
    <xs:element name="provide-status-icon" type="pr:booleanPermission"/>
    <xs:element name="provide-sphere" type="pr:booleanPermission"/>
    <xs:element name="provide-time-offset" type="pr:booleanPermission"/>
    <xs:element name="provide-user-input">
     <xs:simpleType>
      <xs:restriction base="xs:string">
       <xs:enumeration value="false"/>
       <xs:enumeration value="bare"/>
       <xs:enumeration value="thresholds"/>
       <xs:enumeration value="full"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:element>
    <xs:element name="provide-note" type="pr:booleanPermission"/>
    <xs:simpleType name="componentIDPermission">
     <xs:restriction base="xs:token">
      <xs:enumeration value="randomize"/>
      <xs:enumeration value="obfuscate"/>
      <xs:enumeration value="allow"/>
     </xs:restriction>
    </xs:simpleType>
    <xs:complexType name="unknownBooleanPermission">
     <xs:simpleContent>
      <xs:extension base="pr:booleanPermission">
       <xs:attribute name="name" type="xs:string" use="required"/>
      </xs:extension>
     </xs:simpleContent>
    </xs:complexType>
    <xs:element name="provide-unknown-attribute"
     type="pr:unknownBooleanPermission"/>
    <xs:element name="provide-all-attributes">
     <xs:complexType/>
    </xs:element>
   </xs:schema>



Rosenberg                Expires April 27, 2006                [Page 20]


Internet-Draft           Presence Authorization             October 2005


7.  Schema Extensibility

   It is anticipated that future changes to this specification are
   accomplished through extensions that define new types of permissions.
   These extensions MUST exist within a different namespace.
   Furthermore, the schema defined above and the namespace for elements
   defined within it MUST NOT be altered by future specifications.
   Changes in the basic schema, or in the interpretation of elements
   within that schema, may result in violations of user privacy due to
   mis-interpretation of documents.

   This specification also defines two substitution groups.  One is for
   service identifiers, and one is for device identifiers.  It is
   expected that future extensions will specify new ways of identifying
   services and devices for inclusion in a document.  These new
   permissions MUST be assigned to this substitution group.

8.  XCAP Usage

   The following section defines the details necessary for clients to
   manipulate presence authorization documents from a server using XCAP.

8.1  Application Unique ID

   XCAP requires application usages to define a unique application usage
   ID (AUID) in either the IETF tree or a vendor tree.  This
   specification defines the "pres-rules" AUID within the IETF tree, via
   the IANA registration in Section 10.

8.2  Structure of Permission Statements

   The structure of permission statements is defined in Section 3.

8.3  Additional Constraints

   There are no additional constraints defined by this specification.

8.4  Naming Conventions

   When a presence agent receives a subscription for some user foo
   within a domain, it will look for all documents within http://[xcap
   root]/ pres-rules/users/foo, and use all documents found beneath that
   point to guide authorization policy.

8.5  Authorization Policies

   This application usage does not modify the default XCAP authorization
   policy, which is that only a user can read, write or modify their own



Rosenberg                Expires April 27, 2006                [Page 21]


Internet-Draft           Presence Authorization             October 2005


   documents.  A server can allow priveleged users to modify documents
   that they don't own, but the establishment and indication of such
   policies is outside the scope of this document.

8.6  XML Schema

   The XML schema is defined in Section 6.

9.  Security Considerations

   Presence authorization policies contain very sensitive information.
   They indicate which other users are "liked" or "disliked" by a user.
   As such, when these documents are transported over a network, they
   SHOULD be encrypted.

   Modification of these documents by an attacker can disrupt the
   service seen by a user, often in subtle ways.  As a result, when
   these documents are transported, the transport SHOULD provide
   authenticity and message integrity.

   In the case where XCAP is used to transfer the document, clients
   SHOULD use HTTP over TLS, and servers SHOULD define the root services
   URI as an https URI.  The server SHOULD authenticate the client over
   the resulting TLS connection using HTTP digest.

10.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

10.1  XCAP Application Usage ID

   This section registers an XCAP Application Usage ID (AUID) according
   to the IANA procedures defined in [2].

      Name of the AUID: pres-rules

      Description: Presence rules are documents that describe the
      permissions that a presentity [20] has granted to users that seek
      to watch their presence.


10.2  URN Sub-Namespace Registration

   This section registers a new XML namespace, per the guidelines in
   [16]





Rosenberg                Expires April 27, 2006                [Page 22]


Internet-Draft           Presence Authorization             October 2005


      URI: The URI for this namespace is
      urn:ietf:params:xml:ns:pres-rules.

      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      XML:


                BEGIN
                <?xml version="1.0"?>
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
                <html xmlns="http://www.w3.org/1999/xhtml">
                <head>
                  <meta http-equiv="content-type"
                     content="text/html;charset=iso-8859-1"/>
                  <title>Presence Rules Namespace</title>
                </head>
                <body>
                  <h1>Namespace for Permission Statements</h1>
                  <h2>urn:ietf:params:xml:ns:pres-rules</h2>
                  <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
                </body>
                </html>
                END


10.3  XML Schema Registrations

   This section registers an XML schema per the procedures in [16].

      URI: urn:ietf:params:xml:schema:pres-rules.

      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      The XML for this schema can be found as the sole content of
      Section 6.


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.




Rosenberg                Expires April 27, 2006                [Page 23]


Internet-Draft           Presence Authorization             October 2005


   [2]   Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)",
         draft-ietf-simple-xcap-07 (work in progress), June 2005.

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

   [4]   Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
         FirstEdition REC-xml-20001006, October 2000.

   [5]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [6]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [7]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [8]   Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
         Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
         Basic and Digest Access Authentication", RFC 2617, June 1999.

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

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

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

   [12]  Schulzrinne, H., "A Document Format for Expressing Privacy
         Preferences", draft-ietf-geopriv-common-policy-05 (work in
         progress), July 2005.

   [13]  Schulzrinne, H., "RPID: Rich Presence Extensions to the
         Presence Information Data Format  (PIDF)",
         draft-ietf-simple-rpid-09 (work in progress), September 2005.

   [14]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation  Protocol (SIP)",
         draft-ietf-sip-identity-05 (work in progress), May 2005.

   [15]  Rosenberg, J., "A Data Model for Presence",



Rosenberg                Expires April 27, 2006                [Page 24]


Internet-Draft           Presence Authorization             October 2005


         draft-ietf-simple-presence-data-model-05 (work in progress),
         September 2005.

   [16]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [17]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
         December 2004.

   [18]  Duerst, M. and M. Suignard, "Internationalized Resource
         Identifiers (IRIs)", RFC 3987, January 2005.

   [19]  Peterson, J., "A Privacy Mechanism for the Session Initiation
         Protocol (SIP)", RFC 3323, November 2002.

11.2  Informative References

   [20]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
         and Instant Messaging", RFC 2778, February 2000.

   [21]  Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
         Messaging / Presence Protocol Requirements", RFC 2779,
         February 2000.

   [22]  Rosenberg, J., "An Extensible Markup Language (XML)
         Representation for Expressing Presence  Policy Capabilities",
         draft-rosenberg-simple-pres-policy-caps-02 (work in progress),
         February 2005.

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

   [24]  Jennings, C., Peterson, J., and M. Watson, "Private Extensions
         to the Session Initiation Protocol (SIP) for Asserted Identity
         within Trusted Networks", RFC 3325, November 2002.
















Rosenberg                Expires April 27, 2006                [Page 25]


Internet-Draft           Presence Authorization             October 2005


Author's Address

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net








































Rosenberg                Expires April 27, 2006                [Page 26]


Internet-Draft           Presence Authorization             October 2005


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosenberg                Expires April 27, 2006                [Page 27]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/