[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-cook-lemonade-streaming) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5616

Lemonade                                                         N. Cook
Internet-Draft                                                 Cloudmark
Intended status: Informational                          December 8, 2008
Expires: June 11, 2009


                Streaming Internet Messaging Attachments
                    draft-ietf-lemonade-streaming-08

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 June 11, 2009.


















Cook                      Expires June 11, 2009                 [Page 1]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


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 URLAUTH
   authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media
   Service (RFC 4240), and the Media Server Control Markup Language (RFC
   5022).


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in this Document  . . . . . . . . . . . . . .  4
   3.  Mechanism  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Overview of Mechanism  . . . . . . . . . . . . . . . . . .  5
     3.2.  Media Server Discovery . . . . . . . . . . . . . . . . . .  7
     3.3.  Client use of GENURLAUTH Command . . . . . . . . . . . . .  9
     3.4.  Client Determination of Media Server Capabilities  . . . . 10
     3.5.  Client Use of the Media Server Announcement Service  . . . 11
     3.6.  Media Negotiation and Transcoding  . . . . . . . . . . . . 12
     3.7.  Client Use of the Media Server MSCML IVR Service . . . . . 14
     3.8.  Media Server Use of IMAP Server  . . . . . . . . . . . . . 18
     3.9.  Protocol Diagrams  . . . . . . . . . . . . . . . . . . . . 19
       3.9.1.  Announcement Service Protocol Diagram  . . . . . . . . 20
       3.9.2.  IVR Service Protocol Diagram . . . . . . . . . . . . . 20
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   6.  Digital Rights Management (DRM) Issues . . . . . . . . . . . . 26
   7.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 27
   8.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 28
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
     10.2. Informative References . . . . . . . . . . . . . . . . . . 31
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33











Cook                      Expires June 11, 2009                 [Page 2]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


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
   [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
   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 5022) [MSCML].  The choice
   of which mechanism to use is up to the client, for example it may be
   based on limitations of the client or the configured media server.
   This document presents suggestions for determining which of these
   streaming services are available.











Cook                      Expires June 11, 2009                 [Page 3]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


2.  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 [KEYWORDS].

   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 some of the line breaks between those lines are
   for editorial clarity only and may not be part of the actual protocol
   exchange.








































Cook                      Expires June 11, 2009                 [Page 4]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


3.  Mechanism

3.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 URLAUTH [URLAUTH] - Providing the ability
       to generate an IMAP URL that allows access by external entities
       to specific message parts, e.g. an audio clip.

   2.  URLFETCH Binary Extension [URLFETCH_BINARY] - Providing the
       ability to specify BINARY and BODYPARTSTRUCTURE arguments to the
       URLFETCH command.

   3.  Media Server Announcement Service (RFC 4240) [NETANN] - Providing
       the ability for a media server to stream media using a reference
       provided by the media server client in a URL.

   4.  Media Server Interactive Voice Response (IVR) Service (RFC 5022)
       [MSCML] - Providing the ability to stream media as above, but
       with VCR-style controls.

   The approach is shown in the following figure:


   +--------------+
   |              |
   | Email Client |^
   |              | \
   +--------------+  \
       ^           ^  \
       |            \  \ (5)
       | (1),        \  \
       | (2)          \  \
       |           (3),\  \
       |           (6)  \  \
       |                 \  \
       v                  v  v
   +--------------+       +----------------+
   |              |  (4)  |                |
   | IMAP Server  |<----->|  Media Server  |
   |              |       |                |
   +--------------+       +----------------+


                                 Figure 1




Cook                      Expires June 11, 2009                 [Page 5]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   The proposed mechanism has the following steps:

   1.  Client determines from MIME headers of a particular message that
       a particular message part (attachment) should be streamed to the
       user.  Note that no assumptions are made about how/when/if the
       client contacts the user of the client about this decision.  User
       input MAY be required in order to initiate the proposed
       mechanism.

   2.  Client constructs an IMAP URL referencing the message part, and
       uses the GENURLAUTH [URLAUTH] command to generate a URLAUTH
       authorized IMAP URL.

   3.  Client connects to a SIP Media Server using the Announcement
       Service as specified in RFC 4240 [NETANN], or the IVR Service as
       specified in RFC 5022 [MSCML], and passes the URLAUTH authorized
       URL to the media server.

   4.  Media Server connects to the IMAP Server specified in the
       referenced URL, and uses the IMAP URLFETCH [URLAUTH] command to
       retrieve the message part.

   5.  Media server streams the retrieved message part to the client
       using RTP [RTP].

   6.  The media server or the client terminate the media streaming, or
       the streaming ends naturally.  The SIP session is terminated by
       either client or server.

   It should be noted that the proposed mechanism makes several
   assumptions about the mobile device, as well as available network
   services, namely:

   o  Mobile device is provisioned with, or obtains via some dynamic
      mechanism (see Section 3.2), the location of a media server which
      supports either RFC 4240 [NETANN] and/or RFC 5022 [MSCML].

   o  Media Server(s) used by the mobile device support the IMAP URL
      [IMAPURL] scheme for the announcement and/or IVR services

   o  IMAP Server used by the mobile device supports generating
      anonymous IMAP URLs using the URLAUTH mechanism as well as the
      IMAP URLFETCH BINARY [URLFETCH_BINARY] extension








Cook                      Expires June 11, 2009                 [Page 6]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


