idnits 2.17.1
draft-beckmann-sip-reg-event-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 4 instances of too long lines in the document, the longest one
being 14 characters in excess of 72.
** The abstract seems to contain references ([3]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 187 has weird spacing: '... is the info...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 2002) is 8052 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: 'URN' on line 154
-- Looks like a reference, but probably isn't: 'URN-NS-IETF' on line 154
-- Looks like a reference, but probably isn't: 'URN-SUB-NS' on line 155
-- Looks like a reference, but probably isn't: 'RFCXXXX' on line 215
== Unused Reference: '1' is defined on line 244, but no explicit reference
was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIP Working group Mayer
3 Internet-Draft Beckmann
4 Expires: September 30, 2002 Siemens AG
5 April 2002
7 Registration Event package
8 draft-beckmann-sip-reg-event-01
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at http://
26 www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on September 30, 2002.
33 Copyright Notice
35 Copyright (C) The Internet Society (2002). All Rights Reserved.
37 Abstract
39 This draft defines an event package that allows a network entity to
40 request to be notified of changes in the registration state of a
41 particular user. Subscription and notification of registration state
42 is supported by defining an event package within the general SIP
43 event notification event framework. This event package is based on
44 the Presence event package as specified in [3] and therefore this
45 draft only describes the deltas to the Presence event package.
47 1. Introduction
49 In some environments user equipment or network entities require
50 information about the registration state of a user. This
51 registration state information is identical with the existing
52 presence information regarding coding and handling, but may
53 additionally be associated with the users authentication to the
54 network, i.e. if a user is registered he is also regarded as
55 authenticated against network and if the user is de-registered also
56 the authentication is no longer valid. This information is handled
57 and stored by the registrar, which also handles the authentication
58 procedures. Due to this, the set of entities which are allowed to
59 subscribe to this event package will be different from the one that
60 is allowed to subscribe to the same users presence information.
62 This specification creates a new registration event package within
63 the general SIP event notification framework as specified in [2].
64 This event package is based on the Presence event package as
65 described in [3].
67 An environment as described above may additionally require the
68 network capability to request re-authentication from the user, which
69 is, in this case, identical with a re-registration. For this purpose
70 the additional state "re-authenticate" is defined for the
71 registration state event package, which is not part of the already
72 existing presence data format.
74 An entity that is interested in the registration state of a
75 particular user subscribes to registration event package at the users
76 registrar. The data format used for notification of the subscriber
77 is based on the Presence data format as it is specified in [4].
79 2. Registration State Event package
81 The SIP event framework [2] defines a SIP extension for subscribing
82 to, and receiving notifications of, events. It leaves the definition
83 of many additional aspects of these events to concrete extensions,
84 also known as event packages. This document qualifies as an event
85 package. This section fills in the information required by [2].
86 However, since this event package is based on the Presence event
87 package only the differences between both packages are described.
89 2.1 Event package name
91 The name of this package is "registration-state". As specified in
92 [2], this header appears in SUBSCRIBE and NOTIFY requests.
94 Example:
96 Event: registration-state
98 2.2 Event package parameters
100 No differences to the Presence event package.
102 2.3 SUBSCRIBE bodies
104 This package does not define a SUBSCRIBE body
106 2.4 Subscription duration
108 No differences to the Presence event package.
110 2.5 NOTIFY bodies
112 As described in [3], the NOTIFY request contains a presence document
113 with the difference that the presence document used for this event
114 package describes the registration state of the presentity. The
115 registration state is described using the same data format as in [3]
116 with an additional extension as defined in section 3.
118 2.6 Notifier processing of SUBSCRIBE requests
120 The notifier processing of SUBSCRIBE requests is the same as
121 described in [3], whereas the notifier in this case corresponds to
122 the registrar.
124 2.7 Notifier generation of NOTIFY requests
126 The rules for generation of NOTIFY requests by the notifier are the
127 same as the ones described in [3], whereas the notifier in this case
128 corresponds to the registrar.
130 2.8 Subscriber processing of NOTIFY requests
132 No differences to the Presence event package.
134 2.9 Handling of forked requests
136 No differences to the Presence event package.
138 2.10 Rate of notifications
140 No differences to the Presence event package.
142 3. Registration state data format
144 The registration state data format is based on the presence data
145 format as specified in [4]. The registration states that need to be
146 conveyed are "registered", "deregistered" and "re-authenticate". The
147 registration states "registered" and "deregistered" can be mapped to
148 the basic presence status values "open" and "closed". In order to
149 indicate the additional state "re-authenticate" an extension is
150 defined in this document according to the rules specified in [4]. As
151 described there, all elements and attributes are associated with a
152 "namespace", which is in turn associated with a globally unique URI.
153 The namespace URI for elements defined by this document is a URN
154 [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF]
155 and extended by [URN-SUB-NS]:
157 urn:ietf:params:xml:ns:cpim-pidf:registration
159 The tuple id element is used in this event package to identify the
160 adress to which the registration state applies. The registration
161 state data format therefore may look like:
163
166
167
168 open
169
170
171
172 open
173 re-authenticate
174
175
177 4. IANA considerations
179 This memo calls for IANA to:
181 o registers an event package, based on the registration procedures
182 defined in [2].
184 o register a new XML namespace URN per [draft-mealling-iana-xmlns-
185 registry-03].
187 The following is the information required for registration of an
188 event package:
190 Package Name: registration-state
192 Package or Template-Package: This is a package.
194 Published Document: RFC XXXX (Note to RFC Editor: Please fill in
195 XXXX with the RFC number of this specification).
197 Person to Contact: Mark Beckmann, Mark.Beckmann@siemens.com
199 The registration templates for the XML namesapce URN are below. It
200 calls for the creation of a new registry for status type values, and
201 corresponding URN assignments per [draft-mealling-iana-urn-02]. The
202 new registry and initial registrations are described at section 7.3
203 below.
205 URN sub-namespace registration for urn:ietf:params:xml:ns:cpim-
206 pidf:registration
208 URI
210 urn:ietf:params:xml:ns:cpim-pidf:registration
212 Description:
214 This is the XML namespace URI for XML elements defined by
215 [RFCXXXX] to describe CPIM presence information in application/
216 cpim-pidf+xml content type.
218 Registrant Contact:
220 IETF, SP working group,
222 Mark Beckmann,
223 XML
224 BEGIN
225
226
228
229
230
231
232 Welcome to Adobe GoLive 6
233
234
235 Namespace for registration state information
236 application/cpim-pidf+xml
237 See RFCXXXX.
238
239
240 END
242 References
244 [1] J. Rosenberg, H. Schulzrinne, et al., "SIP - Session Initiation
245 Protocol", March 2002.
247 [2] A. Roach et al. , "SIP-specific event notification", Feb. 2002.
249 [3] J. Rosenberg, D. Willis et al., "SIP Extensions for Presence",
250 March 2002.
252 [4] H. Sugano et al., "CPIM Presence Format", March 2002.
254 Authors' Addresses
256 Georg Mayer
257 Siemens AG
258 Hoffmannstr. 51
259 Munich 81359
260 Germany
262 EMail: Georg.Mayer@icn.siemens.de
264 Mark Beckmann
265 Siemens AG
266 P.O. Box 100702
267 Salzgitter 38207
268 Germany
270 EMail: Mark.Beckmann@siemens.com
272 Full Copyright Statement
274 Copyright (C) The Internet Society (2002). All Rights Reserved.
276 This document and translations of it may be copied and furnished to
277 others, and derivative works that comment on or otherwise explain it
278 or assist in its implementation may be prepared, copied, published
279 and distributed, in whole or in part, without restriction of any
280 kind, provided that the above copyright notice and this paragraph are
281 included on all such copies and derivative works. However, this
282 document itself may not be modified in any way, such as by removing
283 the copyright notice or references to the Internet Society or other
284 Internet organizations, except as needed for the purpose of
285 developing Internet standards in which case the procedures for
286 copyrights defined in the Internet Standards process must be
287 followed, or as required to translate it into languages other than
288 English.
290 The limited permissions granted above are perpetual and will not be
291 revoked by the Internet Society or its successors or assigns.
293 This document and the information contained herein is provided on an
294 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
295 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
296 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
297 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
298 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
300 Acknowledgement
302 Funding for the RFC Editor function is currently provided by the
303 Internet Society.