idnits 2.17.1
draft-avasarala-dispatch-comm-barring-notification-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== 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 date (November 22, 2010) is 4904 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 3265 (ref. '6') (Obsoleted by RFC 6665)
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 DISPATCH Ranjit. Avasarala
3 Internet-Draft Motorola Solutions Inc
4 Intended status: Informational R. Jesske
5 Expires: May 26, 2011 Deutsche Telekom
6 November 22, 2010
8 A Session Initiation Protocol (SIP) Event Package for Communication
9 Barring Notification Information in support of the Dynamic Incoming
10 Communication Barring (ICB) service
11 draft-avasarala-dispatch-comm-barring-notification-01.txt
13 Abstract
15 3GPP is defining the protocol specification for the Communication
16 Barring (CB) service using IP Multimedia (IM) Core Network (CN)
17 subsystem supplementary service and more particularly the dynamic
18 incoming communication barring service. As part of dynamic incoming
19 communication barring (ICB) service, a SIP based Event package
20 framework is used for notifying users about communication barrings
21 (dynamic and rule based) of their incoming communication sessions.
22 This document proposes a new SIP event package for allowing users to
23 subscribe to and receive such notifications. Users can further
24 define filters to control the rate and content of such notifications.
25 The proposed event package is applicable to the ICB supplementary
26 service in IMS and may not be applicable to the general internet..
28 Status of this Memo
30 This Internet-Draft is submitted in full conformance with the
31 provisions of BCP 78 and BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF). Note that other groups may also distribute
35 working documents as Internet-Drafts. The list of current Internet-
36 Drafts is at http://datatracker.ietf.org/drafts/current/.
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 This Internet-Draft will expire on May 26, 2011.
45 Copyright Notice
47 Copyright (c) 2010 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (http://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Simplified BSD License text as described in Section 4.e of
57 the Trust Legal Provisions and are provided without warranty as
58 described in the Simplified BSD License.
60 Table of Contents
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
64 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
65 4. Abbreviations and Definitions . . . . . . . . . . . . . . . . 5
66 4.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
67 4.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
68 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
69 6. Package Definition . . . . . . . . . . . . . . . . . . . . . . 5
70 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
71 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6
72 6.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 6
73 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 6
74 6.5. Notify bodies . . . . . . . . . . . . . . . . . . . . . . 6
75 6.6. Notifier Processing of SUBSCRIBE requests . . . . . . . . 7
76 6.6.1. Authentication . . . . . . . . . . . . . . . . . . . . 7
77 6.6.2. Authorization . . . . . . . . . . . . . . . . . . . . 7
78 6.7. Notifier Generation of NOTIFY requests . . . . . . . . . . 8
79 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9
80 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9
81 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9
82 6.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9
83 7. Comm_barring-info Document . . . . . . . . . . . . . . . . . . 9
84 8. Structure of Comm_barring-info Format . . . . . . . . . . . . 10
85 8.1. Comm_barring-info Element . . . . . . . . . . . . . . . . 10
86 8.1.1. comm-barring-subs-info Element . . . . . . . . . . . . 10
87 8.1.2. Comm-barring-ntfy-info Element . . . . . . . . . . . . 12
88 8.1.3. Comm_barring-info-selection-criteria . . . . . . . . . 13
89 8.2. Sample Notification body . . . . . . . . . . . . . . . . . 14
90 8.2.1. Instance of communication barring subscription
91 filter document . . . . . . . . . . . . . . . . . . . 14
92 8.2.2. Instance of communication barring notification
93 document . . . . . . . . . . . . . . . . . . . . . . . 15
94 8.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
97 10.1. Communication Barring Information Event Package
98 Registration . . . . . . . . . . . . . . . . . . . . . . . 20
99 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
102 12.2. Informative References . . . . . . . . . . . . . . . . . . 21
103 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 22
104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
106 1. Introduction
108 3GPP is currently maintaining and specifying incoming communication
109 barring mechanisms which allow users to dynamically block incoming
110 communications from callers whom they consider as unwanted or
111 unsolicited. The intention of such mechanisms is to provide users
112 with sufficient flexibility to manage their incoming communications
113 in a better way. The most common example is the Anonymous
114 Communication Rejection (ACR) where in the incoming communications
115 from senders whose identity is marked as "Anonymous" is rejected.
116 Similarly other variants of ICB include dynamically blocking a
117 particular caller by the subscribers, called the dynamic ICB which is
118 specified in 3GPP specification [1].
120 However, However, with the increasing number of unwanted calls and
121 increased usage of incoming communication barring services, users may
122 have lot of callers being blocked from time to time and for different
123 periods based on temporary or permanent block. For instance, a user
124 may have blocked a particular caller for a temporary period and
125 specified the period as 1 year. Though there are ways by which users
126 can keep track of their communication barrings, there is no efficient
127 mechanism for the users to get information of their communication
128 barrings that get enacted in the network. This information would
129 help them to verify their rules and rectify if required
131 This document defines a SIP event package that allows a SIP User
132 Agents to subscribe to and be notified of communication barrings
133 enacted on their behalf
135 2. Terminology
137 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
138 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
139 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
140 indicate requirement levels for compliant implementations.
142 3. Applicability Statement
144 It is believed that the SIP event package defined here is not
145 applicable to the general Internet and has been designed to serve the
146 architecture of the Dynamic ICB service defined for IMS core
147 networks. The aim of this memo is to follow the procedure indicated
148 in RFC 5727 [3] and to register a new event package with event name
149 "comm-barring-info" with IANA.
151 4. Abbreviations and Definitions
153 4.1. Abbreviations
155 CB: Communication Barring.
157 CBN: Communication Barring Notification.
159 ICB: Incoming Communication Barring.
161 4.2. Definitions
163 Subscriber - The User Agent who has subscribed to the
164 Communication Barring notification service.
166 User - Another term for the subscriber.
168 Barring User - The User Agent who has configured a Communication
169 Barring. This could be the User Agent who has configured the
170 Incoming Communication Barring service rules in the network.
172 Originating User - The User Agent who is the originator of the
173 incoming communication, The Originating User is also referred to
174 as the Caller.
176 IMS Core Network - This refers to the IMS based SIP based network
177 that conforms to the [7] and not the general SIP network as
178 defined in [4].
180 5. Requirements
182 The Communication Barring Notification (CBN) service enables a user
183 to receive notification about the barring of any of his/her incoming
184 communications, which were addressed to the user's address. A
185 comprehensive description of all the requirements that affect the CBN
186 service developed by 3GPP and is found in and [5] and [1]
188 6. Package Definition
190 This section fills in the details needed for an event package as
191 defined in Section 4.4 of [6].
193 6.1. Event Package Name
195 The SIP Events specification requires package definitions to specify
196 the name of their package or template-package.
198 The name of this package is "comm-barring-info". As specified in
199 [6], this value appears in the Event header present in SUBSCRIBE and
200 NOTIFY requests.
202 6.2. Event Package Parameters
204 The SIP Events specification [6] allows packages to define additional
205 parameters. This event package "comm-barring-info" does not define
206 additional parameters. .
208 6.3. SUBSCRIBE bodies
210 The SIP Events specification requires package or template-package
211 definitions to define the usage, if any, of bodies in SUBSCRIBE
212 requests.
214 A SUBSCRIBE for Communication Barring event MAY contain a body. The
215 purpose of the body depends on its type. Subscriptions to the
216 Comm_barring-info event package SHALL only include a body of MIME
217 type "application/comm-barring-info+xml".
219 A body of the SUBSCRIBE request with content type set to MIME type
220 "application/comm-barring-info+xml" contains information about the
221 communication barring notification information filter criteria and
222 notification trigger criteria. The subscriber SHALL also verify that
223 this information conforms to a valid XML document as defined in [8].
224 The subscriber SHALL also verify that the information contained in
225 the XML document contains elements defined in Section 8.1.1 only.
227 6.4. Subscription Duration
229 The default expiration time for subscriptions within this package is
230 3600 seconds. As per [6], the subscriber MAY specify an alternate
231 expiration in the Expires header field.
233 6.5. Notify bodies
235 The SIP Events specification requires package definitions to define a
236 default value for subscription durations, and to discuss reasonable
237 choices for durations when they are explicitly specified.
239 The NOTIFY message contains bodies. This body is a format listed in
240 the Accept header field of the SUBSCRIBE request or a package
241 specific default format if the Accept header field was omitted from
242 the SUBSCRIBE request.
244 In this event package, the body of the notification contains the
245 communication barring information pertaining to the barring that
246 occurred in the network on behalf of the subscriber. The format of
247 the communication barring information is an XML document as per
248 elements defined in Section 8.1.2.
250 All subscribers and notifiers of the "comm-barring-info" event
251 package MUST support the "application/comm-barring-info+xml" data
252 format described in Section 8. The SUBSCRIBE request MAY contain an
253 Accept header field. If no such header field is present, it has a
254 default value of "application/comm-barring-info+xml" (assuming Event
255 header has a value of "comm-barring-info"). If the Accept header
256 field is present, it MUST contain the value "application/
257 comm-barring-info+xml".
259 6.6. Notifier Processing of SUBSCRIBE requests
261 The contents of a document containing comm-barring-info information
262 can contain sensitive information that can reveal some privacy
263 information. Therefore, such comm-barring-info documents MUST only
264 be sent to authorized subscribers. In order to determine if a
265 subscription originates in an authorized user, the subscriber MUST be
266 authenticated as described in Section 6.6.1 and then the user MUST be
267 authorized to be a subscriber as described in Section 6.6.2.
269 The Notifier MUST look into the SUBSCRIBE request body for a comm-
270 barring-info document containing filter criteria. If the filter
271 criteria is present, it should check if the filter criteria conforms
272 to the format described in Section 8.1.1. If the received criteria
273 is valid, then the NOTIFIER MUST use that for generating
274 notifications about communication barrings that occur on behalf of
275 the user.
277 6.6.1. Authentication
279 Notifiers MUST authenticate all subscription requests. This
280 authentication can be done using any of the mechanisms defined in [4]
281 and other authentication extensions.
283 6.6.2. Authorization
285 Once authenticated, the notifier makes an authorization decision. A
286 notifier MUST NOT accept a subscription unless authorization has been
287 provided by the user. The means by which authorization are provided
288 are outside the scope of this document. Authorization may have been
289 provided ahead of time through access lists, perhaps specified in a
290 web page. Authorization may have been provided by means of uploading
291 some kind of standardized access control list document
293 6.7. Notifier Generation of NOTIFY requests
295 The SIP Events specification details the formatting and structure of
296 NOTIFY messages. However, packages are mandated to provide detailed
297 information on when to send a NOTIFY, how to compute the state of the
298 resource, how to generate neutral or fake state information, and
299 whether state information is complete or partial. This section
300 describes those details for the "comm-barring-info" event package.
302 A notifier MUST send a NOTIFY when a communication barring is enacted
303 on behalf of the user. If there is a stored filter criteria for the
304 user, then the notifier MUST look into the filter criteria before
305 generating the NOTIFY request towards the user. If the filter
306 criteria matches, then the notifier generates the NOTIFY request and
307 sends the NOTIFY request to the user. If the filter criteria does
308 not match the enacted communication barring, then the notifier just
309 increments the communication barring count and does not send any
310 NOTIFY request towards the user.
312 The body of the NOTIFY MUST be sent using the type "application/
313 comm-barring-info+xml" and must contain the elements defined in
314 Section 8.1.2 only. The Content-Type header field MUST be set to
315 "application/comm-barring-info+xml".
317 It is RECOMMENDED that the notifiers do maintain the history of last
318 N communication barrings that occurred, where the value N >=1 as part
319 of state information for that server and include it in the
320 communication barring notification information sent to the user. in
321 addition to this it is also RECOMMENDED that the notifiers maintain
322 the list of last M communication barring notifications sent to the
323 user, where M equal to or less than N. M equals N if notifications
324 are sent for all communication barrings that occurred. The value M
325 is decremented whenever a communication barring notification is sent
326 to the user. The notifiers check the value of M as being greater
327 than 0 prior to generating the notification information.
329 The value of N could be configured and is left to server policy to
330 determine appropriate value.
332 The state information is retained even after the notification for
333 those barrings are sent to the subscriber and changes when new
334 barring occurs and whenever a notification is sent. So every time a
335 new barring occurs and a notification is sent, the state information
336 changes to reflect the latest barring removing the oldest barring
337 information and to reflect the latest notification information sent.
339 6.8. Subscriber Processing of NOTIFY Requests
341 The SIP Events specification expects event packages to describe the
342 process followed by the subscriber upon receipt of a NOTIFY request.
343 In this specification, each NOTIFY request contains a comm-barring-
344 info document
346 6.9. Handling of Forked Requests
348 The SIP Events specification requires each package to describe
349 handling of forked Requests.
351 Though the incoming SUBSCRIBE request could be forked, this
352 specification only allows a single dialog to be constructed as a
353 result of emitting an initial SUBSCRIBE request, This guarantees that
354 only a single notifier is generating notifications for a particular
355 subscription to a particular user.
357 6.10. Rate of Notifications
359 The SIP Events specification requires each package to specify maximum
360 rate at which notifications can be sent .
362 Comm_barring-info notifiers SHOULD NOT generate notifications for a
363 single subscription at a rate of more than once every five seconds.
365 6.11. State Agents
367 The notifiers maintain the state of last N communication barrings and
368 last M communication barring notification sent, where N (N>=1) is the
369 number of communication barrings that occurred in the network on
370 behalf of the subscriber and M is the number of communication barring
371 notifications sent to the user. If notifications are sent for every
372 communication barring that occurred, then M will be equal to N, else
373 M will be less than N if filter criteria comes into play.
375 Thus at any point of time a subscriber MAY know the state of
376 communication barrings enacted on his or her behalf and number of
377 notifications sent by the server.
379 7. Comm_barring-info Document
381 Comm_barring-info document is an XML document [8] that MUST be well-
382 formed and SHOULD be valid. Communication Barring Information
383 documents MUST be based on XML 1.0 and MUST be encoded using UTF-8
384 [9].
386 8. Structure of Comm_barring-info Format
388 A Communications Barring Information document starts with a "comm-
389 barring-info" element. The comm-barring-info element has a series of
390 elements describing the particular communication barring or the
391 filter criteria for receiving the communication barring information.
393 8.1. Comm_barring-info Element
395 The comm-barring-info element gives information about the specific
396 communication barring or it could give information about a particular
397 selection criteria for the user receiving the communication barring
398 information.
400 8.1.1. comm-barring-subs-info Element
402 The comm-barring-subs-info element is used by the subscribing user to
403 specify the communication barring information selection criteria and
404 the communication barring notification trigger criteria. It contains
405 the following elements:
407 8.1.1.1. comm-barring-selection-criteria
409 This element contains information about communication barring
410 information selection criteria. It contains following sub-elements
411 for specifying the selection criteria.
413 8.1.1.1.1. originating-user-selection-criteria
415 This element specifies the originating user information for the
416 communication i.e. the caller. This is specified in the form of
417 "user-name" and "user-uri". E.g. sip:Alice@domain.com. The Username
418 as well as User-URI specified will be compared with the originating
419 user information of the current user and if there is a match, then
420 information about the barring of this specific communication would be
421 selected for notification to the Subscriber. It consists of the
422 following sub-elements.
424 8.1.1.1.1.1. user-info
426 This element gives user details like username and URI. This element
427 has further sub-elements for describing username and user URI
429 8.1.1.1.1.1.1. User-name
431 This element gives Username. "Alice".
433 8.1.1.1.1.1.2. User-URI
435 This element gives User URI. E.g "sip:Alice@domain.com". It takes
436 the form of any URI scheme like sip. sips, tel or any other URI
437 scheme
439 8.1.1.1.2. barring-time-selection-criteria
441 This element specifies the time range for receiving notifications.
442 It contains following additional elements .
444 8.1.1.1.2.1. time-range
446 This element specifies the time range at which notifications for
447 communication barrings can be sent to the subscriber. This could be
448 specified in the form of a time-interval to enable periodic
449 triggering of notifications of communication barrings which took
450 place in that time-interval.
452 NOTE: If the time-range element is not specified, then notifications
453 about every communication barring that occurs is sent to the
454 subscriber.
456 8.1.1.1.2.1.1. start-time
458 This element specifies the start time for receiving notifications.
459 Its value is expressed in YYYY:MM:DDTHH:MM:SSZ format.
461 8.1.1.1.2.1.2. end-time
463 This element specifies the end time for receiving notifications. Its
464 value is expressed in YYYY:MM:DDTHH:MM:SSZ format.
466 8.1.1.1.3. barring-reason-selection-criteria
468 This element contains the reason for communication barring. It
469 contains following sub-element:
471 8.1.1.1.3.1. barring-reason-info
473 This element gives the actual reason for the communication barring.
474 E.g. "Call Forward on Busy".
476 8.1.1.1.4. number-of-barrings-selection-criteria
478 This element contains the total number of barrings that occurred in
479 network on behalf of the user till then.
481 8.1.1.1.5. number-of-notifications-selection-criteria
483 This element contains the total number of communication barring
484 notifications sent by the network to user till then.
486 8.1.1.2. comm-barring-ntfy-trigger-criteria
488 8.1.1.2.1. notification-time-selection-criteria
490 This element informs the server about the time at which the
491 notification should be triggered.
493 8.1.1.2.2. presence-status-selection-criteria
495 This element gives the presence status of the subscriber, based on
496 which the decision can be made, whether the subscriber wishes to
497 receive notification information or not.
499 8.1.1.2.2.1. presence-selection-info
501 This element specifies the presence status of the subscriber within
502 which the subscriber expects to receive notifications about
503 communication barrings.
505 8.1.2. Comm-barring-ntfy-info Element
507 This element gives the notification information. This element has
508 following sub-elements:
510 8.1.2.1. originating-user-info
512 Refer to Section 8.1.1.1.1 for details of this element.
514 8.1.2.2. barring-time-info
516 This element gives the time of communication barring. Its value is
517 expressed in YYYY:MM:DDTHH:MM:SS format.
519 8.1.2.3. barring-reason-info
521 This element contains the reason for the communication barring which
522 could be because of the standard rules like ICB or ACR or any other
523 custom rule defined by the subscriber.
525 8.1.2.4. num-barrings
527 This element gives the number of communication barrings that occurred
528 in the network on behalf of the user till date.
530 8.1.2.5. num-notifications
532 This element gives the number of communication barring notifications
533 sent till date to the user.
535 8.1.3. Comm_barring-info-selection-criteria
537 This element gives the subscriber various to select communication
538 barring information. This element has following sub-elements.
540 8.1.3.1. disable-originating-user-info
542 This element gives the subscriber option of adding originating user
543 information to the notification information. The default value is
544 false which means the subscriber wants the originating-user-info
545 element to be present in the notification information.
547 8.1.3.2. disable-barring-time-info
549 This element gives the subscriber option of adding barring-time
550 information to the notification information. The default value is
551 false which means the subscriber wants the barring-time-info to be
552 present in the notification information.
554 8.1.3.3. disable-barring-reason
556 This element gives the subscriber option of adding barring-reason
557 information to the notification information. The default value is
558 false which means the subscriber wants the barring-reason information
559 to be present in the notification information.
561 8.1.3.4. disable-barring-rule
563 This element gives the subscriber option of adding barring-rule
564 information to the notification information. The default value is
565 false which means the subscriber wants the barring-rule information
566 to be present in the notification information.
568 8.1.3.5. disable-number-of-barrings
570 This element gives the subscriber option of adding number of barrings
571 that occurred till date to the notification information. The default
572 value is false which means the subscriber wants the number of
573 barrings that occurred till date information to be present in the
574 notification information
576 8.1.3.6. disable-number-of-notifications
578 This element gives the subscriber option of adding number of
579 communication barring notifications sent to the user till date to the
580 notification information. The default value is false which means the
581 subscriber wants the number of notifications that were sent to the
582 user till date information to be present in the notification
583 information.
585 8.2. Sample Notification body
587 8.2.1. Instance of communication barring subscription filter document
589
590
591
592
593
594 Boss
595
596 sip:boss@office.com
597
598
599
600
601
602 1999-05-31T13:20:00-05:00Z
603 2006-05-06T13:20:00-05:00Z
604
605
606
607 404 302
608
609
610
611
612
613 1999-05-31T13:20:00-05:00Z
614 2006-05-06T13:20:00-05:00Z
615
616
617
618
619
621 8.2.2. Instance of communication barring notification document
623
624
625
626 Boss
627 sip:boss@office.com
628
629 1999-06-01T13:20:00-05:00Z
630
631 404
632 1
633 1
634
635
637 8.3. Schema
639
640
647
650
652
655
657
661
662
663
665
667
669
670
672
673
680
681
682
685
688
691
693
694
695
696
700
701
702
704
706
708
710
712
715
717
718
719
722
723
724
726
729
732
734
735
736
739
740
741
744
747
749
750
751
752
753
754
755
757
758
759
762
763
764
766
768
770
772
774
776
778
779
781
782
783
784
786
787
788
790
794
795
796
797
798
799
800
801
802
803
804
807
808
809
810
812
813
814
817
818
819
822
823
824
827
828
829
831
832
833
836
837
838
841
842
843
846
847
848
849
850
851
852
855
856
857
861
862
863
866
867
868
869
870
871
873 9. Security Considerations
875 Authentication and authorization of subscriptions have been discussed
876 in Section 6.6. Lack of authentication or authorization may provide
877 comm-barring-info information to unauthorized parties and can reveal
878 sensitive information with regards to the user's call receiving
879 patterns. For example, who calls the user and at what time, etc.
881 Integrity protection and confidentiality of notifications are also
882 discussed in Section 6.7. If a notifier does not encrypt bodies of
883 NOTIFY requests, an eavesdropper could learn the status of a SIP user
884 agent and use it to create malicious sessions. If the notifier does
885 not integrity protect the bodies of NOTIFY requests, a man-in- the-
886 middle attacker or malicious SIP proxy could modify the contents of
887 the comm-barring-info event package notification. Although this does
888 not cause harm, it can create annoyances.
890 10. IANA Considerations
892 This document registers the new SIP Event Package.
894 10.1. Communication Barring Information Event Package Registration
896 Package Name: Comm_barring-info
898 Type: Package
900 Contact: Jon Merdith,
902 Published Specification: RFC XXXX (Note to RFC Editor)
904 11. Acknowledgements
906 The authors would like to thank Samir Saklikar, Subir Saha, Ban Al-
907 Bakri, John Elwell, Paul Kyzivat and Mary Barnes for their useful
908 suggestions.
910 12. References
912 12.1. Normative References
914 [1] 3GPP, "Anonymous Communication Rejection (ACR) and Communication
915 Barring (CB) using IP Multimedia (IM) Core Network (CN)
916 subsystem; Protocol specification", 3GPP TS 24.611 8.2.0,
917 December 2008.
919 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
920 Levels", BCP 14, RFC 2119, March 1997.
922 [3] Peterson, J., Jennings, C., and R. Sparks, "Change Process for
923 the Session Initiation Protocol (SIP) and the Real-time
924 Applications and Infrastructure Area", BCP 67, RFC 5727,
925 March 2010.
927 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
928 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
929 Session Initiation Protocol", RFC 3261, June 2002.
931 [5] 3GPP, "IP Multimedia Core Network Subsystem (IMS) Multimedia
932 Telephony Service and supplementary services; Stage 1", 3GPP
933 TS 22.173 10.2.0, March 2010.
935 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
936 Notification", RFC 3265, June 2002.
938 12.2. Informative References
940 [7] 3GPP, "IP multimedia call control protocol based on Session
941 Initiation Protocol (SIP) and Session Description Protocol
942 (SDP); Stage 3", 3GPP TS 24.229 10.1.0, September 2010.
944 [8] Bray, T., Sperberg-McQueen, C., Paoli, J., and E. Maler,
945 "Extensible Markup Language (XML) 1.0 (Second Edition)", World
946 Wide Web Consortium FirstEdition REC-xml-20001006, October 2000,
947 .
949 [9] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
950 J., and J. Rosenberg, "Common Policy: A Document Format for
951 Expressing Privacy Preferences", RFC 4745, February 2007.
953 Appendix A. Change log
955 [RFC EDITOR NOTE: Please remove this section when publishing]
957 Changes from draft-avasarala-sipping-comm-barring-notification-00
959 o Moved from SIPPING to DISPATCH WG.
961 o Incorporated review comments.
963 o Re-submitting since -00 expired
965 Authors' Addresses
967 Ranjit Avasarala
968 Motorola Solutions India Pvt Ltd
969 Bagamane Tech Park, C V Raman Nagar
970 Bangalore 560093
971 India
973 Email: ranjit@motorolasolutions.com
975 Roland Jesske
976 Deutsche Telekom
977 Heinrich-Hertz-Strasse 3-7
978 Darmstadt 64307
979 Germany
981 Email: r.jesske@telekom.de