Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-lemonade-streaming-10

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 6 Apr 2009 12:08:13 -0500

Just to let people know, version 10 of this draft addresses all my questions 
from my -09 review.

Ready to publish as Informational.

Thanks,

Spencer

>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:[email-masked]:5060>:stream;<sip:annc@
>   ms1.example.net:5060>;<sips:[email-masked]:5061>"
>
>   "<sip:[email-masked]: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
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>