Transport Working Group S. Donovan Internet-Draft dynamicsoft Expires: May 22, 2002 November 21, 2001 Requirements for Publication of SIP related service data draft-donovan-publish-requirements-01.txt 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 May 22, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document defines the requirements for a proposed extension to the Session Initiation Protocol [1]. This extension would provide a general-purpose mechanism for uploading service related data. For instance, there is currently the need to upload or publish CPL to SIP Proxies and presence documents to SIP Presence Servers. This document does NOT outline an extension to SIP to handle these requirements. The author is attempting to follow the guidelines that requirements should be defined and agreed to before work on the an extension begins. Donovan Expires May 22, 2002 [Page 1] Internet-Draft SIP Publication Requirements November 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Why SIP? . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Why not SIP? . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1 Publication Data Requirements . . . . . . . . . . . . . . . . 5 5.2 Authentication and Authorization Requirements . . . . . . . . 5 5.3 Data Handling Requirements . . . . . . . . . . . . . . . . . . 5 5.4 Privacy Requirements . . . . . . . . . . . . . . . . . . . . . 6 5.5 Error Cases . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Donovan Expires May 22, 2002 [Page 2] Internet-Draft SIP Publication Requirements November 2001 1. Introduction This document defines the requirements for a proposed extension to the Session Initiation Protocol [1]. This extension would provide for a general-purpose mechanism for uploading service related data. For instance, there is currently the need to upload or publish CPL to SIP Proxies and presence documents to SIP Presence Servers. Note that CPL is currently uploaded using the SIP REGISTER request. It is thought that the REGISTER request, which was designed specifically for publishing Contacts which are in turn used to control routing of SIP requests, is not sufficiently general purpose to handle the uploading of generic service related data. For instance, there is currently no clean mechanism for reporting on the failure to upload CPL while the registration of Contacts is successful. While this draft proposes that the solution to the requirements outlined in this document should be based on SIP, it is recognized that there is currently no consensus that SIP is the correct protocol to be used for the generic publishing of service related data. If there is consensus that something other than SIP should be used, then the requirements in this document still apply to whatever solution is selected. 2. Motivation There are various situations where SIP clients need the ability to supply service related information to SIP servers in order for the services supplied by the SIP servers to operate properly. The following are two well understood examples: o Call Processing Language - Clients load Call Processing Language (CPL) scripts to SIP Proxies. The SIP Proxies then use the CPL scripts to control the routing of subsequent SIP requests. o Presence Documents - Clients load Presence Documents to Presence Servers. The Presence Servers then use the presence documents when notifying watchers of the clients presence state. It is felt that there is the need for a general-purpose mechanism for uploading of SIP service information. Furthermore, it is felt that the SIP REGISTER request is NOT the appropriate mechanism for handing this loading of SIP service information. The semantics of the REGISTER request are tightly coupled with the handling of the contacts contained in the REGISTER request. There is not a clean way to define handling of other service data without also effecting the Donovan Expires May 22, 2002 [Page 3] Internet-Draft SIP Publication Requirements November 2001 handling of REGISTERed contacts. 3. Why SIP? It is valid to ask why the loading of service data should be defined using the SIP protocol. The primary reason for basing it on SIP is that both of the user's of the information, the SIP client that creates it and the SIP server that consumes it, already have SIP implementations running on them. In addition, it might not be easy to put another protocol engine on these devices, especially SIP phones. The other possible reason to base it on SIP is that there is not necessarily a clear mapping between the address of a SIP server that would handle the publication of a CPL script and the address of another protocol's server. As such, there will be additional configuration complexity in the client associated with the ability to send the message to a different server. It can also be argued that SIP already supports a publication mechanism in the REGISTER request. The only problem is that the REGISTER request is not a general-purpose publication mechanism. So all that is being proposed is a generalization of something that is already in SIP (although this draft does NOT propose deprecating the use of REGISTER for the original purpose of associating contacts with a SIP url). 4. Why not SIP? It is fairly easy to model the publication of SIP service information as an HTTP PUT operation. In fact, the draft "Guidelines for Authors of SIP Extensions" [2] explicitly says: "SIP is not a transfer protocol. It is not meant to send large amounts of data unrelated to SIPs operation. It is not meant as a replacement for HTTP..." However, the same draft also says that REGISTER is an exception to this rule, and this draft proposes a generalization of the REGISTER function. In addition, the data being published is clearly related to SIPs operation. This draft does NOT propose that this mechanism apply to any and all uploads of data. Donovan Expires May 22, 2002 [Page 4] Internet-Draft SIP Publication Requirements November 2001 5. Requirements This section contains the requirements for the proposed SIP extension. 5.1 Publication Data Requirements The extension MUST support the ability to carry arbitrary message bodies, here-after called publication data. The extension MUST support the ability to associate publication data contained in a message body with a service. For instance, presence and cpl are services. The extension MUST support the ability to identify the format/encoding of the publication data. 5.2 Authentication and Authorization Requirements The extension MUST support the ability to identify the user to which the publication data applies. The extension MUST support the ability to authenticate the source of the publication requests. The extension MUST support the ability to determine the authorization of the source of the publication request to publish data for the user effected by the publication data. The extension MUST support the ability for the user determined to be the source of the publication request to be different than the user determined to be the target of the publication request. Another way of saying this it that the third party registration concept currently supported for registrations must also be supported for publications. 5.3 Data Handling Requirements The extension MUST support the ability to treat the published data as hard state. CPL is an example of data that would be treated as hard state. As such, it should not have an expiration period applied to it and it is kept in place until it is replaced or explicitly removed. The extension MUST support the ability for the server to indicate Donovan Expires May 22, 2002 [Page 5] Internet-Draft SIP Publication Requirements November 2001 that a request to store published data as hard state will not be honored. The server might not want to be told to store something forever. It is envisioned that this could be achieved by including an expires timer in the response, much has would be done in the soft state case discussed in the next requirement. The extension MUST support the ability to treat the published data as soft state. As such, the extension MUST support the ability to associate an expiration time with a message body. There are times that a presence document could be considered to be soft state, with the explicit requirement that there is an explicit period of time that the presence document is valid. If this is the case then the presentity publishing the data would be required to refresh the publication in order to keep it in effect. The extension MUST support the ability to query or retrieve publication data associated with a service. The extension MUST support the ability to define a desired action to be taken on the published data. Example actions are replace, remove, append and merge. Each service that uses the publication capability must define the actions that apply to that service. The extension MUST allow for the list of actions to be extensible. Note: It is not clear that the action to be taken should be part of the extension or should be a part of the message body containing the publication data. Making it a part of the message body makes it a service/application specific definition, which might make for a cleaner separation from the publication extension and the service to which the publication is targeted. 5.4 Privacy Requirements The extension MUST support the ability to encrypt the publication data. The extension MUST support the ability for the response to unauthorized requests to hide the fact that the source user is not authorized to publish for the target user. It is anticipated that there will be cases where returning a response indicating that the source user is not authorized will supply information about either the server or the target user of the server that could enable attacks on one or the other. As such, it is Donovan Expires May 22, 2002 [Page 6] Internet-Draft SIP Publication Requirements November 2001 envisioned that a generic "accepted" response, that can be differentiated from "successful" and "unauthorized", would be useful in this case 5.5 Error Cases The extension MUST support the ability to reject the publication request when the contents of the publication data are malformed or erroneous. The extension MUST support the ability to reject the publication request because the source user is not authorized to access the particular service. This rejection should indicate the services that the server supports. The extension MUST support the ability to reject the publication request because the source is not allowed to publish data for the target user. The extension MUST support the ability to reject the publication request because the target user is not known to the server. The extension MUST support the ability to reject the publication because the type of the indicated service is not supported. This rejection should indicate the services that the server supports. The extension MUST support the ability to reject the publication because the type of the data is not supported. This rejection should indicate the services for which publication is allowed. The extension MUST support the ability to reject the publication because the operation (replace, remove, append and merge) is not permitted for the particular service. 6. Security Considerations The security considerations are addressed in the Authentication, Authorization and Privacy requirements. References [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "The Session Initiation Protocol", RFC 2543, March 1999. [2] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of SIP Extensions", RFC Guidelines, March 2001. Donovan Expires May 22, 2002 [Page 7] Internet-Draft SIP Publication Requirements November 2001 Author's Address Steven R. Donovan dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 US EMail: sdonovan@dynamicsoft.com Donovan Expires May 22, 2002 [Page 8] Internet-Draft SIP Publication Requirements November 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 assigns. 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 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. Donovan Expires May 22, 2002 [Page 9]