SIP Working group Mayer Internet-Draft Beckmann Expires: October 28, 2002 Siemens AG April 29, 2002 Registration Event package draft-beckmann-sip-reg-event-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 October 28, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft defines an event package that allows a network entity to request to be notified of changes in the registration state of a particular user. Subscription and notification of registration state is supported by defining an event package within the general SIP event notification event framework. This event package is based on the Presence event package as specified in [3] and therefore this draft only describes the deltas to the Presence event package. Mayer & Beckmann Expires October 28, 2002 [Page 1] Internet-Draft Registration Event package April 2002 1. Introduction In some environments user equipment or network entities require information about the registration state of a user. This registration state information is identical with the existing presence information regarding coding and handling, but may additionally be associated with the users authentication to the network, i.e. if a user is registered he is also regarded as authenticated against network and if the user is de-registered also the authentication is no longer valid. This information is handled and stored by the registrar, which also handles the authentication procedures. Due to this, the set of entities which are allowed to subscribe to this event package will be different from the one that is allowed to subscribe to the same users presence information. This specification creates a new registration event package within the general SIP event notification framework as specified in [2]. This event package is based on the Presence event package as described in [3]. An environment as described above may additionally require the network capability to request re-authentication from the user, which is, in this case, identical with a re-registration. For this purpose the additional state "re-authenticate" is defined for the registration state event package, which is not part of the already existing presence data format. An entity that is interested in the registration state of a particular user subscribes to registration event package at the users registrar. The data format used for notification of the subscriber is based on the Presence data format as it is specified in [4]. Mayer & Beckmann Expires October 28, 2002 [Page 2] Internet-Draft Registration Event package April 2002 2. Registration State Event package The SIP event framework [2] defines a SIP extension for subscribing to, and receiving notifications of, events. It leaves the definition of many additional aspects of these events to concrete extensions, also known as event packages. This document qualifies as an event package. This section fills in the information required by [2]. However, since this event package is based on the Presence event package only the differences between both packages are described. 2.1 Event package name The name of this package is "registration-state". As specified in [2], this header appears in SUBSCRIBE and NOTIFY requests. Example: Event: registration-state 2.2 Event package parameters No differences to the Presence event package. 2.3 SUBSCRIBE bodies This package does not define a SUBSCRIBE body 2.4 Subscription duration No differences to the Presence event package. 2.5 NOTIFY bodies As described in [3], the NOTIFY request contains a presence document with the difference that the presence document used for this event package describes the registration state of the presentity. The registration state is described using the same data format as in [3] with an additional extension as defined in section 3. 2.6 Notifier processing of SUBSCRIBE requests The notifier processing of SUBSCRIBE requests is the same as described in [3], whereas the notifier in this case corresponds to the registrar. 2.7 Notifier generation of NOTIFY requests The rules for generation of NOTIFY requests by the notifier are the Mayer & Beckmann Expires October 28, 2002 [Page 3] Internet-Draft Registration Event package April 2002 same as the ones described in [3], whereas the notifier in this case corresponds to the registrar. 2.8 Subscriber processing of NOTIFY requests No differences to the Presence event package. 2.9 Handling of forked requests No differences to the Presence event package. 2.10 Rate of notifications No differences to the Presence event package. Mayer & Beckmann Expires October 28, 2002 [Page 4] Internet-Draft Registration Event package April 2002 3. Registration state data format The registration state data format is based on the presence data format as specified in [4]. The registration states that need to be conveyed are "registered", "deregistered" and "re-authenticate". The registration states "registered" and "deregistered" can be mapped to the basic presence status values "open" and "closed". In order to indicate the additional state "re-authenticate" an extension is defined in this document according to the rules specified in [4]. As described there, all elements and attributes are associated with a "namespace", which is in turn associated with a globally unique URI. The namespace URI for elements defined by this document is a URN [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] and extended by [URN-SUB-NS]: urn:ietf:params:cpim-presence:registration-state The tuple id element is used in this event package to identify the adress to which the registration state applies. The registration state data format therefore may look like: open open Welcome to Adobe GoLive 6

Namespace for registration state information

application/cpim-pidf+xml

See RFCXXXX.

END Mayer & Beckmann Expires October 28, 2002 [Page 7] Internet-Draft Registration Event package April 2002 References [1] J. Rosenberg, H. Schulzrinne, et al., "SIP - Session Initiation Protocol", March 2002. [2] A. Roach et al. , "SIP-specific event notification", Feb. 2002. [3] J. Rosenberg, D. Willis et al., "SIP Extensions for Presence", March 2002. [4] H. Sugano et al., "CPIM Presence Format", March 2002. Authors' Addresses Georg Mayer Siemens AG Hoffmannstr. 51 Munich 81359 Germany EMail: Georg.Mayer@icn.siemens.de Mark Beckmann Siemens AG P.O. Box 100702 Salzgitter 38207 Germany EMail: Mark.Beckmann@siemens.com Mayer & Beckmann Expires October 28, 2002 [Page 8] Internet-Draft Registration Event package April 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Mayer & Beckmann Expires October 28, 2002 [Page 9]