Subject: [lemonade] IESG DISCUSS on SEARCH WITHIN draft

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Apr 2007 11:14:14 +0100

The search WITHIN draft got a DISCUSS comment (and a related comment) 
from IESG:

Cullen Jennings:

Discuss [2007-04-03]:
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.

Lars Eggert:

Comment [2007-04-05]:
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.)

=============
Personally I agree with the comments. I felt that the rounding procedure 
is underspecified and would lead to interoperability comments. I also 
agree with Cullen that it would be better to round in a way that would 
cause the server to return superset of the correct data. At least this 
seems sensible to clients that display this data to users.

Chris suggested that there might be two separate use cases for this 
extensions:

1. A vanilla SEARCH/SORT/THREAD WITHIN that is issued once.

2. When SEARCH WITHIN interacts with an IMAP extension providing dynamic
results over time.

In the first case he suggested that there is no reason to round the value.
In the second case, a server MUST regenerate the dynamic result set at 
least
every hour and MAY regenerate the dynamic result set more frequently.

I agree with Chris' proposal. So let me suggest the following changes to 
the document:

1). Clarify that a one time SEARCH/SORT/THREAD must be exact.
2). Allow implementations to regenerate result once an hour when WITHIN 
is used in VFOLDER/CONTEXT. Possibly add some examples about how 
rounding can be done.

Any objections?

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade