Subject: [lemonade] WGLC Search Within

From: Eric Burger <[email-masked]>
Date: Tue, 07 Nov 2006 10:47:43 -0500

<http://tools.ietf.org/wg/lemonade/ draft-ietf-lemonade-search-within/
draft-ietf-lemonade-search-within-02.txt>

Have at it.  WGLC closes 11/21/06.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 10:57:31 +0200

Hi all,
here are the comments I have on the WITHIN draft:

1. Could we change this in section 2:
      search-key /= "OLDER" SP nz-number / "YOUNGER" SP nz-number 
                       ; search-key defined in [RFC3501]  
To this:
      search-key /= ( "OLDER" SP nz-number ) / ( "YOUNGER" SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number )
                       ; search-key defined in [RFC3501]  
Which essentially means two things:
 - correct sequences using the brackets,
 - we can specify both ends of the time interval (this is an actual proposal).

2. Normative references and informative references do not have a section number.

3. Normative references: URL is missing from [ABNFEXTEND]. URLs are there for the other two references, so the URL should be added to ABNFEXTEND, or removed from the other two.

4. Unused reference: [P-IMAP], suggest removal. Later on I noticed that it's used in Acknowledgements section.

5. Future work:
   [1] Decide whether other interval units are necessary.
I think that the day/months should be added as well. Here is the syntax I have in mind (assuming that comment 1. was accepted):
      search-key /= ( ( "OLDER" SP nz-number ) / ( "YOUNGER" SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) ) i-unit
                       ; search-key defined in [RFC3501] 
      i-unit = "d" / "D" / "h" / "H" / "m" / "M"
                       ; either days (d, D), hours (h, H) or months (m , M)

So, the example in section 3 would be ('h' added to the end):
C: a1 SEARCH UNSEEN YOUNGER 72h

6. There are two acknowledgement sections - is this OK or should these be merged? One is called "Acknowledgements", the other one is called "Acknowledgement".

Thank You.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

>-----Original Message-----
>From: ext Eric Burger [mailto:[email-masked]] 
>Sent: 07 November, 2006 17:48
>To: IETF LEMONADE
>Subject: [lemonade] WGLC Search Within
>

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 11:32:36 +0200

Whoops, I left an error here:

>I think that the day/months should be added as well. Here is 
>the syntax I have in mind (assuming that comment 1. was accepted):
>      search-key /= ( ( "OLDER" SP nz-number ) / ( "YOUNGER" 
>SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP 
>nz-number ) ) i-unit

It should have been:
      search-key /= ( ( "OLDER" SP nz-number ) / ( "YOUNGER" SP
nz-number ) i-unit ) / ( "OLDER" SP nz-number i-unit SP "YOUNGER" SP
nz-number i-unit)
                       ; search-key defined in [RFC3501]

---

From: Ray Cromwell <[email-masked]>
Date: Wed, 08 Nov 2006 02:03:14 -0800

>                        ; search-key defined in [RFC3501]  
I agree the parenthesis are needed, but wouldn't the third option simply 
be written "OLDER x AND YOUNGER y"?

>                        ; either days (d, D), hours (h, H) or months (m , M)

I don't have a huge problem with this, but the draft is very simple and 
I hope it can make it past WGLC without too many revs, so we can 
concentrate on other drafts. I fear an endless debate over time interval 
formats and calendar semantics dragging out for weeks (exactly how long 
is 3 months?! In a leap year?) , when the important thing is to settle 
on the minimum time granularity and accuracy supported by the server.  
The client can always compute any arbitrary interval from the minimum 
granularity, so the extra-interval units seem to be syntactic sugar to 
avoid somewhat trivial arithmetic on the client.

-Ray

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 8 Nov 2006 11:19:20 +0100

Ray Cromwell writes:
>>       search-key /= ( "OLDER" SP nz-number ) / ( "YOUNGER" SP 
>>       nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number 
>>       )
> I agree the parenthesis are needed, but wouldn't the third option 
> simply be written "OLDER x AND YOUNGER y"?

"a SEARCH UNSEEN OLDER 1 YOUNGER 2" is a valid command in the current 
draft: IMAP search has an implicit AND and all three conditions must be 
true, so that commmand finds unseen mail that's 1-2 hours old. (It 
takes a little time to get used to IMAP search syntax ;)

> I don't have a huge problem with this, but the draft is very simple 
> and I hope it can make it past WGLC without too many revs, so we can 
> concentrate on other drafts. I fear an endless debate over time 
> interval formats and calendar semantics dragging out for weeks 
> (exactly how long is 3 months?! In a leap year?) , when the important 
> thing is to settle on the minimum time granularity and accuracy 
> supported by the server.

Yes! Yes! Yes!

Arnt

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 12:40:33 +0200

Hi Ray,

>> To this:
>>       search-key /= ( "OLDER" SP nz-number ) / ( "YOUNGER" 
>SP nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number )
>I agree the parenthesis are needed, but wouldn't the third 
>option simply be written "OLDER x AND YOUNGER y"?

You mean adding search-key twice? Yes, that works too, consider this
withdrawn.

>>                        ; either days (d, D), hours (h, H) or 
>months (m 
>> , M)
>>   
>
>I don't have a huge problem with this, but the draft is very 
>simple and I hope it can make it past WGLC without too many 
>revs, so we can concentrate on other drafts. I fear an endless 
>debate over time interval formats and calendar semantics 
>dragging out for weeks (exactly how long is 3 months?! In a 
>leap year?) , when the important thing is to settle on the 
>minimum time granularity and accuracy supported by the server.  
>The client can always compute any arbitrary interval from the 
>minimum granularity, so the extra-interval units seem to be 
>syntactic sugar to avoid somewhat trivial arithmetic on the client.

Ok, then let's drop months then, but days should still be OK.

---

From: <[email-masked]>
Date: Wed, 8 Nov 2006 13:00:45 +0200

Hi Arnt,

>draft: IMAP search has an implicit AND and all three 
>conditions must be true, so that commmand finds unseen mail 
>that's 1-2 hours old. (It takes a little time to get used to 
>IMAP search syntax ;)

I take it You are saying the same thing as Ray, right? So, this we have
settled.

>> thing is to settle on the minimum time granularity and accuracy 

Erm... Does it mean that You agree with Ray?
I replied to Him saying that we can drop the month - keeping the day if
possible.
Dropping the day should not be a problem either because it's simply
multiplied by 24 - but I would rather keep it.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 8 Nov 2006 12:05:39 +0100

[email-masked] writes:
>>>  and I hope it can make it past WGLC without too many revs, so we 
>>>  can concentrate on other drafts. I fear an endless debate over 
>>>  time interval formats and calendar semantics dragging out for 
>>>  weeks (exactly how long is 3 months?! In a leap year?) , when the 
>>>  important thing is to settle on the minimum time granularity and 
>>>  accuracy supported by the server.
>>
>> Yes! Yes! Yes!
>

Yes I do. Simplicity is a fine and desirable feature.

> I replied to Him saying that we can drop the month - keeping the day 
> if possible.

Do you have an argument to justify the additional argument?

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Wed, 08 Nov 2006 11:12:09 +0000

I'll comment on some comments (meta-comments?) and add some of my own.

On Wed Nov  8 10:03:14 2006, Ray Cromwell wrote:
>> nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number )
The parenthesis aren't needed, RFC3501's search (and search-key) 
productions handle the combination case fine, too. I think the ABNF 
is fine as it is - the precedence of the / operator takes care of 
everything, just as it does in RFC3501's search-key production.

>> I think that the day/months should be added as well. Here is the 
>> syntax I have in mind (assuming that comment 1. was accepted):
>> nz-number ) / ( "OLDER" SP nz-number SP "YOUNGER" SP nz-number ) ) 
>> i-unit
>> months (m , M)
> can concentrate on other drafts. I fear an endless debate over time 
> (exactly how long is 3 months?! In a leap year?) , when the 

I hate to bring this up, but anything other than seconds will have 
this problem. Certain minutes have 61 seconds, for example, leading 
to certain hours having 3601 seconds.

Is a client likely to care? No, almost certainly not.

I don't see a real problem with having the server be allowed some 
leeway in updating these results, either - currently the draft 
essentially dictates that servers have to treat an hour as 3600 (or 
3601) seconds accordingly, and doesn't talk about the granularity of 
the criteria, merely the granularity of how the criteria can be 
specified.

