当我阅读rfc4551时，我注意到第3.4节中示例15之后的注释("Search中的MODSEQ搜索标准"(似乎是错误的。
示例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在上面的示例中，任何消息的消息编号包含字符串"；IMAP4"；在"；值"；的属性"评论"；条目并且具有等于或大于的mod序列超过620162338；\草稿"；在搜索中返回标志后果
CCD_ 1命令似乎不搜索"/评论"；完全
注释是否意味着MODSEQ搜索标准允许搜索任意元数据更改？
通常是一个完整的METADATA"；评论"；标签可能是/private/comment或/shared/comment，但考虑到MODSEQ似乎是如何设计的，以便通过entry-type-req参数指定private vs shared，我想知道是否应该去掉/private或/shared前缀以支持entry-type-req参数，从而给您留下SEARCH1的entry-name(根据下面的解释，这至少看起来与预期的示例相匹配(。
令我困惑的是，根据第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.
这似乎证实了我对能够使用任意元数据标签的怀疑，但当我阅读实际的ABNF语法时，我看到：
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
ABNF语法似乎明确地将元数据限制为/flags/<flagname>。
我已经给这个RFC的作者发了电子邮件，但两位作者中有一位的电子邮件地址已经作为死胡同返回给我了。
我认为其他人可能也对RFC中的上述措辞有疑问，这可能值得在这里发布到StackOverflow。
如果/当我收到唯一一位可能收到我消息的作者的回复时，我会将其发布在回复部分。
与此同时，也许StackOverflow的本地IMAP专家有一些见解？
Alexey Melnikov是最重要的作者，他应该仍然可以在同一地址联系到。他有时回复得很慢(他收到了堆积如山的邮件(，但最终还是回复了。
据我所知，该文件的作者或审稿人还没有实现entry-name/entry-type-req的东西，甚至没有计划实现它，所以如果在这方面遗漏了什么，这是可以理解的。(我复习了一下，但我认为这个特定的例子在我复习的时候还没有添加。(
我建议将modseq视为只适用于每条消息，没有更精细的调整，并且只按照RFC 7162中的描述实现CONDTORE，而不是在任何早期文档中。7162中的示例是正确的。
4551(以及后来的7162(将元数据限制为/flags/…，因为在协议中不存在其他元数据。预计如果另一个RFC添加元数据，它也将扩展entry-flag-name并引用7162。我认为没有人这样做过。可能会更新RFC 5257或5464，但这些扩展并没有引起太多兴趣，也不太可能更新。这个大方向的工作更有可能基于JMAP。