idnits 2.17.1 draft-loreto-sipping-3gpp-ics-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 343. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 356. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 16, 2006) is 6517 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group S. Loreto 3 Internet-Draft S. Terrill 4 Expires: December 18, 2006 Ericsson 5 June 16, 2006 7 Input 3rd-Generation Partnership Project (3GPP) Communications Service 8 Identifiers Requirements on the Session Initiation Protocol (SIP) 9 draft-loreto-sipping-3gpp-ics-requirements-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 18, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The 3rd-Generation Partnership Project (3GPP) is developing the 43 capability to support different communication services on IP 44 Multimedia Subsystem (IMS) as a SIP infrastructure, such as push-to- 45 talk over cellular (PoC), Multimedia Telephony or IMS messaging. As 46 there are different services and is not safe to rely on the expressed 47 media as a means to identify the requested communication service 48 because the media may be used in different communication services, 49 then there is the need to have an unambiguous way of identifying 50 communication services and applications utilizing the logic of 51 communication services as explicitly as possible. In this document, 52 we express the requirements identified by 3GPP to support the 53 identification of communication services and applications on a 54 Session Initiation Protocol (SIP) infrastructure and IMS applications 55 using them. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Requirements on the identification of communication 64 services . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Requirements on the identification of applications 66 using the communication services. . . . . . . . . . . . . 6 67 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 6.2. Informational References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 Intellectual Property and Copyright Statements . . . . . . . . . . 10 75 1. Introduction 77 The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia 78 Subsystem) uses the Session Initiation Protocol (SIP) [1] as its main 79 signaling protocol. (For more information on the IMS, a detailed 80 description can be found in 3GPP TS 23.228 [2] and 3GPP TS 24.229 81 [3]). 83 During the definition of the IMS, 3GPP has adopted the approach of 84 defining a number of procedures and protocols, aggregated in a number 85 of communication services to be used by a number of service 86 applications. With a system that supports a number of applications, 87 each of them utilizing one or more communication services leads to 88 the need of identifying both the communication service and 89 application being invoked. In Release 7 3GPP has identified a set of 90 requirements for the identification of IMS communication services [4] 91 and IMS applications using them. 93 In addition the IMS architecture has been adopted by a number of 94 standardization organizations which themselves, as well as 3GPP, have 95 been defining communication services which can operate over the IMS 96 architecture. These communication services often require the support 97 from particular application server functionality defined for the 98 communication service. 100 The remainder of this document is organized as follows. Section 3 101 gives an overview of the 3GPP scenarios and Section 4 discusses the 102 requirements derived from these scenarios. Section 5 discusses the 103 security properties. 105 1.1. Terminology and Acronyms 107 Application : An application uses a communication service in order to 108 provide a specific service to the end-user. 109 Application Server (AS) : It is a SIP entity that hosts and executes 110 services. Depending on the actual service the AS can operate in 111 SIP proxy mode, SIP UA mode, or SIP B2BUA. 112 Communication service : It is a type of communication defined by a 113 service definition that specifies the rules and procedures and 114 allowed medias for a specific type of communication. 115 S-CSCF : It is essentially a SIP server, but it performs session 116 control as well. All the SIP signaling the IMS terminals sends, 117 and all the SIP signaling the IMS terminal receives, traverse the 118 allocated S-CSCF. The S-CSCF inspects every SIP message and 119 determines whether the SIP signaling should visit one or more 120 application servers en route toward the final destination. 122 2. Overview 124 In the IETF SIP standardization it has been assumed that the media 125 components of a session could uniquely identify the communication 126 service. 128 In a multi-service architecture like IMS, a particular media can be 129 used by a number of services. One such example is audio (RTP media) 130 that is used in both push-to-talk and IMS Multimedia Telephony, but 131 with totally different behaviour. For this reason a certain type of 132 medium does not unambiguously identify a service. In the same way 133 the full set of the medium involved in a particular service could not 134 unambiguously identify a service. 136 The IMS is a multi-service architecture, implying that a number of 137 communication services can be built on a common architecture. A 138 description of a communication service contains a description of the 139 procedures for communication between different terminals. A 140 communication service may be used to contact other users, as well as 141 other services. As the IMS is based on SIP, the majority of the SIP 142 procedures are common amongst the different communication services, 143 though there may be specific usages of the procedures or functions in 144 the network to support the service. 146 3GPP describes an IMS Communication Service as an aggregation of one 147 or several media components and the service logic managing their 148 aggregation represented in the protocol used. That means in IMS it 149 is possible to introduce new services where for the same media 150 different service logic can be applied, and different media handling 151 could occur for different services. 153 The logic of each of the standardized communication service can be 154 utilized by a number of applications, each of them implementing a 155 particular end-user service. Indeed other than the Default 156 Application for the specific communication service it is also 157 possible to define different applications using the same 158 communication service. 160 It is therefore necessary to design a mechanism that is separate from 161 the media to identify both communication services and end-user- 162 applications utilizing a set of communication services. 164 A communication service identifier and an application reference 165 provide a framework for the identification of communication services 166 and applications. 168 This could be seen as a means to identify the context upon which to 169 interpret the SIP signaling, e.g. the media authorization policy can 170 be different for different services using the same media, or the 171 identification of a service can be used in when the network is 172 experiencing overload, where either some service may be prioritized 173 over other services. Additionally it has to be identified in which 174 end-user application context each communication service is used, 175 specially having in mind that each of communication services can be 176 simultaneously used by a number of applications. 178 At terminals, the use of a communication service identifier is 179 similar to the use of the address and port concept in TCP/IP, in that 180 it allows applications in a terminal and the network that use SIP for 181 communication purposes to be identified. In the terminal this means 182 dispatching a SIP message to the correct application. It means that 183 a SIP message can be dispatched to the correct communication service 184 and a correct application can be invoked and receive this message. 186 3. Requirements 188 3.1. Requirements on the identification of communication services 190 This section lists the requirements the communication service should 191 fulfill: 193 REQ-1: The Communication Service Identifier identifies the 194 communication services and shall be included in the relevant SIP 195 methods. 196 REQ-2: It shall be possible for all entities in the networks, which 197 evaluate the different possible protocol elements in order to 198 determine which communications service is requested, arrive at the 199 same result. 200 REQ-3: It shall be possible for the UA and an Application Server (AS) 201 to set the Communication Service Identifier in a SIP request, e.g. 202 in the REGISTER and INVITE request. 203 REQ-4: Based on operator policy the S-CSCF or an AS shall be able to 204 validate a Communication Service Identifier in a SIP request. 205 REQ-5: It shall be possible for the UA to identify a communication 206 service uniquely by the Communication Service Identifier. 207 REQ-6: It shall be possible for the UA to use the Communication 208 Service Identifier as a key for dispatching the SIP Message to the 209 appropriate communication service logic. 210 REQ-7: It shall be possible for the UA to indicate its service 211 capabilities to the network, e.g. during registration, using the 212 Communication Service Identifier. 214 REQ-8: The structure of the Communication Service Identifier shall be 215 as simple as possible, i.e. the Communication Service Identifier 216 shall be limited to identify a service. 217 REQ-9: Based on operator policy, the Communication Service Identifier 218 shall be able to be used as a means to authorize and comunicate to 219 the UA whether a subscriber is allowed to initiate or receive 220 requests for a communication service. 221 REQ-10: It shall be possible to take into account the Communication 222 Service Identifier when selecting the correct UA(s) (i.e. in order 223 to direct a terminating communication request towards a UA that 224 understands the communication service). 225 REQ-11: The usage of Communication Service Identifier shall not 226 adversely affect interoperability between IMS networks and 227 interoperability with external SIP networks. The behaviour of a 228 network receiving the IMS requests without a Communication Service 229 Identifier is a matter of operator policy. Usage of communication 230 service identifier shall not decrease the level of 231 interoperability with networks and UAs that are unaware of the 232 communication service identifier. 233 REQ-12: The usage of Communication Service Identifiers shall not 234 restrict the inherent capabilities of SIP 235 REQ-13: The usage of Communication Service Identifiers shall not 236 require additional user interaction, i.e. the Communication 237 Service Identifier is assumed to be "added" by the UA that 238 initiates the communication. 239 REQ-14: It shall be possible for the S-CSCF to invoke appropriate 240 service logic based on the communication service identifier, as 241 for all other information elements contained in a SIP request, 242 e.g. route a SIP request containing a communication identifier to 243 the correct AS. 245 3.2. Requirements on the identification of applications using the 246 communication services. 248 REQ-1: The Application Reference identifies the application that is 249 using a communication service and shall be possible included in 250 the relevant SIP methods. 251 REQ-2: It shall be possible for the UA and an Application Server (AS) 252 to set the Application Reference in a SIP request, e.g. in the 253 REGISTER and INVITE request. 254 REQ-3: It shall be possible for the UA to identify an end-user 255 application uniquely by the Application Reference contained in a 256 received SIP request. 257 REQ-4: It shall be possible for the UA to invoke appropriate 258 application that is using a communication service based on the 259 Application Reference. 261 REQ-5: It shall be possible for the AS to identify the application or 262 the end-user application context that is using a communication 263 service through the use of Application Reference. 264 REQ-6: It shall be possible for the UA to indicate its end-user 265 service capabilities to the network, e.g. during registration, 266 using the Application Reference. 267 REQ-7: The structure of the Application Reference shall be as simple 268 as possible, i.e. the Application Reference shall be limited to 269 identify the application. 270 REQ-8: The usage of Application Reference shall not restrict the 271 inherent capabilities of SIP 272 REQ-9: The usage of Application Reference shall not require 273 additional user interaction, i.e. the Application Reference is 274 assumed to be "added" by the UA the initiates the communication. 276 4. IANA considerations 278 No actions from the IANA are requested. 280 5. Security Considerations 282 This document discusses high-level requirements for SIP 283 Communications Service and Applications Identifiers. Communication 284 Service has some specific security requirements, which will be 285 summarized here at a very high level. 287 All of the operations and functions described in this document need 288 to be authorized by the user or the network. It is expected that 289 Communication Service will be governed by a set of authorization 290 rules defined as a part of the Communication Service policy. 292 These Communication Service security requirements will be discussed 293 in detail in the protocol documents. 295 6. References 297 6.1. Normative References 299 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 300 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 301 Session Initiation Protocol", RFC 3261, June 2002. 303 6.2. Informational References 305 [2] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 306 7.3.0, March 2006. 308 [3] 3GPP, "Internet Protocol (IP) multimedia call control protocol 309 based on Session Initiation Protocol (SIP) and Session 310 Description Protocol (SDP); Stage 3", 3GPP TS 24.229 7.3.0, 311 March 2006. 313 [4] 3GPP, "Identification of communication services in IMS", 3GPP 314 TR 23.816 7.0.0, March 2006. 316 Authors' Addresses 318 Salvatore Loreto 319 Ericsson 320 Hirsalantie 11 321 Jorvas 02420 322 Finland 324 Email: Salvatore.Loreto@ericsson.com 326 Stephen Terrill 327 Ericsson 328 Via de los Poblados, 13 329 Madrid 28033 330 Spain 332 Email: Stephen.Terrill@ericsson.com 334 Intellectual Property Statement 336 The IETF takes no position regarding the validity or scope of any 337 Intellectual Property Rights or other rights that might be claimed to 338 pertain to the implementation or use of the technology described in 339 this document or the extent to which any license under such rights 340 might or might not be available; nor does it represent that it has 341 made any independent effort to identify any such rights. Information 342 on the procedures with respect to rights in RFC documents can be 343 found in BCP 78 and BCP 79. 345 Copies of IPR disclosures made to the IETF Secretariat and any 346 assurances of licenses to be made available, or the result of an 347 attempt made to obtain a general license or permission for the use of 348 such proprietary rights by implementers or users of this 349 specification can be obtained from the IETF on-line IPR repository at 350 http://www.ietf.org/ipr. 352 The IETF invites any interested party to bring to its attention any 353 copyrights, patents or patent applications, or other proprietary 354 rights that may cover technology that may be required to implement 355 this standard. Please address the information to the IETF at 356 ietf-ipr@ietf.org. 358 Disclaimer of Validity 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 363 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 364 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 365 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Copyright Statement 370 Copyright (C) The Internet Society (2006). This document is subject 371 to the rights, licenses and restrictions contained in BCP 78, and 372 except as set forth therein, the authors retain all their rights. 374 Acknowledgment 376 Funding for the RFC Editor function is currently provided by the 377 Internet Society.