I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
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:
"<sip:ivr(_at_)ms(_dot_)example(_dot_)net:5060>:stream;<sip:annc@
ms1.example.net:5060>;<sips:ivr(_at_)ms2(_dot_)example(_dot_)net:5061>"
"<sip:ivr(_at_)192(_dot_)0(_dot_)2(_dot_)40:5060>;<sip:192.0.2.41:5060>;<sips:annc@
192.0.2.42:5060>: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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf