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

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

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

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
>> 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.
>
> 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 http://tools.ietf.org/html/rfc6778#section-3).
> 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.
>>
>>
>>
>
>