One document matched: draft-isomaki-sipping-file-transfer-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 16:57:43 |