LEMONADE E. Burger Internet-Draft Cantata Technology, Inc. Expires: January 19, 2007 July 18, 2006 Lemonade Protocol for Streaming Media With Controls draft-burger-lemonade-streamctrls-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 January 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a method for providing streaming multimedia servives in the lemonade architecture. The method provides for third-party streaming, as well as object playback control. It leverages SIP for providing stream negotiation and media control. Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", Burger Expires January 19, 2007 [Page 1] Internet-Draft STREAMING July 2006 "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. 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. All examples use the host name "me.example.com" for the client, "ms.example.net" for the media server, and "imap.example.net" for the IMAP server. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Email Client . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Media Server Behavior . . . . . . . . . . . . . . . . . . . 5 2.3. IMAP Server Behavior . . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Burger Expires January 19, 2007 [Page 2] Internet-Draft STREAMING July 2006 1. Introduction The lemonade architecture [7] proposes to enable forward-without- download by creating a mechanism for a submit server to securely fetch an IMAP [8] body part for later submission. The LEMONADE Profile [9] describes this mechanism in detail. In particular, the mechanism uses the URLAUTH [2] token to give access to the body part in question to the submit server. The submit server uses the URLFETCH command as described by RFC4467 to download the body part from the IMAP Server. The streaming media with controls approach is to use the same trust triangle established by URLAUTH, but have a media server fetch the content, perform appropriate content and protocol transformations, and stream the result to the client. The three components of interest for our purposes is a URLAUTH-aware client that supports SIP [3] and MSCML [4]; an IMAP server that supports URLAUTH, URLFETCH and the IMAP BINARY [5] extension; and a media server that supports SIP, MSCML, URLFETCH, and the IMAP BINARY extension. Shamelesly lifting a drawing from LEMONADE Streaming [10], we have the following diagram. +----------------+ | |< | Email Client | \ | me.example.com | \ | |\ \ +----------------+ \ \ | \ \ | \ \ (5) | (1), \ \ | (2) \ \ | (3),\ \ | (6) \ \ | \ \ v v \ +------------------+ +----------------+ | | (4) | | | IMAP Server |<------| Media Server | | imap.example.net | | ms.example.net | +------------------+ +----------------+ Shamelessly lifting Neil's text, as the call flow is nearly identical, we have the following protocol steps. 1. The Email Client determines that it wants to stream a particular message part (attachment). Burger Expires January 19, 2007 [Page 3] Internet-Draft STREAMING July 2006 2. The Email Client constructs an IMAP URL referencing the message part and requests the IMAP Server to generate a URLAUTH authorized IMAP URL. 3. The Email Client, takes the IMAP URL, constructs an appropriate MSCML request referencing the desired object, and uses the IVR service as described by RFC4240 [6] to establish a SIP sessoin with the Media Server. 4. The Media Server connects to the IMAP Server specified in the referenced URL, and uses the IMAP URLFETCH command to retrieve the message part that the Email Client requested. 5. The Media server streams the retrieved message part to the client as negotiated by SIP. 6. Either the Media server terminates the SIP session after playing the object or the Email Client terminates the session by issuing the SIP BYE method. The key difference betwenn LEMONADE Streaming [10] and this document is step (3) above. In LEMONADE Streaming, using raw RFC4240 means that the Email Client does not have controls such as pause, rewind, skip-ahead, speed-up, slow-down, or replay. In this document, we will describe how to implement such controls. The codec (data format) conversion, if required, is a matter for the Media Server and Email Client to negotiate, using SIP. The Media Server fetches the content in the format specified by the Email Client, which presumably is the format returned by the BODYSTRUCTURE. That is, it should be the format the IMAP Server has stored the body part. This means the IMAP Server does not have to do any media conversion. Moreover, the Media Server fetches the content using IMAP, which means the IMAP Server does not need to do streaming. 2. Protocol Behavior 2.1. Email Client In an IMAP session, the client sees a body part it would like to stream. For example, it may have seen the following result to the BODYSTRUCTURE IMAP command. We have formatted the BODYSTRUCTURE result to be more readable for the purposes of this exposition. Burger Expires January 19, 2007 [Page 4] Internet-Draft STREAMING July 2006 ( ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 4946 139) ("AUDIO" "BASIC" "" "Voice Message Object" "BASE64" 1774064 23343) "MIXED" ) Fetching the headers C: a122 UID FETCH 24359 BODY[1.2.MIME] S: * 26 FETCH (BODY[1.3.MIME] {127} S: Content-Transfer-Encoding: base64 S: Content-Type: audio/basic; S: UID 24359 FLAGS (\Seen)) S: a122 OK FETCH completed. Here the Email client sees there is an audio/basic body part that is a little bit less than 1.7 megabytes. The client decides it wants to stream that object. C: a123 GENURLAUTH "imap://joe@imap.example.com/INBOX/;uid=24359/; section=1.3;expire=2006-12-19T16:39:57-08:00; urlauth=submit+ms" INTERNAL S: * GENURLAUTH "imap://joe@imap.example.com/INBOX/;uid=24359/; section=1.3;expire=2006-12-20T18:31:\45-08:00; urlauth=submit_ms: internal:0a9823092c34092b84092d3840ff928402934c8023d948c2" S: a123 OK GENURLAUTH completed The Email client then forumlates the SIP INVITE to initiate the MSCML session. Note the content is in G.711 (audio/basic) format; the Email client wants the content in G.729. INVITE sip:ivr@ms.example.net this is where the MSCML would go IF and only IF my net connection didn't die so I could put in real MSCML in time!!! 2.2. Media Server Behavior Receive the INVITE. Execute the MSCML. Note that the imap: URL scheme works just fine. Note the availability of VCR controls. Burger Expires January 19, 2007 [Page 5] Internet-Draft STREAMING July 2006 2.3. IMAP Server Behavior The beauty of it all: nothing changes! 3. IANA Considerations 4. Security Considerations 5. References 5.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006. [3] 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. [4] Dyke, J., "Media Server Control Markup Language (MSCML) and Protocol", draft-vandyke-mscml-09 (work in progress), June 2006. [5] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003. [6] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005. 5.2. Informative References [7] Wong, J., "Goals for Internet Messaging to Support Diverse Service Environments", RFC 4416, February 2006. [8] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [9] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006. [10] Cook, N., "Streaming Multimedia Messaging Attachments", June 2006. Burger Expires January 19, 2007 [Page 6] Internet-Draft STREAMING July 2006 Appendix A. Acknowledgements Lifted lots of text from Neil. Burger Expires January 19, 2007 [Page 7] Internet-Draft STREAMING July 2006 Author's Address Eric Burger Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA Email: eburger@cantata.com Burger Expires January 19, 2007 [Page 8] Internet-Draft STREAMING July 2006 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 (2006). 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. Burger Expires January 19, 2007 [Page 9]