1) Paragraph 2 of section 1 implies that YOUNGER and OLDER use an 
interval of hours from which a date is calculated, and the use of the 
phrase "after the date calculated" could be read to imply that 
servers round off to a date, and not a time. Since this code will 
exist in a base IMAP server, you might find people quite happy to 
take this somewhat literally.

2) Also, the use of the phrase "[...] depositied in the mailbox after 
the date calculated [...]" is in itself problematic, since it implies 
that a third date, neither the Date header field nor the 
INTERNALDATE, is used for this.

3) A nit: The example in section 3 contains no tagged OK response.

4) As a general comment, I'd personally apprciate a new section 
inserted between the Introduction (which I generally read expecting a 
non-normative summary) and the formal syntax, giving a strictly 
worded definition of OLDER and YOUNGER.

By way of a suggestion:

2. Protocol Changes

For both new search keys, a date and time is calculated by 
subtracting the interval on the current date and time of the server. 
Servers need not maintain a greater precision than an hour in this 
calculation.

The resultant date and time is then compared against the INTERNALDATE 
(as specified in [RFC3501]). For OLDER, messages match if the date 
and time is less recent then the INTERNALDATE, for YOUNGER, messages 
match if the date and time is more recent then the INTERNALDATE. If 
the date and time matches the INTERNALDATE precisely,the message will 
be matched by both OLDER and YOUNGER.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Ray Cromwell <[email-masked]>
Date: Wed, 08 Nov 2006 04:38:01 -0800

Dave Cridland wrote:
> this problem. Certain minutes have 61 seconds, for example, leading to 
> certain hours having 3601 seconds.
>
   Apropos, proposals are floating to eliminate leap-seconds for 
precisely the reason that they make interval calculation non-trivial if 
you desire accuracy.  But this just shows the can of worms that can open 
up when we start getting creative with interval formats, which is why 
the original search-within draft used seconds as a unit, since it is 
straight forward for clients to pick whatever definition of minutes, 
hours, days, months, they desire and translate them into interval 
seconds, and seconds is already a convenient input to date/time interval 
routines on many platforms.  It was only changed because of concerns of 
accuracy guarantees that were raised, but in hindsight, we could have 
stuck with seconds, and simply mandated that servers guarantee no more 
than minute, or hour accuracy. The multiple unit proposal simply brings 
to light the fact that units and server accuracy (or granularity if you 
prefer) are separate issues.

> the criteria, merely the granularity of how the criteria can be 
Yes, this was a mistake I think, in trying to address original concerns 
of per-second granularity, especially with vfolder (do I need to 
recompute all vfolder criteria every second!!!?), we settled on changing 
the interval units, instead of leaving them as is, and mandating / 
relaxing accuracy.  Anyone in favor of a return to seconds? :)

> non-normative summary) and the formal syntax, giving a strictly worded 
> definition of OLDER and YOUNGER.
>
Yes, in discussions with Arnt, he has pointed out the need to define 
what "NOT OLDER" and "YOUNGER" mean, e.g. synonyms/semantic equivalence?

-Ray

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 8 Nov 2006 13:55:45 +0100

Arnt Gulbrandsen writes:
> Yes. I suggest: "The client specifies the age limit in seconds. The 
> server need not recheck every second when using WITHIN with CONTEXTS, 
> VFOLDER or other mechanisms that cause the search to be repeatedly 
> executed. The server can use any time between the start and end of 
> the command processing as base, and may disregard leap seconds when 
> processing age."

Ick. Half the verbs are wrong. I suck.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 8 Nov 2006 13:54:25 +0100

Ray Cromwell writes:
> Yes, this was a mistake I think, in trying to address original 
> concerns of per-second granularity, especially with vfolder (do I 
> need to recompute all vfolder criteria every second!!!?), we settled 
> on changing the interval units, instead of leaving them as is, and 
> mandating / relaxing accuracy.  Anyone in favor of a return to 
> seconds? :)

Yes. I suggest: "The client specifies the age limit in seconds. The 
server need not recheck every second when using WITHIN with CONTEXTS, 
VFOLDER or other mechanisms that cause the search to be repeatedly 
executed. The server can use any time between the start and end of the 
command processing as base, and may disregard leap seconds when 
processing age."

