Spencer,
thanks for these comments, I broadly agree with most of them. I've
replied specifically inline below, and if you agree will update the
draft accordingly.
Neil
On 6 Mar 2009, at 22:29, Spencer Dawkins wrote:
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...
I'm okay with changing this.
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..
You're right, that should simply be a lowercase may.
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".
Nod.
Example values of the /shared/mediaServers METADATA entry:
"<sip:ivr@xxxxxxxxxxxxxx:5060>:stream;<sip:annc@
ms1.example.net:5060>;<sips:ivr@xxxxxxxxxxxxxxx:5061>"
"<sip:ivr@xxxxxxxxxx: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...
Well to be fair - this is showing the value of an entry stored on the
IMAP server, not showing a protocol exchange. However I can add some
text saying that the lines below are wrapped for clarity, and add an
extra space at the start of the line.
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.
"after" is the word we're looking for here I think :)
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.
You're right, I actually took this verbatim from an earlier version of
the IMAP URL RFC, but I notice the latest version has removed this
text. There is no particular need for it in this doc either, as the
base IMAP RFCs cover the perils of using non-encrypted communication
channels adequately enough, and as such it's not a security concern of
this doc. So I lean towards removing the sentence completely, or
simply lowercasing the SHOULD NOT.
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/
Nod.
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..)
Will fix the nits below.
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf