[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

SIPPING                                                     G. Camarillo
Internet-Draft                                                  Ericsson
Expires: August 29, 2006                               February 25, 2006


  The Session Initiation Protocol (SIP) Grant Permission Event Package
            draft-camarillo-sipping-grant-permission-00.txt

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 August 29, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines the SIP Grant Permission event package.  This
   event package is used by permission servers to inform user agents
   about translations for which a particular user agent needs to give
   consent.








Camarillo                Expires August 29, 2006                [Page 1]


Internet-Draft       Grant Permission Event Package        February 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  3
   4.  Grant Permission Event Package Definition  . . . . . . . . . .  4
     4.1.  Event Package Name . . . . . . . . . . . . . . . . . . . .  4
       4.1.1.  Event Package Parameters . . . . . . . . . . . . . . .  4
       4.1.2.  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . .  4
       4.1.3.  Subscription Duration  . . . . . . . . . . . . . . . .  4
       4.1.4.  NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . .  5
       4.1.5.  Notifier Processing of SUBSCRIBE Requests  . . . . . .  5
       4.1.6.  Notifier Generation of NOTIFY Requests . . . . . . . .  5
       4.1.7.  Subscriber Processing of NOTIFY Requests . . . . . . .  5
       4.1.8.  Handling of Forked Requests  . . . . . . . . . . . . .  5
       4.1.9.  Rate of Notifications  . . . . . . . . . . . . . . . .  6
       4.1.10. State Agents . . . . . . . . . . . . . . . . . . . . .  6
   5.  Grant Permission Document Format . . . . . . . . . . . . . . .  6
     5.1.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  XCAP Usage for Manipulating Grant Permission Documents . . . .  8
     6.1.  Application Usage ID . . . . . . . . . . . . . . . . . . .  8
     6.2.  Structure of Manipulated Grant Permission Information  . .  8
     6.3.  Additional Constraints . . . . . . . . . . . . . . . . . .  8
     6.4.  Resource Interdependencies . . . . . . . . . . . . . . . .  8
     6.5.  Naming Conventions . . . . . . . . . . . . . . . . . . . .  8
     6.6.  Authorization Policies . . . . . . . . . . . . . . . . . .  8
     6.7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Usage of the 'grant-permission' Event Package with the
       XCAP Diff Format . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Permission Server Behavior . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     12.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13












Camarillo                Expires August 29, 2006                [Page 2]


Internet-Draft       Grant Permission Event Package        February 2006


1.  Introduction

   The framework for consent-based communications in SIP [8] identifies
   the need for users to be informed about translations for which they
   need to give consent.  Users are informed about these translations by
   receiving CONSENT requests from the relays performing the
   translations.  However, users are not on-line all the time and, so,
   sometimes are not able to receive CONSENT requests.

   Therefore, there is a need for a means to handle incoming CONSENT
   requests even when users are off-line.  Permission servers are
   defined as network elements that act as SIP user agents and handle
   CONSENT requests for a user.

   Permission servers inform users about new incoming CONSENT requests
   using the 'grant-permission' event package, which is defined in this
   document.


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.  Overview of Operation

   A user agents subscribes to its permission server using the 'grant-
   permission' event package.  NOTIFY requests within this event package
   can carry an XML document in the "application/grant-permission+xml"
   format, which is defined in Section 5, or in the "application/
   xcap-diff+xml" format [9].

   A document in the "application/grant-permission+xml" format informs
   the user agent about permission requests received so far.  For each
   permission request that has been received by the permission server,
   the document provides the user agent with the permission document
   carried in the CONSENT request and with the URI in the CONSENT
   request's Permission-Upload header field.

   A document in the "application/xcap-diff+xml" format informs the user
   agent that the document where the permission server stores pending
   permission requests for the user has changed.  The user agent then
   downloads the document in the "application/grant-permission+xml"
   format from the permission server using XCAP.



Camarillo                Expires August 29, 2006                [Page 3]


Internet-Draft       Grant Permission Event Package        February 2006


   Once the user agent handles a permission request (e.g., it gives or
   denies permission for the translation described in the permission
   request), the user agent needs to delete the permission request from
   the permission server.  The user agent uses XCAP to delete permission
   requests from a permission server.

      OPEN ISSUE: this forces UAs to support XCAP (at least to delete
      already-handled permission requests).  If this was a problem,
      permission servers could implement some type of garbage collection
      mechanism.  For example, they could delete automatically those
      permission requests the users already knows about (i.e., they have
      been sent in a NOTIFY request to the user agent).


4.  Grant Permission Event Package Definition

   This section provides the details for defining a SIP [4] event
   notification package, as specified by RFC 3265 [5].

4.1.  Event Package Name

   The name of this event package is "grant-permission".  This package
   name is carried in the Event and Allow-Events header, as defined in
   RFC 3265 [5].

4.1.1.  Event Package Parameters

   This package does not define any event package parameters.

4.1.2.  SUBSCRIBE Bodies

   A SUBSCRIBE for 'grant-permission' events MAY contain a body.  This
   body would serve the purpose of filtering the subscription.  The
   definition of such a body is outside the scope of this specification.

   A SUBSCRIBE for the 'grant-permission' package MAY be sent without a
   body.  This implies that the default session policy filtering policy
   has been requested.  The default policy is that notifications are
   generated every time there is any change in the translation state for
   the user.

4.1.3.  Subscription Duration

   The default expiration time for a subscription to a conference is one
   hour (3600 seconds).






Camarillo                Expires August 29, 2006                [Page 4]


Internet-Draft       Grant Permission Event Package        February 2006


4.1.4.  NOTIFY Bodies

   In this event package, the body of the notifications contains a grant
   permission document.  This document describes the translation state
   of a user.  All subscribers and notifiers MUST support the
   "application/grant-permission+xml" data format described in
   Section 5.  The subscribe request MAY contain an Accept header field.
   If no such header field is present, it has a default value of
   "application/grant-permission+xml".  If the header field is present,
   it MUST include "application/grant-permission+xml", and MAY include
   any other types capable of representing translation state.

   OPEN ISSUE: do we need to discuss how to use content indirection
   here?

   Additionally, all subscribers and notifiers SHOULD support the
   "application/xcap-diff+xml" format [9].  Section 7 discusses the
   usage of the 'grant-permission' event package with this format.

4.1.5.  Notifier Processing of SUBSCRIBE Requests

   The translation state can reveal sensitive information.  Therefore,
   all subscriptions SHOULD be authenticated and then authorized before
   approval.  Authorization policy is at the discretion of the
   administrator.

4.1.6.  Notifier Generation of NOTIFY Requests

   Notifications SHOULD be generated for the Grant Permission package
   whenever there is a change in the translation state for the user.

4.1.7.  Subscriber Processing of NOTIFY Requests

   NOTIFY requests contain the full translation state.  The subscriber
   does not need to perform any type of information aggregation.

4.1.8.  Handling of Forked Requests

   The translation state of a user is normally handled by a permission
   server and stored in a repository.  Therefore, there is usually a
   single place where the translation state of a user is resident.  This
   implies that a subscription for this information is readily handled
   by a single element with access to this repository.  There is,
   therefore, no compelling need for a subscription to session policy
   information to fork.  As a result, a subscriber MUST NOT create
   multiple dialogs as a result of a single subscription request.  The
   required processing to guarantee that only a single dialog is
   established is described in Section 4.4.9 of RFC 3265 [5].



Camarillo                Expires August 29, 2006                [Page 5]


Internet-Draft       Grant Permission Event Package        February 2006


4.1.9.  Rate of Notifications

   For reasons of congestion control, it is important that the rate of
   notifications not become excessive.  As a result, it is RECOMMENDED
   that the server doesn't generate notifications for a single
   subscriber at a rate faster than once every 5 seconds.

4.1.10.  State Agents

   State agents have no role in the handling of this package.


5.  Grant Permission Document Format

   Grant Permission information is an XML document that MUST be well-
   formed and valid.  It MUST be based on Extensible Markup Language
   (XML) 1.0 and MUST be encoded using UTF-8 [6].

   This specification makes use of XML namespaces for identifying Grant
   Permission documents.  The namespace URI for elements defined by this
   specification is a URN [2], using the namespace identifier 'ietf'
   defined by [3] and extended by [7].  This URN is:

      urn:ietf:params:xml:ns:grant-permission

   Grant Permission documents are identified with the MIME type
   "application/grant-permission+xml" and are instances of the XML
   schema defined in Section 5.1.

   A Grant Permission document begins with the root element tag <grant-
   permission>.  It consists of zero or more <permit> elements.  Each
   <permit> element contains a <rule> element and an <upload> element.
   The <rule> element contains a permission document describing the
   permission being requested.  The <upload> element contains the URI
   where the permission document granting or denying permission needs to
   be uploaded.

5.1.  XML Schema

   Implementations according to this specification MUST comply to the
   following XML Schema, which defines the constraints of the Grant
   Permission document:









Camarillo                Expires August 29, 2006                [Page 6]


Internet-Draft       Grant Permission Event Package        February 2006


   <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema
        targetNamespace="urn:ietf:params:xml:ns:grant-permission"
        xmlns:cr="urn:ietf:params:xml:ns:consent-rules"
        xmlns:cp="urn:ietf:params:xml:ns:common-policy"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">

   TBD.

      </xs:schema>


5.2.  Example

   The following is an example of a Grant Permission document:


   <?xml version="1.0" encoding="UTF-8"?>
      <cr:ruleset
       xmlns="urn:ietf:params:xml:ns:grant-permission"
       xmlns:cr="urn:ietf:params:xml:ns:consent-rules"
       xmlns:cp="urn:ietf:params:xml:ns:common-policy"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="urn:ietf:params:xml:ns:grant-permission
       grant-permission.xsd">
      <grant-permission>
       <permit>
         <cp:rule id="1">
          <cp:conditions>
           <cp:identity>
            <cp:id entity="bob@example.org" scheme="sip"/>
           </cp:identity>
           <cr:target>
            <cp:id entity="alices-friends@example.com" scheme="sip"/>
           </cr:target>
           <cr:sender>
            <cp:any/>
           </cr:sender>
          </cp:conditions>
          <cp:actions>
           <cr:trans-handling>pending</cr:trans-handling>
          </cp:actions>
          <cp:transformations/>
         </cp:rule>
         <upload>sip:upload@example.com</upload>
       </permit>



Camarillo                Expires August 29, 2006                [Page 7]


Internet-Draft       Grant Permission Event Package        February 2006


      </grant-permission>


6.  XCAP Usage for Manipulating Grant Permission Documents

6.1.  Application Usage 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 'grant-permission-manipulation' AUID within
   the IETF tree, via the IANA registration in the Section TBD.

6.2.  Structure of Manipulated Grant Permission Information

   The XML Schema for grant permission documents is defined in
   Section 5.1.  The namespace URI for the schema is:

   urn:ietf:params:xml:ns:grant-permission

6.3.  Additional Constraints

   There are no constraints on the document beyond those described by
   the XML schema and its description.

6.4.  Resource Interdependencies

   There are no resource interdependencies that need to be defined for
   this application usage.

6.5.  Naming Conventions

   There are no naming conventions that need to be defined for this
   application usage.

6.6.  Authorization Policies

   This application usage does not modify the default XCAP authorization
   policy, which allows only a user (owner) to read, write or modify
   their own documents.  A server can allow privileged users to modify
   documents that they do not own, but the establishment and indication
   of such policies is outside the scope of this document.

6.7.  Example

   TBD.






Camarillo                Expires August 29, 2006                [Page 8]


Internet-Draft       Grant Permission Event Package        February 2006


7.  Usage of the 'grant-permission' Event Package with the XCAP Diff
    Format

   As discussed in Section 4.1.4, if a client subscribing to the 'grant-
   permission' event package an Accept header field including the MIME
   type "application/xcap-diff+xml", the permission server has the
   option of returning documents in this format (instead of in the
   'application/grant-permission+xml' format).

   Upon initial subscription, the permission server does not know which
   instance of the grant permission document for the user (where each
   instance is identified by an etag) the client currently posesses, if
   any.  Indeed, upon startup, the client will not have any documents.

   The initial NOTIFY request in this case MUST include a <document>
   element the grant permission document for the user.  The "previous-
   etag" attribute MUST be absent, and the "new-etag" attribute MUST be
   present and contain the entity tag for the current version of the
   document.  An XCAP diff document structured this way is called a
   "reference" XCAP diff document.  It establishes the baseline etag and
   document URI for the document covered by the subscription.

   Upon receipt of this document, the client can determine whether its
   local instance document, if any, matches the etag in the XCAP diff
   document.  If they do not match, the client SHOULD perform a
   conditional GET for each document.  The document URI is constructed
   by appending the XCAP root in the "xcap-root" attribute of the <xcap-
   diff> element to the escape coded "doc-selector" from the <document>
   element.  The request is made conditional by including an If-Match
   header field, with the value of the etag from the <document> element.
   So long as the documents haven't changed between the NOTIFY and the
   GET, the client will obtain the reference version that the server
   will use for subsequent notifications.

   If the conditional GET should fail, the client SHOULD generate a
   SUBSCRIBE refresh request to trigger a new NOTIFY.  The server will
   always generate a "reference" XML diff document on receipt of a
   SUBSCRIBE refresh.  This establishes a new baseline etag, and the
   client can then attempt to do another fetch.

   Once the client has obtained the version of the document identified
   in the reference XML diff, it can process NOTIFY requests on that
   subscription.  To process the NOTIFY requests, it makes sure that its
   current version matches the version in the "previous-etag" attribute
   of the <document> element.  If not, the client can then fetch the
   updated document from the server.  If they do match, the client has
   the most current version.




Camarillo                Expires August 29, 2006                [Page 9]


Internet-Draft       Grant Permission Event Package        February 2006


8.  Permission Server Behavior

   TBD.


9.  IANA Considerations

   TBD.


10.  Security Considerations

   TBD.


11.  Acknowledgements

   TBD.


12.  References

12.1.  Normative References

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

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

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

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

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

   [6]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        STD 63, RFC 3629, November 2003.

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

   [8]  Rosenberg, J., "A Framework for Consent-Based Communications in
        the Session Initiation  Protocol (SIP)",
        draft-ietf-sipping-consent-framework-03 (work in progress),



Camarillo                Expires August 29, 2006               [Page 10]


Internet-Draft       Grant Permission Event Package        February 2006


        October 2005.

   [9]  Rosenberg, J., "An Extensible Markup Language (XML) Document
        Format for Indicating A Change  in XML Configuration Access
        Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-02 (work
        in progress), October 2005.

12.2.  Informative References











































Camarillo                Expires August 29, 2006               [Page 11]


Internet-Draft       Grant Permission Event Package        February 2006


Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com










































Camarillo                Expires August 29, 2006               [Page 12]


Internet-Draft       Grant Permission Event Package        February 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.




Camarillo                Expires August 29, 2006               [Page 13]


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