idnits 2.17.1 draft-rosenberg-sip-reg-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 (May 28, 2002) is 8004 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 draft-rosenberg-sip-reg-00.txt 6 May 28, 2002 7 Expires: November 2002 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. 38 These registrations therefore 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 .......................... 10 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 .......................................... 14 71 6 Example Call Flow ................................... 16 72 7 Security Considerations ............................. 19 73 8 IANA Considerations ................................. 20 74 8.1 application/reginfo+xml MIME Registration ........... 20 75 8.2 URN Sub-Namespace Registration for 76 urn:ietf:params:xml:ns:reginfo ................................. 21 77 9 Contributors ........................................ 21 78 10 Acknowledgements .................................... 22 79 11 Authors Addresses ................................... 22 80 12 Normative References ................................ 23 81 13 Informative References .............................. 23 83 1 Introduction 85 The Session Initiation Protocol (SIP) [1] provides all of the 86 functions needed for the establishment and maintenance of 87 communications sessions between users. One of the functions it 88 provides is a registration operation. A registration is a binding 89 between a SIP URI, called an address-of-record, and one or more 90 contact URIs. These contact URIs represent additional resources that 91 can be contacted in order to reach the user identified by the 92 address-of-record. When a proxy receives a request within its domain 93 of administration, it uses the Request-URI as an address-of-record, 94 and uses the contacts bound to the address-of-record to forward (or 95 redirect) the request. 97 The SIP REGISTER method provides a way for a user agent to manipulate 98 registrations. Contacts can be added or removed, and the current set 99 of contacts can be queried. Registrations can also change as a result 100 of administrator policy. For example, if a user is suspected of 101 fraud, their registration can be deleted so that they cannot receive 102 any requests. Registrations also expire after some time if not 103 refreshed. 105 Registrations therefore represent a dynamic piece of state maintained 106 by the network. There are many cases in which user agents would like 107 to know about changes to the state of registrations. The SIP Events 108 Framework [2] defines a generic framework for subscription to, and 109 notification of, events related to SIP systems. The framework defines 110 the methods SUBSCRIBE and NOTIFY, and introduces the notion of a 111 package. A package is a concrete application of the event framework 112 to a particular class of events. Packages have been defined for user 113 presence [9], for example. This specification defines a package for 114 registration state. 116 2 Terminology 118 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 119 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 120 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 121 indicate requirement levels for compliant implementations. 123 3 Usage Scenarios 125 There are many applications of this event package. A few are 126 documented here for illustrative purposes. 128 3.1 Forcing Re-Authentication 130 It is anticipated that future SIP devices will wireless devices that 131 will be always-on, and therefore, continually registered to the 132 network. Unfortunately, history has shown that these devices can be 133 compromised, and therefore, an administrator will want to terminate a 134 registration and ask the device to re-register so it can be re- 135 authenticated. To do this, the device subscribes to the registration 136 event package for the address-of-record that it is registering 137 contacts against. When the administrator terminates the registration 138 (for example, when fraud is suspected) the registration server sends 139 a notification to the device. It can then re-register and re- 140 authenticate itself. 142 3.2 Composing Presence 144 An important concept to understand is the relationship between this 145 event package and the event package for user presence [9]. User 146 presence represents the willingness and ability of a user to 147 communicate with other users on the network. It is composed of a set 148 of contact addresses that represent the various means for contacting 149 the user. Those contact addresses might represent the contact address 150 for voice, for example. Typically, the contact address listed for 151 voice will be an address-of-record. The status of that contact 152 (whether its open or closed) may depend on any number of factors, 153 including the state of any registrations against that address-of- 154 record. As a result, registration state can be viewed as an input to 155 the process which determines the presence document for a user. 156 Effectively, registration state is "raw" data, which is combined with 157 other information about a user to generate a document that describes 158 the user presence. 160 In fact, this event package allows for a presence server to be 161 separated from a SIP registration server, yet still use registration 162 information to construct a presence document. When a presence server 163 receives a presence subscription for some user, the presence server 164 itself would generate a subscription to the registration server for 165 the registration event package. As a result, the presence server 166 would learn about the registration state for that user, and it could 167 use that information to generate presence documents. 169 3.3 Welcome Notices 171 A common service in current mobile networks are "welcome notices". 172 When the user turns on their phone in a foreign country, they receive 173 a message that welcomes them to the country, and provides information 174 on transportation services, for example. 176 In order to implement this service in a SIP system, an application 177 server can subscribe to the registration state of the user. When the 178 user turns on their phone, the phone will generate a registration. 180 This will result in a notification being sent to the application that 181 the user has registered. The application can then send a SIP MESSAGE 182 request [10] to the device, welcoming the user and providing any 183 necessary information. 185 4 Package Definition 187 This section fills in the details needed to specify an event package 188 as defined in Section 5.4 of [2]. 190 4.1 Event Package Name 192 The SIP Events specification requires package definitions to specify 193 the name of their package or template-package. 195 The name of this package is "reg". As specified in [2], this value 196 appears in the Event header present in SUBSCRIBE and NOTIFY requests. 198 Example: 200 Event: reg 202 4.2 Event Package Parameters 204 The SIP Events specification requires package and template-package 205 definitions to specify any package specific parameters of the Event 206 header that are used by it. 208 No package specific Event header parameters are defined for this 209 event package. 211 4.3 SUBSCRIBE Bodies 213 The SIP Events specification requires package or template-package 214 definitions to define the usage, if any, of bodies in SUBSCRIBE 215 requests. 217 A SUBSCRIBE for registration events MAY contain a body. This body 218 would serve the purpose of filtering the subscription. The definition 219 of such a body is outside the scope of this specification. 221 A SUBSCRIBE for the registration package MAY be sent without a body. 222 This implies that the default registration filtering policy has been 223 requested. The default policy is: 225 o Notifications are generated every time there is any change in 226 the state of any of the registered contacts for the resource 227 being subscribed to. Those notifications only contain 228 information on the contacts whose state has changed. 230 o Notifications triggered from a SUBSCRIBE contain full state 231 (the list of all contacts bound to the address-of-record). 233 Of course, the server can apply any policy it likes to the 234 subscription. 236 4.4 Subscription Duration 238 The SIP Events specification requires package definitions to define a 239 default value for subscription durations, and to discuss reasonable 240 choices for durations when they are explicitly specified. 242 Registration state changes as contacts are created through REGISTER 243 requests, and them time out due to lack of refresh. Their rate of 244 change is therefore related to the typical registration expiration. 245 Since the default expiration for registrations is 3600 seconds, the 246 default duration of subscriptions to registration state is also 3600 247 seconds. Of course, clients MAY include an Expires header in the 248 SUBSCRIBE request asking for a different duration. 250 4.5 NOTIFY Bodies 252 The SIP Events specification requires package definitions to describe 253 the allowed set of body types in NOTIFY requests, and to specify the 254 default value to be used when there is no Accept header in the 255 SUBSCRIBE request. 257 The body of a notification of a change in registration state contains 258 a registration information document. This document describes some or 259 all of the contacts associated with a particular address-of-record. 260 All subscribers to registration state MUST support the 261 application/reginfo+xml format described in Section 5, and MUST list 262 its MIME type, application/reginfo+xml, in any Accept header present 263 in the SUBSCRIBE request. 265 Other registration information formats might be defined in the 266 future. In that case, the subscriptions MAY indicate support for 267 other formats. However, they MUST always support and list 268 application/reginfo+xml as an allowed format. 270 Of course, the notifications generated by the server MUST be in one 271 of the formats specified in the Accept header in the SUBSCRIBE 272 request. If no Accept header was present, the notifications MUST use 273 the application/reginfo+xml format described in Section 5. 275 4.6 Notifier Processing of SUBSCRIBE Requests 277 The SIP Events framework specifies that packages should define any 278 package-specific processing of SUBSCRIBE requests at a notifier, 279 specifically with regards to authentication and authorization. 281 Registration state can be sensitive information. Therefore, all 282 subscriptions to it SHOULD be authenticated and authorized before 283 approval. Authentication MAY be performed using any of the techniques 284 available through SIP, including digest, S/MIME, TLS or other 285 transport specific mechanisms [1]. Authorization policy is at the 286 discretion of the administrator, as always. However, a few 287 recommendations can be made. 289 It is RECOMMENDED that a user A be allowed to subscribe to their own 290 registration state. Such subscriptions are useful when there are many 291 devices that represent a user, each of which needs to learn the 292 registration state of the other devices. We also anticipate that 293 applications and automata will frequently be subscribers to the 294 registration state. In those cases, authorization policy will 295 typically be provided ahead of time. 297 4.7 Notifier Generation of NOTIFY Requests 299 The SIP Event framework requests that packages specify the conditions 300 under which notifications are sent for that package, and how such 301 notifications are constructed. 303 To determine when a notifier should send notifications of changes in 304 registration state, we define a finite state machine (FSM) that 305 represents the state of a contact for a particular address-of-record. 306 Transitions in this state machine MAY result in the generation of 307 notifications. These notifications will carry information on the new 308 state and the event which triggered the state change. It is important 309 to note that this FSM is just a model of the registration state 310 machinery maintained by a server. An implementation would map its own 311 state machines to this one in an implementation-specific manner. 313 4.7.1 The Registration State Machine 315 The underlying state machine for a registration is shown in Figure 1. 316 The machine is very simple. An instance of this machine is associated 317 with each address-of-record. When the first contact is registered to 318 that address-of-record, the state machine moves from init to active. 319 As long as there is at least one contact bound to the address-of- 320 +------------+ 321 | | 322 | Init | 323 | | 324 +------------+ 325 | 326 V 327 +------------+ 328 | | 329 | Active | 330 | | 331 +------------+ 332 | 333 V 334 +------------+ 335 | | 336 | Terminated | 337 | | 338 +------------+ 340 Figure 1: Registration State Machine 342 record, the state machine remains in the active state. When the last 343 contact expires or is removed, the registration transitions to 344 terminated. 346 In addition to this state machine, each registration is associated 347 with a set of contacts, each of which is modelled with its own state 348 machine. The diagram for the per-contact state machine is shown in 349 Figure 2. This FSM is identical to the registration state machine in 350 terms of its states, but has many more transition events. 352 When a new contact is added, the FSM moves from the init state into 353 the active state. There are two ways in which it can become active. 354 One is through an actual SIP REGISTER request (correspoding to the 355 registered event), and the other is when the contact is created 356 administratively, or through some non-SIP means (the created event). 357 The FSM remains in the active state so long as the contact is a bound 358 +------+ 359 | | refreshed 360 | | 361 V | 362 +------------+ +------------+ +------------+ 363 | | | | | | 364 | Init |----------->| Active |----------->| Terminated | 365 | | | | | | 366 +------------+ registered +------------+ expired +------------+ 367 created deactivated 368 probation 369 unregistered 370 rejected 372 Figure 2: Contact State Machine 374 to the address-of-record. When a contact is refreshed through a 375 REGISTER request, the FSM stays in the same state, but a refreshed 376 event is generated. When the contact is no longer bound to the 377 address-of-record, the FSM moves to the terminated state. There are 378 several reasons this can happen. The first is an expiration, which 379 occurs when the contact was not refreshed by a REGISTER request. The 380 second reason is deactivated. This occurs when the administrator has 381 removed the contact as a valid binding, but wishes the client to 382 attempt to re-register the contact. In contast, the rejected event 383 occurs when an active contact is removed by the administrator, but 384 re-registrations will not help to re-establish it. This might occur 385 if a user does not pay their bills, for example. The probation event 386 occurs when an active contact is removed by the administrator, and 387 the administrator wants the client to re-register, but to do so at a 388 later time. The unregistered event occurs when a REGISTER request is 389 received which has set the expiration time of that contact to zero. 391 4.7.2 Applying the state machine 393 The server MAY generate a notification to subscribers when any event 394 occurs in the state machine. Whether it does or does not is policy 395 dependent. However, several guidelines are defined. 397 As a general rule, when a subscriber is authorized to receive 398 notifications about set of registrations, it is RECOMMENDED that 399 notifications contain information about those contacts which have 400 changed state (and thus triggered a notification), instead of 401 delivering the current state of every contact in all registrations. 402 However, notifications triggered as a result of a fetch operation (a 403 SUBSCRIBE with Expires of 0) SHOULD result in the full state of all 404 contacts for all registrations to be present in the NOTIFY. 406 4.8 Subscriber Processing of NOTIFY Requests 408 The SIP Events framework expects packages to specify how a subscriber 409 processes NOTIFY requests in any package specific ways, and in 410 particular, how it uses the NOTIFY requests to contruct a coherent 411 view of the state of the subscribed resource. Typically, the NOTIFY 412 will only contain information for contacts whose state has changed. 413 To construct a coherent view of the total state of all registrations, 414 the subscriber will need to combine NOTIFYs received over time. The 415 details of this process depend on the document format used to convey 416 registration state. Section 5 outlines the process for the 417 application/reginfo+xml format. 419 4.9 Handling of Forked Requests 421 The SIP Events framework mandates that packages indicate whether or 422 not forked SUBSCRIBE requests can install multiple subscriptions. 424 Registration state is normally stored in some repository (whether it 425 be co-located with a proxy/registrar or in a separate database). As 426 such, there is usually a single place where a the contact information 427 for a particular address-of-record is resident. This implies that a 428 subscription for this information is readily handled by and element 429 with access to this repository. There is, therefore, no compelling 430 need for a subscription to registration information to fork. As a 431 result, a subscriber MUSTNOT create multiple dialogs as a result of a 432 single subscription request. The required processing to guarantee 433 that only a single dialog is established is described in Section 434 5.4.9 of the SIP Events framework [2]. 436 4.10 Rate of Notifications 438 The SIP Events framework mandates that packages define a maximum rate 439 of notifications for their package. 441 For reasons of congestion control, it is important that the rate of 442 notifications not become excessive. As a result, it is RECOMMENDED 443 that the server not generate notifications for a single subscriber at 444 a rate faster than once every 5 seconds. 446 4.11 State Agents 448 The SIP Events framework asks packages to consider the role of state 449 agents in their design. 451 State agents have no role in the handling of this package. 453 5 Registration Information 455 5.1 Structure of Registration Information 457 Registration information is an XML document [4] that MUST be well- 458 formed and SHOULD be valid. Registration information documents MUST 459 be based on XML 1.0 and MUST be encoded using UTF-8. This 460 specification makes use of XML namespaces for identifying 461 registration information documents and document fragments. The 462 namespace URI for elements defined by this specification is a URN 463 [5], using the namespace identifier 'ietf' defined by [6] and 464 extended by [7]. This URN is: 466 urn:ietf:params:xml:ns:reginfo 468 A registration information document begins with the root element tag 469 "reginfo". It consists of any number of "registration" sub-elements, 470 each of which is contains the registration state for a particular 471 address-of-record. Other elements from different namespaces MAY be 472 present for the purposes of extensibility; elements or attributes 473 from unknown namespaces MUST be ignored. There are two attributes 474 associated with the "reginfo" element, both of which MUST be present: 476 version: This attribute allows the recipient of registration 477 information documents to properly order them. Versions 478 start at 0, and increment by one for each new document sent 479 to a subscriber. Versions are scoped within a subscription. 480 Versions MUST be representable using a 32 bit integer. 482 state: This attribute indicates whether the document contains 483 the full registration state, or whether it contains only 484 information on those registrations which have changed since 485 the previous document (partial). 487 Note that the document format explicitly allows for conveying 488 information on multiple addresses-of-record. This enables 489 subscriptions to groups of registrations, where such a group is 490 identified by some kind of URI. For example, a domain might define 491 sip:allusers@example.com as a subscribable resource that generates 492 notifications when the state of any address-of-record in the domain 493 changes. 495 The "reginfo" element has a list of "registration" sub-elements. The 496 "registration" element contains information on a single registration. 497 Other elements from different namespaces MAY be present for the 498 purposes of extensibility; elements or attributes from unknown 499 namespaces MUST be ignored. There are three attributes associated 500 with the "registration" element, all of which MUST be present: 502 aor: The aor attribute contains a URI which is the address-of- 503 record this registration refers to. 505 id: The id attribute identifies this registration. It MUST be 506 unique amongst all other id attributes present in other 507 registration elements conveyed to the subscriber within the 508 scope of their subscription. 510 state: The state attribute indicates the state of the 511 registration. The valid values are "init", "active" and 512 "terminated". 514 The "registration" element has a list of "contact" sub-elements. 515 Other elements from different namespaces MAY be present for the 516 purposes of extensibility; elements or attributes from unknown 517 namespaces MUST be ignored. There are several attributes associated 518 with the "contact" element which MUST be present: 520 id: The id attribute identifies this contact. It MUST be unique 521 amongst all other id attributes present in other contact 522 elements conveyed to the subscriber within the scope of 523 their subscription. 525 state: The state attribute indicates the state of the contact. 526 The valid values are "active" and "terminated". 528 event: The event attribute indicates the event which caused the 529 contact state machine to go into its current state. Valid 530 values are registered, created, refreshed, expired, 531 deactivated, probation, unregistered and rejected. 533 If the event attribute has a value of probation, the "retry-after" 534 attribute MUST be present. It contains an unsigned long which 535 indicates the amount of seconds after which the owner of the contact 536 is expected to retry its registration. 538 The optional "duration-registered" attribute conveys the amount of 539 time that the contact has been bound to the address-of-record, in 540 seconds. The optional "q" attribute conveys the relative priority of 541 this contact compared to other registered contacts. The optional 542 "params" attribute conveys any contact parameters that have been 543 associated with this contact. As an example, contact parameters can 544 be specified through the caller preferences extension [11]. The 545 optional "callid" attribute contains the current Call-ID carried in 546 the REGISTER that was last used to update this contact, and the 547 optional "cseq" attribute contains the last CSeq value present in a 548 REGISTER request that updated this contact value. The optional 549 "display-name" attribute contains the textual display name associated 550 with this contact. The xml:lang attribute MAY be present to indicate 551 the language of the display-name. 553 The value of the contact element is the URI of that contact. 555 5.2 Computing Registrations from the Document 557 Typically, the NOTIFY for registration information will only contain 558 information about those contacts whose state has changed. To 559 construct a coherent view of the total state of all registration, a 560 subscriber will need to combine NOTIFYs received over time. The 561 subscriber maintains a table for each registration it receives 562 information for. Each registration is uniquely identified by the "id" 563 attribute in the "registration" element. Each table contains a row 564 for each contact in that registration. Each row is indexed by the 565 unique ID for that contact. It is conveyed in the "id" attribute of 566 the "contact" element. The contents of each row contain the state of 567 that contact as conveyed in the "contact" element. The tables are 568 also associated with a version number. The version number MUST be 569 initialized with the value of the "version" attribute from the 570 "reginfo" element in the first document received. Each time a new 571 document is received, the value of the local version number, and the 572 "version" attribute in the new document, are compared. If the value 573 in the new document is one higher than the local version number, the 574 local version number is increased by one, and the document is 575 processed. If the value in the document is more than one higher than 576 the local version number, the local version number is set to the 577 value in the new document, the document is processed, and the 578 subscriber SHOULD generate a refresh request to trigger a full state 579 notification. If the value in the document is less than the local 580 version, the document is discarded without processing. 582 The processing of the document depends on whether it contains full or 583 partial state. If it contains full state, indicated by the value of 584 the "state" attribute in the "reginfo" element, the contents of all 585 tables associated with this subscription are flushed. They are 586 repopulated from the document. A new table is created for each 587 "registration" element, and a new row in each table is created for 588 each "contact" element. If the reginfo contains partial state, as 589 indicated by the value of the "state" attribute in the "reginfo" 590 element, the document is used to update the existing tables. For each 591 "registration" element, the subscriber checks to see if a table 592 exists for that list. This check is done by comparing the value in 593 the "id" attribute of the "registration" element with the ID 594 associated with the table. If a table doesn't exist for that list, 595 one is created. For each "contact" element in the list, the 596 subscriber checks to see whether a row exists for that contact. This 597 check is done by comparing the ID in the "id" attribute of the 598 "contact" element with the ID associated with the row. If the contact 599 doesn't exist in the table, a row is added, and its state is set to 600 the information from that "contact" element. If the contact does 601 exist, its state is updated to be the information from that "contact" 602 element. If a row is updated or created, such that its state is now 603 terminated, that entry MAY be removed from the table at any time. 605 5.3 Example 607 The following is an example registration information document: 609 610 612 614 sip:user@pc887.example.com 617 sip:user@university.edu 620 621 623 5.4 XML Schema 625 The following is the schema definition of the reginfo format: 627 628 632 634 637 638 639 640 642 644 645 647 648 649 650 651 652 653 654 655 656 657 658 659 660 662 664 665 666 667 668 669 670 671 672 673 674 676 677 678 679 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 708 709 710 711 712 713 714 715 716 717 718 719 721 6 Example Call Flow 722 User Registrar Application 723 | |(1) SUBSCRIBE | 724 | |Event:reg | 725 | |<------------------| 726 | |(2) 200 OK | 727 | |------------------>| 728 | |(3) NOTIFY | 729 | |------------------>| 730 | |(4) 200 OK | 731 | |<------------------| 732 |(5) REGISTER | | 733 |------------------>| | 734 |(6) 200 OK | | 735 |<------------------| | 736 | |(7) NOTIFY | 737 | |------------------>| 738 | |(8) 200 OK | 739 | |<------------------| 740 |(9) MESSAGE | | 741 |<--------------------------------------| 743 Figure 3: Example Call Flow 745 This section provides an example call flow, shown in Figure 3. It 746 shows an implementation of the welcome notice application described 747 in Section 3.3. First, the application SUBSCRIBEs to the registration 748 event package for the desired user (1): 750 SUBSCRIBE sip:joe@bar.com SIP/2.0 751 Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds7 752 From: sip:app.bar.com;tag=123aa9 753 To: sip:joe@bar.com 754 Call-ID: 9987@app.bar.com 755 CSeq: 9887 SUBSCRIBE 756 Contact: sip:app.bar.com 757 Event: reg 758 Max-Forwards: 70 760 The registrar (which is acting as the notifier for the registration 761 event package) generates a 200 OK to the SUBSCRIBE: 763 SIP/2.0 200 OK 764 Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds7 765 ;received=1.2.3.4 766 From: sip:app.bar.com;tag=123aa9 767 To: sip:joe@bar.com;tag=xyzygg 768 Call-ID: 9987@app.bar.com 769 CSeq: 9987 SUBSCRIBE 770 Contact: sip:server19.bar.com 771 Expires: 3600 773 The registrar then generates a notification (3) with the current 774 state. Since there is no active registration, the state of the 775 registration is "init": 777 NOTIFY sip:app.bar.com SIP/2.0 778 Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaii 779 From: sip:joe@bar.com;tag=xyzygg 780 To: sip:app.bar.com;tag=123aa9 781 Call-ID: 9987@app.bar.com 782 CSeq: 1288 NOTIFY 783 Contact: sip:server19.bar.com 784 Event: reg 785 Max-Forwards: 70 786 Content-Type: application/reginfo+xml 787 Content-Length: ... 789 790 792 793 795 Later on, the user registers (5): 797 REGISTER sip:joe@bar.com SIP/2.0 798 Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnaaff 799 From: sip:joe@bar.com;tag=99a8s 800 To: sip:joe@bar.com 801 Call-ID: 88askjda9@pc34.bar.com 802 CSeq: 9976 REGISTER 803 Contact: sip:joe@pc34.bar.com 804 This results in a NOTIFY being generated to the application (7): 806 NOTIFY sip:app.bar.com SIP/2.0 807 Via: SIP/2.0/UDP server19.bar.com;branch=z9hG4bKnasaij 808 From: sip:joe@bar.com;tag=xyzygg 809 To: sip:app.bar.com;tag=123aa9 810 Call-ID: 9987@app.bar.com 811 CSeq: 1289 NOTIFY 812 Contact: sip:server19.bar.com 813 Event: reg 814 Max-Forwards: 70 815 Content-Type: application/reginfo+xml 816 Content-Length: ... 818 819 821 822 sip:joe@pc34.bar.com 824 825 827 The application can then sends its instant message to the device (9): 829 MESSAGE sip:joe@pc34.bar.com SIP/2.0 830 Via: SIP/2.0/UDP app.bar.com;branch=z9hG4bKnashds8 831 From: sip:app.bar.com;tag=123aa10 832 To: sip:joe@bar.com 833 Call-ID: 9988@app.bar.com 834 CSeq: 82779 MESSAGE 835 Max-Forwards: 70 836 Content-Type: text/plain 837 Content-Length: ... 839 Welcome to the bar.com service! 841 7 Security Considerations 843 Registration information is sensitive information. The protocol used 844 to distribute it SHOULD ensure privacy, message integrity and 845 authentication. Furthermore, the protcol should provide access 846 controls which restrict who can see the registration information for 847 a user. 849 8 IANA Considerations 851 This document registers a new MIME type, application/reginfo+xml, and 852 registers a new XML namespace. 854 8.1 application/reginfo+xml MIME Registration 856 MIME media type name: application 858 MIME subtype name: reginfo+xml 860 Mandatory parameters: none 862 Optional parameters: Same as charset parameter application/xml 863 as specified in RFC 3023 [8]. 865 Encoding considerations: Same as encoding considerations of 866 application/xml as specified in RFC 3023 [8]. 868 Security considerations: See Section 10 of RFC 3023 [8] and 869 Section 7 of this specification. 871 Interoperability considerations: none. 873 Published specification: This document. 875 Applications which use this media type: This document type is 876 being used in notifications to alert SIP user agents that 877 their registrations have expired and must be redone. 879 Additional Information: 881 Magic Number: None 883 File Extension: .rif or .xml 885 Macintosh file type code: "TEXT" 887 Personal and email address for further information: Jonathan 888 Rosenberg, 890 Intended usage: COMMON 892 Author/Change controller: The IETF. 894 8.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:reginfo 896 This section registers a new XML namespace, as per the guidelines in 897 [7]. 899 URI: The URI for this namespace is 900 urn:ietf:params:xml:ns:reginfo. 902 Registrant Contact: IETF, SIMPLE working group, 903 , Jonathan Rosenberg 904 . 906 XML: 908 BEGIN 909 910 912 913 914 916 Registration Information Namespace 917 918 919

