Internet DRAFT - draft-beckmann-sip-reg-event
draft-beckmann-sip-reg-event
SIP Working group Mayer
Internet-Draft Beckmann
Expires: September 30, 2002 Siemens AG
April 2002
Registration Event package
draft-beckmann-sip-reg-event-01
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 September 30, 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 September 30, 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 September 30, 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 September 30, 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 September 30, 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:xml:ns:cpim-pidf:registration
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:
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf:"
xmlns:registeration="urn:ietf:params:xml:ns:cpim-pidf:registration"
entity="sip:shingo@jp.fujitsu.com"/>
<tuple id="shingo_1@jp.fujitsu.com">
<status>
<basic>open</basic>
</status>
<tuple id="shingo_2jp.fujitsu.com">
<status>
<basic>open</basic>
<registration>re-authenticate</registration>
</status>
</presence>
Mayer & Beckmann Expires September 30, 2002 [Page 5]
Internet-Draft Registration Event package April 2002
4. IANA considerations
This memo calls for IANA to:
o registers an event package, based on the registration procedures
defined in [2].
o register a new XML namespace URN per [draft-mealling-iana-xmlns-
registry-03].
The following is the information required for registration of an
event package:
Package Name: registration-state
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: Mark Beckmann, Mark.Beckmann@siemens.com
The registration templates for the XML namesapce URN are below. It
calls for the creation of a new registry for status type values, and
corresponding URN assignments per [draft-mealling-iana-urn-02]. The
new registry and initial registrations are described at section 7.3
below.
URN sub-namespace registration for urn:ietf:params:xml:ns:cpim-
pidf:registration
URI
urn:ietf:params:xml:ns:cpim-pidf:registration
Description:
This is the XML namespace URI for XML elements defined by
[RFCXXXX] to describe CPIM presence information in application/
cpim-pidf+xml content type.
Registrant Contact:
IETF, SP working group, <sip@ietf.org>
Mark Beckmann, <Mark.Beckmann@siemens.com>
Mayer & Beckmann Expires September 30, 2002 [Page 6]
Internet-Draft Registration Event package April 2002
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"/>
<meta name="generator" content="Adobe GoLive 6"/>
<title>Welcome to Adobe GoLive 6</title>
</head>
<body>
<h1>Namespace for registration state information</h1>
<h2>application/cpim-pidf+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
Mayer & Beckmann Expires September 30, 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 September 30, 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 September 30, 2002 [Page 9]
