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