Namespace for Registration Information

920

application/reginfo+xml

921

See RFCXXXX.

922 923 924 END 926 9 Contributors 928 This draft is based heavily on the registration event package 929 originally proposed by Beckmann and Mayer in [12]. They can be 930 contacted at: 932 Georg Mayer 933 Siemens AG 934 Hoffmannstr. 51 935 Munich 81359 936 Germany 937 EMail: Georg.Mayer@icn.siemens.de 938 Mark Beckmann 939 Siemens AG 940 P.O. Box 100702 941 Salzgitter 38207 942 Germany 943 EMail: Mark.Beckmann@siemens.com 945 10 Acknowledgements 947 We would like to thank Dean Willis for his support. 949 11 Authors Addresses 951 Jonathan Rosenberg 952 dynamicsoft 953 72 Eagle Rock Avenue 954 First Floor 955 East Hanover, NJ 07936 956 email: jdrosen@dynamicsoft.com 958 Full Copyright Statement 960 Copyright (c) The Internet Society (2002). All Rights Reserved. 962 This document and translations of it may be copied and furnished to 963 others, and derivative works that comment on or otherwise explain it 964 or assist in its implementation may be prepared, copied, published 965 and distributed, in whole or in part, without restriction of any 966 kind, provided that the above copyright notice and this paragraph are 967 included on all such copies and derivative works. However, this 968 document itself may not be modified in any way, such as by removing 969 the copyright notice or references to the Internet Society or other 970 Internet organizations, except as needed for the purpose of 971 developing Internet standards in which case the procedures for 972 copyrights defined in the Internet Standards process must be 973 followed, or as required to translate it into languages other than 974 English. 976 The limited permissions granted above are perpetual and will not be 977 revoked by the Internet Society or its successors or assigns. 979 This document and the information contained herein is provided on an 980 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 981 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 982 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 983 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 984 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 986 12 Normative References 988 [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 989 protocol," Internet Draft, Internet Engineering Task Force, Feb. 990 2002. Work in progress. 992 [2] A. Roach, "SIP-specific event notification," Internet Draft, 993 Internet Engineering Task Force, Mar. 2002. Work in progress. 995 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 996 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 998 [4] W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The 999 XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml- 1000 19980210. 1002 [5] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task 1003 Force, May 1997. 1005 [6] R. Moats, "A URN namespace for IETF documents," RFC 2648, 1006 Internet Engineering Task Force, Aug. 1999. 1008 [7] M. Mealling, "The IANA XML registry," Internet Draft, Internet 1009 Engineering Task Force, Nov. 2001. Work in progress. 1011 [8] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC 1012 3023, Internet Engineering Task Force, Jan. 2001. 1014 13 Informative References 1016 [9] J. Rosenberg et al. , "Session initiation protocol (SIP) 1017 extensions for presence," Internet Draft, Internet Engineering Task 1018 Force, Apr. 2002. Work in progress. 1020 [10] B. Campbell and J. Rosenberg, "Session initiation protocol 1021 extension for instant messaging," Internet Draft, Internet 1022 Engineering Task Force, May 2002. Work in progress. 1024 [11] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and 1025 callee capabilities," Internet Draft, Internet Engineering Task 1026 Force, Nov. 2001. Work in progress. 1028 [12] G. Mayer and M. Beckmann, "Registration event package," Internet 1029 Draft, Internet Engineering Task Force, May 2002. Work in progress.