3.2.  Media Server Discovery

   This section discusses possibilities for the automatic discovery of
   suitable media servers to perform streaming operations, and provides
   for such a mechanism using the IMAP METADATA [METADATA] extension.

   There are two possibilities for clients with regard to determining
   the hostname and port number information of a suitable media server:

   1.  No discovery of media servers is required: clients are configured
       with suitable media server information in an out-of-band manner.

   2.  Discovery of media servers is required: clients use a discovery
       mechanism to determine a suitable media server that will be used
       for streaming multimedia message parts.

   There are several scenarios where media server discovery would be a
   requirement for streaming to be successful:

   o  Client is not configured with the address of any media servers.

   o  Client is configured with the address of one or more media
      servers, but the IMAP server is configured to only accept URLFETCH
      requests from specific media servers (for security or site policy
      reasons), and thus streaming would fail due to the media server
      not being able to retrieve the media from the IMAP server.

   There is also a scenario where media server discovery would improve
   the security of the streaming mechanism, by avoiding the use of
   completely anonymous URLs.  For example, the client could discover a
   media server address that was an authorised user of the IMAP server
   for streaming purposes, which would allow the client to generate a
   URL, which was secure in that it could *only* be accessed by an
   entity that is trusted by the IMAP Server to retrieve content.  The
   issue of trust in media servers is discussed more fully in Section 4

   This document describes using the IMAP METADATA [METADATA] extension,
   via the use of a server entry that provides the contact information
   for suitable media servers for use with the IMAP server.  Media
   Server discovery is optional: clients are free to use pre-configured
   information about media servers, or to fall back to pre-configured
   information if they encounter IMAP servers that do not support either
   the METADATA extension or the proposed entry, or that do not provide
   a value for the entry.

   A METADATA entry with the name of "/public/mediaServers" is used to
   store the locations of suitable media servers known to the IMAP
   server.  The entry is formatted according to the formalSyntax



Cook                      Expires June 11, 2009                 [Page 7]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   specified in Section 8.  This consists of a tuple of a URI and
   optional "stream" string, where the URI is surrounded by <> symbols,
   the URI and "stream" are separated using a colon ":", and tuples are
   separated using a ";".

   The "stream" string (c.f. the "stream" access identifier from
   [ACCESSID]) is used to identify media servers capable of connecting
   to the IMAP server as users authorized to retrieve URLs constructed
   using the "stream" access identifier.  It indicates that the client
   MUST create the content URI using the "stream" access identifier.
   See Section 3.3 for a description of how the client should make use
   of the access identifier when generating IMAP URLs.)

   Example values of the /public/mediaServers METADATA entry:

   "<sip:ivr@ms.example.net:5060>:stream;<sip:annc@
   ms1.example.net:5060>;<sips:ivr@ms2.example.net:5061>"

   "<sip:ivr@192.0.2.40:5060>;<sip:192.0.2.41:5060>;<sips:annc@
   192.0.2.42:5060>:stream"

   It should be noted that the URI specified in the ABNF is generic,
   i.e. not restricted to SIP URIs; however this document only specifies
   how to make use of SIP URIs.  Additionally, the "userinfo" (known as
   the "service indicator" in RFC 4240 and RFC 4722) component of the
   URI is optional; if specified it gives the client additional
   information about the media server capabilities.  For example, a
   userinfo component of "annc" indicates that the media server supports
   RFC 4240, and "ivr" indicates support for RFC 4722.  Section 3.4
   further describes how clients should behave if the "userinfo"
   component is not present.

   Clients SHOULD parse the value of the /public/mediaServers entry, and
   contact a media server using one of the returned URIs.  The servers
   are returned in order of preference as suggested by the server,
   however it is left to the client to decide if a different order is
   more appropriate when selecting the media server(s) to contact, as
   well as the selection of alternates under failure conditions.

   Administrators configuring the values of the /mediaServers entry, who
   do not know the capabilities of the media servers being configured,
   SHOULD NOT include a userinfo component as part of of the URI, in
   which case the client will determine which service to use as
   specified in Section 3.4.  Note that if a media server supports
   multiple services, a URI with the appropriate userinfo component
   SHOULD be configured for each service.





Cook                      Expires June 11, 2009                 [Page 8]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


3.3.  Client use of GENURLAUTH Command

   The decision to make use of streaming services for a message part
   will usually be predicated on the content type of the message part.
   Using the capabilities of the IMAP FETCH command, clients determine
   the MIME [MIME] Content-Type of particular message parts and based on
   local policies or heuristics, decide that streaming for that message
   part will be attempted.

   Once the client has determined that a particular message part
   requires streaming, the client generates an IMAP URL that refers to
   the message part according to the method described in RFC 5092
   [IMAPURL].  The client then begins the process of generating an
   URLAUTH URL, by appending ";EXPIRE=<datetime>" and
   ";URLAUTH=<access>" to the initial URL.

   The ";EXPIRE=<datetime>" parameter is optional, however it SHOULD be
   used, since the use of anonymous URLAUTH authorized URLs is a
   security risk (see Section 4, and doing so ensures that at some point
   in the future, permission to access that URL will cease.  IMAP server
   implementors may choose to reject anonymous URLs that are considered
   insecure (for example with an EXPIRE date too far in the future), as
   a matter of local security policy.  To prevent this causing
   interoperability problems, IMAP servers that implement this profile
   MUST NOT reject GENURLAUTH commands for anonymous URLs on the basis
   of the EXPIRE time, if that time is equal to, or less than 1 hour in
   the future.

   The <access> portion of the URLAUTH URL MUST be 'stream' (see
   [ACCESSID]) if an out of band mechanism or the media server discovery
   mechanism discussed in Section 3.2 specifies that the media server is
   an authorized user of the IMAP server for the purposes of retrieving
   content via URLFETCH.  Without specific prior knowledge of such a
   configuration (either through the discovery mechanism described in
   this document, or by an out of band mechanism), the client SHOULD use
   the 'stream' access identifier, which will cause streaming to fail if
   the media server is not an authorized user of the IMAP server for the
   purposes of streaming.

   However, if the client wishes to take the risk associated with
   generating a URL that can be used by any media server (see
   Section 4), it MAY use 'anonymous' as the <access> portion of the
   URLAUTH URL passed to the GENURLAUTH command.  For example, the
   client may have been preconfigured with the address of media servers
   in the local administrative domain, (thus implying a level of trust
   in those media servers), without knowing whether those media servers
   have a pre-existing trust relationship with the IMAP server to be
   used (which may well be in a different administrative domain).  See



Cook                      Expires June 11, 2009                 [Page 9]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   Section 4 for a full discussion of the security issues.

   The client uses the URL generated as a parameter to the GENAUTHURL
   command, using the INTERNAL authorization mechanism.  The URL
   returned by a successful response to this command will then be passed
   to the media server.  If no successful response to the GENURLAUTH
   command is received, then no further action will be possible with
   respect to streaming media to the client.

   Examples:

   C: a122 UID FETCH 24356 (BODYSTRUCTURE)
   S: * 26 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
   S: ("CHARSET" "US-ASCII") NIL
   S: NIL "7BIT" 1152 23)("VIDEO" "MPEG"
   NIL NIL "BASE64" 655350)) UID 24356)
   S: a122 OK FETCH completed.
   C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
   section=1.2;expire=2006-12-19T16:39:57-08:00;
   urlauth=anonymous" INTERNAL
   S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;
   section=1.2;expire=2006-12-19T16:39:57-08:00;
   urlauth=anonymous:
   internal:238234982398239898a9898998798b987s87920"
   S: a123 OK GENURLAUTH completed


   C: a122 UID FETCH 24359 (BODYSTRUCTURE)
   S: * 27 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN"
   S: ("CHARSET" "US-ASCII") NIL
   S: NIL "7BIT" 1152 23)("AUDIO" "G729"
   NIL NIL "BASE64" 87256)) UID 24359)
   S: a122 OK FETCH completed.
   C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
   section=1.3;expire=2006-12-19T16:39:57-08:00;
   urlauth=stream" INTERNAL
   S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;
   section=1.3;expire=2006-12-20T18:31:45-08:00;
   urlauth=stream:
   internal:098230923409284092384092840293480239482"
   S: a123 OK GENURLAUTH completed

