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