SIPPING Working Group                                            V. Hilt
Internet-Draft                             Bell Labs/Lucent Technologies
Expires: September 6, 2006                                  G. Camarillo
                                                                Ericsson
                                                           March 5, 2006


 A Session Initiation Protocol (SIP) Event Package for Session-Specific
                           Session Policies.
                  draft-hilt-sipping-policy-package-01

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 September 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This specification defines a Session Initiation Protocol (SIP) event
   package for session-specific session policies.  This event package
   enables users to subscribe to the policies for a SIP session and to
   receive notifications if the policies change.  The package is part of
   the Framework for SIP Session Policies.




Hilt & Camarillo        Expires September 6, 2006               [Page 1]


Internet-Draft        Session Policy Event Package            March 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Event Package Formal Definition  . . . . . . . . . . . . . . .  4
     3.1.  Event Package Name . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Event Package Parameters . . . . . . . . . . . . . . . . .  4
     3.3.  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . .  4
     3.4.  Subscription Duration  . . . . . . . . . . . . . . . . . .  5
     3.5.  NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . .  6
     3.6.  Subscriber generation of SUBSCRIBE requests  . . . . . . .  6
     3.7.  Notifier processing of SUBSCRIBE requests  . . . . . . . .  7
     3.8.  Notifier generation of NOTIFY requests . . . . . . . . . .  8
     3.9.  Subscriber processing of NOTIFY requests . . . . . . . . .  8
     3.10. Handling of forked requests  . . . . . . . . . . . . . . .  9
     3.11. Rate of notifications  . . . . . . . . . . . . . . . . . .  9
     3.12. State Agents . . . . . . . . . . . . . . . . . . . . . . .  9
     3.13. Examples . . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Event Package Name . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Content-Disposition Types  . . . . . . . . . . . . . . . . 10
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14























Hilt & Camarillo        Expires September 6, 2006               [Page 2]


Internet-Draft        Session Policy Event Package            March 2006


1.  Introduction

   The Framework for Session Initiation Protocol (SIP) [8] Session
   Policies [10] defines a protocol framework for the exchange of
   session policy information between a network domain and a user agent.
   This framework introduces two types of session policies: session-
   specific policies and session-independent policies.  Session-specific
   policies are policies for one specific session.  They are created
   based on the session description of a session.  Naturally, a user
   agent needs to request session-specific policies on a session-by-
   session basis at the time a session is created and the session
   description is known.  Session-independent policies on the other hand
   are policies that are created independent of a session and generally
   apply to SIP sessions.  Since these policies are not based on a
   specific session description, they can be created and conveyed to the
   user agent at any time.  User agents receive session-independent
   policies as part of their configuration information [6].

   This specification defines a SIP event package [7] that enables user
   agents to subscribe to session-specific policies.  Session policies
   can change while they are in effect.  These changes can result, for
   example, from changes in network conditions, the use of services, or
   simply because a provider wants to revoke rights or grant additional
   rights to a customer.

   Setting up session-specific policies involves the following steps
   (see [10]):

   1.  A user agent submits a session description to the policy server
       and asks whether a session using this session description is
       permissible.  This request covers all aspects of the included
       session description.  For example, if the session description
       contains a media line for video, the user agent implicitly asks
       for permission to use video.
   2.  The policy server creates a policy decision for this particular
       session and returns the decision to the user agent.  Possible
       policy decisions are to (1) deny the session, (2) propose changes
       to the session description with which the session is acceptable,
       or (3) accept the session as it was proposed.  An example for a
       policy decision is to disallow the use of video but agree to all
       other aspects of the proposed session.
   3.  The policy server can update the policy decision at any time.  A
       policy decision update can, for example, propose additional
       changes to the session description (e.g. change the allowed
       codecs) or deny a previously accepted session (e.g. disallow the
       continuation of a session).





Hilt & Camarillo        Expires September 6, 2006               [Page 3]