3.4.  Client Determination of Media Server Capabilities

   Once an authorized IMAP URL has been generated, it is up to the
   client to pass that URL to a suitable media server that is capable of
   retrieving the URL via IMAP, and streaming the content to the client
   using the RTP [RTP] protocol.



Cook                      Expires June 11, 2009                [Page 10]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   This section specifies the behaviour of clients that have not
   determined, (either statically through configuration, or dynamically
   through a discovery process as discussed in Section 3.2), the
   capabilities of the media server with respect to the services (i.e.
   RFC 4240 or 5022) supported by that media server.  Clients that have
   determined those capabilities should use the mechanisms described in
   Section 3.5 or Section 3.7, as appropriate.

   If the client supports the MSCML IVR service, then it SHOULD attempt
   to contact the media server using the MSCML protocol by sending a SIP
   INVITE which has the service indicator "ivr".  Due to issues
   described in Section 4, the client SHOULD use a suitable end-to-end
   encryption method, such as S/MIME [SMIME], as described in the SIP
   Specification [SIP].

   Assuming the media server responds to the INVITE without error, the
   client can carry on using the MSCML IVR service as specified in
   Section 3.7.  If the media server responds with an error indicating
   that the "ivr" service is not supported, then if the client supports
   it, the client SHOULD attempt to contact the media server using the
   Announcement Service, as described in Section 3.5.

   The following example shows an example SIP INVITE using the "ivr"
   service indicator:

   C: INVITE sip:ivr@ms2.example.com SIP/2.0
   < SIP Header fields omitted for reasons of brevity >

3.5.  Client Use of the Media Server Announcement Service

   Assuming the client or media server does not support use of the MSCML
   protocol, the media server announcement service is used, as described
   in RFC 4240 [NETANN].  This service allows the client to send a SIP
   INVITE to a special username ('annc') at the media server (the
   "announcement" user), supplying the URL obtained as per Section 3.3.

   The SIP INVITE is constructed as shown in the examples below; note
   that as per RFC 4240, the play parameter is mandatory, and specifies
   the authorized IMAP URL to be played.

   Examples of valid SIP INVITE URIs sent to the media server
   announcement service:

   C: sip:annc@ms2.example.net;
   play=imap://joe@example.com/INBOX/%3Buid=24356/%3Bsection=1.2%3B
   expire=2006-12-19T16:39:57-08:00%3Burlauth=anonymous:
   internal:238234982398239898a9898998798b987s87920




Cook                      Expires June 11, 2009                [Page 11]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   C: sip:annc@ms1.example.net;
   play=imap://fred@example.com/INBOX/%3Buid=24359/%3Bsection=1.3%3B
   expire=2006-12-20T18:31:45-08:00%3Burlauth=stream:
   internal:098230923409284092384092840293480239482

   Notice that the ; characters that are used as parameters of the IMAP
   URI are escaped as %3B, as otherwise they would change the meaning of
   the enclosing SIP URI, by being regarded as SIP URI parameters
   instead of IMAP URL parameters.

   If the client receives a 200 (OK) response, the media server has
   successfully retrieved the content from the IMAP server and the
   negotiated RTP stream will shortly begin after the ACK.

   There are many possible response codes, however a response code of
   404 received from the media server indicates that the content could
   not be found or could not be retrieved for some reason.  For example,
   the media server may not support the use of IMAP URLs.  At this
   point, there are several options to the client, such as using
   alternate media servers, or giving up in attempting to stream the
   required message part.

