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.