Document: draft-ietf-lemonade-streaming-09 Reviewer: Spencer Dawkins Review Date: 2009-03-06 IETF LC End Date: 2009-03-12 IESG Telechat date: (not known) Summary: Almost ready for publication as Informational. A couple of nits (forwarded for the editor, not part of Gen-ART reviews), and a couple of minor questions. Comments: 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 Spencer (nit): s/attachment/attachment before displaying any of it/, perhaps? The sentence seems to say the user won't download the entire attachment under any conditions, but that's probably not what it should say... 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. 3.1. Overview of Mechanism The proposed mechanism has the following steps: 1. Client determines from MIME headers of a particular message that a particular message part (attachment) should be streamed to the user. Note that no assumptions are made about how/when/if the client contacts the user of the client about this decision. User input MAY be required in order to initiate the proposed mechanism. Spencer (minor): this MAY doesn't smell 2119 to me... 3.2. Media Server Discovery There is also a scenario where media server discovery would improve the security of the streaming mechanism, by avoiding the use of completely anonymous URLs. For example, the client could discover a media server address that was an authorised user of the IMAP server for streaming purposes, which would allow the client to generate a URL, which was secure in that it could *only* be accessed by an entity that is trusted by the IMAP Server to retrieve content. The issue of trust in media servers is discussed more fully in Section 4 Spencer (nit): missing period after "4". Example values of the /shared/mediaServers METADATA entry: ":stream;;" ";;:stream" Spencer (minor): Hmm. The paragraph that talked about line wrapping in section 2 was specifically about S: and C:, and that doesn't apply here. Is this clear enough for the target reader? At a minimum, I see people indenting continuation lines in other specs... 3.7. Client Use of the Media Server MSCML IVR Service Since the playcollect request is used purely for its VCR capabilities, there is no need for the media server to perform DTMF collection, therefore the playcollect attributes "firstdigittimer", "interdigittimer" and "extradigittimer" SHOULD all be set to "0ms", which will have the effect of causing digit collection to cease immediately the media has finished playing. Spencer (minor): "immediately the" is missing a word... if I could guess which word, this would be a nit. 3.8. Media Server Use of IMAP Server If the media server is configured as an authorized user of the IMAP server, it SHOULD authenticate to the IMAP server using the credentials for that user. This document does not go into the details of IMAP authentication, but the authentication SHOULD NOT use the LOGIN command over a non-encrypted communication path. Spencer (minor, because I'm not your security reviewer): I'm struggling why this last statement is SHOULD NOT with no qualifications... if you tell me that this is normal practice in the e-mail community, I'll be quiet, but this would worry me if I saw it happening. 4. Security Considerations o However, since the media server will retrieve content from an IMAP server on the users behalf, the issue of security between the IMAP Spencer (nit): s/users/user's/ server and the media server also needs to be considered. A client has no way of determining (programatically at least) the security of the exchanges between the media server and the IMAP server. However, it can determine, using the "stream" token that is part of the media server discovery mechanism described in Section 3.2, that the media server has a pre-existing authentication relationship with the IMAP server for the purposes of retrieving content using IMAP URLs. The IMAP server administrator may put pre-requisites on media server administrator before this relationship can be established, for example to guarantee the security of the communication between the media server and the IMAP server. From IDNits: (Yeah, I know my working group has pre-RFC5378 work, too..) Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). trust-12-feb-2009 Section 6.c.iii text: "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." Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ncook-urlauth-accessid-00 == Outdated reference: draft-daboo-imap-annotatemore has been published as RFC 5464