3.6.  Media Negotiation and Transcoding

   This document uses standards and protocols from two traditionally
   separate application areas: Mobile Email (primarily IMAP) and
   Internet Telephony/Streaming (e.g.  SIP/RTP).  Since the document
   primarily addresses enhancing the capabilities of mobile email, it is
   felt worthwhile to give some examples of simple SIP/SDP exchanges,
   and discussing capabilities such as media negotiation (using SDP) and
   media transcoding.

   In the below example, the client contacts the media server using the
   SIP INVITE command to contact the Announcement service (see
   Section 3.5), advertising support for a range of audio and video
   codecs (using SDP [SDP]), and in response the media server advertises
   only a set of audio codecs.  This process is identical for the IVR
   service, except that the IVR service does not use the SIP Request-URI
   to indicate the content to be played; instead this is carried in a
   subsequent SIP INFO request.

   The client and server now know from the SDP advertised by both client
   and server that communication must be using the subset of audio
   codecs supported by both client and server (in the example SDP, it is
   clear that the server does not support any video codecs).  The media
   server may perform transcoding (i.e. converting between codecs) on
   the media received from the IMAP server in order to satisfy the
   codecs supported by the client: for example the media server may



Cook                      Expires June 11, 2009                [Page 12]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   downgrade the video retrieved from the IMAP server to the audio
   component only.

   For clients using the Announcement service, the media server MUST
   return an error to the INVITE if it cannot find a common codec
   between the client, server and media, and it cannot transcode to a
   suitable codec.  Similarly, for clients using the MSCML IVR service,
   the media server MUST return a suitable error response to the
   <playcollect> request.

   Example SIP INVITE and SDP Media Negotiation

   C: INVITE sip:annc@ms2.example.com;
   play=imap://joe@example.com/INBOX/%3Buid=24356/%3Bsection=1.2%3B
   expire=2006-12-19T16:39:57-08:00%3Burlauth=anonymous:
   internal:238234982398239898a9898998798b987s87920 SIP/2.0
   C: From: UserA <sip:UAA@example.com>
   C: To: NetAnn <sip:annc@ms2.example.com>
   C: Call-ID: 8204589102@example.com
   C: CSeq: 1 INVITE
   C: Contact: <sip:UAA@192.0.2.40>
   C: Content-Type: application/sdp
   C: Content-Length: 481
   C:
   C: v=0
   C: o=UserA 2890844526 2890844526 IN IP4 192.0.2.40
   C: s=Session SDP
   C: c=IN IP4 192.0.2.40
   C: t=3034423619 0
   C: m=audio 9224 RTP/AVP 0 8 3 98 101
   C: a=alt:1 1 : 01BB7F04 6CBC7A28 192.0.2.40 9224
   C: a=fmtp:101 0-15
   C: a=rtpmap:98 ilbc/8000
   C: a=rtpmap:101 telephone-event/8000
   C: a=recvonly
   C: m=video 9226 RTP/AVP 105 34 120
   C: a=alt:1 1 : 01BCADB3 95DFFD80 192.0.2.40 9226
   C: a=fmtp:105 profile=3;level=20
   C: a=fmtp:34 CIF=2 QCIF=2 MAXBR=5120
   C: a=rtpmap:105 h263-2000/90000
   C: a=rtpmap:120 h263/90000
   C: a=recvonly

   S: SIP/2.0 200 OK
   S: From: UserA <sip:UAA@example.com>
   S: To: NetAnn <sip:annc@ms2.example.com>
   S: Call-ID: 8204589102@example.com
   S: CSeq: 1 INVITE



Cook                      Expires June 11, 2009                [Page 13]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   S: Contact: <sip:netann@192.0.2.41>
   S: Content-Type: application/sdp
   S: Content-Length: 317
   S:
   S: v=0
   S: o=NetAnn 2890844527 2890844527 IN IP4 192.0.2.41
   S: s=Session SDP
   S: c=IN IP4 192.0.2.41
   S: t=3034423619 0
   S: m=audio 17684 RTP/AVP 0 8 3 18 98 101
   S: a=rtpmap:0 PCMU/8000
   S: a=rtpmap:8 PCMA/8000
   S: a=rtpmap:3 GSM/8000
   S: a=rtpmap:18 G729/8000
   S: a=fmtp:18 annexb=no
   S: a=rtpmap:98 iLBC/8000
   S: a=rtpmap:101 telephone-event/8000
   S: a=fmtp:101 0-16

   C: ACK sip:netann@192.0.2.41 SIP/2.0
   C: From: UserA <sip:UAA@example.com>
   C: To: NetAnn <sip:annc@ms2.example.com>
   C: Call-ID: 8204589102@example.com
   C: CSeq: 1 ACK
   C: Content-Length: 0

3.7.  Client Use of the Media Server MSCML IVR Service

   Once the client has determined that the media server supports the IVR
   service, it is up to the client to generate a suitable MSCML request
   to initiate streaming of the required media.

   When using the IVR service, the initial SIP invite is used only to
   establish that the media server supports the MSCML IVR service, and
   to negotiate suitable media codecs.  Once the initial SIP INVITE and
   response to that INVITE have been completed successfully, the client
   must generate a SIP INFO request with MSCML in the body of the
   request to initiate streaming.

   The <playcollect> request is used, as this allows the use of DTMF
   digits to control playback of the media, such as fast-forward or
   rewind.

   Since the playcollect request is used purely for its VCR
   capabilities, there is no need for the media server to perform DTMF
   collection, therefore the playcollect attributes "firstdigittimer",
   "interdigittimer" and "extradigittimer" SHOULD all be set to "0ms",
   which will have the effect of causing digit collection to cease



