idnits 2.17.1 draft-rosenberg-sipping-service-identification-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 865. 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 : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 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 (March 5, 2007) is 6261 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-11 == Outdated reference: A later version (-07) exists of draft-ietf-ecrit-service-urn-05 == Outdated reference: A later version (-02) exists of draft-rosenberg-sip-ua-loose-route-00 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-10 == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-04 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '13') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '15') (Obsoleted by RFC 5727) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Best Current March 5, 2007 5 Practice 6 Expires: September 6, 2007 8 Identification of Communications Services in the Session Initiation 9 Protocol (SIP) 10 draft-rosenberg-sipping-service-identification-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 6, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document considers the problem of how SIP endpoints can support 44 a multiplicity of distinct SIP services within the context of a 45 single user agent. The principle problem to be addressed is that of 46 dispatching of incoming requests to the right services, and how 47 service contexts are matched up between calling and called parties. 48 This document proposes the usage of service URN and service URI to 49 solve the problem. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Concepts and Terminology . . . . . . . . . . . . . . . . . . . 4 57 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 59 7. UA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 7.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 61 7.2. Publication . . . . . . . . . . . . . . . . . . . . . . . 10 62 7.3. Session Initiation . . . . . . . . . . . . . . . . . . . . 10 63 7.4. Receipt of a Request . . . . . . . . . . . . . . . . . . . 11 64 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 12 65 8.1. Request Targeting . . . . . . . . . . . . . . . . . . . . 12 66 8.2. Application Invocation . . . . . . . . . . . . . . . . . . 12 67 9. Guidelines for Using Service URN . . . . . . . . . . . . . . . 13 68 10. Guidelines on Namespace Structure . . . . . . . . . . . . . . 14 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 73 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 75 15.2. Informational References . . . . . . . . . . . . . . . . . 18 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Intellectual Property and Copyright Statements . . . . . . . . . . 20 79 1. Introduction 81 The Session Initiation Protocol (SIP) [2] defines mechanisms for 82 initiating and managing communications sessions between agents. 83 These agents can be entities such as hardphones, softphones, or 84 gateways to other networks, such as the PSTN. These agents are 85 addressed by SIP URI, and in particular, a SIP Address-of-Record or 86 AOR. 88 However, in practice, the entities participating in a call can be 89 more complicated. An agent might be inside of a cell phone, 90 supporting traditional telephony, Push-To-Talk, and voice and data 91 content as part of an interactive game. Furthermore, the servers 92 within the network itself might provide additional functions, such as 93 call screening or call recording. These functions are often referred 94 to as 'services', 'features' or 'applications'. Their usage raises 95 questions on how users invoke them, how they are identified, and how 96 interoperability between them is provided. 98 Section 3 defines the problem in more detail. Section 4 defines 99 concepts and terminology. Section 5 introduces requirements for the 100 solution. Section 6 overviews the solution, and Section 7 defines 101 detailed procedures for user agents, while Section 8 defines 102 procedures for proxies. 104 2. Terminology 106 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 108 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 109 [1] and indicate requirement levels for compliant STUN 110 implementations. 112 3. Problem Statement 114 Consider a device that allows the user to select two applications. 115 One of these applications is a traditional telephony application, 116 which lets the user make and receive phone calls using telephone 117 numbers. The second application is a two-player chess game that 118 utilizes voice commands to move pieces. When one player says "Queen 119 to D7", the software on their phone recognizes this and moves the 120 piece. At the same time, the user's voice is sent to the other 121 player, where it is both rendered to the user, and interpreted 122 locally in order to move the piece. 124 If the user should make a call using the telephony application, the 125 result would be a SIP INVITE for a single voice media stream. 126 Interestingly, if the user launches the game application, the same is 127 true - the result would be a SIP INVITE for a single voice media 128 stream. However, depending on which application the caller selected, 129 the appropriate application at the called party must also be 130 selected. It would be nonsensical for the user to invoke the 131 telephony application and be connected to the gaming application on 132 another user's device. The user interface for the gaming application 133 would not function properly, and the overall experience would be 134 poor. What is needed is some kind of way to differentiate these two 135 applications. 137 A similar problem arises in the invocation of outbound applications 138 that reside in the network. Consider once more our user with the 139 telephony and gaming application. The user wishes to make a 140 telephony call, but wants the call to be recorded. The recording 141 option is available on a call-by-call basis. The recording 142 application itself resides on a server in the domain of the caller, 143 and acts as a back-to-back user agent (B2BUA) in order to perform the 144 call recording (there are alternative models involving the 145 application interaction framework [9] and conferencing [12], but the 146 specific mechanism is not relevant to the discussion here). When the 147 user initiates the call, how do they signal to their outbound proxy 148 that the call needs to pass through the recording application? 150 In both cases, the problem at hand is the identification and 151 invocation of applications which reside either on the endpoint (in 152 the first example) or in the network (in the second example). 154 4. Concepts and Terminology 156 The problem of identifying and invoking services within SIP is not a 157 new one. The problem has been considered extensively in the context 158 of presence. In particular, the presence data model for SIP [14] 159 defines the concept of a service as one of the core notions that 160 presence describes. Services are described in Section 3.3 of RFC 161 4479, which has this to say on the topic: 163 3.3. Service 165 Each presentity has access to a number of services. Each of these 166 represents a point of reachability for communications that can be 167 used to interact with the user. Examples of services are telephony 168 (that is, traditional circuit-based telephone service), push-to-talk, 169 instant messaging, Short Message Service (SMS), and Multimedia 170 Message Service (MMS). 172 It is difficult to give a precise definition for service. One 173 reasonable approach is to model each software or hardware agent in 174 the system as a service. If a user starts a softphone application on 175 their PC, then that represents a service. If a user has a videophone 176 device, then that represents another service. This is effectively a 177 physical view of services. This definition, however, starts to fall 178 apart when a service is spread across multiple software agents or 179 devices. For example, a SIP URI representing an address-of-record 180 can be routed to a softphone or a videophone, or both. In that case, 181 one might attempt instead to define a service based on its address on 182 the network. This definition also falls apart when modeling devices 183 or applications that receive calls and dispatch them to different 184 "helpers" based on potentially complex logic. For example, a 185 cellular telephone might house multiple SIP applications, each of 186 which can "register" different handlers based on the method or even 187 body type of the request. Each of those applications or handlers can 188 rightfully be considered a service, but it doesn't have an address on 189 the network distinct from the others. 191 Because of this inherent difficulty in precisely defining a service, 192 the data model doesn't try to constrain what can be considered a 193 service. Rather, anything can be considered a service so long as it 194 exhibits a set of key properties defined by this model. In 195 particular, each service is associated with characteristics that 196 identify the nature and capabilities of that service, with reach 197 information that indicates how to connect to the service, with status 198 information representing the state of that service, and relative 199 information that describes the ways in which that service relates to 200 others associated with the presentity. 202 As a consequence, in this model, services are not explicitly 203 enumerated. There is no central registry where one finds identifiers 204 for each service. Consequently, each service does not have a single 205 "service" attribute with values such as "ptt" or "telephony". That 206 doesn't mean that these consolidated monikers aren't useful; indeed, 207 they represent an essential summary of what the service is. Such 208 summarization is useful in creating icons that allow a user to choose 209 one service over another. A watcher is free to create such 210 summarization information from any of the information associated with 211 a service. The reach information often provides valuable information 212 for creating such a summarization. Oftentimes, the scheme of the URI 213 is synonymous with the view of what a service is. An "sms" URI [14] 214 clearly indicates SMS, for example. For some URIs, there may be many 215 services available, for example, SIP or tel [15], in which case the 216 scheme is less meaningful as a way of creating a summary. The reach 217 information could also indicate that certain application software has 218 to be invoked (such as a videogame), in which case that aspect of the 219 reach information would be useful for generating an iconic 220 representation of the game. 222 Building upon this, we can model a user agent as containing a SIP 223 processing layer ontop of which sit a number of different SIP 224 services, as shown in Figure 2 226 +---------------------------------+ 227 | | 228 | +-------------+ +-------------+ | 229 | | UI | | UI | | 230 | +-------------+ +-------------+ | 231 | +-------------+ +-------------+ | 232 | | | | | | 233 | | Service 1 | | Service 2 | | 234 | | | | | | 235 | +-------------+ +-------------+ | 236 | +-----------------------------+ | 237 | | | | 238 | | SIP | | 239 | | Layer | | 240 | | | | 241 | +-----------------------------+ | 242 | | 243 +---------------------------------+ 245 Physical Device 247 Figure 2 249 The role of the SIP layer is to parse incoming messages, handle the 250 SIP state machinery for transactions and dialogs, and then dispatch 251 request to the appropriate service. The dispatching operation is 252 based on any number of criteria in the SIP message itself. For 253 example, the method might be used to dispatch the request. A 254 messaging application on the phone would be dispatched when a MESSAGE 255 request arrives. Similarly, when a user interacts with the device, 256 they would select a specific service, and then use that service to 257 initiate communications. The service would then request the SIP 258 layer to send an appropriate message, depending on what was needed. 259 Each service has a user interface (UI) that dictates how it interacts 260 with the user. 262 SIP uses URI, and in particular, SIP URI, to identify resources 263 within the system. The Address-of-Record, or AOR, identifies the 264 user that is the originator or target of the request. The Globally 265 Routable User Agent URI (GRUU) [4] identifies a specific instance of 266 a user agent. In the model of Figure 2, there is still but one user 267 agent, and thus a single GRUU. However, we have effectively 268 introduced a layer of hierarchy into the system. Within a particular 269 UA instance, there can be one or more service instances. Each 270 service instance can be addressed by a URI. This URI is formed by 271 adding a parameter, at the discretion of the UA, to the GRUU. The 272 resulting URI is called a service instance URI. 274 When a service spans multiple devices and multiple SIP UA instances, 275 the aggregate set is represented by a service URI. Typically, a 276 domain will need to construct such a URI, and bind it to the various 277 service instances that can be reached through the service URI. 279 In addition, each service may or may not be a well-known service. A 280 well-known service is identified by a service URN [5]. The URN 281 refers to the set of assumptions and processing requirements within 282 the service layer that define how a request is processed. For 283 example, a service URN of urn:service:games:voice-chess could be used 284 to identify the voice chess application described in Section 3. In 285 this case, the URN would need to be standardized, and there would be 286 agreement that the "context" is that voice is interpreted by speech 287 recognition for the purposes of performing chess moves, and a 288 specific set of phrases would be agreed upon. It is also possible to 289 have vendor specific services, which would be identified using a URN 290 such as "urn:service:vnd:example.com:foobar", which refers to the 291 foobar service produced by a specific vendor. 293 It is extremely important to note that this name refers to the 294 additional logic that is required in the processing of a SIP session 295 in order for it to be successfully utilized. SIP assumes that the 296 "normal" service is multimedia communications - the exchange of real 297 time media between the users which generated and received the 298 requests for the purpose of communications between humans or automata 299 which act like a human. The chess example is more than this, because 300 the media is additionally consumed by an automata that is looking to 301 do specialized processing, and because the media is not primarily for 302 human communication, its for controlling moves on a chess board. 303 Because of this, a traditional communications applications has no 304 well-known service associated with it. 306 5. Requirements 308 REQ 1: It shall be possible for an incoming request to be dispatched 309 to the correct service on a device. 311 REQ 2: When multiple services reside on a single device, sharing a 312 single SIP layer, it must not require multiple registrations. 313 This is primarily a performance and overhead requirement. 315 REQ 3: It shall be possible to support cases where sessions 316 initiated from a particular service purposefully fail unless they 317 can be connected to a matching service for the called party. 319 REQ 4: It must be possible for services to "match" based on 320 proprietary and well-known identifiers. 322 REQ 5: It must be possible for a user to initiate a session without 323 knowledge of any information about the recipient except for their 324 AOR. 326 REQ 6: The mechanism must allow a presence server to determine the 327 services on the phone, without requiring advanced knowledge of 328 those services. 330 REQ 7: It must be possible to support cases where sessions initiated 331 from a service on the caller side connect to a different service 332 on the other side in cases where the session is meaningful when 333 the notions of service on each side do not match. 335 6. Overview of Operation 337 The proposed solution to the problem is relatively straightforward. 339 The essential problem is that there are cases where a session cannot 340 take place correctly unless the terminating party implements a 341 certain piece of service logic. This is directly analagous to the 342 case where a session cannot take place correctly unless the 343 terminating party implements a certain SIP extension correctly; the 344 problem is just occurring at a different layer in the stack based on 345 the model of Figure 2. Consequently, the proposed solution is 346 similar. The Require header field is utilized, and the option tag is 347 just the service URN for the well-known service, suitably escaped. 349 When a request with a Require header arrives at the home proxy of the 350 UAS, the home proxy utilizes implicit preferences, as described in 351 RFC 3841 [3]. This will prefer routing of the request to contacts 352 which have indicated support for those extensions. The UAS itself 353 uses the Require header field to dispatch the request to the correct 354 service instance. 356 In addition, the user agents make use of UA loose routing [6] and 357 GRUU [4], and add an implementation-specific parameter to their GRUU 358 for each service instance on a device. This allows future out-of- 359 dialog and mid-dialog requests to be targeted at the right service 360 instance, and provides a simple mechanism for dispatch in the device, 361 based entirely on the URI. 363 When a UAC wants the request to be processed by an application prior 364 to reaching the terminating proxy, it includes the service URN in 365 Route headers that get appended to the route set for the request. 366 For example, if a UA wants a call to be recorded, it would include a 367 service URN like "urn:service:comm:recording" to the bottom-most 368 Route header. This will cause an originating proxy to resolve the 369 service URN to a URI for an application server, and then proxy the 370 request there. 372 In order to discover available services on a device, presence can be 373 used. A UA would just SUBSCRIBE to the presence of the AOR, and get 374 back a document that contains a service element for each service 375 available for that user. The presence document includes the service 376 URN for any well-known services (noting again that this is only 377 needed when other information, such as method or media types, are 378 insufficient to define the service). The service URN can then be 379 used for creating summary information about the service. The URI 380 present in the contact for that service is the service instance URI 381 or service URI. The former is published by the UA to the network in 382 a presence document, and the latter may be constructed by the network 383 when composing documents together. 385 7. UA Behavior 387 7.1. Registration 389 When a UA supports numerous services, it SHOULD generate a single 390 registration representing the entire UA instance. The UA MUST 391 utilize GRUU [4] and UA loose routing [6]. If any of the services on 392 the UA are well-known services, the UA SHOULD include their URNs as 393 option tags in the extensions media feature tag in the Contact header 394 field parameter. 396 The media feature tags can help the network construct presence 397 documents when the UA doesn't publish them separately (though this 398 is recommended as described below). They are also used for 399 routing of requests. 401 NOTE: An alternative design would be to have each service instance 402 be a separate registered Contact. This would be more helpful for 403 presence, though not needed if a PUBLISH is used. However it has 404 the drawback of adding more state to the network and exposing 405 "internal" routing within the UA to outside of the UA. It would 406 mean that the proxy would need to know the dispatch logic, which 407 is more likely to be known by the UA. 409 7.2. Publication 411 If the UA supports presence, it SHOULD PUBLISH [7] a presence 412 document for itself. This document SHOULD include a service 413 (represented by a tuple) for each service instance. The contact of 414 each tuple SHOULD be derived from the GRUU, and constructed by adding 415 a UA-defined parameter to the GRUU for each service instance. The 416 parameter MUST be different for each service instance, and SHOULD 417 persist over time. The UA SHOULD include information that identifies 418 what the service is, including supported methods and media types, 419 when those are important for its definition. For services that 420 require well-known logic, the agent SHOULD include the service URN 421 amongst the extensions listed for that service. 423 The UA can do a better job constructing the presence document than 424 the registrar. This is because the UA knows what mechanisms are 425 used to dispatch requests to each service, and knows what well- 426 known service URN are associated with each service. Having an 427 explicit contact for each service allows a UA to unambiguously be 428 reached based on a service selection made by a watcher. This is 429 important, since choice is a key concept provided by presence 430 [14]. 432 7.3. Session Initiation 434 A UA can initiate a session either directly, or using presence. 436 When using presence, the UA would start with the AOR for the target. 437 It subscribes to the presence state for the AOR [8]. The result will 438 be a presence document that includes a tuple for each service. The 439 services will include information that describe them with sufficient 440 information for the user to choose one. This may include well-known 441 service URN associated with each service. When the user selects a 442 service for the target user, the UA will generate an INVITE to the 443 contact listed there. Since this contact is a service instance URI 444 or service URI, the request will be routed towards the target UA and 445 explicitly identify the desired service by the URI alone. 447 Of course, when the UA selected the service to contact, the request 448 would have been initiated from a matching service on the device. In 449 that case, if the initiating request is associated with a required 450 well-known service, the corresponding escaped service URN MUST appear 451 as an option tag in the Require header field. 453 When initiating a session directly, the user will select a service on 454 the phone and then request communications by entering or selecting 455 the target AOR. If the service from which the request is being made 456 is associated with a required well-known service, the corresponding 457 escaped service URN MUST appear as an option tag in the Require 458 header field. 460 This has an important procedural side effect. Based on the rules 461 of the SIP change processs [15], the Require header field can only 462 contain option tags defined in standards track documents. 463 Otherwise, the resulting protocol cannot be considered SIP. This 464 also means that a UA can only require well-known services when 465 they are IETF defined. Otherwise, the resulting protocol is 466 proprietary. This was purposefully done to help temper usage of 467 the mechanism, which can cause significant interop problems if 468 abused. 470 RFC 3261 uses the 'token' construct for option tags. The service URN 471 is a valid token with the exception of the colon (:). Consequently, 472 when used as an option tag, a service URN MUST be escape coded by 473 replacing the colon with an exclamation point (!). 475 When initiating a session from a presence document, there is no need 476 for the UA to insert any Require header fields or otherwise add any 477 content to the request beyond what is implied by the contact URI. 478 This does not prevent a UA from inserting one when the UA does in 479 fact require that a specific well-known service be present. 481 The Contact header field of a dialog forming request SHOULD be formed 482 by taking the GRUU, and adding a URI parameter (at the discretion of 483 the UA) which identifies the particular service invoking the request. 484 The resulting URI is called the service instance URI. 486 If a UA wants the network to pass the request through application 487 servers that provide specific processing, the UA MUST include a 488 service URN for that service as the bottom-most Route header. The 489 service URN that are available to the UA are learned through 490 mechanisms outside the scope of this specification, and can include 491 configuration [10] for example. If the UA wants the request to be 492 processed by multiple applications, it MUST include a Route header 493 value for each service URN. The UA SHOULD order them based on 494 desired order of invocation, if known. 496 7.4. Receipt of a Request 498 When a UA receives a request, it MAY use any content of the request 499 in order to determine which service on the device is appropriate for 500 handling the request. This includes the method, media types, and 501 required extensions, including any service URN that might be present 502 in the Require header field. The specific means by which a service 503 "registers" itself with the underlying SIP layer to drive the 504 dispatch logic is a matter of local implementation and outside the 505 scope of this specification. 507 Of course, if the UAS doesn't understand one of the option tags in 508 the Require header field, it will generate a 420 response and include 509 the list of unsupported option tags, including those which happen to 510 be service URN. This is helpful for diagnosing interoperability 511 problems due to incompatible services. 513 Once the request is delivered to the service instance for processing, 514 any response SHOULD include the service URI derived from the GRUU in 515 the Contact header field. 517 8. Proxy Behavior 519 8.1. Request Targeting 521 When a home proxy receives a request and uses the location service to 522 route the request, it SHOULD follow the procedures defined in RFC 523 3841 [3] for preference and capability matching. These SHOULD be 524 done even if the request did not contain an Accept-Contact or Reject- 525 Contact header field. When neither was present, the proxy will 526 construct implicit preferences based on the rules in Section 7.2.2 of 527 RFC 3841. 529 In addition, a proxy SHOULD construct an explicit preference for 530 extensions when the request contains a Require header field. For 531 each option tag in the Require header field, the proxy adds a term to 532 the conjunction of the following form: 534 (sip.extension=[option tag]) 536 This would include any option tags that were service URN. The result 537 will be that calls get routed to devices which understand the 538 required service. 540 8.2. Application Invocation 542 When a proxy receives a request where the next Route header field 543 value after the proxy itself contains a service URN, the proxy MUST 544 resolve the service URN to a SIP URI that can be used to perform that 545 service. The specific mechanism for resolution is outside of the 546 scope of this specification. It can include standardized resolution 547 services such as DDDS [16] or LoST [11], or can be done through local 548 configuration. 550 If there are more than one consecutive Route header field values with 551 service URN, a proxy MAY resolve all of them, and MAY reorder them 552 based on localized knowledge of the required invocation sequence. 553 This is particularly important when the proxy is aware of additional 554 applications that need to be invoked, for which it needs to add 555 additional Route header field values. 557 9. Guidelines for Using Service URN 559 This document introduces the concept of using a service URN to 560 identify well-known logic that is required in order to successfully 561 process a request. Care must be taken in the usage of this 562 mechanism, or serious interoperability problems can occur. 564 For example, consider an extreme example whereby the vendor of a UA 565 defines a service URN for each version of their software, under the 566 assumption that the logic in the UA represents a well-known service. 567 If multiple vendors do this, a request from one vendor's device will 568 fail to interoperate with the devices from any other vendor, even if 569 they would be interoperable otherwise. 571 Consider a more realistic case where a service provider chooses to 572 utilize a well-known service URN for voice telephony and another one 573 for video telephony. There is nothing unique about the actual 574 service logic used to realize each. However, calls made from the 575 video telephony application include a Require header field, requiring 576 the usage of video telephony on the other side. If the call should 577 reach a device that supports only voice, such as a PSTN gateway, the 578 call will automatically fail. However, had existing SIP negotiation 579 techniques been utilized (in this case, the ability to reject media 580 streams), the call would have succeeded. 582 It is for this reason that the well-known service URN in the Require 583 header field are restricted in several ways. Firstly, they are meant 584 specifically and exclusively for usage in cases where some service 585 logic must be present and matching on both the originating and 586 terminating sides in order for any type of reasonable communications 587 to exist. Secondly, it is limited to capabilities that cannot be 588 negotiated or indicated by other SIP techniques (such as support for 589 a specific media type). One metric for this is that, absent the 590 option tag in the Require header, a request to initiate the session 591 would be identical to a request to or from a different service that 592 is not actually interoperable. 594 Furthermore, the SIP change process forbids the usage of vendor 595 proprietary option tags in the Require header field. This means that 596 IETF standardization is required for the definition of service URN 597 that would be used with the mechanism proposed here. 599 10. Guidelines on Namespace Structure 601 The service URN [5] creates a basic namespace in which services can 602 be registered. When a new service is added, care should be taken to 603 make sure it is as general purpose as possible while still preserving 604 interoperability. When variations are possible, but for which 605 interoperability exists, these SHOULD be registered using 606 subservices. 608 This specification requests IANA to create the "vendor" top-level 609 service for vendor specific services. Each sub service MUST be 610 constructed by taking the domain name of the vendor (example.com for 611 example), and following that by a vendor-defined subservice that 612 identifies their service. For example, if vendor example.org wants 613 to create a service called foo, its service URN would be 614 "urn:service:vendor.example.org.foo". Note that these subservices 615 are not IANA registered, and that vendor-defined service URN are not 616 IANA registered SIP option tags. 618 11. Security Considerations 620 This specification makes use of option tags and URI to facilitate 621 routing of a request to the appropriate service instance. An 622 attacker in the network could modify these fields to cause the 623 request to be routed to the wrong service instance, which would 624 worsen user experience and possibly cause an interoperability 625 failure. Such an attack would require a man-in-the-middle to modify 626 SIP requests. An attacker capable of such modifications can launch 627 far more disruptive attacks by manipulating other fields, such as 628 Contact or the SDP. Consequently, such attacks do not seem likely. 630 12. IANA Considerations 632 This specification registers a new service URN label per the 633 guidelines in Section 4 of [5]. This represents vendor-proprietary 634 services. Allocation of subservices is done using hierarchical 635 allocation [13] and requires no IANA action. 637 Here is the information to be added to the table of service URN: 639 Service: vendor 641 Specification: RFC XXXX [[NOTE TO RFC-EDITOR: Please replace XXXX 642 with the RFC number of this specification.]] 644 Brief Description: Vendor proprietary service tree 646 13. Example 648 Consider our example from Section 3. A user, joe@example.com, starts 649 their chess application and wishes to play with bob@example.com. 650 Joe's INVITE would look like: 652 INVITE sip:bob@example.com SIP/2.0 653 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 654 From: Joe ;tag=n88ah 655 To: Bob 656 Call-ID: 1j9FpLxk3uxtma7@host.example.com 657 CSeq: 1 INVITE 658 Supported: gruu 659 Require: urn!service!chess 660 661 Contact: 662 664 ;service=chess 665 666 Content-Length: -- 667 Content-Type: application/sdp 669 [SDP Not shown] 671 Note that the request contains a Require header field with the 672 service URN. The Contact header field contains a GRUU, and Joe's UA 673 has added a parameter, "service=chess" to this URI. This parameter 674 is used only by Joe's UA for dispatching the request to the chess 675 application when a request is sent to that URI. 677 In another example, a Joe receives a presence document indicating 678 that the chess service is supported for Bob: 680 681 688 689 690 open 691 692 mac:8asd7d7d70 693 694 695 696 urn:service:chess 697 698 699 700 sip:bob@example.com 701 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> 702 ;service=chess 703 704 705 706 707 708 709 710 idle 711 mac:8asd7d7d70 712 713 715 Joe's UA notices that the chess service is available by the service 716 URN, and it renders an icon representing that service. When Joe 717 selects it, the chess application launches and generates an INVITE. 718 Note that the chess application itself will include a Require header 719 field, since chess has to be supported on the far end to proceed with 720 the call: 722 723 INVITE sip:bob@example.com 724 ;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> 725 ;service=chess SIP/2.0 726 727 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bK99a 728 From: Joe ;tag=n88ah 729 To: Bob 730 Call-ID: 1j9FpLxk3uxtma7@host.example.com 731 CSeq: 1 INVITE 732 Supported: gruu 733 Require: urn!service!chess 734 735 Contact: 736 738 ;service=chess 739 740 Content-Length: -- 741 Content-Type: application/sdp 743 [SDP Not shown] 745 14. Acknowledgements 747 This document is based on discussions with Paul Kyzivat and Andrew 748 Allen, who contributed significantly to the ideas here. 750 15. References 752 15.1. Normative References 754 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 755 Levels", BCP 14, RFC 2119, March 1997. 757 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 758 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 759 Session Initiation Protocol", RFC 3261, June 2002. 761 [3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 762 Preferences for the Session Initiation Protocol (SIP)", 763 RFC 3841, August 2004. 765 [4] Rosenberg, J., "Obtaining and Using Globally Routable User 766 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 767 (SIP)", draft-ietf-sip-gruu-11 (work in progress), 768 October 2006. 770 [5] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", 771 draft-ietf-ecrit-service-urn-05 (work in progress), 772 August 2006. 774 [6] Rosenberg, J., "Applying Loose Routing to Session Initiation 775 Protocol (SIP) User Agents (UA)", 776 draft-rosenberg-sip-ua-loose-route-00 (work in progress), 777 October 2006. 779 [7] Niemi, A., "Session Initiation Protocol (SIP) Extension for 780 Event State Publication", RFC 3903, October 2004. 782 [8] Rosenberg, J., "A Presence Event Package for the Session 783 Initiation Protocol (SIP)", RFC 3856, August 2004. 785 15.2. Informational References 787 [9] Rosenberg, J., "A Framework for Application Interaction in the 788 Session Initiation Protocol (SIP)", 789 draft-ietf-sipping-app-interaction-framework-05 (work in 790 progress), July 2005. 792 [10] Petrie, D. and S. Channabasappa, "A Framework for Session 793 Initiation Protocol User Agent Profile Delivery", 794 draft-ietf-sipping-config-framework-10 (work in progress), 795 January 2007. 797 [11] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 798 draft-ietf-ecrit-lost-04 (work in progress), February 2007. 800 [12] Rosenberg, J., "A Framework for Conferencing with the Session 801 Initiation Protocol (SIP)", RFC 4353, February 2006. 803 [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 804 Considerations Section in RFCs", BCP 26, RFC 2434, 805 October 1998. 807 [14] Rosenberg, J., "A Data Model for Presence", RFC 4479, 808 July 2006. 810 [15] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 811 Rosen, "Change Process for the Session Initiation Protocol 812 (SIP)", BCP 67, RFC 3427, December 2002. 814 [16] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 815 One: The Comprehensive DDDS", RFC 3401, October 2002. 817 Author's Address 819 Jonathan Rosenberg 820 Cisco 821 Edison, NJ 822 US 824 Email: jdrosen@cisco.com 825 URI: http://www.jdrosen.net 827 Full Copyright Statement 829 Copyright (C) The IETF Trust (2007). 831 This document is subject to the rights, licenses and restrictions 832 contained in BCP 78, and except as set forth therein, the authors 833 retain all their rights. 835 This document and the information contained herein are provided on an 836 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 837 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 838 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 839 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 840 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 841 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 843 Intellectual Property 845 The IETF takes no position regarding the validity or scope of any 846 Intellectual Property Rights or other rights that might be claimed to 847 pertain to the implementation or use of the technology described in 848 this document or the extent to which any license under such rights 849 might or might not be available; nor does it represent that it has 850 made any independent effort to identify any such rights. Information 851 on the procedures with respect to rights in RFC documents can be 852 found in BCP 78 and BCP 79. 854 Copies of IPR disclosures made to the IETF Secretariat and any 855 assurances of licenses to be made available, or the result of an 856 attempt made to obtain a general license or permission for the use of 857 such proprietary rights by implementers or users of this 858 specification can be obtained from the IETF on-line IPR repository at 859 http://www.ietf.org/ipr. 861 The IETF invites any interested party to bring to its attention any 862 copyrights, patents or patent applications, or other proprietary 863 rights that may cover technology that may be required to implement 864 this standard. Please address the information to the IETF at 865 ietf-ipr@ietf.org. 867 Acknowledgment 869 Funding for the RFC Editor function is provided by the IETF 870 Administrative Support Activity (IASA).