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.