Lemonade N. Cook Internet-Draft Cloudmark Updates: RFC 4240, RFC 4722 May 4, 2007 (if approved) Intended status: Informational Expires: November 5, 2007 Streaming Internet Messaging Attachments draft-ietf-lemonade-streaming-02 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 November 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Cook Expires November 5, 2007 [Page 1] Internet-Draft Streaming Messaging Attachments May 2007 Abstract This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 4722). The document also defines a new IMAP METADATA entry. Cook Expires November 5, 2007 [Page 2] Internet-Draft Streaming Messaging Attachments May 2007 Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [8]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Overview of Mechanism . . . . . . . . . . . . . . . . . . 5 2.2. Client use of GENURLAUTH Command . . . . . . . . . . . . . 7 2.3. Media Server Discovery using the METADATA Extension . . . 9 2.4. Client Determination of Media Server Capabilities . . . . 10 2.5. Client Use of the Media Server Announcement Service . . . 11 2.6. Media Negotiation and Transcoding . . . . . . . . . . . . 12 2.7. Client Use of the Media Server MSCML IVR Service . . . . . 14 2.8. Media Server Use of IMAP Server . . . . . . . . . . . . . 19 2.9. Protocol Diagrams . . . . . . . . . . . . . . . . . . . . 20 2.9.1. Announcement Service Protocol Diagram . . . . . . . . 21 2.9.2. IVR Service Protocol Diagram . . . . . . . . . . . . . 21 3. Security Considerations . . . . . . . . . . . . . . . . . . . 23 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 5. Digital Rights Management (DRM) Issues . . . . . . . . . . . . 25 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Cook Expires November 5, 2007 [Page 3] Internet-Draft Streaming Messaging Attachments May 2007 1. Introduction Email clients on resource and/or network constrained devices, such as mobile phones, may have difficulties in retrieving and/or storing large attachments received in a message. For example, on a poor network link, the latency required to download the entire attachment may not be acceptable to the user. Conversely, even on a high-speed network, the device may not have enough storage space to secure the attachment once retrieved. For certain media, such as audio and video, there is a solution: the media can be streamed to the device, using protocols such as RTP [7]. Streaming can be initiated and controlled using protocols such as SIP [5] and particularly the media server profiles as specified in RFC 4240 [1] or MSCML [13]. Streaming the media to the device addresses both the latency issue, since the client can start playing the media relatively quickly, and the storage issue, since the client does not need to store the media locally. A tradeoff is that the media cannot be viewed/played when the device is offline. Examples of the types of media that would benefit from the ability to stream such media to the device include: o Voice or Video mail messages received as an attachment o Audio clips such as ring tones received as an attachment o Video clips, such as movie trailers, received as an attachment The client may wish to present the user with the ability to use simple "VCR"-style controls such as pause, fast-forward and rewind. In consideration of this, the document presents two alternatives for streaming media - a simple mechanism which makes use of the announcement service of RFC 4240, and a more complex mechanism which allows VCR controls, based on MSCML (RFC 4722) [13]. The choice of which mechanism to use is up to the client. The choice may be based on limitations of the client or the configured media server. This document presents suggestions for determining which of these services are available. Cook Expires November 5, 2007 [Page 4] Internet-Draft Streaming Messaging Attachments May 2007 2. Mechanism 2.1. Overview of Mechanism The proposed mechanism for streaming media to messaging clients is a profile for making use of several existing mechanisms, namely: 1. IMAP URLAUTH Extension (RFC 4467) [2] - Providing the ability to generate an IMAP URL [4] that allows anonymous access from external systems to specific message parts; for example, an audio clip. 2. Media Server Announcement Service (RFC 4240) [1] - Providing the ability for a media server to stream media using a reference provided by the media server client in a URL. 3. Media Server Interactive Voice Response (IVR) Service (RFC 4722) [13] - Providing the ability to stream media as above, but with VCR-style controls. However, it should be noted that this document proposes an extension to the SIP Parameter Registry [9], in order to accommodate passing a content transfer encoding parameter to the Announcement Service. Additionally two new attributes to the MSCML