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

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 01 May 2013 18:35:21 +0900

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.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 01 May 2013 16:25:21 -0500

On 5/1/13 4:35 AM, "Martin J. Dürst" wrote:
> 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:
>
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.
> does (see http://tools.ietf.org/html/rfc6778#section-3).
I will work to sew in a reference to 6855
> 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:
>
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"?
> '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.
> significant storage space"
Will fix all those.
> 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.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 1 May 2013 18:05:46 -0400

Hi, Robert (and Martin).  A couple of notes here:

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

It's probably best to note that "support for 6855 is desirable," and
not really anything more than that.  Let's also remember that there's
not really any deployment of 6855 support yet, in clients or servers.

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

Be careful here:
In IMAP terms, what mostly matters is the session, not the user (but
see below).  It's theoretically possible for an IMAP server to run
multiple searches in the same session in parallel without multimailbox
search (RFC 6237), but it's not practical for a number of reasons, and
isn't supported by any IMAP servers I'm aware of.  And there's already
a reference to 6237 later in the paragraph.

IMAP servers already do have to deal with multiple sessions for the
same user, and it's well know that limits might need to be put on
that: how many sessions one user can log in with, and how many
resources those sessions can consume.  This document shouldn't be
trying to deal with standard advice for things all IMAP servers need
to consider.

I take the sentence in question to address capacity, not function.  If
anything here needs clarification, it's that.  I don't think it makes
sense for this bullet to go into details of sessions vs users vs
anything else.

> "(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.
>

Wrong direction, but only a minor point:
1. There's absolutely nothing wrong with beginning a sentence with a
conjunction; please don't let yourself be pushed on that point.
2. That said, in this case the conjunction adds nothing.  So, yes,
just "But" out.
3. On the other hand, when parentheses contain a complete sentence,
the period does need to be inside the parentheses.  Absolutely.

And, yes, the RFC Editor will fix all of that.[1]

Barry

[1] Yes, I know.  I did it earlier in the message also, and I bet you
didn't notice.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 02 May 2013 09:56:09 -0500

> not really any deployment of 6855 support yet, in clients or servers.
Any reason to not just copy what we put in 6778 with minor tweaks?

3.  Internationalized Address Considerations

    The implementation should anticipate internationalized
    email addresses as discussed in the following three documents --
    [RFC6531], [RFC6532], and [RFC6855].  There is no firm requirement
    at this time.

> sense for this bullet to go into details of sessions vs users vs

I think you're arguing for not changing the text?
I've taken a stab at punching up "capacity". There wasn't anything obvious.
Does this help (I don't really think it does, but haven't come up with 
anything better):

<t hangText="o">
The interface must have server-side searching enabled, and should scale 
to support multiple simultaneous extensive searches.  The server should 
provide the enhanced search capabilities described in <xref 
target="RFC6778"/>.   The implementation should consider taking 
advantage of the extensions defined for IMAP SORT and THREAD <xref 
target="RFC5256"/>, multimailbox search <xref target="RFC6237"/>, and 
fuzzy search <xref target="RFC6203"/>.</t>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 13 May 2013 14:27:49 +0900

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.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 13 May 2013 09:27:34 -0500

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

RjS

>>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate 
>>>
>>> ).
>>>
>>> that