SIPPING WG M. Isomaki Internet-Draft Nokia Expires: April 20, 2006 October 17, 2005 Requirements and Possible Mechanisms for File Transfer Services Within the Context of SIP Based Communication draft-isomaki-sipping-file-transfer-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes use cases and defines requirements for how different types of file transfer services could be integrated into the general Session Initiation Protocol (SIP) based communication framework. It also explores some of the possible solutions to meet those requirements, either based on existing protocol mechanisms or defining minor extensions to them. The purpose of the document is to start the discussion on whether some new standardization work is needed in this area. Isomaki Expires April 20, 2006 [Page 1] Internet-Draft SIP File Transfer October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases and requirements for file transfer services . . . . 3 3.1. Common requirements . . . . . . . . . . . . . . . . . . . 4 3.2. Page mode file transfer from one user to another . . . . . 5 3.3. Page mode file transfer from one to many users . . . . . . 5 3.4. File transfer in the context of a media session between two users . . . . . . . . . . . . . . . . . . . . 5 3.5. File transfer in the context of a multiparty conference . 6 4. Survey of potential mechanisms . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Isomaki Expires April 20, 2006 [Page 2] Internet-Draft SIP File Transfer October 2005 1. Introduction Session Initiation Protocol (SIP) [2] provides generic functions for setting up multimedia sessions between users. It has also been extended in the areas of conferencing, presence and instant messaging services. This makes SIP, together with some accompanying protocols such as Message Session Relay Protocol (MSRP) [3] and HypeText Transfer Protocol (HTTP) an excellent toolkit for buiding user-to- user communication applications with a rich set of features. In many cases applications that do e.g. multimedia sessions and instant messaging, also have a requirement for different kind of file transfer services. The information contained in the files can be of any nature, but in typical situations users transfer files containing e.g. images, video clips or music. These use cases are quite diverse including both one-to-one and one-to-many situations as well as both "instant" and "store-and-retrieve" models. The common denominator is that in all these cases it is desirable to use SIP identities to represent the source and the destination(s) of the transfer. Many of the needed mechanisms for file transfer services readily exist in SIP and the related protocols. For instance page mode (SIP MESSAGE) and session mode (MSRP) instant messaging developed in SIMPLE WG, together with e.g. SIP content indirection and "traditional" file transfer protocols such as FTP and HTTP, already satisfies most of the needs. However, there are still missing pieces here and there to build a really interoperable services. This document desribes the use cases and technical requirements for file transfer services in the context of SIP based applications. These are covered in Section 3. Section 4 explores the solutions space based on existing mechanisms and in some cases minor extensions to them are proposed. The purpose of the document is to initiate discussion on the requirements themselves and whether new Informational or Standards Track documents should be produced to address them. 2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Use cases and requirements for file transfer services Isomaki Expires April 20, 2006 [Page 3] Internet-Draft SIP File Transfer October 2005 This section presents use cases for file transfer service and the technical requirements that stem from those cases. 3.1. Common requirements These are common requirements for all use cases. REQ-COMMON-1: The sender of the file MUST be able to use the SIP identity of the recipient(s) as the starting point. If some other protocols than SIP are used for the actual transfer, there MUST be an automatic process to map the SIP identity to the possible other identities used. REQ-COMMON-2: The maximum size of the transfered file MUST NOT be limited by default by any protocol involved. However, the recipients and the possible intermediaries MUST be able to advertise such limitations to the sender and enforce them. REQ-COMMON-3: The recipient MUST be able to distinguish "file transfer" from "file attached to IM", allowing the recipient to treat the cases differently. (Note: Any particular user interface metaphor is not intended to be mandated here, the requirement is only that the difference on the protocol level should be explicit. This requirement comes from practical usability experience.) REQ-COMMON-4: It MUST be possible to protect the integrity and confidentiality of the file contents between the sender and the recipients. The recipients MUST be able to verify the identity of the sender, and the sender must be able to make sure that only the intended recipients are able to receive the file. REQ-COMMON-5: It MUST be possible for both the sender and the recipient(s) to gracefully discontinue the file transfer. Gracefully means that it MUST be possible to distinguish that the discontinuation was done on purpose. REQ-COMMON-6: It MUST be possible for the sender to pass some meta information on the file before the actual transfer. This MUST include at least content type and size, and a short (human readable) description. In cases where the file is not transfered immediately, but is available for later retrieval, the sender MUST be able to indicate the availability period for the file. (OPEN ISSUE: Should there be requirement that in case the file is sent to multiple recipients, it MUST be possible to guarantee that they all receive it in synchron, if the sender wants this? This kind of feature would be important in some cases, but would also add complexity.) Isomaki Expires April 20, 2006 [Page 4] Internet-Draft SIP File Transfer October 2005 3.2. Page mode file transfer from one user to another The term "page mode" is taken from SIMPLE WG instant messaging work, where IM interactions have been separated into two different modes: page mode and session mode. In this case a user wants to submit a file to another user ad hoc, outside the context of any other communication or media session between the users. The sender knows the recipient (possibly only) by her SIP identity. The transfer is done either so that the recipient needs to accept the file immediately (otherwise the transfer is not done), or so that the recipient is initially just notified and she can retrieve the file when suitable (the receiving user interface can of course hide this decision). REQ-PAGEONE-1: It MUST be possible for the sender to indicate whether the recipient need to start receiving the file immediately, or whether the recipient can retrieve the file at a later point. REQ-PAGEONE-2: If immidiate tranfer is used, the transfer MUST be possible directly between the sender and the recipient, without the need for any intermediate storage element. REQ-PAGEONE-3: If deferred tranfer is used, It MUST be possible for the sender to store the file in such a way that the recipient can retrieve it at a later point, without further involvement from the sender. 3.3. Page mode file transfer from one to many users In this case a user wants to submit a file to a group of other users ad hoc, outside the context of any other communication or media session between the users. The sender may know each of the recipients by their SIP identities, or the sender may only know the SIP identity representing the whole group. Each recipient can retrieve the file at a suitable time. REQ-PAGEMULTI-1: The solution MUST allow the sender to need to send the file contents once, even if there are multiple recipients. (Without this requirement the case would reduce to just multiplication of the one-to-one case.) Requirements REQ-PAGEONE-1, REQ-PAGEONE-2 and REQ-PAGEONE-3 apply also to this case. 3.4. File transfer in the context of a media session between two users In this case two users are having a SIP based media session (perhaps Isomaki Expires April 20, 2006 [Page 5] Internet-Draft SIP File Transfer October 2005 audio, video and/or MSRP), and during that session one of the users wants to submit a file to another. This is signaled within the context of the media session. The acceptance of the recipient is explicitly requested and she is able to distinguish the file transfer from normal IM, which means that the case is different from just simply attaching the file to an IM message sent within the session. There are two variants in this case depending on whether the actual file transfer happens within the context of the media session, or whether the recipient can retrieve the file even after the media session has been concluded. REQ-SESSION-1: It MUST be possible to use the context of the ongoing media session and SIP dialog for the file transfer, without the sender needing to have any further reference to the recipient. The sender MUST be able to identify (or pinpoint) the receiving User Agent to be the exactly same as the one who is involved in the session. REQ-SESSION-2: It MUST be possible for the sender to send the request for a file transfer. It MUST be possible for the recipient to accept or decline it. The actual transfer MUST take place only after acceptance by the recipient. REQ-SESSION-3: It MUST be possible to conduct the file transfer immediately during (or within) the media session if the sender and the recipient want this. (OPEN ISSUE: what to say about unfinished file transfers when the SIP dialog is terminated? Are those terminated as well, or should it be possible or desirable to finish them as long as media connectivity prevail?) REQ-SESSION-4: If inside-the-session file transfer is used, that MUST be possible directly between the sender and the recipient, without the need for any intermediate storage element. REQ-SESSION-5: It MUST be possible to do only the required "signaling" within the context of the media session, and allow the recipient to retrieve the file at a later point outside the context of the session, even after the session has been concluded. It MUST be possible for the sender to indicate whether the file is available only during the session or also after it has concluded. 3.5. File transfer in the context of a multiparty conference In this case a user is participating a SIP based conference with multiple other participants, and during the conference the user wants to submit a file to all or one of the other participants. This is signaled within the context of the conference. The acceptance of the Isomaki Expires April 20, 2006 [Page 6] Internet-Draft SIP File Transfer October 2005 recipient is explicitly requested and she is able to distinguish the file transfer from normal IM, which means that the case is different from just attaching the file to an IM message sent within the conference. There are two variants in this case depending on whether the actual file transfer happens within the context of the conference, or whether the recipient can retrieve the file even after the conference has been concluded or she has departed from the conference. REQ-CONFERENCE-1: It MUST be possible to use the context of the ongoing conference for the file transfer. The sender MUST be able to identify (or pinpoint) the receiving User Agents to be the exactly same ones as those which are participating in the conference. The sender does not need to have any other reference to the recipient beyond the context of the conference. This means that it MUST be possible to use e.g. the identities specific to the context of the conference, not needing to know the "real" globally routable SIP identities of the participants. REQ-CONFERENCE-2: It MUST be possible for the sender to select all participants or any subset of the participants as the targers or recipients. The participants not selected MUST not be able to detect this. REQ-CONFERENCE-3: It MUST be possible for the sender to send the request for a file transfer. It MUST be possible for each recipient to accept or decline it independently. The actual transfer MUST take place only after acceptance by the recipients and only with those recipients who have accepted. (OPEN ISSUE: This requirement may lead to a lot of complexity in the actual realization. Should it be dropped?) REQ-CONFERENCE-4: It MUST be possible to conduct the file transfer immediately during (or within) the conference if the sender and the recipients want this. (OPEN ISSUE: what to say about unfinished file transfers when the SIP dialogs of either sender or the recipients are terminated? Are those terminated as well, or should it be possible or desirable to finish them as long as media connectivity prevail?) REQ-CONFERENCE-5: If inside-the-session file transfer is used, that MUST be possible using the normal means within the conference, not requiring e.g. a separate intermediate element. REQ-CONFERENCE-6: If the sender and the recipients want, it MUST be possible to do only the required "signaling" within the context of the conference, and allow the recipient to retrieve the file at a later point outside the context of the conference, even after the Isomaki Expires April 20, 2006 [Page 7] Internet-Draft SIP File Transfer October 2005 sender or the recipient have left the conference or the whole conference (instance) has been terminated. It MUST be possible for the sender to indicate the scope when the file is available with respect to the conference (for instance that the file is available only until the conference ends). For conference cases the management of situations where participants have vastly different transfer capacity available for them needs to be considered. For instance some participants might be accessing the Internet via extremely high speed access networks, while others are using low bandwidth wireless technologies. (OPEN ISSUE: Are there any exact requirements related to this?) 4. Survey of potential mechanisms This Section explores the possible mechanisms to meet the requirements listed in Section 3. The intention is to reuse as much of the readily available protocols as possible, and leave the new development to a minimum. "Page mode" file transfer clearly resembles page mode instant messaging. The latter is based on SIP MESSAGE [3]. Due to congestion control reasons related to the use of UDP as a transport between some SIP elements, SIP MESSAGE however has the maximum size of 1300 Bytes. (Unless the User Agent Client has by some means "postitive knowledge that the message will not traverse congestion- unsafe link at any hop". As of today, such means do not exist generally.) SIP content indirection [4] defines a mechanism for how the size limitation could be lifted from SIP MESSAGE. Combinging the use of HTTP/TLS for uploading and retrieving the files and SIP content indirection for distributing the URI seems like a viable solution for the page mode file transfer. For the multi-recipient case it is possible to use MESSAGE URI-list [6], by including the recipients in the URI-list. SIP MESSAGE with content indirection would work also to some extent for the session or conferencing related casees. However, in those cases the Message Session Relay Protocol (MSRP) might be better suited. MSRP does not have similar limitations as SIP MESSAGE. On the other hand it may still be useful to define similar content indirection framework for MSRP as exists for SIP, and use that instead of inline content within MSRP directly. Currently MSRP has not been defined for conferencing, so in order to address the conferencing case with MSRP that work has to be concluded first. Isomaki Expires April 20, 2006 [Page 8] Internet-Draft SIP File Transfer October 2005 The various aspecsts related to the sender requesting the file transfer and the recipient responding to it either positively or negatively still need more attention, but in general the combination of SIP MESSAGE, MSRP, content indirection and HTTP seems to be the suitable toolkit for the job. 5. Security Considerations Shared files contain often sensitive information, so it is required that the confidentiality and integrity of the information can be protected. Also, it is important for the recipients to be able to authenticate the sender and for the sender to make sure that the recipients are who they are meant to be. These requirements are addressed in REQ-COMMON-4 in Section 3.1. 6. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [4] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", draft-ietf-sip-content-indirect-mech-05 (work in progress), October 2004. [5] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-12 (work in progress), October 2005. [6] Garcia-Martin, M. and G. Camarillo, "Multiple-recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", draft-ietf-sipping-uri-list-message-03 (work in progress), April 2005. Isomaki Expires April 20, 2006 [Page 9] Internet-Draft SIP File Transfer October 2005 Author's Address Markus Isomaki Nokia Keilalahdentie 2-4 02150 Espoo Finland Phone: +358 50 522 5984 Email: markus.isomaki@nokia.com Isomaki Expires April 20, 2006 [Page 10] Internet-Draft SIP File Transfer October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Isomaki Expires April 20, 2006 [Page 11]