Streaming Internet Messaging Attachments
RFC 5616

 
Document Type RFC - Informational (August 2009; Errata)
Last updated 2013-03-02
Replaces draft-cook-lemonade-streaming
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5616 (Informational)
Telechat date
Responsible AD Alexey Melnikov
Send notices to lemonade-chairs@ietf.org, neil.cook@noware.co.uk
Network Working Group                                            N. Cook
Request for Comments: 5616                                     Cloudmark
Category: Informational                                      August 2009

                Streaming Internet Messaging Attachments

Abstract

   This document describes a method for streaming multimedia attachments
   received by a resource- and/or network-constrained device from an
   IMAP server.  It allows such clients, which often have limits in
   storage space and bandwidth, to play video and audio email content.

   The document describes a profile for making use of the URLAUTH-
   authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media
   Service (RFC 4240), and the Media Server Control Markup Language (RFC
   5022).

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Cook                         Informational                      [Page 1]
RFC 5616        Streaming Internet Messaging Attachments     August 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   3.  Mechanism  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Overview of Mechanism  . . . . . . . . . . . . . . . . . .  3
     3.2.  Media Server Discovery . . . . . . . . . . . . . . . . . .  5
     3.3.  Client Use of GENURLAUTH Command . . . . . . . . . . . . .  7
     3.4.  Client Determination of Media Server Capabilities  . . . .  9
     3.5.  Client Use of the Media Server Announcement Service  . . . 10
     3.6.  Media Negotiation and Transcoding  . . . . . . . . . . . . 11
     3.7.  Client Use of the Media Server MSCML IVR Service . . . . . 13
     3.8.  Media Server Use of IMAP Server  . . . . . . . . . . . . . 17
     3.9.  Protocol Diagrams  . . . . . . . . . . . . . . . . . . . . 18
       3.9.1.  Announcement Service Protocol Diagram  . . . . . . . . 18
       3.9.2.  IVR Service Protocol Diagram . . . . . . . . . . . . . 19
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   6.  Digital Rights Management (DRM) Issues . . . . . . . . . . . . 24
   7.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 24
   8.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 25
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     10.2. Informative References . . . . . . . . . . . . . . . . . . 28

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
   before displaying any of it 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
   [RTP].  Streaming can be initiated and controlled using protocols
   such as SIP [SIP] and particularly the media server profiles as
   specified in RFC 4240 [NETANN] or MSCML [MSCML].  Streaming the media
Show full document text