Cook                      Expires June 11, 2009                [Page 14]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   immediately the media has finished playing.

   The "ffkey" and "rwkey" attributes of <playcollect> are used to
   control fast forward and rewind behaviour, with the "skipinterval"
   attribute being used to control the 'speed' of these actions.

   The <prompt> tag is used to specify the media to be played, and
   SHOULD have a single <audio> tag that gives the URL of the media, as
   per the Section 3.3.  The audio-specific name of the tag is
   historical, as the tag can be used for video as well as audio
   content.  The "stoponerror" attribute SHOULD be set to "yes", as then
   meaningful error messages will be returned by the media server in the
   event of problems such as retrieving the media from the IMAP server.

   An example SIP INFO request using the <playcollect> request is shown
   at the end of this section.

   It should be noted that under normal (i.e. non-error) conditions, the
   response to the <playcollect> request is a SIP 200 (OK) response.
   The media server then streams the media, and only when the media has
   finished playing (naturally or due to a user request), does the media
   server send a <playcollect> response, which includes details of the
   media played, such as length, and any digits collected.

   The client may suspend playback of the media at any time by either
   sending the DTMF escape key (specified as an attribute to the
   <playcollect> request) or by sending a <stop> request to the media
   server in a SIP INFO request.  Upon receipt of the request, the media
   server will acknowledge it, and then cease streaming of the media,
   followed by a SIP INFO request containing the <playcollect> response.

   If the media server cannot play the media for any reason, for example
   if it cannot retrieve the media from the IMAP server, streaming will
   not take place, and the <playcollect> response will be sent, usually
   with meaningful values in the <error_info> element.

   The following gives an example dialog between a client and media
   server, including a rewind request, and termination of the playback
   by use of the escape key.  Some elements of the SIP dialog such as
   full SIP header fields and SDP are omitted for reasons of brevity.
   (The protocol diagram in Section 3.9.2 shows the high-level message
   flow between all the components, including the IMAP server.)

   C: INVITE sip:ivr@ms.example.com SIP/2.0
   C: From: UserA <sip:UAA@example.com>
   C: To: IVR <sip:ivr@ms.example.com>
   C: Call-ID: 3298420296@example.com
   C: CSeq: 1 INVITE



Cook                      Expires June 11, 2009                [Page 15]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   C: Contact: <sip:UAA@192.0.2.40>
   C: Content-Type: application/sdp
   C: Content-Length: XXX
   C:
   C: <SDP Here>

   S: SIP/2.0 200 OK
   S: From: UserA <sip:UAA@example.com>
   S: To: IVR <sip:ivr@ms.example.com>
   S: Call-ID: 3298420296@example.com
   S: CSeq: 1 INVITE
   S: Contact: <sip:ivr@192.0.2.41>
   S: Content-Type: application/sdp
   S: Content-Length: XXX
   S:
   S: <SDP Here>

   C: ACK sip:ivr@ms.example.com SIP/2.0
   C: From: UserA <sip:UAA@example.com>
   C: To: IVR <sip:ivr@ms2.example.com>
   C: Call-ID: 3298420296@example.com
   C: CSeq: 1 ACK
   C: Content-Length: 0

   C: INFO sip:ivr@192.0.2.41 SIP/2.0
   C: From: UserA <sip:UAA@example.com>
   C: To: IVR <sip:ivr@ms.example.com>
   C: Call-ID: 3298420296@example.com
   C: CSeq: 2 INFO
   C: Content-Type: application/mediaservercontrol+xml
   C: Content-Length: 423
   C:
   C: <?xml version="1.0"?>
   C: <MediaServerControl version="1.0">
   C: <request>
   C: <playcollect id="332985001"
   C: firstdigittimer="0ms" interdigittimer="0ms" extradigittimer="0ms"
   C: skipinterval="6s" ffkey="6" rwkey="4" escape="*">
   C: <prompt stoponerror="yes"
   C: locale="en_US" offset="0" gain="0" rate="0"
   C: delay="0" duration="infinite" repeat="0">
   C: <audio url="imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
   expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
   internal:238234982398239898a9898998798b987s87920">
   C: </prompt>
   C: </playcollect>
   C: </request>
   C: </MediaServerControl>



Cook                      Expires June 11, 2009                [Page 16]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   S: SIP/2.0 200 OK
   S: From: UserA <sip:UAA@example.com>
   S: To: IVR <sip:ivr@ms.example.com>
   S: Call-ID: 3298420296@example.com
   S: CSeq: 2 INFO
   S: Contact: <sip:ivr@192.0.2.41>
   S: Content-Length: 0

   S: <Media Server retrieves media from IMAP Server and streams to
   client>

   C: <Client streams 6 key>

   S: <Media Server fast forwards media by 6 seconds>

   C: <Client streams * key>

   S: <Media Server stops streaming>

   S: INFO sip:UAA@192.0.2.40 SIP/2.0
   S: From: IVR <sip:ivr@ms.example.com>
   S: To: UserA <sip:UAA@example.com>
   S: Call-ID: 3298420296@example.com
   S: CSeq: 5 INFO
   S: Contact: <sip:ivr@192.0.2.41>
   S: Content-Type: application/mediaservercontrol+xml
   S: Content-Length: XXX
   S:
   S: <?xml version="1.0"?>
   S: <MediaServerControl version="1.0">
   S: <response id="332985001" request="playcollect" code="200"
   S: reason="escapekey" playduration="34s"
   S: playoffset="34s" digits="" />
   S: </MediaServerControl>

   C: SIP/2.0 200 OK
   C: From: IVR <sip:ivr@ms.example.com>
   C: To: UserA <sip:UAA@example.com>
   C: Call-ID: 3298420296@example.com
   C: CSeq: 5 INFO
   C: Content-Length: 0

   C: BYE sip:ivr@192.0.2.41 SIP/2.0
   C: From: UserA <sip:UAA@example.com>
   C: To: IVR <sip:ivr@ms.example.com>
   C: Call-ID: 3298420296@example.com
   C: CSeq: 6 BYE
   C: Content-Length: 0



Cook                      Expires June 11, 2009                [Page 17]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   S: SIP/2.0 200 OK
   S: From: UserA <sip:UAA@example.com>
   S: To: IVR <sip:ivr@ms.example.com>
   S: Call-ID: 3298420296@example.com
   S: CSeq: 6 BYE
   S: Contact: <sip:ivr@192.0.2.41>
   S: Content-Length: 0

3.8.  Media Server Use of IMAP Server

   This section describes how the media server converts the IMAP URL
   received via the announcement or IVR service into suitable IMAP
   commands for retrieving the content.

   The media server first connects to the IMAP server specified in the
   URL.  Once connected, the media server SHOULD use TLS [TLS] to
   encrypt the communication path.

   If the media server is configured as an authorized user of the IMAP
   server, it SHOULD authenticate to the IMAP server using the
   credentials for that user.  This document does not go into the
   details of IMAP authentication, but the authentication SHOULD NOT use
   the LOGIN command over a non-encrypted communication path.

   If the media server is not configured as an authorized user of the
   IMAP server, then the behaviour specified in IMAP URL bis4 [IMAPURL]
   MUST be followed.  That is, if the server advertises AUTH=ANONYMOUS
   IMAP capability, the media server MUST use the AUTHENTICATE command
   with ANONYMOUS [ANONYMOUS] SASL mechanism.  If SASL ANONYMOUS is not
   available, the user name "anonymous" is used with the "LOGIN" command
   and the password is supplied as the Internet e-mail address of the
   administrative contact for the media server.

   Once authenticated, the media server issues the URLFETCH command,
   using the URL supplied in the 'play' parameter of the SIP INVITE (or
   audio tag of the MSCML).  If the IMAP server does not advertise
   URLAUTH=BINARY in its post-authentication capability string, then the
   media server returns a suitable error code to the client.

   The additional parameters to the URLFETCH command specified in
   (URLFETCH BINARY) [URLFETCH_BINARY] are used by the media server to
   tell the IMAP server to remove any transfer encoding and return the
   content type of the media (as content type information is not
   contained in the IMAP URL).

   A successful URLFETCH command will return the message part containing
   the media to be streamed.  If the URLFETCH was unsuccessful, then the
   media server MUST return an appropriate error response to the client.



Cook                      Expires June 11, 2009                [Page 18]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   Assuming the content is retrieved successfully, the media server
   returns a 200 (OK) response code to the client.  After an ACK is
   received, an RTP stream is delivered to the client using the
   parameters negotiated in the SDP.

   If appropriate, the media server MAY choose to implement connection
   caching, in which case connection and disconnection from the IMAP
   server are handled according to whatever algorithm the media server
   chooses.  For example, the media server may know, a priori, that it
   will always access the same IMAP server using the same login
   credentials with an access pattern that would benefit from connection
   caching, without unduly impacting server resources.

   Examples:

   C: a001 LOGIN anonymous null
   S: a001 OK LOGIN completed.
   C: a002 URLFETCH
   ("imap://joe@example.com/INBOX/;uid=24356/;section=1.2;
   expire=2006-12-19T16:39:57-08:00;urlauth=anonymous:
   internal:238234982398239898a9898998798b987s87920" BODYPARTSTRUCTURE
   BINARY )
   S: * URLFETCH "imap://joe@example.com/INBOX/;uid=24356/;
   section=1.2;expire=2006-12-19T16:39:57-08:00;urlauth=anonymous
   internal:238234982398239898a9898998798b987s87920"
   (BODYPARTSTRUCTURE ("VIDEO" "MPEG" () NIL NIL "BINARY" 655350 ))
   (BINARY ~{655350}
   S: [ ~655350 octets of binary data, containing NUL octets ])
   S: a002 OK URLFETCH completed.
   C: a003 LOGOUT
   S: a003 OK LOGOUT completed.

3.9.  Protocol Diagrams

   This section gives examples of using the mechanism described in the
   document to stream media from a media server to a client, fetching
   the content from an IMAP server.  In all of the examples, the IMAP,
   SIP and RTP protocols use the line styles "-", "=", and "+",
   respectively.












Cook                      Expires June 11, 2009                [Page 19]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


3.9.1.  Announcement Service Protocol Diagram

   The following diagram shows the protocol interactions between the
   email client, the IMAP server and the media server when the client
   uses the Announcement Service.

   Client                     IMAP Server                   Media Server
     |   FETCH (BODYSTRUCTURE)     |                              |
     |---------------------------->|                              |
     |           OK                |                              |
     |<----------------------------|                              |
     |   GENURLAUTH                |                              |
     |---------------------------->|                              |
     |           OK                |                              |
     |<----------------------------|                              |
     |                             |                              |
     |                          SIP INVITE                        |
     |===========================================================>|
     |                             |                              |
     |                             |          URLFETCH            |
     |                             |<-----------------------------|
     |                             |             OK               |
     |                             |----------------------------->|
     |                             |                              |
     |                          200 OK                            |
     |<===========================================================|
     |                          ACK                               |
     |===========================================================>|
     |                             |                              |
     |                    Stream Message Part (RTP)               |
     |<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
     |                             |                              |
     |                            BYE                             |
     |<===========================================================|
     |                          200 OK                            |
     |===========================================================>|


3.9.2.  IVR Service Protocol Diagram

   The following diagram shows a simplified view of the protocol
   interactions between the email client, the IMAP server and the media
   server when the client uses the MSCML IVR Service.








Cook                      Expires June 11, 2009                [Page 20]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   Client                     IMAP Server                   Media Server
     |   FETCH (BODYSTRUCTURE)     |                              |
     |---------------------------->|                              |
     |           OK                |                              |
     |<----------------------------|                              |
     |   GENURLAUTH                |                              |
     |---------------------------->|                              |
     |           OK                |                              |
     |<----------------------------|                              |
     |                             |                              |
     |                          SIP INVITE                        |
     |===========================================================>|
     |                             |                              |
     |                          200 OK                            |
     |<===========================================================|
     |                          ACK                               |
     |===========================================================>|
     |                             |                              |
     |                          SIP INFO (playcollect)            |
     |===========================================================>|
     |                             |                              |
     |                          200 OK                            |
     |<===========================================================|
     |                             |                              |
     |                             |          URLFETCH            |
     |                             |<-----------------------------|
     |                             |             OK               |
     |                             |----------------------------->|
     |                             |                              |
     |                    Stream Message Part (RTP)               |
     |<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
     |                             |                              |
     |                          SIP INFO (e.g., DTMF ff)          |
     |===========================================================>|
     |                          200 OK                            |
     |<===========================================================|
     |                             |                              |
     |                    Continue streaming (RTP)                |
     |<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++|
     |                             |                              |
     |                (Streaming Ends or is terminated)           |
     |                             |                              |
     |                     SIP INFO (playcollect response)        |
     |<===========================================================|
     |                            BYE                             |
     |===========================================================>|
     |                           200 OK                           |
     |<===========================================================|