(I know the second sentence disregards an obvious optimisation.)

(And I don't really care how the age is specified so long as it's 
simple. Seconds, minutes, hours, I don't care. I liked days until 
Alexey persuaded me otherwise.)

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Wed, 15 Nov 2006 16:17:36 -0800

>  Is a client likely to care? No, almost certainly not.

I agree.  When people are looking for a message, or a client is 
resynchronizing a subset of a mailbox, the time range is approximate.

> 3601) seconds accordingly, and doesn't talk about the granularity 
> of the criteria, merely the granularity of how the criteria can be 
> specified.

Yes.

> interval of hours from which a date is calculated, and the use of 
> the phrase "after the date calculated" could be read to imply that 

So we need some text specifying the criteria that servers use.

>
>  2) Also, the use of the phrase "[...] depositied in the mailbox 
> after the date calculated [...]" is in itself problematic, since it 
> implies that a third date, neither the Date header field nor the 

Good point.

> inserted between the Introduction (which I generally read expecting 
> a non-normative summary) and the formal syntax, giving a strictly 
> subtracting the interval on the current date and time of the 
> server. Servers need not maintain a greater precision than an hour 
> in this calculation.
>
>  The resultant date and time is then compared against the 
> INTERNALDATE (as specified in [RFC3501]). For OLDER, messages match 
> if the date and time is less recent then the INTERNALDATE, for 
> YOUNGER, messages match if the date and time is more recent then 
> the INTERNALDATE. If the date and time matches the INTERNALDATE 
> precisely,the message will be matched by both OLDER and YOUNGER.

This text works for me.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
1.  People to whom you are attracted invariably think you
    remind them of someone else.
2.  The love letter you finally got the courage to send will
    be delayed in the mail long enough for you to make a fool
    of yourself in person.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 15 Nov 2006 16:32:20 -0800

> resynchronizing a subset of a mailbox, the time range is approximate.

Not that it seems to matter in this discussion:

I made the decision to have date ranges instead of date/time in IMAP ~20 
years ago.  My observation at that time was that date was the best 
granularity that most people could come up with, and even that was often 
approximate.

I've heard the arguments for time granularity and remain unconvinced.  All 
the use cases for time granularity seem to have better ways to solve the 
problem.

But not all battles are worth fighting, and this one was not.  There are 
no particular ill effects either way.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Dan Karp <[email-masked]>
Date: Fri, 17 Nov 2006 09:10:25 -0800 (PST)

> > INTERNALDATE, is used for this.

Would it be reasonable to use INTERNALDATE for the OLDER/YOUNGER calculation instead?  The cost of the overhead of an extra indexed date per message would probably outweigh the benefit of the WITHIN extension for me.

---

From: Randall Gellens <[email-masked]>
Date: Fri, 17 Nov 2006 14:40:22 -0800

At 9:10 AM -0800 11/17/06, Dan Karp wrote:

>  Would it be reasonable to use INTERNALDATE for the OLDER/YOUNGER 
> calculation instead?  The cost of the overhead of an extra indexed 
> date per message would probably outweigh the benefit of the WITHIN 
> extension for me.

I think Dave was pointing out that the current wording "deposited..." 
was problematic, and suggested being explicit about using 
INTERNALDATE.  I don't think anyone intended to create a third date 
field.

-------------- Randomly-selected tag: ---------------
ondinnonk (ON-din-onk; Iroquoian; noun): the soul's innermost
benevolent desires.

---

From: Dave Cridland <[email-masked]>
Date: Sat, 18 Nov 2006 21:19:01 +0000

On Fri Nov 17 22:40:22 2006, Randall Gellens wrote:
> I think Dave was pointing out that the current wording 
> "deposited..." was problematic, and suggested being explicit about 
> using INTERNALDATE.  I don't think anyone intended to create a 
> third date field.

I want more dates! More, I tell you, more!

No, seriously, I was indeed suggesting that the document refers 
explicitly to INTERNALDATE, which is by default the date the message 
was deposited in the mailbox, but can be specified explicitly on 
APPEND, and carries over on a COPY.

So I'm pretty sure Ray meant INTERNALDATE, and hence I included that 
in the text I sketched out rather more explicitly.

Dave.