Internet-Draft        Session Policy Event Package            March 2006


   4.  The user agent applies the policy decision to the session it is
       establishing or managing.

   The session-specific policy event package defined in this document
   enables a user agent to subscribe to session-specific policies based
   on this model.  In this event package, the resource the subscriber is
   subscribing to is created at the time the subscription is
   established.  The notifier takes information from the SUBSCRIBE
   request and generates the resource the subscription is for.  This is
   different from other event packages, in which subscriptions are for
   an existing resource.


2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.


3.  Event Package Formal Definition

   This document provides the details for defining a SIP event package
   as required by RFC 3265 [7].

3.1.  Event Package Name

   The name of the event package defined in this specification is
   "session-spec-policy".

3.2.  Event Package Parameters

   This package does not define any event package parameters.

3.3.  SUBSCRIBE Bodies

   A SUBSCRIBE for the session-specific policy package SHOULD contain a
   body that consists of a session description.  The purpose of this
   body is to enable the notifier to generate the policy decision the
   subscriber is interested in.  In this event packet, the Request-URI,
   the event package name and event parameters are not sufficient for
   this purpose.  With the session description in the SUBSCRIBE body,
   the notifier can generate the requested policy decision and create
   policy events for this resource.

   All subscribers and notifiers MUST support the "application/sdp"



Hilt & Camarillo        Expires September 6, 2006               [Page 4]


Internet-Draft        Session Policy Event Package            March 2006


   format as described in [4].  The "application/sdp" format is the
   default format for session descriptions in this event package.
   Subscribers and notifiers MAY negotiate the use of other formats
   capable of representing a session description.

   Subscriptions to the session-specific policy package are typically
   created in conjunction with an SDP offer/answer exchange [11] during
   the establishment of a session as described in [10].  If used with an
   offer/answer exchange, the subscriber SHOULD insert the local session
   description in the SUBSCRIBE body.  The local session description is
   the one that was created by the subscriber (i.e. the offer if the
   subscriber has initiated the offer/answer exchange).  A body that
   contains the local session description offer MUST have a Content-
   Disposition [9] disposition-type of "session-policy" and a Content-
   Disposition parameter "description=local", a new value and a new
   parameter defined in this document.

   The subscriber MAY choose to also include the remote session
   description in the SUBSCRIBE body.  The remote session description is
   the one the subscriber has received (i.e. the answer if the
   subscriber has initiated the offer/answer exchange).  In some
   scenarios, the remote session description is not available to the
   subscriber at the time the subscription to session-specific policies
   is created.  In this case, the initial SUBSCRIBE message SHOULD only
   contain the local session description.  When the remote description
   becomes available, the subscriber SHOULD refresh the subscription by
   sending another SUBSCRIBE request, which then contains the local and
   the remote session description.

   All subscribers and notifiers SHOULD support the MIME type
   "multipart/mixed" [3].  This is needed to include the local and the
   remote session description in the SUBSCRIBE body.  The body that
   contains the remote session description MUST have the Content-
   Disposition disposition-type of "session-policy" and a Content-
   Disposition parameter of "description=remote", a new value and a new
   parameter defined in this document.

3.4.  Subscription Duration

   A subscription to the session-specific policy package is usually
   established at the beginning of a session and terminated when the
   corresponding session ends (it may, of course, be terminated
   earlier).  A typical duration of a phone call is a few minutes.

   Since the duration of a subscription to the session-specific policy
   package is closely related to the lifetime of the corresponding
   session, the value for the duration of a subscription is largely
   irrelevant.  However, it SHOULD be longer than the typical duration



Hilt & Camarillo        Expires September 6, 2006               [Page 5]


Internet-Draft        Session Policy Event Package            March 2006


   of a session.  The default subscription duration for this event
   package is set to two hours.

