SIPPING J. Rosenberg Internet-Draft dynamicsoft Expires: August 13, 2003 February 12, 2003 URI Leasing in the Session Initiation Protocol (SIP) draft-rosenberg-sipping-lease-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 13, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. An example of such an application is call transfer, based on the REFER method. To date, a variety of techniques have been proposed for the contruction of such URI. All of them have fatal drawbacks. This document proposes that the problem is actually one of URI leasing - a feature whereby a UA can dynamically request the creation of an address-of-record (AOR) within a domain. Requirements for a URI leasing mechanism are outlined. Rosenberg Expires August 13, 2003 [Page 1] Internet-Draft URI Leasing February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Defining a GRUU . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 REFER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Conferencing . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Host IP or FQDN . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 User AOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 Caller Preferences . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Embedded Route Header Field . . . . . . . . . . . . . . . . . 9 5. Implications of GRUU . . . . . . . . . . . . . . . . . . . . . 11 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Example Mechanism . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 Informative References . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22 Rosenberg Expires August 13, 2003 [Page 2] Internet-Draft URI Leasing February 2003 1. Introduction Several applications of the Session Initiation Protocol (SIP) [1] require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a call to that specific UA instance. An example of such an application is call transfer, based on the REFER method [7]. Another application is the usage of endpoint-hosted conferences within the conferencing framework [2]. We call these URIs Globally Routable UA URIs (GRUU). To date, a variety of techniques have been proposed for the contruction of such URI. All of them have fatal drawbacks. Section 2 formally defines a GRUU by three specific properties. Section 3 describes the cases where a GRUU is needed. Section 4 describes the solutions proposed to date. Section 5 argues that the problem is one of leasing. Section 6 provides requirements for a leasing mechanism, and Section 7 discusses a potential solution. Rosenberg Expires August 13, 2003 [Page 3] Internet-Draft URI Leasing February 2003 2. Defining a GRUU A GRUU is a SIP URI which has a specific set of characteristics: Global: It can be used by any UAC connected to the Internet. In that regard, it is like an address-of-record (AOR) for a user. The address-of-record for a user, sip:joe@example.com, is meant to be used by anyone to call that user. The same is true for a GRUU. Temporally Scoped: It may be temporally scoped. In that regard, its not like an AOR for a user. The general assumption is that an AOR for a user is valid so long as the user resides within that domain (of course, policies can be imposed to limit its validity, but that is not the default case). However, a GRUU has a limited lifetime by default. It can never be valid for longer than the duration of the registration of the UA to which it is bound. For example, if my PC registers to the SIP network, a GRUU for my PC is only valid as long as my PC is registered. If the PC unregisters, the GRUU is invalid; calls to it would result in a 404. If the PC comes back, the GRUU may or may not be valid once more. Furthermore, it will frequently be the case that the GRUU has a lifetime shorter than the duration of the registration. Instance Routing: It routes to a specific UA instance, and never forks. In that regard, it is unlike an address-of-record. When a call is made to a normal AOR which represents a user, routing logic is applied in proxies to deliver the call to one or more UAs. That logic can result in a different routing decisio based on the time-of-day, or the identity of the caller. However, when a call is made to a GRUU, the routing logic is much more static. It has to cause the call to be delivered to a very specific UA instance. That UA instance has to be the same UA instance throughout the lifetime of the GRUU. These three properties are guaranteed by the creator of the GRUU. That means they will be exhibited with 100 percent certainty, within the bounds of an operational network. They are not probabilistic guarantees; they don't just work sometimes. They ALWAYS work as advertised. Such a guarantee is important for reliable service offerings using a GRUU. As the examples below show, many features rely on these GRUU properties. If they are not always provided, the services will not always work. We believe there is a need to provide reliable versions of these services, and therefore, there is a need for a mechanism to construct a GRUU so that it has these properties with complete certainty. It is very important to understand that it is the responsibility of the element which constructs the GRUU to do so in a fashion which Rosenberg Expires August 13, 2003 [Page 4] Internet-Draft URI Leasing February 2003 guarantees these properties. Rosenberg Expires August 13, 2003 [Page 5] Internet-Draft URI Leasing February 2003 3. Use Cases We have encountered at least three use cases for a GRUU. These are for REFER, for conferencing, and for presence. 3.1 REFER Consider a blind transfer application [5]. User A is talking to user B. A wants to transfer the call to user C. So, it sends a REFER to user C. That REFER looks like, in part: REFER sip:C@example.com SIP/2.0 From: sip:A@example.com;tag=99asd To: sip:C@example.com Refer-To: (URI that identifiers B's UA) The Refer-To header needs to contain a URI that can be used by C to place a call to B. However, this call needs to route to the specific UA which B is using to talk to A. If it didn't, the transfer service would not execute. This URI is provided to A by B. Because B doesn't know who A will transfer the call to, the URI has to be usable by anyone. Therefore, it is a GRUU. 3.2 Conferencing A similar need arises in conferencing [2]. In that framework, a conference is described by a URI which identifies the focus of the conference. The focus is a SIP UA at the center of a conference. Each conference participant has a dialog with the focus. One case described in the framework is where a user A has made a call to B. They then put B on hold, and call C. Now, A has two separate dialogs for two separate calls - one to B, and one to C. A would like to conference them. One model is that A morphs itself into a focus. It sends a re-INVITE on each existing dialog, and provides both B and C with an updated Contact URI that now holds the conference URI. It also has a caller preferences [3] parameter which indicates that this URI is a conference URI. A proceeds to mix the media streams from B and C. This is called an ad-hoc conference. At this point, normal conferencing features can be applied. That means that B can send another user, D, the conference URI, perhaps in an email. D can send an INVITE to that URI, and join the conference. For this to work, the conference URI used by A in its re-INVITE has to be usable by anyone, and it has to route to the specific UA instance of A that is acting as the focus. If it didn't, basic conferencing features would fail. Therefore, it is a GRUU. Rosenberg Expires August 13, 2003 [Page 6] Internet-Draft URI Leasing February 2003 3.3 Presence In a SIP-based presence [6] system, the presence agent (PA) generates notifications about the state of a user. This state is represented with the Presence Information Document Format (PIDF) [4]. In a PIDF document, a user is represented by a series of tuples, each of which identifies the devices that the user has and provides information about them. Each tuple also has a contact URI, which is a SIP URI representing that device. A watcher can make a call to that URI, with the expectation that the call is routed to the device whose presence is represented in the tuple. The URI in the presence document therefore has to route to the specific UA instance whose presence was reported. Furthermore, since the presence document could be used by anyone who subscribes to the user, the URI has to be usable by anyone. As a result, it is a GRUU. It is interesting to note that, in this case, the GRUU needs to be constructed by a presence agent. This may be a server in the network, or may be on an end-device, such as a PC. Rosenberg Expires August 13, 2003 [Page 7] Internet-Draft URI Leasing February 2003 4. Proposed Solutions Several solutions have been proposed for the construction of a GRUU. Some are documented in the transfer [5] specification. In this section, we review the four solutions proposed to date and show the drawbacks of each. 4.1 Host IP or FQDN The most obvious solution is to construct a URI of the form sip:host, where host is the FQDN of the host, or its IP address, where the UA instance is running. However, this solution has many problems: The UA may be running on a private network. Therefore, a URI constructed in this fashion will not be usable by anyone on the public Internet. Even if the UA is running on a public network, there may be firewalls preventing direct connection to a host on the inside. The domain in which the host resides may have policies that require all calls to it to pass through certain proxies. This may be needed for logging or features (for example, automatic recording of all calls). A direct call to the host would bypass those proxies and therefore violate this policy. A domain would typically deploy a firewall to enforce the policy. The URI continues to be valid even if the UA instance un-registers in its domain. That violates the second property of a GRUU. For these reasons, it is clear that a host FQDN or IP address will not work. 4.2 User AOR Another solution that has been proposed is to use the AOR of the user on whose behalf the device is registered (sip:B@example.com, for example). This also has many obvious problems: Call routing within the example.com network might deliver that INVITE to a completely separate UA each time a call is made. This violates the critical third characteristic of a GRUU. The element constructing the GRUU may not wish to reveal its AOR to the caller. As an example, consider the REFER case above. Lets say A called a customer service number. This was routed by a call center application to an operator, and the operator's cell phone was rung. The operator needs to provide the caller a GRUU Rosenberg Expires August 13, 2003 [Page 8] Internet-Draft URI Leasing February 2003 so that the caller can transfer users to it. However, the operator does not want the caller to know their identity. Since the GRUU equals the AOR of the user, it has an unbounded temporal scope. This violates the second GRUU property. Therefore, the user's AOR cannot be used as a GRUU. 4.3 Caller Preferences Another proposed solution is to use the SIP caller preferences [3] specification. If a user sip:A@example.com has a device running on the IP address 192.0.2.1, the GRUU would be constructed as sip:A@example.com?Accept-Contact=*%3Buri-domain=%x22192.0.2.1%x22. When a UAC sends an INVITE to this URI, it results in a request that includes the Accept-Contact header field: INVITE sip:A@example.com SIP/2.0 Accept-Contact: *;uri-domain="192.0.2.1" This URI will provide the temporal scoping property of a GRUU. If the UA instance should unregister, the caller preferences mechanism will result in the rejection of the request with a 480 (not a 404 though), no matter what the internal routing looks like. The URI is also globally usable because it is based on a user AOR. However, the UA instance routing property cannot be guaranteed. Within the example.com domain, this request would be routed to the correct UA instance if the routing policy were based solely on UA registrations, coupled with static routing policy before the proxy which uses the registrations. However, the routing policy at example.com may be more complex, such that the request is never forwarded to the UA instance at 192.0.2.1. The call center agent is a good example of this case. Therefore, although this mechanism will work in some cases, it is not a reliable way to guarantee the UA instance routing property. Because there are no guarantees, this mechanism cannot be used to create a GRUU. 4.4 Embedded Route Header Field Another solution that has been proposed is to include embedded route headers in a URI. Considering once more the case of a user sip:A@example.com with a UA running at 192.0.2.1, the URI would look like sip:A@example.com?Route=sip:192.0.2.1;lr. This solution is very similar to the caller preferences based Rosenberg Expires August 13, 2003 [Page 9] Internet-Draft URI Leasing February 2003 solution above. However, it has similar problems. It only works under the assumption that the domain policy allows a request to be routed directly to a UA instance once it has been processed by the first proxy in that domain. This may not be true in large enterprises that have created sub-domains, for example, and require the request to pass through a multiplicity of servers. This solution does not provide the temporal scoping property either. Even if the UA is unregistered (but still running), the request will be delivered to it. However, this mechanism does provide the global usability characteristic. Rosenberg Expires August 13, 2003 [Page 10] Internet-Draft URI Leasing February 2003 5. Implications of GRUU Although the characteristics of a GRUU are simple, they have important implications that impact the mechanism that can be used to obtain them. Because they need to always work, they must be allocated in a way which is always consistent with the routing rules and topology of the domain in which the GRUU resides. All of the mechanisms that have been proposed fail because they are attempts at constructing a GRUU by an entity which is not authoritative over the namespace. Only the owner of the namespace (identified by the domain portion of the GRUU) can create a GRUU and guarantee it has the desired properties. This means that the GRUU needs to be constructed in cooperation with the administrators of the domain. It cannot be "guessed", as most of the mechanisms above try to do. One must explicitly ask for a GRUU. Otherwise, there is no way to guarantee that a GRUU always works. Indeed, the problem with guessing is clear from a read of the call transfer spec. Since the transferor is creating the GRUU, and is doing so without acting in concert with the domain in which it resides, there is no guarantee it will work. Therefore, the transfer spec is forced to recommend a trial-and-error tactic, having the transferor cycle through several mechanisms, hoping one will work. It is possible none of them will work, and even if one does, it may substantially increase call setup to try several others first. Furthermore, a GRUU needs to be allocated from a domain to which the UA is registering, or capable of registering. When a UA successfully registers, it knows that calls to its AOR will reach it. That is the service guarantee that is provided by the domain. The implication is that the UA knows for certain that this domain is capable of providing a URI that can route to it. Since a GRUU also has to route to it, it knows that this domain is capable of providing a URI which has the routing properties of a GRUU. [[OPEN ISSUE: This is a weak argument. A succesful registration does not imply that the registration works. I am trying to find a way to say that you can't just get a GRUU from any domain. If I work for example.com, and they have lots of firewalls and policies set up, I can't try to allocate a GRUU from example.org.]] Therefore, we conclude that the problem of GRUU allocation is that of URI leasing. An entity that wishes to obtain a GRUU is asking their domain to allocate them a new address-of-record, which will be used by the entity to register its UA instance. Its a lease, and not a purchase, because the URI is temporary. It identifies a UA only. A GRUU is never placed on a business card or on a web page. They are Rosenberg Expires August 13, 2003 [Page 11] Internet-Draft URI Leasing February 2003 handed out through protocol mechanisms, and they always have a bounded lifetime. Indeed, an enforcement of that lifetime is part of the lease itself. Rosenberg Expires August 13, 2003 [Page 12] Internet-Draft URI Leasing February 2003 6. Requirements Given that the construction of a GRUU is a leasing operation, the implication is that there is a protocol between the entity that wants a GRUU (the acquirer), and the domain which provides it. In this section, we present requirements for such a protocol. REQ 1: It must be possible for an acquirer to obtain a URI from its domain, which is an address-of-record, for which the domain guarantees the GRUU properties. REQ 2: It must be possible for an acquirer to specify the desired duration of the lease. REQ 3: It must be possible for the domain to indicate a lower duration for the lease than requested by the client. . Since the domain is the one expending the effort here, it should have final say in how long the lease lasts. It is similar to registrations in that regard. REQ 4: It must be possible for an acquirer to refresh its lease, so that it can keep the same URI. This makes sure that the GRUU is valid for as long as the acquirer needs it to be. For example, for the duration of the conference in an endpoint hosted conference. REQ 5: When the lease expires, requests for that URI will fail with a 404. This provides the temporal validity characteristic which is core to a GRUU. REQ 6: It must be possible for the domain to specify the format of the URI. The domain is the one that needs to make sure that requests for that AOR are routed properly. So, we need to make sure that the domain has the flexibility to construct the GRUU in whichever way it likes. REQ 7: The mechanism must not require any provisioning overhead in the domain. For example, we don't want to mandate the domain administrator to provision identities for the phones used by its customers. Rosenberg Expires August 13, 2003 [Page 13] Internet-Draft URI Leasing February 2003 REQ 8: It should be possible for a domain to create a GRUU without requiring any additional network state to store it, or any registrations bound to it. This requirement may be met conditionally, such that it only applies for certain registration cases. . This requires some explanation. In SIP networks today, the administrator incurs overhead for storing and managing registration state. Now, if every single UA in the network leases an additional URI, and registers against it, the domain requires double the registration state that it did previously. We'd like to avoid that if possible. REQ 9: It must be possible for the acquirer to obtain a GRUU which does not reveal anything about the identity of the acquirer. This is needed for cases where the called party wishes to remain anonymous, and yet hand out a GRUU. REQ 10: It must be possible for features to be associated with a GRUU, just like a user AOR in the domain. This covers the case where an enterprise wants to have call screening turned on for all incoming calls, whether they are made to the user or their device. REQ 11: It must be possible for an acquirer to obtain an infinitely large range of URIs, from which the acquirer can create specific URIs at will, without protocol operations. This requirement is important for latency and scale reasons. Every time a UA makes a call, it will need to insert a GRUU into the Contact header field of its INVITE, and every time it answers a call, it places one into the 200 OK of that INVITE. It will probably want to use a different GRUU in each call, to help limit the validity of the GRUU to the duration of that call. It is unacceptable for there to be a protocol operation every time this happens. Therefore, the UA has to be able to obtain a block of URIs at one time, and then create URIs out of that block until the lease on the block expires (it can of course be refreshed). REQ 12: It must be possible for the domain to authenticate the identity of the acquirer. REQ 13: It must be possible for the acquirer to authenticate the identity of the domain. Rosenberg Expires August 13, 2003 [Page 14] Internet-Draft URI Leasing February 2003 REQ 14: It must be possible for the acquirer to verify the integrity of the message sent by the domain containing the GRUU which has been leased. REQ 15: It must be possible for a user to query for the GRUUs which it has leased, and learn when they expire, and what URI are registered to them. Rosenberg Expires August 13, 2003 [Page 15] Internet-Draft URI Leasing February 2003 7. Example Mechanism This section presents an example mechanism to illustrate how the requirements might be met. It is still incomplete, but is a useful tool for understanding. One approach is to define a new SIP method called LEASE. It is far from clear that the mechanism should be based on SIP. It has many of the same properties of REGISTER, which would argue for a SIP method (if REGISTER is, why not this). Then again, many argue that REGISTER should never have been a SIP method in the first place. For example purposes, SIP is used. The LEASE method operates much like REGISTER. The request URI identifies the domain (no user part) from which the lease is desired. The From field identifies the client who is asking for the lease. The To field, unlike REGISTER, identifies the domain, just like the request-URI does. The LEASE request contains an Expires header field, indicating the desired duration of the lease. The 200 OK response contains a Lease header field, which contains a URI template. The URI template is like a SIP URI, but provides a wildcard character, into which the UA is free to place any URI characters it wants. Any URI constructed by the client will be treated as an AOR by the domain. The LEASE request can also optionally take a Contact header field, which has to have a single value. When present, the server will simultaneously create the GRUU, and create a registration which maps it (in fact, which maps ALL URI constructed by the template) to that Contact header field. As a result, the LEASE method can also perform registrations. The 200 OK to LEASE will contain a Lease header field, whose values are all the GRUU which have been leased to that user. Each one has a contact parameter that indicates the contact registered to that GRUU, if any. These contacts are only those bound to the GRUU through the LEASE method. If a user performs a normal REGISTER against a GRUU, and there is a contact already bound to it through the LEASE, the REGISTER is rejected with a 409. When the client refreshes its lease, it sends a LEASE request and includes a Lease header field containing the URI template that is to be refreshed. If the client already has that GRUU leased, the server treats the request as a refresh. If not, it treats it as a request to lease that GRUU. If the server wishes to accept the request, it generates a 200 OK. Otherwise, it generates an TBD response code to indicate that that particular GRUU cannot be leased. Figure 3 Rosenberg Expires August 13, 2003 [Page 16] Internet-Draft URI Leasing February 2003 A Proxy B C |(1) LEASE | | | |------------->| | | |(2) 200 OK | | | |<-------------| | | |(3) REGISTER | | | |------------->| | | |(4) 200 OK | | | |<-------------| | | |(5) INVITE | | | |------------->| | | | |(6) INVITE | | | |------------->| | | |(7) 200 OK | | | |<-------------| | |(8) 200 OK | | | |<-------------| | | |(9) ACK | | | |---------------------------->| | | | |(10) REFER | | | |------------->| | | |(11) 202 | | | |<-------------| | |(12) INVITE | | | |<----------------------------| |(13) INVITE | | | |<-------------| | | |(14) 200 OK | | | |------------->| | | | |(15) 200 OK | | | |---------------------------->| |(16) ACK | | | |<-------------------------------------------| | | |(17) NOTIFY | | | |<-------------| | | |(18) 200 OK | | | |------------->| |(19) BYE | | | |<----------------------------| | |(20) 200 OK | | | |---------------------------->| | Figure 3 The LEASE request (message 1) would look like: Rosenberg Expires August 13, 2003 [Page 17] Internet-Draft URI Leasing February 2003 LEASE sip:example.com SIP/2.0 From: sip:A@example.com;tag=988asd To: sip:example.com Call-ID: asdhh77766as00098 CSeq: 1 LEASE Contact: sip:192.0.2.1 Via: SIP/2.0/UDP 192.0.2.1 Expires: 30000 and its response: SIP/2.0 200 OK From: sip:A@example.com;tag=988asd To: sip:example.com Lease: sip:*.dskkia99s88a77dll===00asd887jjja7s@example.com ;contact=sip:192.0.2.1 Call-ID: asdhh77766as00098 CSeq: 1 LEASE Via: SIP/2.0/UDP 192.0.2.1 Expires: 30000 In this case, the lease is for a template, with the * as the wildcard. When the client registers, it actually registers the GRUU, and not its IP address (message 3): REGISTER sip:example.com SIP/2.0 From: sip:A@example.com;tag=9877asd To: sip:A@example.com Call-ID: asdhh77766as00099 CSeq: 1 REGISTER Contact: sip:XYZ.dskkia99s88a77dll===00asd887jjja7s@example.com Via: SIP/2.0/UDP 192.0.2.1 Expires: 3600 The client instantiated the template with an XYZ. Next, the client sends an INVITE. It includes, in the Contact header field of its INVITE, another GRUU which it creates from the template: INVITE sip:B@example.com SIP/2.0 From: sip:A@example.com;tag=9877ase To: sip:B@example.com Call-ID: asdhh77766as0009a CSeq: 1 INVITE Contact: sip:ABC.dskkia99s88a77dll===00asd887jjja7s@example.com Via: SIP/2.0/UDP 192.0.2.1 After the call is setup, B wishes to transfer A to C. So, it chooses to send a REFER to C (message 10), which looks like: Rosenberg Expires August 13, 2003 [Page 18] Internet-Draft URI Leasing February 2003 REFER sip:C@example.com SIP/2.0 From: sip:B@example.com;tag=9877ase To: sip:C@example.com Call-ID: asdhh77766as0009b Event: refer CSeq: 1 REFER Refer-To: sip:ABC.dskkia99s88a77dll===00asd887jjja7s@example.com Via: SIP/2.0/UDP 192.0.2.1 Notice that the Refer-To URI is taken directly from the Contact URI of the INVITE. Now, when C calls this URI, it is routed to the example.com proxy, and from there, to sip:192.0.2.1. Rosenberg Expires August 13, 2003 [Page 19] Internet-Draft URI Leasing February 2003 8. Security Considerations Security requirements are discussed above where relevant. Rosenberg Expires August 13, 2003 [Page 20] Internet-Draft URI Leasing February 2003 Informative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-rosenberg-sipping-conferencing-framework-00 (work in progress), November 2002. [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities", draft-ietf-sip-callerprefs-07 (work in progress), November 2002. [4] Fujimoto, S. and H. Sugano, "Common Presence and Instant Messaging (CPIM)Presence Information Data Format", draft-ietf-impp-cpim-pidf-06 (work in progress), November 2002. [5] Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-00 (work in progress), October 2002. [6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-09 (work in progress), December 2002. [7] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-07 (work in progress), December 2002. Author's Address Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue East Hanover, NJ 07936 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg Expires August 13, 2003 [Page 21] Internet-Draft URI Leasing February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rosenberg Expires August 13, 2003 [Page 22] Internet-Draft URI Leasing February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires August 13, 2003 [Page 23]