idnits 2.17.1 draft-ietf-sipping-reg-event-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 28, 2002) is 7844 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) ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 3023 (ref. '8') (Obsoleted by RFC 7303) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIPPING WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 draft-ietf-sipping-reg-event-00.txt 6 October 28, 2002 7 Expires: April 2003 9 A Session Initiation Protocol (SIP) Event Package for Registrations 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document defines a Session Initiation Protocol (SIP) event 35 package for registrations. Through its REGISTER method, SIP allows a 36 user agent to create, modify, and delete registrations. Registrations 37 can also be altered by administrators in order to enforce policy. As 38 a result, these registrations represent a piece of state in the 39 network that can change dynamically. There are many cases where a 40 user agent would like to be notified of changes in this state. This 41 event package defines a mechanism by which those user agents can 42 request and obtain such notifications. 44 Table of Contents 46 1 Introduction ........................................ 3 47 2 Terminology ......................................... 3 48 3 Usage Scenarios ..................................... 3 49 3.1 Forcing Re-Authentication ........................... 3 50 3.2 Composing Presence .................................. 4 51 3.3 Welcome Notices ..................................... 4 52 4 Package Definition .................................. 5 53 4.1 Event Package Name .................................. 5 54 4.2 Event Package Parameters ............................ 5 55 4.3 SUBSCRIBE Bodies .................................... 5 56 4.4 Subscription Duration ............................... 6 57 4.5 NOTIFY Bodies ....................................... 6 58 4.6 Notifier Processing of SUBSCRIBE Requests ........... 7 59 4.7 Notifier Generation of NOTIFY Requests .............. 7 60 4.7.1 The Registration State Machine ...................... 7 61 4.7.2 Applying the state machine .......................... 9 62 4.8 Subscriber Processing of NOTIFY Requests ............ 10 63 4.9 Handling of Forked Requests ......................... 10 64 4.10 Rate of Notifications ............................... 10 65 4.11 State Agents ........................................ 11 66 5 Registration Information ............................ 11 67 5.1 Structure of Registration Information ............... 11 68 5.2 Computing Registrations from the Document ........... 13 69 5.3 Example ............................................. 14 70 5.4 XML Schema .......................................... 15 71 6 Example Call Flow ................................... 17 72 7 Security Considerations ............................. 20 73 8 IANA Considerations ................................. 20 74 8.1 SIP Event Package Registration ...................... 20 75 8.2 application/reginfo+xml MIME Registration ........... 20 76 8.3 URN Sub-Namespace Registration for 77 urn:ietf:params:xml:ns:reginfo ................................. 21 78 9 Changes since draft-rosenberg-sip-reg-event-00.txt 79 ................................................................ 22 80 10 Contributors ........................................ 22 81 11 Acknowledgements .................................... 23 82 12 Authors Addresses ................................... 23 83 13 Normative References ................................ 24 84 14 Informative References .............................. 24 86 1 Introduction 88 The Session Initiation Protocol (SIP) [1] provides all of the 89 functions needed for the establishment and maintenance of 90 communications sessions between users. One of the functions it 91 provides is a registration operation. A registration is a binding 92 between a SIP URI, called an address-of-record, and one or more 93 contact URIs. These contact URIs represent additional resources that 94 can be contacted in order to reach the user identified by the 95 address-of-record. When a proxy receives a request within its domain 96 of administration, it uses the Request-URI as an address-of-record, 97 and uses the contacts bound to the address-of-record to forward (or 98 redirect) the request. 100 The SIP REGISTER method provides a way for a user agent to manipulate 101 registrations. Contacts can be added or removed, and the current set 102 of contacts can be queried. Registrations can also change as a result 103 of administrator policy. For example, if a user is suspected of 104 fraud, their registration can be deleted so that they cannot receive 105 any requests. Registrations also expire after some time if not 106 refreshed. 108 Registrations represent a dynamic piece of state maintained by the 109 network. There are many cases in which user agents would like to know 110 about changes to the state of registrations. The SIP Events Framework 111 [2] defines a generic framework for subscription to, and notification 112 of, events related to SIP systems. The framework defines the methods 113 SUBSCRIBE and NOTIFY, and introduces the notion of a package. A 114 package is a concrete application of the event framework to a 115 particular class of events. Packages have been defined for user 116 presence [9], for example. This specification defines a package for 117 registration state. 119 2 Terminology 121 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 123 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 124 indicate requirement levels for compliant implementations. 126 3 Usage Scenarios 128 There are many applications of this event package. A few are 129 documented here for illustrative purposes. 131 3.1 Forcing Re-Authentication 133 It is anticipated that many SIP devices will be wireless devices that 134 will be always-on, and therefore, continually registered to the 135 network. Unfortunately, history has shown that these devices can be 136 compromised. To deal with this, an administrator will want to 137 terminate or shorten a registration, and ask the device to re- 138 register so it can be re-authenticated. To do this, the device 139 subscribes to the registration event package for the address-of- 140 record that it is registering contacts against. When the 141 administrator shortens registration (for example, when fraud is 142 suspected) the registration server sends a notification to the 143 device. It can then re-register and re-authenticate itself. If it 144 cannot re-authenticate, the expiration will terminate shortly 145 thereafter. 147 3.2 Composing Presence 149 An important concept to understand is the relationship between this 150 event package and the event package for user presence [9]. User 151 presence represents the willingness and ability of a user to 152 communicate with other users on the network. It is composed of a set 153 of contact addresses that represent the various means for contacting 154 the user. Those contact addresses might represent the contact address 155 for voice, for example. Typically, the contact address listed for 156 voice will be an address-of-record. The status of that contact 157 (whether its open or closed) may depend on any number of factors, 158 including the state of any registrations against that address-of- 159 record. As a result, registration state can be viewed as an input to 160 the process which determines the presence state of a user. 161 Effectively, registration state is "raw" data, which is combined with 162 other information about a user to generate a document that describes 163 the user presence. 165 In fact, this event package allows for a presence server to be 166 separated from a SIP registration server, yet still use registration 167 information to construct a presence document. When a presence server 168 receives a presence subscription for some user, the presence server 169 itself would generate a subscription to the registration server for 170 the registration event package. As a result, the presence server 171 would learn about the registration state for that user, and it could 172 use that information to generate presence documents. 174 3.3 Welcome Notices 176 A common service in current mobile networks are "welcome notices". 177 When the user turns on their phone in a foreign country, they receive 178 a message that welcomes them to the country, and provides information 179 on transportation services, for example. 181 In order to implement this service in a SIP system, an application 182 server can subscribe to the registration state of the user. When the 183 user turns on their phone, the phone will generate a registration. 184 This will result in a notification being sent to the application that 185 the user has registered. The application can then send a SIP MESSAGE 186 request [10] to the device, welcoming the user and providing any 187 necessary information. 189 4 Package Definition 191 This section fills in the details needed to specify an event package 192 as defined in Section 5.4 of [2]. 194 4.1 Event Package Name 196 The SIP Events specification requires package definitions to specify 197 the name of their package or template-package. 199 The name of this package is "reg". As specified in [2], this value 200 appears in the Event header present in SUBSCRIBE and NOTIFY requests. 202 Example: 204 Event: reg 206 4.2 Event Package Parameters 208 The SIP Events specification requires package and template-package 209 definitions to specify any package specific parameters of the Event 210 header that are used by it. 212 No package specific Event header parameters are defined for this 213 event package. 215 4.3 SUBSCRIBE Bodies 217 The SIP Events specification requires package or template-package 218 definitions to define the usage, if any, of bodies in SUBSCRIBE 219 requests. 221 A SUBSCRIBE for registration events MAY contain a body. This body 222 would serve the purpose of filtering the subscription. The definition 223 of such a body is outside the scope of this specification. 225 A SUBSCRIBE for the registration package MAY be sent without a body. 226 This implies that the default registration filtering policy has been 227 requested. The default policy is: 229 o Notifications are generated every time there is any change in 230 the state of any of the registered contacts for the resource 231 being subscribed to. Those notifications only contain 232 information on the contacts whose state has changed. 234 o Notifications triggered from a SUBSCRIBE contain full state 235 (the list of all contacts bound to the address-of-record). 237 Of course, the server can apply any policy it likes to the 238 subscription. 240 4.4 Subscription Duration 242 The SIP Events specification requires package definitions to define a 243 default value for subscription durations, and to discuss reasonable 244 choices for durations when they are explicitly specified. 246 Registration state changes as contacts are created through REGISTER 247 requests, and then time out due to lack of refresh. Their rate of 248 change is therefore related to the typical registration expiration. 249 Since the default expiration for registrations is 3600 seconds, the 250 default duration of subscriptions to registration state is also 3600 251 seconds. Of course, clients MAY include an Expires header in the 252 SUBSCRIBE request asking for a different duration. 254 4.5 NOTIFY Bodies 256 The SIP Events specification requires package definitions to describe 257 the allowed set of body types in NOTIFY requests, and to specify the 258 default value to be used when there is no Accept header in the 259 SUBSCRIBE request. 261 The body of a notification of a change in registration state contains 262 a registration information document. This document describes some or 263 all of the contacts associated with a particular address-of-record. 264 All subscribers to registration state MUST support the 265 application/reginfo+xml format described in Section 5, and MUST list 266 its MIME type, application/reginfo+xml, in an Accept header present 267 in the SUBSCRIBE request. 269 Other registration information formats might be defined in the 270 future. In that case, the subscriptions MAY indicate support for 271 other formats. However, they MUST always support and list 272 application/reginfo+xml as an allowed format. 274 Of course, the notifications generated by the server MUST be in one 275 of the formats specified in the Accept header in the SUBSCRIBE 276 request. 278 4.6 Notifier Processing of SUBSCRIBE Requests 280 The SIP Events framework specifies that packages should define any 281 package-specific processing of SUBSCRIBE requests at a notifier, 282 specifically with regards to authentication and authorization. 284 Registration state can be sensitive information. Therefore, all 285 subscriptions to it SHOULD be authenticated and authorized before 286 approval. Authentication MAY be performed using any of the techniques 287 available through SIP, including digest, S/MIME, TLS or other 288 transport specific mechanisms [1]. Authorization policy is at the 289 discretion of the administrator, as always. However, a few 290 recommendations can be made. 292 It is RECOMMENDED that a user be allowed to subscribe to their own 293 registration state. Such subscriptions are useful when there are many 294 devices that represent a user, each of which needs to learn the 295 registration state of the other devices. We also anticipate that 296 applications and automata will frequently be subscribers to the 297 registration state. In those cases, authorization policy will 298 typically be provided ahead of time. 300 4.7 Notifier Generation of NOTIFY Requests 302 The SIP Event framework requests that packages specify the conditions 303 under which notifications are sent for that package, and how such 304 notifications are constructed. 306 To determine when a notifier should send notifications of changes in 307 registration state, we define a finite state machine (FSM) that 308 represents the state of a contact for a particular address-of-record. 309 Transitions in this state machine MAY result in the generation of 310 notifications. These notifications will carry information on the new 311 state and the event which triggered the state change. It is important 312 to note that this FSM is just a model of the registration state 313 machinery maintained by a server. An implementation would map its own 314 state machines to this one in an implementation-specific manner. 316 4.7.1 The Registration State Machine 318 The underlying state machine for a registration is shown in Figure 1. 319 The machine is very simple. An instance of this machine is associated 320 with each address-of-record. When the first contact is registered to 321 that address-of-record, the state machine moves from init to active. 323 +------------+ 324 | | 325 | Init | 326 | | 327 +------------+ 328 | 329 V 330 +------------+ 331 | | 332 | Active | 333 | | 334 +------------+ 335 | 336 V 337 +------------+ 338 | | 339 | Terminated | 340 | | 341 +------------+ 343 Figure 1: Registration State Machine 345 As long as there is at least one contact bound to the address-of- 346 record, the state machine remains in the active state. When the last 347 contact expires or is removed, the registration transitions to 348 terminated. 350 In addition to this state machine, each registration is associated 351 with a set of contacts, each of which is modelled with its own state 352 machine. The diagram for the per-contact state machine is shown in 353 Figure 2. This FSM is identical to the registration state machine in 354 terms of its states, but has many more transition events. 356 When a new contact is added, the FSM moves from the init state into 357 the active state. There are two ways in which it can become active. 358 One is through an actual SIP REGISTER request (correspoding to the 359 registered event), and the other is when the contact is created 360 administratively, or through some non-SIP means (the created event). 362 +------+ 363 | | refreshed 364 | | shortened 365 V | 366 +------------+ +------------+ +------------+ 367 | | | | | | 368 | Init |----------->| Active |----------->| Terminated | 369 | | | | | | 370 +------------+ registered +------------+ expired +------------+ 371 created deactivated 372 probation 373 unregistered 374 rejected 376 Figure 2: Contact State Machine 378 The FSM remains in the active state so long as the contact is bound 379 to the address-of-record. When a contact is refreshed through a 380 REGISTER request, the FSM stays in the same state, but a refreshed 381 event is generated. Likewise, when an administrator modifies the 382 expiration time of a binding (without deleting the binding) to 383 trigger the contact to re-register and possibly re-authenticate, the 384 FSM stays in the active state, but a shortened event is generated. 386 When the contact is no longer bound to the address-of-record, the FSM 387 moves to the terminated state. There are several reasons this can 388 happen. The first is an expiration, which occurs when the contact was 389 not refreshed by a REGISTER request. The second reason is 390 deactivated. This occurs when the administrator has removed the 391 contact as a valid binding, but still wishes the client to attempt to 392 re-register the contact. In contast, the rejected event occurs when 393 an active contact is removed by the administrator, but re- 394 registrations will not help to re-establish it. This might occur if a 395 user does not pay their bills, for example. The probation event 396 occurs when an active contact is removed by the administrator, and 397 the administrator wants the client to re-register, but to do so at a 398 later time. The unregistered event occurs when a REGISTER request 399 sets the expiration time of that contact to zero. 401 4.7.2 Applying the state machine 403 The server MAY generate a notification to subscribers when any event 404 occurs in the state machine. Whether it does or does not is policy 405 dependent. However, several guidelines are defined. 407 As a general rule, when a subscriber is authorized to receive 408 notifications about a set of registrations, it is RECOMMENDED that 409 notifications contain information about those contacts which have 410 changed state (and thus triggered a notification), instead of 411 delivering the current state of every contact in all registrations. 412 However, notifications triggered as a result of a fetch operation (a 413 SUBSCRIBE with Expires of 0) SHOULD result in the full state of all 414 contacts for all registrations to be present in the NOTIFY. 416 4.8 Subscriber Processing of NOTIFY Requests 418 The SIP Events framework expects packages to specify how a subscriber 419 processes NOTIFY requests in any package specific ways, and in 420 particular, how it uses the NOTIFY requests to contruct a coherent 421 view of the state of the subscribed resource. Typically, the NOTIFY 422 will only contain information for contacts whose state has changed. 423 To construct a coherent view of the total state of all registrations, 424 the subscriber will need to combine NOTIFYs received over time. The 425 details of this process depend on the document format used to convey 426 registration state. Section 5 outlines the process for the 427 application/reginfo+xml format. 429 4.9 Handling of Forked Requests 431 The SIP Events framework mandates that packages indicate whether or 432 not forked SUBSCRIBE requests can install multiple subscriptions. 434 Registration state is normally stored in some repository (whether it 435 be co-located with a proxy/registrar or in a separate database). As 436 such, there is usually a single place where the contact information 437 for a particular address-of-record is resident. This implies that a 438 subscription for this information is readily handled by a single 439 element with access to this repository. There is, therefore, no 440 compelling need for a subscription to registration information to 441 fork. As a result, a subscriber MUSTNOT create multiple dialogs as a 442 result of a single subscription request. The required processing to 443 guarantee that only a single dialog is established is described in 444 Section 5.4.9 of the SIP Events framework [2]. 446 4.10 Rate of Notifications 448 The SIP Events framework mandates that packages define a maximum rate 449 of notifications for their package. 451 For reasons of congestion control, it is important that the rate of 452 notifications not become excessive. As a result, it is RECOMMENDED 453 that the server not generate notifications for a single subscriber at 454 a rate faster than once every 5 seconds. 456 4.11 State Agents 458 The SIP Events framework asks packages to consider the role of state 459 agents in their design. 461 State agents have no role in the handling of this package. 463 5 Registration Information 465 5.1 Structure of Registration Information 467 Registration information is an XML document [4] that MUST be well- 468 formed and SHOULD be valid. Registration information documents MUST 469 be based on XML 1.0 and MUST be encoded using UTF-8. This 470 specification makes use of XML namespaces for identifying 471 registration information documents and document fragments. The 472 namespace URI for elements defined by this specification is a URN 473 [5], using the namespace identifier 'ietf' defined by [6] and 474 extended by [7]. This URN is: 476 urn:ietf:params:xml:ns:reginfo 478 A registration information document begins with the root element tag 479 "reginfo". It consists of any number of "registration" sub-elements, 480 each of which contains the registration state for a particular 481 address-of-record. Other elements from different namespaces MAY be 482 present for the purposes of extensibility; elements or attributes 483 from unknown namespaces MUST be ignored. There are two attributes 484 associated with the "reginfo" element, both of which MUST be present: 486 version: This attribute allows the recipient of registration 487 information documents to properly order them. Versions 488 start at 0, and increment by one for each new document sent 489 to a subscriber. Versions are scoped within a subscription. 490 Versions MUST be representable using a 32 bit integer. 492 state: This attribute indicates whether the document contains 493 the full registration state, or whether it contains only 494 information on those registrations which have changed since 495 the previous document (partial). 497 Note that the document format explicitly allows for conveying 498 information on multiple addresses-of-record. This enables 499 subscriptions to groups of registrations, where such a group is 500 identified by some kind of URI. For example, a domain might define 501 sip:allusers@example.com as a subscribable resource that generates 502 notifications when the state of any address-of-record in the domain 503 changes. 505 The "reginfo" element has a list of "registration" sub-elements. The 506 "registration" element contains information on a single registration. 507 Other elements from different namespaces MAY be present for the 508 purposes of extensibility; elements or attributes from unknown 509 namespaces MUST be ignored. There are three attributes associated 510 with the "registration" element, all of which MUST be present: 512 aor: The aor attribute contains a URI which is the address-of- 513 record this registration refers to. 515 id: The id attribute identifies this registration. It MUST be 516 unique amongst all other id attributes present in other 517 registration elements conveyed to the subscriber within the 518 scope of their subscription. 520 state: The state attribute indicates the state of the 521 registration. The valid values are "init", "active" and 522 "terminated". 524 The "registration" element has a list of "contact" sub-elements. 525 Other elements from different namespaces MAY be present for the 526 purposes of extensibility; elements or attributes from unknown 527 namespaces MUST be ignored. There are several attributes associated 528 with the "contact" element which MUST be present: 530 id: The id attribute identifies this contact. It MUST be unique 531 amongst all other id attributes present in other contact 532 elements conveyed to the subscriber within the scope of 533 their subscription. 535 state: The state attribute indicates the state of the contact. 536 The valid values are "active" and "terminated". 538 event: The event attribute indicates the event which caused the 539 contact state machine to go into its current state. Valid 540 values are registered, created, refreshed, shortened, 541 expired, deactivated, probation, unregistered and rejected. 543 If the event attribute has a value of shortened, the "expires" 544 attribute MUST be present. It contains an unsigned long integer which 545 indicates the number of seconds remaining until the binding is due to 546 expire. This attribute MAY be included with any event attribute value 547 for which the state of the contact is active. 549 If the event attribute has a value of probation, the "retry-after" 550 attribute MUST be present. It contains an unsigned long integer which 551 indicates the amount of seconds after which the owner of the contact 552 is expected to retry its registration. 554 The optional "duration-registered" attribute conveys the amount of 555 time that the contact has been bound to the address-of-record, in 556 seconds. The optional "q" attribute conveys the relative priority of 557 this contact compared to other registered contacts. The optional 558 "params" attribute conveys any contact parameters that have been 559 associated with this contact. As an example, contact parameters can 560 be specified through the caller preferences extension [11]. The 561 optional "callid" attribute contains the current Call-ID carried in 562 the REGISTER that was last used to update this contact, and the 563 optional "cseq" attribute contains the last CSeq value present in a 564 REGISTER request that updated this contact value. The optional 565 "display-name" attribute contains the textual display name associated 566 with this contact. The xml:lang attribute MAY be present to indicate 567 the language of the display-name. 569 The value of the contact element is the URI of that contact. 571 5.2 Computing Registrations from the Document 573 Typically, the NOTIFY for registration information will only contain 574 information about those contacts whose state has changed. To 575 construct a coherent view of the total state of all registration, a 576 subscriber will need to combine NOTIFYs received over time. The 577 subscriber maintains a table for each registration it receives 578 information for. Each registration is uniquely identified by the "id" 579 attribute in the "registration" element. Each table contains a row 580 for each contact in that registration. Each row is indexed by the 581 unique ID for that contact. It is conveyed in the "id" attribute of 582 the "contact" element. The contents of each row contain the state of 583 that contact as conveyed in the "contact" element. The tables are 584 also associated with a version number. The version number MUST be 585 initialized with the value of the "version" attribute from the 586 "reginfo" element in the first document received. Each time a new 587 document is received, the value of the local version number, and the 588 "version" attribute in the new document, are compared. If the value 589 in the new document is one higher than the local version number, the 590 local version number is increased by one, and the document is 591 processed. If the value in the document is more than one higher than 592 the local version number, the local version number is set to the 593 value in the new document, the document is processed, and the 594 subscriber SHOULD generate a refresh request to trigger a full state 595 notification. If the value in the document is less than the local 596 version, the document is discarded without processing. 598 The processing of the document depends on whether it contains full or 599 partial state. If it contains full state, indicated by the value of 600 the "state" attribute in the "reginfo" element, the contents of all 601 tables associated with this subscription are flushed. They are 602 repopulated from the document. A new table is created for each 603 "registration" element, and a new row in each table is created for 604 each "contact" element. If the reginfo contains partial state, as 605 indicated by the value of the "state" attribute in the "reginfo" 606 element, the document is used to update the existing tables. For each 607 "registration" element, the subscriber checks to see if a table 608 exists for that list. This check is done by comparing the value in 609 the "id" attribute of the "registration" element with the ID 610 associated with the table. If a table doesn't exist for that list, 611 one is created. For each "contact" element in the list, the 612 subscriber checks to see whether a row exists for that contact. This 613 check is done by comparing the ID in the "id" attribute of the 614 "contact" element with the ID associated with the row. If the contact 615 doesn't exist in the table, a row is added, and its state is set to 616 the information from that "contact" element. If the contact does 617 exist, its state is updated to be the information from that "contact" 618 element. If a row is updated or created, such that its state is now 619 terminated, that entry MAY be removed from the table at any time. 621 5.3 Example 623 The following is an example registration information document: 625 626 628 630 sip:user@pc887.example.com 633 sip:user@university.edu 636 637 639 5.4 XML Schema 641 The following is the schema definition of the reginfo format: 643 644 648 650 653 654 655 656 658 660 661 663 664 665 666 667 668 669 670 671 672 673 674 675 676 678 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 724 725 726 727 728 729 730 731 732 733 735 736 737 739 6 Example Call Flow 741 User Registrar Application 742 | |(1) SUBSCRIBE | 743 | |Event:reg | 744 | |<------------------| 745 | |(2) 200 OK | 746 | |------------------>| 747 | |(3) NOTIFY | 748 | |------------------>| 749 | |(4) 200 OK | 750 | |<------------------| 751 |(5) REGISTER | | 752 |------------------>| | 753 |(6) 200 OK | | 754 |<------------------| | 755 | |(7) NOTIFY | 756 | |------------------>| 757 | |(8) 200 OK | 758 | |<------------------| 759 |(9) MESSAGE | | 760 |<--------------------------------------| 762 Figure 3: Example Call Flow 764 This section provides an example call flow, shown in Figure 3. It 765 shows an implementation of the welcome notice application described 766 in Section 3.3. First, the application SUBSCRIBEs to the registration 767 event package for the desired user (1): 769 SUBSCRIBE sip:joe@bar.com SIP/2.0 770 Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds7 771 From: sip:app.bar.com;tag=123aa9 772 To: sip:joe@bar.com 773 Call-ID: 9987@app.bar.com 774 CSeq: 9887 SUBSCRIBE 775 Contact: sip:app.bar.com 776 Event: reg 777 Max-Forwards: 70 778 Accept: application/reginfo+xml 780 The registrar (which is acting as the notifier for the registration 781 event package) generates a 200 OK to the SUBSCRIBE: 783 SIP/2.0 200 OK 784 Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds7 785 ;received=1.2.3.4 786 From: sip:app.bar.com;tag=123aa9 787 To: sip:joe@bar.com;tag=xyzygg 788 Call-ID: 9987@app.bar.com 789 CSeq: 9987 SUBSCRIBE 790 Contact: sip:server19.bar.com 791 Expires: 3600 793 The registrar then generates a notification (3) with the current 794 state. Since there is no active registration, the state of the 795 registration is "init": 797 NOTIFY sip:app.bar.com SIP/2.0 798 Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaii 799 From: sip:joe@bar.com;tag=xyzygg 800 To: sip:app.bar.com;tag=123aa9 801 Call-ID: 9987@app.bar.com 802 CSeq: 1288 NOTIFY 803 Contact: sip:server19.bar.com 804 Event: reg 805 Max-Forwards: 70 806 Content-Type: application/reginfo+xml 807 Content-Length: ... 809 810 812 813 814 Later on, the user registers (5): 816 REGISTER sip:joe@bar.com SIP/2.0 817 Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnaaff 818 From: sip:joe@bar.com;tag=99a8s 819 To: sip:joe@bar.com 820 Call-ID: 88askjda9@pc34.bar.com 821 CSeq: 9976 REGISTER 822 Contact: sip:joe@pc34.bar.com 824 This results in a NOTIFY being generated to the application (7): 826 NOTIFY sip:app.bar.com SIP/2.0 827 Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaij 828 From: sip:joe@bar.com;tag=xyzygg 829 To: sip:app.bar.com;tag=123aa9 830 Call-ID: 9987@app.bar.com 831 CSeq: 1289 NOTIFY 832 Contact: sip:server19.bar.com 833 Event: reg 834 Max-Forwards: 70 835 Content-Type: application/reginfo+xml 836 Content-Length: ... 838 839 841 842 sip:joe@pc34.bar.com 844 845 847 The application can then send its instant message to the device (9): 849 MESSAGE sip:joe@pc34.bar.com SIP/2.0 850 Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds8 851 From: sip:app.bar.com;tag=123aa10 852 To: sip:joe@bar.com 853 Call-ID: 9988@app.bar.com 854 CSeq: 82779 MESSAGE 855 Max-Forwards: 70 856 Content-Type: text/plain 857 Content-Length: ... 859 Welcome to the bar.com service! 861 7 Security Considerations 863 Security considerations for SIP event packages are discussed in RFC 864 3265 [2], and those considerations apply here. 866 Registration information is sensitive, potentially private, 867 information. Subscriptions to this event package SHOULD be 868 authenticated and authorized according to local policy. Some policy 869 guidelines are suggested in Section 4.6. In addition, notifications 870 SHOULD be sent in such a way to ensure confidentiality, message 871 integrity and verification of subscriber identity, such as sending 872 subscriptions and notifications using a SIPS URL or protecting the 873 notification bodies with S/MIME. 875 8 IANA Considerations 877 This document registers a new SIP Event Package, a new MIME type 878 (application/reginfo+xml), and a new XML namespace. 880 8.1 SIP Event Package Registration 882 Package name: reg 884 Type: package 886 Contact: Jonathan Rosenberg, 888 Published Specification: RFC XXXX (Note to RFC Editor: Please 889 fill in XXXX with the RFC number of this specification). 891 8.2 application/reginfo+xml MIME Registration 893 MIME media type name: application 895 MIME subtype name: reginfo+xml 897 Mandatory parameters: none 899 Optional parameters: Same as charset parameter application/xml 900 as specified in RFC 3023 [8]. 902 Encoding considerations: Same as encoding considerations of 903 application/xml as specified in RFC 3023 [8]. 905 Security considerations: See Section 10 of RFC 3023 [8] and 906 Section 7 of this specification. 908 Interoperability considerations: none. 910 Published specification: This document. 912 Applications which use this media type: This document type is 913 being used in notifications to alert SIP user agents that 914 their registrations have expired and must be redone. 916 Additional Information: 918 Magic Number: None 920 File Extension: .rif or .xml 922 Macintosh file type code: "TEXT" 924 Personal and email address for further information: Jonathan 925 Rosenberg, 927 Intended usage: COMMON 929 Author/Change controller: The IETF. 931 8.3 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:reginfo 933 This section registers a new XML namespace, as per the guidelines in 934 [7]. 936 URI: The URI for this namespace is 937 urn:ietf:params:xml:ns:reginfo. 939 Registrant Contact: IETF, SIMPLE working group, 940 , Jonathan Rosenberg 941 . 943 XML: 945 BEGIN 946 947 949 950 951 953 Registration Information Namespace 954 955 956