3.5.  NOTIFY Bodies

   In this event package, the body of the notification contains the
   policy decision requested by the subscriber.  All subscribers and
   notifiers MUST support the "application/SDP" format [4] as a format
   for NOTIFY bodies.

   The SUBSCRIBE request MAY contain an Accept header field.  If no such
   header field is present, it has a default value of "application/sdp".
   If the header field is present, it MUST include "application/sdp",
   and MAY include any other types capable of representing session-
   specific policy decisions.  As defined RFC 3265 [7], the body of
   notifications MUST be in one of the formats defined in the Accept
   header of the SUBSCRIBE request or in the default format.

   If the notifier uses the same format in NOTIFY bodies that was used
   by the subscriber in the SUBSCRIBE body (e.g. "application/SDP"), the
   notifier can expect that the subscriber supports all format
   extensions it has used in the SUBSCRIBE body.  However, the notifier
   cannot assume that the subscriber supports any other extension beyond
   that.  If the notifier uses other extensions, it cannot count on the
   fact that they will be understood by the subscriber.

   If the SUBSCRIBE request did contain the local session description of
   the subscriber and the subscription was accepted, then the NOTIFY
   body MUST contain a policy decision for this session description.
   This decision MUST have a disposition-type of "session-policy" and a
   parameter "description=local".

   If the SUBSCRIBE request of an accepted subscription contained the
   local and the remote session description, then the NOTIFY body MUST
   contain two policy decisions, one for the local and one for the
   remote session description.  The decision for the local description
   MUST have a disposition-type of "session-policy" with a parameter
   "description=local", the decision for remote description MUST have a
   disposition-type of "session-policy" with a parameter
   "description=remote".

3.6.  Subscriber generation of SUBSCRIBE requests

   The subscriber follows the general rules for generating SUBSCRIBE
   requests defined in [7].  The subscriber SHOULD include the session
   description in the SUBSCRIBE body that most accurately reflects the
   session for which it seeks to receive session-specific policies.  It
   SHOULD use the most recent session description if multiple versions



Hilt & Camarillo        Expires September 6, 2006               [Page 6]


Internet-Draft        Session Policy Event Package            March 2006


   are available.

   A user agent can, of course, change the session description of an
   ongoing session.  A change in the session description often affects
   the policy decisions that are created for this session.  A subscriber
   SHOULD therefore refresh the subscription to session-specific
   policies every time the session description of the associated session
   changes.  It does so by sending a SUBSCRIBE request, which contains
   the updated session description.

   Session policies can contain sensitive information.  Moreover, policy
   decisions can significantly impact the functionality and behavior of
   a user agent.  A user agent should therefore verify the identity of a
   policy server and make sure that policies have not been altered in
   transit.  All implementations of this package MUST support TLS [2]
   and the SIPS URI scheme.  A subscriber SHOULD use SIPS URIs, if
   possible, when subscribing to session-specific policy events so that
   policies are transmitted over TLS.  Subscribers MAY perform server
   authentication, for example, via TLS or another transport mechanism.

3.7.  Notifier processing of SUBSCRIBE requests

   All subscriptions to session-specific policies SHOULD be
   authenticated and authorized before approval.  The notifier SHOULD
   authenticate the subscriber using any of the techniques available
   through SIP, including digest, S/MIME, TLS or other transport
   specific mechanisms.  Administrators SHOULD use an SIPS URI as a
   policy server URI.

   The authorization policy is at the discretion of the administrator.
   It is RECOMMENDED that all users are allowed to subscribe to the
   session-specific policies of their sessions.  A subscription to this
   event package will typically be established by a device that needs to
   know about the policies for its sessions.  However, subscriptions may
   also be established by applications and automata (e.g. a conference
   server).  In those cases, an authorization policy will typically be
   provided for these applications.

   Responding timely to a SUBSCRIBE requests is crucial for this event
   package.  A notifier must minimize the time needed for processing
   SUBSCRIBE requests and generating the initial NOTIFY.  This includes
   minimizing the time needed to generate an initial policy decision.  A
   short response time is in particular important for this event package
   since it minimizes the delay for fetching policies during an INVITE
   transaction and therefore reduces call setup time.  In addition,
   subscriptions to session-specific policies can be established while
   the subscriber is in an INVITE transaction at a point where it has
   received the 200 OK but before sending the ACK.  Delaying the



