WITHIN Search Extension to the IMAP Protocol
draft-ietf-lemonade-search-within-05

[Ballot discuss]
The IESG appears to have consensus that the text in the -04 version of the document related to rounding is sufficiently imprecise that it hampers interoperability.  We are waiting for an -05 version which folds in the RFC editor notes and addresses the rounding issue appropriately (have interoperable behavior for immediate searches and address the issue of how this is interpreted when it interacts with a persistent search).

Given the size of the present RFC editor note, and the DISCUSS comments, this needs a revised ID which folds in the RFC editor notes and clarifies the problematic text related to rounding.

The rounding issue needs to balance the requirement to not re-issue the search every second in the VFOLDER interaction with the need for clients to get reasonably predictable results.  The current text doesn't do an adequate job of the latter.

[Ballot comment]
Section 4020, paragraph 0:
>    For example, if the client requests messages that are younger than
>    4020 (67 minutes), but the server only performs searches with hourly
>    accuracy (as mandated above), the server performs the search as if
>    the client requested a 60-minute interval.  Note the choice of
>    rounding up or down is at the discretion of the server.  However,
>    rounding down to zero is NOT RECOMMENDED, as this may result in
>    searches for messages YOUNGER than a value being rounded to YOUNGER
>    0, which will always fail.

  The issue of rounding down for YOUNGER being problematic is
  important. It should be moved from the example to the preceding
  paragraph, where behavior is specified. Also, rounding up for OLDER is
  similarly problematic and should be discouraged, too.

  (I'll let Cullen hold the DISCUSS on the rounding issue.)

[Ballot discuss]
It seems like it would be better if the rounding was always done in such a way that the result included a super set of  what the original query requested. Given there is no way to report what sort of rounding or how much rounding was done by the server, I would be concerned about a scheme where the client could not even figure out how much of the requested time was being omitted from the returned result set.

[Ballot comment]
Gen-ART Review by Lucy Lynch.

  Lucy notes that Lars already has a discuss position posted.  She
  doesn't feel quite as strongly about the YOUNGER calculation as
  Lars, but she believes a couple examples (good and bad) might help.

  The abstract is beautifully clear, but the protocol operation
  section (from "In some cases" on) is less so. The series of key
  words: "SHOULD" "MUST" "MAY" "NOT RECOMMENDED" make it obvious
  that the 60 min/YOUNGER interval problem is serious, but it took
  a couple of reading to visualize the sliding window permutations
  as described.

[Ballot discuss]
Section 4020, paragraph 0:
>    For example, if the client requests messages that are younger than
>    4020 (67 minutes), but the server only performs searches with hourly
>    accuracy (as mandated above), the server performs the search as if
>    the client requested a 60-minute interval.  Note the choice of
>    rounding up or down is at the discretion of the server.  However,
>    rounding down to zero is NOT RECOMMENDED, as this may result in
>    searches for messages YOUNGER than a value being rounded to YOUNGER
>    0, which will always fail.

  DISCUSS: The issue of rounding down for YOUNGER being problematic is
  important. It should be moved from the example to the preceding
  paragraph, where behavior is specified. Also, rounding up for OLDER is
  similarly problematic and should be discouraged, too.

[Ballot discuss]
Section 4020, paragraph 0:
>    For example, if the client requests messages that are younger than
>    4020 (67 minutes), but the server only performs searches with hourly
>    accuracy (as mandated above), the server performs the search as if
>    the client requested a 60-minute interval.  Note the choice of
>    rounding up or down is at the discretion of the server.  However,
>    rounding down to zero is NOT RECOMMENDED, as this may result in
>    searches for messages YOUNGER than a value being rounded to YOUNGER
>    0, which will always fail.

  DISCUSS: The issue of rounding down for YOUNGER being problematic is
  important. It should be moved from the example to the preceding
  paragraph, where behavior is specified. Also, rounding up for OLDER is
  similarly problematic and should be discouraged, too.


Section 3., paragraph 1:
>    The following syntax specification uses the Augmented Backus-Naur
>    Form (ABNF) notation.  Elements not defined here can be found in the
>    formal syntax of ABNF [1], IMAP [2], and IMAP Extended ABNF [3]

  DISCUSS: [1] is RFC2119, which doesn't define ABNF. Also, the ABNF
  in the document doesn't validate.

DOCUMENT:
WITHIN Search extension to the IMAP Protocol
draft-ietf-lemonade-search-within-04

(1.a) Document Shepherd: Glenn Parsons, gparsons@nortel.com, personally
reviewed this document. This document is ready for publication.

(1.b) Work group review: The lemonade work group provided extensive review
of this document.

(1.c) Further review required: This document does not need further
specialized review.

(1.d.i) Document Shepherd Comfort Level: High
(1.d.ii) Document Useful and Needed: Yes
(1.d.iii) IPR Disclosures: None known

(1.e) WG Consensus: There are no open issues or internal discussion
remaining. Only discussion was on units; want accuracy to minutes+, but
seconds is universal. Consensus is what you see in the document.

(1.f) There are no members with objections or concerns. There are no threats
of appeal or process issues.  One of the chairs did take the editor pen to
get the document published.

(1.g) ID-nits: Check and verified with idnits 1.118.

(1.h) References: All references are normative and are current RFCs

(1.i) IANA Considerations: None

(1.j) ABNF: Checked and verified with Bill Fenner's ABNF checker

(1.k) Document Announcement:

Technical Summary

This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH
returns messages whose internal date is within or outside a specified
interval. The mechanism described here, OLDER and YOUNGER, differs from
BEFORE and SINCE in that the client specifies an interval, rather than a
date. We expect WITHIN to be most useful for persistent searches from mobile
devices.

Working Group Summary

There is consensus in the WG to publish this document.


Document Quality

Virtually all members of the Lemonade WG have reviewed the document.  Dave
Cridland contributed significant text.

The document has been checked using idnits and an ABNF checker and passed
both checks.

Personnel
Glenn Parsons shepherds this document, has reviewed this document, and
believes that the -04 version is ready for forwarding to the IESG for
publication.  The responsible Area Director is Ted Hardie.