Cook                      Expires June 11, 2009                [Page 21]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


4.  Security Considerations

   This document proposes the use of URLAUTH [URLAUTH] "pawn tickets",
   received over IMAP [IMAP], and transmitted over SIP [SIP], possibly
   within the MSCML payload of RFC 5022 [MSCML], in order to stream
   media received in messages.  As such, the security considerations in
   all these documents apply to this specification.

   In summary, as the authorized URLs may grant access to data,
   implementors of this specification need to consider the following
   with respect to the security implications of using IMAP URLs:

   o  Use of an anonymous pawn ticket grants access to any client of the
      IMAP server without requiring any authentication credentials.  The
      security mechanisms referenced above (with the caveats specified
      below) SHOULD be used to prevent unauthorized access to the pawn
      ticket.

   o  Use of pawn tickets that contain the "stream" access identifier
      restricts access to the content to those entities that are
      authorized users of the IMAP server for the purposes of streaming
      retrieved content.  Use of such pawn tickets is thus desirable and
      so implementors should consult Section 3.3, which describes when
      such pawn tickets should be used.

   o  If the announcement service is used to set up streaming, then RFC
      4240 [NETANN] specifies that the pawn ticket is passed in the
      Request-URI.  Thus, if the SIP communication channel is not
      secured with TLS (e.g. using the sips URI scheme [SIP]), untrusted
      third-parties may be able to intercept the pawn ticket.  Using
      sips in this situation protects the pawn ticket from untrusted
      third-parties, however, it still allows proxies access to the pawn
      ticket.

   o  To fully protect the pawn ticket, the IVR service, RFC 5022
      [MSCML], which uses MSCML to carry the pawn ticket in the body of
      the request, is RECOMMENDED, using an end-to-end encryption of the
      MSCML payload, such as S/MIME [SMIME].  Information on how to use
      S/MIME to protect SIP payloads can be found in [SIP].

   This document describes a mechanism that makes use of two separate
   servers to achieve the goal of streaming the content desired by the
   client.  A major security implication of this is that the media
   server and IMAP server may well be located in separate administrative
   domains.  This leads us to consider the security implications of a
   three-way protocol exchange, and the potential trust model implicit
   in that tripartate relationship.  The security implications of the
   individual protocols have already been referenced, therefore this



Cook                      Expires June 11, 2009                [Page 22]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


   section describes the security considerations specific to the three-
   way data exchange, specifically:

   o  The client grants the media server full access to the potentially-
      private media content specified by the IMAP URL.  As a result, the
      client is responsible for verifying the authenticity of the media
      server to a degree it finds acceptable for the content (we can
      refer to this process as determining the "trust" that the client
      has in a particular media server).  The security mechanisms
      provided by SIP [SIP] and RTP [RTP] may be used for this purpose,
      as well as out of band mechanisms such as pre-configuration.

   o  However, since the media server will retrieve content from an IMAP
      server on the users behalf, the issue of security between the IMAP
      server and the media server also needs to be considered.  A client
      has no way of determining (programatically at least) the security
      of the exchanges between the media server and the IMAP server.
      However, it can determine, using the "stream" token that is part
      of the media server discovery mechanism described in Section 3.2,
      that the media server has a pre-existing authentication
      relationship with the IMAP server for the purposes of retrieving
      content using IMAP URLs.  The IMAP server administrator may put
      pre-requisites on media server administrator before this
      relationship can be established, for example to guarantee the
      security of the communication between the media server and the
      IMAP server.

   o  The above two security considerations will influence the decision
      the client makes with regards to generation of the pawn ticket
      that is subsequently passed to the media server.  This document
      mandates the use of URLs protected with the "stream" access
      identifier where the client knows in advance that the "stream"
      authentication relationship between media server and IMAP server
      exists.  However, it does allow the use of anonymous pawn tickets
      where the possibility exists that use of "stream" would cause
      streaming to fail.

   o  There exists the possibility of an attack by a malicious media
      server against pawn tickets protected with the "stream" access
      identifier.  In this attack, the client contacts a media server,
      MS1 (note this is not a man-in-the-middle attack per-se, as the
      client is intentionally contacting the media server in question),
      and that media server M1 then proxies the streaming request to a
      second media server, MS2, that it has determined or guessed to
      have "stream" authorization credentials with the IMAP server
      specified in the pawn ticket.  While this attack would technically
      defeat the protection of the "stream" access identifier, the
      security mechanisms inherent in SIP, such as authentication, would



Cook                      Expires June 11, 2009                [Page 23]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


      be expected to prevent unauthorized access to MS2 by malicious
      clients such as M1.

   Media servers handling streaming requests will be making use of pawn
   ticket URLs for the period of time required to process the streaming
   request, after which the URL will be forgotten.  However, media
   servers may log the URLs received from clients, in which case the
   private data contained in the IMAP server could be accessed by a
   malicious or curious media server administrator.  Even URLs protected
   with EXPIRE may be accessed within the period of expiry.  Therefore,
   media servers SHOULD remove or anonymize the internal portion of the
   IMAP URL when logging that URL.

   Additionally, many of the security considerations in the Message
   Submission BURL Extension apply to this document, particularly around
   the use of pawn tickets and prearranged trust relationships such as
   those described above.

   Message parts that are encrypted using mechanisms such as S/MIME
   [SMIME], are designed to prevent third-parties from accessing the
   data, thus media servers will not be able to fulfil streaming
   requests for messages parts that are encrypted.





























Cook                      Expires June 11, 2009                [Page 24]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


