Odtnhj

As I was reading over rfc4551, I noticed that the comment after example 15 in section 3.4 ("MODSEQ Search Criterion in SEARCH") seems to be wrong.

Example 15:

 C: a SEARCH MODSEQ "/flags/\draft" all 620162338
 S: * SEARCH 2 5 6 7 11 12 18 19 20 23 (MODSEQ 917162500)
 S: a OK Search complete

In the above example, the message numbers of any messages
containing the string "IMAP4" in the "value" attribute of the
"/comment" entry and having a mod-sequence equal to or greater
than 620162338 for the "Draft" flag are returned in the search
results.

The SEARCH command does not appear to search "/comment" at all.

Does the comment imply that the MODSEQ search criteria allows searching for arbitrary metadata changes?

Normally a full METADATA "comment" tag would be either /private/comment or /shared/comment, but seeing as how MODSEQ seems to be designed such that you specify private vs shared via the entry-type-req parameter, I wonder if the idea is that the /private or /shared prefix should be stripped in favor of the entry-type-req parameter, thus leaving you with an entry-name of /comment (which would at least seem to match the intended example based on the explanation below it).

What confuses me is that based on the definition in section 3.4:

Syntax: MODSEQ [<entry-name> <entry-type-req>] <mod-sequence-valzer>

 Messages that have modification values that are equal to or
 greater than <mod-sequence-valzer>. This allows a client, for
 example, to find out which messages contain metadata items that
 have changed since the last time it updated its disconnected
 cache. The client may also specify <entry-name> (name of metadata
 item) and <entry-type-req> (type of metadata item) before
 <mod-sequence-valzer>. <entry-type-req> can be one of "shared",
 "priv" (private), or "all". The latter means that the server
 should use the biggest value among "priv" and "shared" mod-
 sequences for the metadata item. If the server doesn't store
 internally separate mod-sequences for different metadata items, it
 MUST ignore <entry-name> and <entry-type-req>. Otherwise, the
 server should use them to narrow down the search.

 For a flag <flagname>, the corresponding <entry-name> has a form
 "/flags/<flagname>" as defined in [IMAPABNF]. Note that the
 leading "" character that denotes a system flag has to be escaped
 as per Section 4.3 of [IMAP4], as the <entry-name> uses syntax for
 quoted strings.

It seems to confirm my suspicions about being able to use arbitrary metadata tags, but when I read the actual ABNF grammar, I see:

 search-modsequence = "MODSEQ" [search-modseq-ext] SP
 mod-sequence-valzer

 search-modseq-ext = SP entry-name SP entry-type-req

 resp-text-code =/ "HIGHESTMODSEQ" SP mod-sequence-value /
 "NOMODSEQ" /
 "MODIFIED" SP set

 entry-name = entry-flag-name

 entry-flag-name = DQUOTE "/flags/" attr-flag DQUOTE
 ;; each system or user defined flag <flag>
 ;; is mapped to "/flags/<flag>".
 ;;
 ;; <entry-flag-name> follows the escape rules
 ;; used by "quoted" string as described in
 ;; Section 4.3 of [IMAP4], e.g., for the flag
 ;; Seen the corresponding <entry-name> is
 ;; "/flags/\seen", and for the flag
 ;; $MDNSent, the corresponding <entry-name>
 ;; is "/flags/$mdnsent".

 entry-type-resp = "priv" / "shared"
 ;; metadata item type

 entry-type-req = entry-type-resp / "all"
 ;; perform SEARCH operation on private
 ;; metadata item, shared metadata item or both

The ABNF grammar appears to limit the metadata explicitly to /flags/<flagname>.

I've emailed the authors of this RFC, but the email address of 1 of the 2 authors has already returned to me as a dead end.

I figured that others might also have this question about the above wording in the RFC, that it might be worth posting here to StackOverflow.

If/when I hear back from the only remaining author that may have received my message, I'll post it in the answer section.

In the meantime, perhaps a native IMAP expert on StackOverflow has some insight?

Alexey Melnikov is the most important author, and he should be reachable at the same address still. He's slow to reply sometimes (he gets a mountain of mail), but ultimately does reply.

As far as I know, none of the document's authors or reviewers had yet implemented the entry-name/entry-type-req stuff, or even planned to implement it, so it's quite understandable if something was missed in that area. (I reviewed it, but I think this particular example hadn't been added yet when I did.)

I suggest treating modseq as if it only applies per message, nothing more finely tuned, and implementing CONDSTORE only as described in RFC 7162, not in either of the earlier documents. The example is correct in 7162.

4551 (and later 7162) limit the metadata to /flags/… because no other metadata exist in the protocol. It's expected that if another RFC adds metadata, it will also extend entry-flag-name and refer to 7162. I don't think anyone has done that. An update to either RFC 5257 or 5464 might, but those extensions haven't met a lot of interest and are unlikely ever to be updated. Work in that general direction is more likely be based on JMAP.