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

Robert Sparks <> Mon, 13 May 2013 14:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED2DA21F914C; Mon, 13 May 2013 07:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.3
X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QQE-WekK2qtk; Mon, 13 May 2013 07:27:48 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id E64BC21F925A; Mon, 13 May 2013 07:27:44 -0700 (PDT)
Received: from unnumerable.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id r4DERe3t061625 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 13 May 2013 09:27:42 -0500 (CDT) (envelope-from
Message-ID: <>
Date: Mon, 13 May 2013 09:27:34 -0500
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc:, IESG <>, Apps Area WG <>
Subject: Re: [apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 May 2013 14:27:50 -0000

On 5/13/13 12:27 AM, "Martin J. Dürst" wrote:
> Hello Robert,
> I have looked at your update, i.e. draft-sparks-genarea-imaparch-07. 
> It seems that all my concerns have been addressed, thanks very much.
> Thanks also for adding me to the acks section. However, please there 
> change my name from "Martin Durst" to "Martin Duerst". That's how it's 
> spelled if the "ü" character isn't available (which fortunately is 
> less and less the case).
Will do, and apologies for not getting it right the first time.


> Regards,   Martin.
> On 2013/05/02 6:25, Robert Sparks wrote:
>> On 5/1/13 4:35 AM, "Martin J. Dürst" wrote:
>>> I have been selected as the Applications Area Directorate reviewer for
>>> this draft (for background on appsdir, please see
>>> ).
>>> 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.
>> It will be used as input to the development of a tool providing the
>> capabilities described here.
>> We are capturing input from the IETF participants on what that tool
>> needs to do.
>> We've followed this approach with several other documents
>> - RFC6778 (the web-based email archive)
>> - RFC6730 (for nomcom tools)
>> - RFC6433 (milestones)
>> - RFC6292 (charters)
>> The document already says
>> "This memo captures the
>> requirements for providing a service that would allow such browsing
>> and searching."
>> Would it help to add "and it is intended as input to a later activity
>> for the design and development of such a tool." and would that address
>> your concern? Or is it fine as it was after seeing that other context?
>> Whether this results in an IAOC funded project or is satisfied with
>> volunteer effort is not something this document needs to discuss.
>>> 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.
>> That will be for Jari to judge, but as I point out above, we've followed
>> this pattern, using the language in this draft before.
>>> 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
>> I will work to sew in a reference to 6855
>>> 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.
>> I'll fold this suggestion in.
>>> "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.
>> I think it's _both_, not one or the other. I will attempt to clarify.
>>> "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.
>> Would "provide" work better for you than "facilitate"?
>>> "(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.
>> I will remove the But, and leave ). vs .) to the RFC Editor.
>>> "an LOGIN command" -> "a LOGIN command"
>> Thanks - will fix.
>>> "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"
>> Will fix all those.
>>> "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).
>> The language is intended to leave latitude for design. Forcing
>> administrators to poll would not satisfy "making it easy".
>> I will try to make that clearer.
>>> 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.
>> I will look at calling this out. However, there are many bad things that
>> an implementation _could_ do, and calling them all out is not needed
>> here. Things like this would get caught at design review or as source
>> comes in. (You can get the source for the running datatracker - see the
>> codesprint pages if you don't already know how). Such bad design will be
>> caught. Good designs are often improved at codesprints.
>>> Regards, Martin.