5.  IANA Considerations

   The following gives the proposed IANA submission for the METADATA
   server entry to be used for media server discovery.

   To: iana@iana.org

   Subject: IMAP METADATA Entry Registration


   Type: Server


   Name: /pubic/mediaServers

   Description: Defines a set of URIs containing the locations of
   suitable media servers for streaming multimedia content


   Content-type: text/plain;charset=utf-8


   Contact: ncook@cloudmark.com




























Cook                      Expires June 11, 2009                [Page 25]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


6.  Digital Rights Management (DRM) Issues

   This document does not specify any Digital Rights Management (DRM)
   mechanisms for controlling access to and copying of the media to be
   streamed.  This is intentional.  A reference to a piece of media
   content is created using the URLAUTH [URLAUTH] command; any DRM
   required thus should be implemented within the media itself, as
   implementing checks within URLAUTH could affect any use of the
   URLAUTH command, such as the BURL [BURL] command for message
   submission.

   The use of URLAUTH in this specification is believed to be pursuant
   with, and used only for, the execution of those rights to be expected
   when media is sent via traditional internet messaging, and causes no
   duplication of media content which is not essentially provided by the
   action of sending the message; that is, the use of the content for
   downloading and viewing, which *is* implicitly granted by the sender
   of the message, in as much as the sender has the right to grant such
   rights.

   The document author believes that if DRM is a requirement for
   Internet messaging, then a suitable DRM mechanism should be created.
   How such a mechanism would work is outside the scope of this
   document.



























Cook                      Expires June 11, 2009                [Page 26]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


7.  Deployment Considerations

   This document assumes an Internet deployment where there are no
   network restrictions between the different components.  Specifically,
   it does not address issues that can occur when network policies
   restrict the communication between different components, especially
   between the media server and the IMAP server, and between the client
   the media server.  In particular, RFC 5022 states that "It is
   unlikely, but not prohibited, for end-user SIP UACs to have a direct
   signaling relationship with a media server."  This caveat makes it
   likely that firewalls and other network security mechanisms will be
   configured to block direct end-user access to media servers.

   In order for either of the streaming mechanisms described in this
   document to work, local administrators MUST relax firewalls policies
   such that appropriate SIP UACs running on mobile devices are
   permitted to access the media servers directly using the SIP
   protocol.  The detail of how the restrictions are relaxed, (for
   example, only allowing clients connecting from the network space
   owned/maintained by the operator of the media server) is a matter of
   local policy, and so is outside the scope of this document.






























Cook                      Expires June 11, 2009                [Page 27]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


8.  Formal Syntax

   The following syntax specification for the mediaServer METADATA entry
   value uses the Augmented Backus-Naur Form (ABNF) notation as
   specified in RFC 4234 [ABNF] and the "absolute-URI" definition from
   RFC 3986 [RFC3986].

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   media-servers = ms-tuple *(";" ms-tuple)

   ms-tuple = <absolute-URI> [":" "submit+"]




































Cook                      Expires June 11, 2009                [Page 28]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


9.  Contributors

   Eric Burger, eburger@standardstrack.com

   Eric Burger provided the initial inspiration for this document, along
   with advice and support on aspects of the media server IVR and
   Announcement services, as well as help with the IETF process.

   Many people made helpful comments on the document, including Alexey
   Melnikov, Dave Cridland, Martijn Koster, and a variety of folks in
   the Lemonade and Sipping WGs.








































Cook                      Expires June 11, 2009                [Page 29]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


10.  References

10.1.  Normative References

   [NETANN]   Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
              Media Services with SIP", RFC 4240, December 2005.

   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 3501, March 2003.

   [URLAUTH]  Crispin, M., "Internet Message Access Protocol (IMAP) -
              URLAUTH Extension", RFC 4467, May 2006.

   [IMAPURL]  Newman, C. and A. Melnikov, "IMAP URL Scheme", RFC 5092,
              Oct 2007.

   [SIP]      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.

   [SMIME]    Ramsdell, B. and B. Ramsdell, "S/MIME Version 3.1 Message
              Specification"", RFC 3851, July 2004.

   [RTP]      Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", RFC 3550, July 2003.

   [KEYWORDS]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, BCP 14, March 1997.

   [MIME]     Freed, N., Borenstein, N., Moore, K., Klensin, J., and J.
              Postel, "Multipurpose Internet Mail Extensions (MIME)",
              RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049,
              November 1996.

   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol", RFC 5246,
              August 2008.

   [SDP]      Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [MSCML]    Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
              Control Markup Language", RFC 5022, Sep 2007.

   [URLFETCH_BINARY]
              Cridland, D., "URLAUTH Binary Extension",



Cook                      Expires June 11, 2009                [Page 30]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


              draft-cridland-urlfetch-binary-02.txt (Work in Progress) ,
              Sep 2007.

   [ACCESSID]
              Cook, N., "Internet Message Access Protocol (IMAP) - URL
              Access Identifier Extension",
              draft-ncook-urlauth-accessid-00.txt (Work in Progress) ,
              Dec 2008.

   [METADATA]
              Daboo, C., "IMAP METADATA Extension",
              draft-daboo-imap-annotatemore-16.txt (Work in Progress) ,
              July 2008.

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, Jan 2008.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Generic
              URI Syntax", RFC 3986, Jan 2005.

   [ANONYMOUS]
              Zeilenga, K., "Anonymous SASL Mechanism", RFC 4505,
              June 2006.

10.2.  Informative References

   [BURL]     Newman, C., "Message Submission BURL Extension", RFC 4468,
              May 2006.























Cook                      Expires June 11, 2009                [Page 31]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


Author's Address

   Neil L Cook
   Cloudmark

   Email: neil.cook@noware.co.uk













































Cook                      Expires June 11, 2009                [Page 32]

Internet-Draft  Streaming Internet Messaging Attachments   December 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.











Cook                      Expires June 11, 2009                [Page 33]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/