Hilt & Camarillo        Expires September 6, 2006               [Page 7]


Internet-Draft        Session Policy Event Package            March 2006


   creation of the initial NOTIFY would delay the transmission of the
   ACK (a more detailed discussion of this scenario can be found in
   [10]).

3.8.  Notifier generation of NOTIFY requests

   A notifier sends a notification in response to SUBSCRIBE requests as
   defined in RFC 3265 [7].  In addition, a notifier MAY send a
   notification at any time during the subscription.  Typically, it will
   send one every time the policy decision this subscription is for has
   changed.  When and why a policy decision changes is entirely at the
   discretion of the administrator.  A change in the policy decision may
   be triggered, for example, by a change in the network status, a
   change in the services used or simply by an update of the service
   level agreement with the customer.

   The policy decision document in a NOTIFY body MUST represent a
   complete policy decision.  Notifications that contain the deltas to
   previous policy decisions or partial policy decisions are not
   supported in this event package.

   The policy decision to reject a session is expressed by returning an
   empty NOTIFY body.  The notifier MAY terminate the subscription after
   sending such a notification if it can be expected that this decision
   will not change in the foreseeable future.  The notifier SHOULD keep
   the subscription up, if it expects that the session can be admitted
   at a later point in time.  A session is admitted by returning a
   policy decision document that requires some or no changes to the
   session.  If the format "application/sdp" is used, a session is
   admitted by returning an unmodified session description.  To admit a
   session with changes required, the notifier returns a session
   description that contains all necessary changes.  For example, to
   disallow video, the notifier returns a session description in which
   all media lines for video have been removed.  When making changes,
   the notifier SHOULD NOT use any session description format extensions
   that were not previously used by the subscriber in the original
   session description.

3.9.  Subscriber processing of NOTIFY requests

   A subscriber SHOULD apply the policy decision received to the session
   associated with this subscription.  If the body of a notification
   contains a policy decision in the "application/sdp" format, the
   subscriber SHOULD replace the current session description(s) (i.e.
   the ones submitted in the SUBSCRIBER request) with the ones received
   in the notification.  The subscriber MAY silently ignore extensions
   to the policy decision format it does not support.




Hilt & Camarillo        Expires September 6, 2006               [Page 8]


Internet-Draft        Session Policy Event Package            March 2006


   If the subscriber receives a notification with an empty body, the
   session has been rejected.  The subscriber SHOULD NOT attempt to
   establish this session.  However, the subscriber MAY keep up the
   subscription to session-specific policy events for this session since
   the policy decision may change.

   A subscriber may receive an update to a policy decision for a session
   that is already established.  The subscriber SHOULD apply the new
   policy decision to this session.  It may need to generate a re-INVITE
   or UPDATE request for the session or it may need to terminate this
   session.

3.10.  Handling of forked requests

   This event package allows the creation of only one dialog as a result
   of an initial SUBSCRIBE request.  The techniques to achieve this
   behavior are described in [7].

3.11.  Rate of notifications

   It is anticipated that the rate of policy changes will be very low.
   In any case, notifications SHOULD NOT be generated at a rate of more
   than once every five seconds.

3.12.  State Agents

   State agents play no role in this package.

3.13.  Examples

   TBD.


4.  Security Considerations

   Authentication and authorization is important for both, the
   subscriber and the notifier.

   A subscriber transmits information about the sessions it wants to
   establish to the policy server.  This data may contain sensitive
   information that needs to be protected.  In addition, a subscriber
   applies the policies it receives from the policy server to its
   sessions.  These policies can have a significant impact on the
   functionality and the behavior of a device.  A subscriber should
   therefore verify the identity of a policy server and make sure that
   policies have not been altered in transit.

   The policy decisions generated by the notifier may also reveal



