doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc5616.txt b/doc/rfc/rfc5616.txt
new file mode 100644
index 0000000..4728e77
--- /dev/null
+++ b/doc/rfc/rfc5616.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+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
+   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.
+
+
+
+
+
+Cook                         Informational                      [Page 2]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   Examples of the types of media that would benefit from the ability to
+   stream 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 that 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.
+
+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.
+
+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:
+
+   o  IMAP URLAUTH Extension [URLAUTH] - Providing the ability to
+      generate an IMAP URL that allows access by external entities to
+      specific message parts, e.g., an audio clip.
+
+   o  URLFETCH Binary Extension [URLFETCH_BINARY] - Providing the
+      ability to specify BINARY and BODYPARTSTRUCTURE arguments to the
+      URLFETCH command.
+
+
+
+
+
+Cook                         Informational                      [Page 3]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   o  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.
+
+   o  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: Proposed Mechanism
+
+   The proposed mechanism has the following steps:
+
+   (1)  The 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)  The client constructs an IMAP URL referencing the message part,
+        and uses the GENURLAUTH [URLAUTH] command to generate a URLAUTH-
+        authorized IMAP URL.
+
+   (3)  The 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.
+
+
+
+Cook                         Informational                      [Page 4]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   (4)  The 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)  The media server streams the retrieved message part to the
+        client using RTP [RTP].
+
+   (6)  The media server or the client terminates 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  The 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  The media server(s) used by the mobile device support the IMAP URL
+      [IMAPURL] scheme for the announcement and/or IVR services.
+
+   o  The 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.
+
+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.
+
+
+
+
+
+Cook                         Informational                      [Page 5]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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 authorized 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 "/shared/mediaServers" is used to
+   store the locations of suitable media servers known to the IMAP
+   server.  The entry is formatted according to the formalSyntax
+   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 /shared/mediaServers METADATA entry (N.B. Any
+   line-wrapping below is for the purpose of clarity):
+
+   "<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"
+
+
+
+Cook                         Informational                      [Page 6]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   It should be noted that the URI specified in the ABNF (in Section 8)
+   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 /shared/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 /shared/mediaServers
+   entry, who do not know the capabilities of the media servers being
+   configured, SHOULD NOT include a "userinfo" component as part of the
+   URI.  In that 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.
+
+   Note that even though the media server address can be discovered
+   dynamically, it is assumed that the necessary security arrangements
+   between the client and the media server already exist.  For example,
+   the media server could use SIP digest authentication to provide
+   access only to authenticated clients; in this case, it is assumed the
+   username and password have already been set up.  Likewise, if the
+   client wants to authenticate the media server using, e.g., TLS and
+   certificates, it is assumed the necessary arrangements (trust anchors
+   and so on) already exist.  In some deployments, the clients and media
+   servers may even be willing to rely on the security of the underlying
+   network, and omit authentication between the client and the media
+   server entirely.  See Section 4 for more details.
+
+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, they decide whether streaming for
+   that message part will be attempted.
+
+
+
+
+Cook                         Informational                      [Page 7]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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 it 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 from 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 pre-configured 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
+   Section 4 for a full discussion of the security issues.
+
+   The client uses the URL generated as a parameter to the GENURLAUTH
+   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.
+
+
+
+
+Cook                         Informational                      [Page 8]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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.
+
+   This section specifies the behavior 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
+   Sections 3.5 or 3.7, as appropriate.
+
+
+
+
+Cook                         Informational                      [Page 9]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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 that has the service indicator "ivr".
+
+   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:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3Bsection
+   %3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3Danonymous:
+   internal:238234982398239898a9898998798b987s87920
+
+   C: sip:annc@ms1.example.net;
+   play=imap:%2F%2Ffred@
+   example.com%2FINBOX%2F%3Buid%3D24359%2F%3Bsection
+   %3D1.3%3Bexpire%3D2006-12-20T18:31:45-08:00%3Burlauth%3Dstream:
+   internal:098230923409284092384092840293480239482
+
+   Notice that many of the characters that are used as parameters of the
+   IMAP URI are escaped, as otherwise they would change the meaning of
+   the enclosing SIP URI, by being regarded as SIP URI parameters
+   instead of IMAP URL parameters.
+
+
+
+
+Cook                         Informational                     [Page 10]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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.
+
+   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
+   to discuss 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 session description
+   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 session description below, 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 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, or 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.
+
+
+
+
+Cook                         Informational                     [Page 11]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   Example SIP INVITE and SDP Media Negotiation
+
+   C: INVITE sip:annc@ms2.example.com;
+   play=imap:%2F%2Fjoe@example.com%2FINBOX%2F%3Buid%3D24356%2F%3B
+   section%3D1.2%3Bexpire%3D2006-12-19T16:39:57-08:00%3Burlauth%3D
+   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
+   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
+
+
+
+Cook                         Informational                     [Page 12]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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 dual
+   tone multi-frequency (DTMF) digits to control playback of the media,
+   such as fast-forward or rewind.
+
+   Since the <playcollect> request is used purely for its VCR-like
+   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
+   immediately after the media has finished playing.
+
+   The "ffkey" and "rwkey" attributes of <playcollect> are used to
+   control fast-forward and rewind behavior, 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
+
+
+
+Cook                         Informational                     [Page 13]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   content.  The "stoponerror" attribute SHOULD be set to "yes", so that
+   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
+   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
+
+
+
+Cook                         Informational                     [Page 14]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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>
+
+   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
+
+
+
+
+
+Cook                         Informational                     [Page 15]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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
+
+   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
+
+
+
+Cook                         Informational                     [Page 16]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+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 has a user identity on the IMAP server, the media
+   server SHOULD authenticate itself to the IMAP server using the media
+   server's user identity.
+
+   If the media server is not configured as an authorized user of the
+   IMAP server, then the behavior specified in IMAP URL [IMAPURL] MUST
+   be followed.  That is, if the server advertises AUTH=ANONYMOUS IMAP
+   capability, the media server MUST use the AUTHENTICATE command with
+   the ANONYMOUS [ANONYMOUS] SASL mechanism.  If SASL ANONYMOUS is not
+   available, the username "anonymous" is used with the "LOGIN" command
+   and the password is supplied as the Internet email 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.
+
+   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
+
+
+
+Cook                         Informational                     [Page 17]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cook                         Informational                     [Page 18]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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                         Informational                     [Page 19]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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                         Informational                     [Page 20]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+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, and so untrusted third parties may be able to
+      intercept the pawn ticket.  The SIP communication channel MAY be
+      secured by using SIPS URIs [SIP], which would provide hop-by-hop
+      TLS encryption.
+
+   o  If the IVR service (RFC 5022 [MSCML]) is used to set up and
+      control streaming, then MSCML is used to carry the pawn ticket in
+      the body of the request, and so untrusted third parties may be
+      able to intercept the pawn ticket.  This MAY be secured by using
+      SIPS URIs [SIP], which would provide hop-by-hop TLS encryption.
+
+   o  Using SIPS URIs in the above situations protects the pawn ticket
+      from third parties; however, it still allows proxies access to the
+      pawn ticket, which could result in misuse by malicious proxies;
+      see note below.
+
+   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
+
+
+
+Cook                         Informational                     [Page 21]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   three-way protocol exchange, and the potential trust model implicit
+   in that tripartite relationship.  The security implications of the
+   individual protocols have already been referenced; therefore, this
+   section describes the security considerations specific to the three-
+   way data exchange, as follows:
+
+   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 user's 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 prerequisites 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 several types of attack by a
+      malicious media server, SIP proxy, or other network elements even
+      against pawn tickets protected with the "stream" access
+      identifier.  All of these attacks allow access to the RTP stream,
+      if not the original content.  These attacks include:
+
+
+
+
+
+
+Cook                         Informational                     [Page 22]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+      *  The client contacts a malicious media server, MS1, that 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.  The media server can then redirect the streamed
+         RTP traffic elsewhere.
+
+      *  Any proxy on the path between the client and the media server
+         has access to the client's message in cleartext.  In this case,
+         a malicious proxy could perform a man-in-the-middle attack and
+         could change the message to redirect RTP traffic elsewhere.
+
+      *  Any network element that is able to "see" the traffic between
+         the client and the media server (or between any two proxies)
+         can capture the pawn ticket, and then reissue a request using
+         that pawn ticket to the same media server.  Again the streamed
+         traffic can be redirected to any desired location.
+
+   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 fulfill streaming
+   requests for messages parts that are encrypted.
+
+5.  IANA Considerations
+
+   IANA has registered the following [METADATA] server entry to be used
+   for media server discovery, using the [METADATA] registry.
+
+
+
+
+
+
+
+
+
+Cook                         Informational                     [Page 23]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+      To: iana@iana.org
+
+      Subject: IMAP METADATA Entry Registration
+
+      Type: Server
+
+      Name: /shared/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: neil.cook@noware.co.uk
+
+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; thus, any DRM
+   required 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 that is not essentially provided by the
+   action of sending the message.  In other words, the use of the
+   content for downloading and viewing *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.
+
+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
+
+
+
+Cook                         Informational                     [Page 24]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   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 firewall policies
+   such that appropriate SIP UACs (user agent clients) 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.
+
+8.  Formal Syntax
+
+   The following syntax specification for the mediaServers METADATA
+   entry value uses the Augmented Backus-Naur Form (ABNF) notation as
+   specified in RFC 5234 [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.
+
+   Copyright (c) 2009 IETF Trust and the persons identified as authors
+   of the code.  All rights reserved.
+
+   Redistribution and use in source and binary forms, with or without
+   modification, are permitted provided that the following conditions
+   are met:
+
+   - Redistributions of source code must retain the above copyright
+     notice, this list of conditions and the following disclaimer.
+
+   - Redistributions in binary form must reproduce the above copyright
+     notice, this list of conditions and the following disclaimer in the
+     documentation and/or other materials provided with the
+     distribution.
+
+   - Neither the name of Internet Society, IETF or IETF Trust, nor the
+     names of specific contributors, may be used to endorse or promote
+     products derived from this software without specific prior written
+     permission.
+
+   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+
+
+
+Cook                         Informational                     [Page 25]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
+   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+        media-servers = ms-tuple *(";" ms-tuple)
+        ms-tuple      = "<" absolute-URI ">" [":" "stream"]
+
+9.  Contributors
+
+   Eric Burger (eburger@standardstrack.com) 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.
+
+10.  References
+
+10.1.  Normative References
+
+   [ABNF]      Crocker, D., Ed. and P. Overell, "Augmented BNF for
+               Syntax Specifications: ABNF", STD 68, RFC 5234,
+               January 2008.
+
+   [ACCESSID]  Cook, N., "Internet Message Access Protocol (IMAP) - URL
+               Access Identifier Extension", RFC 5593, June 2009.
+
+   [ANONYMOUS] Zeilenga, K., "Anonymous Simple Authentication and
+               Security Layer (SASL) Mechanism", RFC 4505, June 2006.
+
+   [IMAP]      Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+               4rev1", RFC 3501, March 2003.
+
+   [IMAPURL]   Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",
+               RFC 5092, October 2007.
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [METADATA]  Daboo, C., "The IMAP METADATA Extension", RFC 5464,
+               February 2009.
+
+
+
+Cook                         Informational                     [Page 26]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   [MIME]      Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME)", RFC 2045, November 1996.
+
+               Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part Two: Media Types", RFC 2046,
+               November 1996.
+
+               Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+               Part Three: Message Header Extensions for Non-ASCII
+               Text", RFC 2047, November 1996.
+
+               Freed, N. and J. Klensin, "Media Type Specifications and
+               Registration Procedures", BCP 13, RFC 4288, December
+               2005.
+
+               Freed, N. and J. Klensin, "Multipurpose Internet Mail
+               Extensions (MIME) Part Four: Registration Procedures",
+               BCP 13, RFC 4289, December 2005.
+
+               Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part Five: Conformance Criteria and
+               Examples", RFC 2049, November 1996.
+
+   [MSCML]     Van Dyke, J., Burger, E., Ed., and A. Spitzer, "Media
+               Server Control Markup Language (MSCML) and Protocol",
+               RFC 5022, September 2007.
+
+   [NETANN]    Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
+               Media Services with SIP", RFC 4240, December 2005.
+
+   [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+               Resource Identifier (URI): Generic Syntax", STD 66,
+               RFC 3986, January 2005.
+
+   [RTP]       Schulzrinne, H., Casner, S., Frederick, R., and V.
+               Jacobson, "RTP: A Transport Protocol for Real-Time
+               Applications", STD 64, RFC 3550, July 2003.
+
+   [SDP]       Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+               Description Protocol", RFC 4566, July 2006.
+
+   [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.
+
+   [TLS]       Dierks, T. and E. Rescorla, "The Transport Layer Security
+               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+
+
+Cook                         Informational                     [Page 27]
+
+RFC 5616        Streaming Internet Messaging Attachments     August 2009
+
+
+   [URLAUTH]   Crispin, M., "Internet Message Access Protocol (IMAP) -
+               URLAUTH Extension", RFC 4467, May 2006.
+
+   [URLFETCH_BINARY]
+               Cridland, D., "Extended URLFETCH for Binary and Converted
+               Parts", RFC 5524, May 2009.
+
+10.2.  Informative References
+
+   [BURL]      Newman, C., "Message Submission BURL Extension",
+               RFC 4468, May 2006.
+
+   [SMIME]     Ramsdell, B., Ed., ""Secure/Multipurpose Internet Mail
+               Extensions (S/MIME) Version 3.1 Message Specification"",
+               RFC 3851, July 2004.
+
+Author's Address
+
+   Neil L Cook
+   Cloudmark
+
+   EMail: neil.cook@noware.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cook                         Informational                     [Page 28]
+