[apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-06

["Martin J. Dürst" <[e-mail]>]

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-sparks-genarea-imaparch-06
Title: IMAP Access to IETF Email List Archives
Reviewer: Martin Dürst
Review Date: 2013/05/01


Summary: There is one main issue that's unclear to me. Otherwise, the 
draft is close to publication, but needs some additional work.

Note: I'm not an IMAP expert, not even an IMAP user, and not somebody 
the Apps Area would call an email expert, although I wrote RFC 5064 and 
quite a bit of RFC 6068. So the comments here are mostly of general nature.

Main issue: It is totally unclear to me what the actual consequences of 
this draft are if approved. I could imagine any one of the following:

- It's informational, so it doesn't have any standing, and is just a
   wishlist, mostly just by the author.
- If and when it will be IESG-approved, it documents IETF consensus
   on how to best implement IMAP-based access to mailing list archives
   for the IETF should such access be desirable, but it does not
   represent an IETF consensus to actually implement this (e.g. because
   that needs money, and money doesn't move by IETF consensus).
- If and when it will be IESG-approved, it documents IETF consensus that
   IMAP-based access to IETF mailing lists is desirable, and should be
   implemented asap (assuming somebody can come up with the necessary
   resources).
- An informal mixture of the above: Those in the know agree it's a good
   idea, but somebody said they need a document that can be referenced in
   an RFP.

While I'm personally okay with any of the above (I won't use this kind 
of access in the near future, but can understand that many people are 
using IMAP and it would be pretty handy to have such a feature; also I 
won't have to pay for it), I think the fact that this unclarity exists 
may make it difficult for others to review the draft.

So I suggest that this be clarified. Unless it's just me who's unclear 
on this issue, it may get close to meriting a new or prolonged last call.


Minor issue: The draft should reference RFC 6855 (IMAP Support for 
UTF-8) and require its support *at least* to the extent that RFC 6778 
does (see http://tools.ietf.org/html/rfc6778#section-3).


Editorial/Nits:

  o  The interface must allow administrators to disable setting read/
     unread marks and other annotations, and delete any such marks or
     annotations on a per user basis.

It's unclear how far back "on a per user basis" applies. Also, "the 
interface" means "an IMAP interface" (first bullet point), but it may 
not be possible or practical to have administrators use IMAP itself for 
this function. So I suggest something along the following lines:

  o  It must be possible for administrators, on a per-user basis, to
     disable setting read/unread marks and other annotations and to
     delete any such marks or annotations.


"and should support multiple simultaneous extensive searches.": Is this 
simultaneous searches by the same user, or by different users? I suspect 
the later. If so, the clause should be rewritten so that it is clear 
that this is a dimensioning requirement, not a functionality requirement.

"The server should facilitate the enhanced search capabilities described 
in [RFC6778].": It is unclear what "facilitate" means here. Technology 
usually implements something or doesn't; facilitate sounds quite fuzzy. 
Although RFC 6778 is informational, it uses quite a bit of 'must',... On 
the other hand, IMAP may or may not support some of the queries listed 
as a 'must' in RFC 6778.

"(But it is acceptable for a user to access such archives while 
providing credentials).": Don't start a sentence with 'But' (use 
'However'). Also, please put the final period inside the parentheses.

"an LOGIN command" -> "a LOGIN command"

"determined by the administrator ." -> "determined by the administrator."

"local copies all messages" -> "local copies of all messages"

"maliciously crafted searches attempting to consume all available 
resources" -> "maliciously crafted searches attempting to consume 
significant available resources" (there is no need to consume all 
resources to result in significant DOS problems)

" maliciously crafted annontations attempting to consume all storage 
space" -> " maliciously crafted annontations attempting to consume 
significant storage space"

"The implementers should consider making it easy for the administrator 
to determine which users are consuming exceptional space.": "exceptional 
space" -> "exceptional amounts of space"; I also think "should consider" 
is rather too weak, and "easy to determine" seems to imply that 
administrators will have to actively check this (rather than getting 
alerts when something fishy starts).

This may be just an implementation detail, but it may be a good idea to 
note that flag implementation (and annotation implementation if an 
annotation can be applied by the user to more than one message at once) 
has to be quite clever because otherwise, even benign use might use up 
lots of space. As an example, if the system allocates 4 bytes for each 
message in the system for each user that logs into the system even once, 
that may already create huge storage demands.

Regards,   Martin.