Hilt & Camarillo        Expires September 6, 2006               [Page 9]


Internet-Draft        Session Policy Event Package            March 2006


   sensitive information about a user and about the network provider.  A
   notifier therefore needs to ensure that only authorized users can
   subscribe to session-specific policies.

   A session description may contain sensitive information the
   subscriber does not want to share with the notifier.  For example, it
   may contain keys for media encryption.  The subscriber needs to
   ensure that the session description it sends to the notifier in a
   SUBSCRIBE body only contains information it is actually willing to
   disclose to the notifier.

      ISSUE: more details on possible threads and protection mechanisms
      need to be worked out.


5.  IANA Considerations

5.1.  Event Package Name

   This specification registers an event package, based on the
   registration procedures defined in RFC 3265 [2].  The following is
   the information required for such a registration:

   Package Name: session-spec-policy

   Package or Template-Package: This is a package.

   Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX
   with the RFC number of this specification).

   Person to Contact: Volker Hilt, volkerh@bell-labs.com.

5.2.  Content-Disposition Types

   This document defines a new MIME Content-Disposition disposition-type
   value and a new parameter.

   The value "session-policy" indicates that the MIME body describes a
   session policy.

   An optional parameter "description" is defined for the disposition-
   type "session-policy".  This parameter may have the following values:

   o  The value "description=local" indicates that the MIME body
      contains the local session description of a user agent in an
      offer/answer exchange [11].  If the user agent has initiated the
      offer/answer exchange by sending an offer, then the local
      description is the offer.  If the user agent has received an offer



Hilt & Camarillo        Expires September 6, 2006              [Page 10]


Internet-Draft        Session Policy Event Package            March 2006


      and responds to it, then the local description is the answer.
   o  The value "description=remote" indicates that the MIME body
      contains the remote session description of a user agent in an
      offer/answer exchange [11].  If the user agent has initiated the
      offer/answer exchange, then the remote description is the answer
      it has received back.  If the user agent responds to an offer,
      then the remote description is the offer.

   If the parameter "description" is missing, the default value of
   "description=local" applies.


Appendix A.  Acknowledgements

   Many thanks to Jonathan Rosenberg for the discussions and the
   suggestions for this draft.


6.  References

6.1.  Normative References

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

   [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
        RFC 2246, January 1999.

   [3]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046,
        November 1996.

   [4]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [5]  Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile
        Data Set for Media Policy",
        draft-hilt-sipping-media-policy-dataset-01 (work in progress),
        March 2006.

   [6]  Petrie, D., "A Framework for Session Initiation Protocol User
        Agent Profile Delivery", draft-ietf-sipping-config-framework-07
        (work in progress), July 2005.

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

   [8]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,



Hilt & Camarillo        Expires September 6, 2006              [Page 11]


Internet-Draft        Session Policy Event Package            March 2006


        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [9]  Troost, R., Dorner, S., and K. Moore, "Communicating
        Presentation Information in Internet Messages: The Content-
        Disposition Header Field", RFC 2183, August 1997.

6.2.  Informative References

   [10]  Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for
         Session Initiation Protocol (SIP) Session Policies",
         draft-hilt-sipping-session-policy-framework-01 (work in
         progress), March 2006.

   [11]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.



































Hilt & Camarillo        Expires September 6, 2006              [Page 12]


Internet-Draft        Session Policy Event Package            March 2006


Authors' Addresses

   Volker Hilt
   Bell Labs/Lucent Technologies
   101 Crawfords Corner Rd
   Holmdel, NJ  07733
   USA

   Email: volkerh@bell-labs.com


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com

































Hilt & Camarillo        Expires September 6, 2006              [Page 13]


Internet-Draft        Session Policy Event Package            March 2006


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


Acknowledgment

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




Hilt & Camarillo        Expires September 6, 2006              [Page 14]