Namespace for Registration Information

957

application/reginfo+xml

958

See RFCXXXX.

959 960 961 END 963 9 Changes since draft-rosenberg-sip-reg-event-00.txt 965 o Added to the contact state machine a "shortened" event which 966 requests reregistration but keeps the binding state active. 968 o Added an "expires" parameter, to indicate the number of 969 seconds remaining for a binding. 971 o Updated the Security Considerations section. 973 o An IANA registration template was added for the "reg" package. 975 10 Contributors 977 This document is based heavily on the registration event package 978 originally proposed by Beckmann and Mayer in [12]. They can be 979 contacted at: 981 Georg Mayer 982 Siemens AG 983 Hoffmannstr. 51 984 Munich 81359 985 Germany 986 EMail: Georg.Mayer@icn.siemens.de 988 Mark Beckmann 989 Siemens AG 990 P.O. Box 100702 991 Salzgitter 38207 992 Germany 993 EMail: Mark.Beckmann@siemens.com 994 Rohan Mahy provided editorial work in order to progress this 995 specification. His contact address is: 997 Rohan Mahy 998 Cisco Systems 999 170 West Tasman Dr, MS: SJC-21/3/3 1000 Phone: +1 408 526 8570 1001 Email: rohan@cisco.com 1003 11 Acknowledgements 1005 We would like to thank Dean Willis for his support. 1007 12 Authors Addresses 1009 Jonathan Rosenberg 1010 dynamicsoft 1011 72 Eagle Rock Avenue 1012 First Floor 1013 East Hanover, NJ 07936 1014 email: jdrosen@dynamicsoft.com 1016 Full Copyright Statement 1018 Copyright (c) The Internet Society (2002). All Rights Reserved. 1020 This document and translations of it may be copied and furnished to 1021 others, and derivative works that comment on or otherwise explain it 1022 or assist in its implementation may be prepared, copied, published 1023 and distributed, in whole or in part, without restriction of any 1024 kind, provided that the above copyright notice and this paragraph are 1025 included on all such copies and derivative works. However, this 1026 document itself may not be modified in any way, such as by removing 1027 the copyright notice or references to the Internet Society or other 1028 Internet organizations, except as needed for the purpose of 1029 developing Internet standards in which case the procedures for 1030 copyrights defined in the Internet Standards process must be 1031 followed, or as required to translate it into languages other than 1032 English. 1034 The limited permissions granted above are perpetual and will not be 1035 revoked by the Internet Society or its successors or assigns. 1037 This document and the information contained herein is provided on an 1038 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1039 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1040 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1041 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1042 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1044 13 Normative References 1046 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1047 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 1048 initiation protocol," RFC 3261, Internet Engineering Task Force, June 1049 2002. 1051 [2] A. B. Roach, "Session initiation protocol (sip)-specific event 1052 notification," RFC 3265, Internet Engineering Task Force, June 2002. 1054 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 1055 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1057 [4] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The 1058 XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml- 1059 19980210. 1061 [5] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task 1062 Force, May 1997. 1064 [6] R. Moats, "A URN namespace for IETF documents," RFC 2648, 1065 Internet Engineering Task Force, Aug. 1999. 1067 [7] M. Mealling, "The IETF XML registry," Internet Draft, Internet 1068 Engineering Task Force, July 2002. Work in progress. 1070 [8] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC 1071 3023, Internet Engineering Task Force, Jan. 2001. 1073 14 Informative References 1075 [9] J. Rosenberg, "Session initiation protocol (SIP) extensions for 1076 presence," Internet Draft, Internet Engineering Task Force, May 2002. 1077 Work in progress. 1079 [10] B. Campbell and J. Rosenberg, "Session initiation protocol 1080 extension for instant messaging," Internet Draft, Internet 1081 Engineering Task Force, Sept. 2002. Work in progress. 1083 [11] H. Schulzrinne and J. Rosenberg, "Session initiation protocol 1084 (SIP) caller preferences and callee capabilities," Internet Draft, 1085 Internet Engineering Task Force, July 2002. Work in progress. 1087 [12] G. Mayer and M. Beckmann, "Registration event package," Internet 1088 Draft, Internet Engineering Task Force, May 2002. Work in progress.