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

Barry Leiba <> Wed, 01 May 2013 22:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F13821F9B35; Wed, 1 May 2013 15:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.067
X-Spam-Status: No, score=-103.067 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GqvhL65jHXqk; Wed, 1 May 2013 15:05:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4E06621F9B21; Wed, 1 May 2013 15:05:47 -0700 (PDT)
Received: by with SMTP id v5so1844553lbc.18 for <multiple recipients>; Wed, 01 May 2013 15:05:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OQHpfltSqCQiTdNZPxq1qVZzZL2636rYu01IXXfL6Kg=; b=YSlH5uf5bROcZHpJQf4/9nhPLetcmzpEmhR9SvajZQUUlroL80pn3onuRDbj/Yy3Z+ s9N2O6aLXKRj2eV6iXRL4MdLPKnm/9nh7VfGNXZObdD0GuNR06D0Uhxq6HYktDbklpaL 7B7CrlXy/KZxN+Adgrk20ZCDdvF/xViGmYPmDDC0owAMOqVEeCKjgm4+thQ0WtWckY7h qE3fxQ2LGVowpBoUXYmeEy8b+eWrJ1sQc3lybIgkI9eUmWwRUB9GpygCePWRZ1V36Zj9 qiaYWDSL/EMBqWOOEdBUZyx1QHkySiaijnph/pE0m3K/BKU+FBL3P+DAjz2+WHWUJFF8 S8rQ==
MIME-Version: 1.0
X-Received: by with SMTP id qm5mr1793553lbb.2.1367445946166; Wed, 01 May 2013 15:05:46 -0700 (PDT)
Received: by with HTTP; Wed, 1 May 2013 15:05:46 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 1 May 2013 18:05:46 -0400
X-Google-Sender-Auth: LY9NqgfFaNMdUwWOmONq1Enu9OY
Message-ID: <>
From: Barry Leiba <>
To: Robert Sparks <>
Content-Type: text/plain; charset=ISO-8859-1
Cc:, Apps Area WG <>, IESG <>
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: Wed, 01 May 2013 22:05:57 -0000

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
> I will work to sew in a reference to 6855

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.

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

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.
> I will remove the But, and leave ). vs .) to the RFC Editor.

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]


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