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.