Re: draft-ietf-imapext-condstore-05

[Alexey Melnikov <[e-mail]>]

Ken Murchison wrote:

> I just starting working on a CONDSTORE implementation in Cyrus, and I 
> wanted to make a few comments/suggestions before the document gets too 
> far along in the queue.
>
> Here is what I have come up with over the last day.  I might have more 
> as I get further into my implementation.
>
> - As a general note, should the STORE/FETCH modifier syntax be broken 
> out into a separate draft and then referenced by CONDSTORE? 

I thought about this as well. I don't remember now, but I thought I've 
asked this question on the mailing list.
Anyway, CONDSTORE is approved as RFC now and I fear it will take another 
3 years before updated CONDSTORE and that separate document get published.

>   Any subsequent draft which introduces a new modifier will have to 
> reference CONDSTORE, which seems a bit awkward.
>
> - Section 2 doesn't mention STATUS (HIGHESTMODSEQ) as a CONDSTORE 
> enabling command?  Is this by design or an oversight? 

An oversight.

> - Section 3.1.1 leads me to believe that HIGHESTMODSEQ is *always* 
> returned for SELECT/EXAMINE.

That is correct.

>   Why is this necessary when we explicitly have CONSTORE enabling 
> commands which require that we return HIGHESTMODSEQ?  It seems 
> redundant that weShould we just return HIGHESTMODSEQ for 
> SELECT/EXAMINE CONDSTORE? would return this on SELECT/EXAMINE and then 
> again on the first CONDSTORE-specific STORE/FETCH.  

You are probably right, but I don't see a problem with returning 
HIGHESTMODSEQ on the first CONDSTORE-aware STORE/FETCH.

If Ned agrees that just returning HIGHESTMODSEQ on SELECT/EXAMINE 
CONDSTORE is not a substantial change to the document, I can try to 
modify it.

> - Section 3.2, first example: the MODSEQ value of UID 6 is less than 
> UNCHANGEDSINCE 

Good catch.

> - Section 3.3.1 leaves out "OPTIONAL fetch modifiers" as the last 
> argument.

Corrected in my copy, thanks.

> - Section 4.  The grammar for the STORE and FETCH modifiers seem 
> inconsistent with one another.  The STORE grammar defines 
> UNCHANGEDSINCE as the only modifier, where FETCH defines the modifier 
> in general terms, and has the chgsince-fetch-mod terminal unused. 

The latter approach is probably better.

chgsince-fetch-mod is not really unused. There is a comment that it 
conforms to fetch-modifier syntax.

> - Does the MODSEQ search criterion also apply to THREAD in the same 
> way that it does to SORT?

Yes, search criterion applies to all commands that make use of it.

> - Grammatical nits:
>
> Section 2, paragraph 3, sentence 2: perhaps replacing both instances 
> of "and before" with "where previously" would read better.
>
> Section 3.1, paragraph 1, sentence 2: "SELECT and EXAMINE commands" 
> should probably read "SELECT or EXAMINE command"

I've changed this in my copy, thanks.

Alexey