idnits 2.17.1 draft-cook-lemonade-streaming-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 512. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 502. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 19, 2006) is 6550 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'BINARY' on line 277 -- Looks like a reference, but probably isn't: 'MIME' on line 385 == Unused Reference: '3' is defined on line 442, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4240 (ref. '1') ** Obsolete normative reference: RFC 3501 (ref. '3') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2192 (ref. '4') (Obsoleted by RFC 5092) ** Obsolete normative reference: RFC 2246 (ref. '10') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (ref. '11') (Obsoleted by RFC 4566) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Lemonade N. Cook 3 Internet-Draft Openwave 4 Expires: November 20, 2006 May 19, 2006 6 Streaming Multimedia Messaging Attachments 7 draft-cook-lemonade-streaming-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 20, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document, part of the Lemonade Working Group, describes the Best 41 Current Practice for streaming multimedia attachments received by a 42 resource constrained and/or mobile device from a IMAP server. It 43 allows such clients, which are limited in storage space and 44 bandwidth, to play video and audio content which is attached to email 45 messages. The document describes a profile for making use of the 46 existing IMAP URLAUTH extension [2] and the "Netann" SIP Media 47 Service as described in RFC 4240 [1]. 49 Conventions Used in this Document 51 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 52 in this document are to be interpreted as defined in RFC 2119 [7]. 54 In examples, "C:" and "S:" indicate lines sent by the client and 55 server respectively. If a single "C:" or "S:" label applies to 56 multiple lines, then the line breaks between those lines are for 57 editorial clarity only and are not part of the actual protocol 58 exchange. 60 1. Introduction 62 Email clients on resource and/or network constrained devices, such a 63 mobile phones, may have difficulties in retrieving and/or storing 64 large attachments received in a message. For example, on a poor 65 network link, the latency required to download the entire attachment 66 may not be acceptable to the user. Conversely, even on a high-speed 67 network, the device may not have enough storage space to secure the 68 attachment once retrieved. 70 For certain media, such as audio and video, there is a solution: the 71 media can be streamed to the device, using protocols such as SIP [5] 72 and particularly the media server profile as specified in RFC 4240 73 [1]. Streaming the media to the device addresses both the latency 74 issue, since the client can start playing the media immediately, and 75 the storage issue, since the client does not need to store the media 76 locally. A tradeoff is that the media cannot be viewed/played when 77 the device is offline. 79 Examples of the types of media that would benefit from the ability to 80 stream such media to the device include: 82 + Voice or Video mail messages received as an attachment 84 + Audio clips such as ringtones received as an attachment 86 + Video clips such as movie trailers received as an attachment 88 2. Mechanism 90 2.1. Overview of Mechanism 92 The proposed mechanism for streaming media to messaging clients is a 93 profile for making use of two existing mechanisms, namely: 95 1. IMAP URLAUTH Extension [2] - Providing the ability to generate an 96 IMAP URL [4] which allows anonymous access from external systems 97 to specific message parts; for example, an audio clip. 99 2. Media Server Announcement Service RFC 4240 [1] - Providing the 100 ability for a media server to stream media using a reference 101 provided by the media server client in a URL. 103 However, it should be noted that this document proposes a extension 104 to the SIP Parameter Registry [8], in order to accomodate the passing 105 of a content transfer encoding parameter. 107 The approach is shown in the following figure: 109 +--------------+ 110 | | 111 | Email Client |^ 112 | | \ 113 +--------------+ \ 114 | \ \ 115 | \ \ (5) 116 | (1), \ \ 117 | (2) \ \ 118 | (3),\ \ 119 | (6) \ \ 120 | \ \ 121 v v \ 122 +--------------+ +----------------+ 123 | | (4) | | 124 | IMAP Server |<------| Media Server | 125 | | | | 126 +--------------+ +----------------+ 128 Figure 1 130 The proposed mechanism has the following steps: 132 1. Client determines from headers of a particular message that a 133 particular message part (attachment) should be streamed to the 134 user. Note that no assumptions are made about how/when/if the 135 client contacts the user of the client about this decision. User 136 input MAY be required in order to initiate the proposed 137 mechanism. 139 2. Client constructs an IMAP URL referencing the message part, and 140 uses the GENURLAUTH [2] command to generate a URLAUTH authorized 141 IMAP URL. 143 3. Client connects to a SIP Media Server using the Announcement 144 Service as specified in RFC 4240 [1], and passes the URLAUTH 145 authorized URL to the media server. 147 4. Media Server connects to the IMAP Server specified in the 148 referenced URL, and uses the IMAP URLFETCH [2] command to 149 retrieve the message part. 151 5. Media server streams the retrieved message part to the client 152 using RTP [6]. 154 6. Media server terminates the SIP session. 156 It should be noted that the proposed mechanism makes several 157 assumptions about the mobile device, as well as the network services, 158 namely: 160 + Mobile device is provisioned with address or addresses of a 161 media server which supports the announcement service defined in 162 RFC 4240 [1] 164 + Media Server(s) used by the mobile device support the IMAP URL 165 [4] scheme for the announcement service 167 + IMAP Server used by the mobile device supports generating 168 anonymous IMAP URLs using the URLAUTH mechanism 170 This document assumes that there are no network restrictions between 171 the different components. Specifically it does not address the 172 issues that could occur when the media server and the IMAP server are 173 provided by different entities, and network security protocols 174 restrict the communication between the different components, 175 especially between the media server and the IMAP server. 177 2.2. Client use of GENURLAUTH Command 179 The decision to make use of streaming services for a message part 180 will usually be predicated on the content type of the message part. 181 Using the capabilities of the IMAP FETCH command, clients can 182 determine the MIME [9] Content-Type of particular message parts, and 183 based on local policies or heuristics, decide that streaming for that 184 message part will be attempted. 186 Once the client has determined that a particular message part 187 requires streaming, the client generates an IMAP URL that refers to 188 the message part according to the method described in RFC 2192 [4]. 189 The client then begins the process of generating an URLAUTH URL, by 190 appending ";EXPIRE=" and ";URLAUTH=" to the initial 191 URL. 193 The ";EXPIRE=" parameter is optional, however it SHOULD be 194 used, since the use of anonymous URLAUTH authorized URLs is a 195 security risk, and doing so ensures that at some point in the future, 196 permission to access that URL will cease. 198 The portion of the URLAUTH parameter SHOULD be 'anonymous'. 199 This document makes the assumption that Media Servers are unlikely to 200 be configured as authorized users to IMAP servers. In this case, 201 without specific prior knowledge of such a configuration, the client 202 MUST use the 'anonymous' access identifier. In the event that the 203 client does have prior knowledge of a media server which is 204 configured for authorized access to the media server, the 'authuser' 205 access identifier SHOULD be used. 207 The client uses the URL generated as a parameter to the GENAUTHURL 208 command, using the INTERNAL authorization mechanism. The URL 209 returned by a successful response to this command will then be passed 210 to the media server. If no successful response to the GENURLAUTH 211 command is received, then no further action will be possible with 212 respect to streaming media to the client. 214 Examples: 216 C: a122 UID FETCH 24356 BODY[1.2.MIME] 217 S: * 26 FETCH (BODY[1.2.MIME] {127} 218 S: Content-Transfer-Encoding: base64 219 S: Content-Type: video/mpeg; 220 S: UID 24356 FLAGS (\Seen)) 221 S: a122 OK FETCH completed. 222 C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;\ 223 section=1.2;expire=2006-12-19T16:39:57-08:00;\ 224 urlauth=anonymous" INTERNAL 225 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24356/;\ 226 section=1.2;expire=2006-12-19T16:39:\57-08:00;\ 227 urlauth=anonymous:\ 228 internal:238234982398239898a9898998798b987s87920" 229 S: a123 OK GENURLAUTH completed 230 C: a122 UID FETCH 24359 BODY[1.2.MIME] 231 S: * 26 FETCH (BODY[1.3.MIME] {127} 232 S: Content-Transfer-Encoding: base64 233 S: Content-Type: audio/G729; 234 S: UID 24359 FLAGS (\Seen)) 235 S: a122 OK FETCH completed. 236 C: a123 GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;\ 237 section=1.3;expire=2006-12-19T16:39:57-08:00;\ 238 urlauth=anonymous" INTERNAL 239 S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=24359/;\ 240 section=1.3;expire=2006-12-20T18:31:\45-08:00;\ 241 urlauth=authuser:\ 242 internal:098230923409284092384092840293480239482" 243 S: a123 OK GENURLAUTH completed 245 2.3. Client Use of the Media Server Announcement Service 247 Once an authorized IMAP URL has been generated, it is up to the 248 client to pass that URL to a suitable media server that is capable of 249 retrieving the URL via IMAP, and streaming the content to the client 250 using the RTP [6]protocol. 252 The media server announcement service is used, as described in RFC 253 4240 [1]. This service allows the client to send a SIP INVITE to a 254 special username ('annc') at the media server (the "announcement" 255 user), supplying the URL obtained as per the previous section. 257 The SIP INVITE is constructed as shown in the examples below, note 258 that as per RFC 4240, the play parameter is mandatory, and specifies 259 the authorized IMAP URL to be played. 261 The content-type parameter is optional in RFC 4240, however it MUST 262 be supplied here, using the Content-Type header returned by the IMAP 263 server for the message part. The reason for supplying the content- 264 type parameter is that when the media server issues a URLFETCH 265 command to retrieve the message part, the message part will be 266 returned without any content type information. Since the media 267 server is not likely to have authorized access to other sections in 268 that message, for example the MIME section, then it may fail to 269 stream the content if the content type is not supplied as a parameter 270 to the SIP INVITE URI. 272 Similarly, the message well be encoded with a content transfer 273 encoding such as base 64. However, RFC 4240 does not include a 274 method for communicating content transfer encoding to the media 275 server as part of the announcement service, nor does the URLFETCH 276 command include a mechanism for retrieving message parts without 277 encoding (c.f. the [BINARY] extension to IMAP). Therefore, an 278 extension parameter is required, namely a 'content-transfer-encoding' 279 parameter, using the value of the Content-Transfer-Encoding MIME 280 header returned by the IMAP server for the message part. The 281 content-transfer-encoding parameter MUST be supplied if a Content- 282 Transfer-Encoding header for the message part existed in the original 283 message. 285 Examples of valid SIP INVITE URIs sent to the media server 286 announcement service: 288 sip:annc@ms2.example.net; \ 289 play=imap://joe@example.com/INBOX/;uid=24356/;section=1.2;\ 290 expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\ 291 internal:238234982398239898a9898998798b987s87920; \ 292 content-type=video/mpeg; \ 293 content-transfer-encoding=base64 295 sip:annc@ms1.example.net; \ 296 play=imap://fred@example.com/INBOX/;uid=24359/;section=1.3;\ 297 expire=2006-12-20T18:31:\45-08:00;urlauth=authuser:\ 298 internal:098230923409284092384092840293480239482; \ 299 content-type=audio/G729; \ 300 content-transfer-encoding=base64 302 If the SIP INVITE is successful, as indicated by a 200 OK response, 303 the client can assume that the media server has successfully 304 retrieved the content from the IMAP server, and that the negotiated 305 RTP stream will shortly begin. 307 An unsuccessful response code of 404 received from the media server 308 indicates that the content could not be found or could not be 309 retrieved for some reason. For example, the media server may not 310 support the use of IMAP URLs. At this point, there are several 311 options to the client, such as using alternate media servers, or 312 giving up in attempting to stream the required message part. 314 This document does not go into the details of the SIP [5], SDP [11] 315 or RTP [6] protocols; these are well described elsewhere. 317 2.4. Media Server Use of IMAP Server 319 A media server receiving a SIP INVITE to the annc user must first 320 attempt to retrieve the content indicated in the play parameter, 321 before returning a response to the client. This section describes 322 how the media server converts the received IMAP URL into suitable 323 IMAP commands for retrieving the content. 325 The media server first connects to the IMAP server specified in the 326 URL. Once connected, the media server MAY choose to use TLS [10] to 327 encrypt the communication path. 329 If the media server is configured as an authorized user of the IMAP 330 server, it SHOULD authenticate to the IMAP server using the 331 credentials for that user. This document does not go into the 332 details of IMAP authentication, but the authentication SHOULD NOT use 333 the LOGIN command over a non-encrypted communication path. 335 If the media server is not configured as an authorized user of the 336 IMAP server, it MUST authenticate to the IMAP server using the LOGIN 337 command, with the username of "anonymous". However, in this case, if 338 the URL supplied in the 'play' parameter of the SIP invite specifies 339 an authorization of 'authuser', then the media server SHOULD NOT 340 attempt to contact the IMAP server, but SHOULD instead immediately 341 return a response code of 404 with a reason phrase of 'Not authorized 342 to access resource'. reason. 344 Once authenticated, the media server issues the URLFETCH command, 345 using the URL supplied in the 'play' parameter of the SIP invite. A 346 successful URLFETCH command will return the message part, which must 347 be decoded by the media server, according to the content-transfer- 348 encoding header provided by the client (if any). If the URLFETCH was 349 unsuccessful, then the media server MUST return a response code of 350 404 with an appropriate reason code. 352 Assuming the content is retrieved and decoded successfully, the media 353 server returns a 200 OK response code, and after an ACK is received, 354 an RTP stream is delivered to the client using the parameters 355 negotiated in the SDP. 357 The media server MAY choose to implement connection caching, in which 358 case connection and disconnection from the IMAP server are handled 359 according to whatever algorithm the media server chooses. 361 Examples: 363 C: a001 LOGIN anonymous null 364 S: a001 OK LOGIN completed. 365 C: a002 URLFETCH 366 "imap://joe@example.com/INBOX/;uid=24356/;section=1.2; \ 367 expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous:\ 368 internal:238234982398239898a9898998798b987s87920" 369 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=24356/; \ 370 section=1.2;expire=2006-12-19T16:39:\57-08:00;urlauth=anonymous: \ 371 internal:238234982398239898a9898998798b987s87920" {36} 372 S: U2kgdmlzIHBhY2VtLCBwYXJhIGJlbGx1bS4K 373 S: a002 OK URLFETCH completed. 374 C: a003 LOGOUT 375 S: a003 OK LOGOUT completed. 377 2.5. Protocol Diagram 379 The following diagram shows a simplified view of the protocol 380 interactions between the email client, the IMAP server and the media 381 server. The IMAP, SIP and RTP protocols are distinguished with 382 different line styles. 384 Client IMAP Server Media Server 385 | FETCH BODY[MIME] | | 386 |---------------------------->| | 387 | GENURLAUTH | | 388 |---------------------------->| | 389 | | | 390 | SIP INVITE | 391 |===========================================================>| 392 | | | 393 | | URLFETCH | 394 | |<-----------------------------| 395 | | | 396 | 200 OK | 397 |<===========================================================| 398 | ACK | 399 |===========================================================>| 400 | | | 401 | Stream Message Part (RTP) | 402 |<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++| 403 | | | 405 3. Security Considerations 407 This document proposes the use of URLAUTH "pawn-tickets" to grant 408 access to message parts that are required to be streamed by the media 409 server. If an anonymous pawn-ticket is used, that grants access to 410 any client of the IMAP server, without requiring any authentication 411 credentials. Even if an authorized pawn-ticket is granted, access is 412 granted to any client that happens to be an authorized user of the 413 IMAP server. 415 Clearly, any third parties which gain access to the pawn-tickets can 416 potentially access private data. To minimise this, implementors 417 should consider the following: 419 IMAP clients SHOULD use encryption such as TLS [10] to secure the 420 communication path to the IMAP server 422 The media server SHOULD use encryption such as TLS secure the 423 communication path to the IMAP server 425 However, the communication path between the client and the media 426 server uses SIP, which currently has no mechanism to secure the data 427 contained in the SIP INVITE URI. Thus, even if an encrypted 428 communication path is used to the IMAP server, the potential for 429 third parties to gain access to the pawn-ticket still exists. 431 4. Contributors 433 5. References 435 [1] Burger, E., "Basic Network Media Services with SIP", RFC 4240, 436 December 2005. 438 [2] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH 439 Extension", draft-ietf-lemonade-urlauth-08.txt (work in 440 progress), October 2005. 442 [3] Crispin, M., "Internet Message Access Protocol - Version 443 4rev1", RFC 3501, March 2003. 445 [4] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. 447 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 448 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 449 Session Initiation Protocol", RFC 3261, June 2002. 451 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 452 "RTP: A Transport Protocol for Real-Time Applications", 453 RFC 3550, July 2003. 455 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 456 Levels", RFC 2119, BCP 14, March 1997. 458 [8] Camarillo, G., "The Internet Assigned Number Authority (IANA) 459 Uniform Resource Identifier (URI) Parameter Registry for the 460 Session Initiation Protocol (SIP)", RFC 3969, BCP 99, 461 December 2004. 463 [9] Freed, N., Borenstein, N., Moore, K., Klensin, J., and J. 464 Postel, "Multipurpose Internet Mail Extensions (MIME)", 465 RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049, 466 November 1996. 468 [10] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, 469 January 1999. 471 [11] Handley, M. and V. Jacobson, "SDP: Session Description 472 Protocol", RFC 2327, April 1998. 474 Author's Address 476 Neil L Cook 477 Openwave Systems 478 e-mail: neil.cook@openwave.com 480 Intellectual Property Statement 482 The IETF takes no position regarding the validity or scope of any 483 Intellectual Property Rights or other rights that might be claimed to 484 pertain to the implementation or use of the technology described in 485 this document or the extent to which any license under such rights 486 might or might not be available; nor does it represent that it has 487 made any independent effort to identify any such rights. Information 488 on the procedures with respect to rights in RFC documents can be 489 found in BCP 78 and BCP 79. 491 Copies of IPR disclosures made to the IETF Secretariat and any 492 assurances of licenses to be made available, or the result of an 493 attempt made to obtain a general license or permission for the use of 494 such proprietary rights by implementers or users of this 495 specification can be obtained from the IETF on-line IPR repository at 496 http://www.ietf.org/ipr. 498 The IETF invites any interested party to bring to its attention any 499 copyrights, patents or patent applications, or other proprietary 500 rights that may cover technology that may be required to implement 501 this standard. Please address the information to the IETF at 502 ietf-ipr@ietf.org. 504 Disclaimer of Validity 506 This document and the information contained herein are provided on an 507 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 508 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 509 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 510 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 511 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 512 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 514 Copyright Statement 516 Copyright (C) The Internet Society (2006). This document is subject 517 to the rights, licenses and restrictions contained in BCP 78, and 518 except as set forth therein, the authors retain all their rights. 520 Acknowledgment 522 Funding for the RFC Editor function is currently provided by the 523 Internet Society.