Gen-ART LC review of draft-ietf-lemonade-streaming-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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...

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]