IMAP MODSEQ SEARCH 扩展可以与任意元数据标签一起使用吗？
Can the IMAP MODSEQ SEARCH extension be used with arbitrary metadata tags?
当我阅读 rfc4551, I noticed that the comment after example 15 in section 3.4（“SEARCH 中的 MODSEQ 搜索条件”）似乎是错误的。
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.
SEARCH 命令似乎根本没有搜索“/comment”。
评论是否暗示 MODSEQ 搜索条件允许搜索任意元数据更改？
通常一个完整的元数据“评论”标签可以是 /private/comment 或 /shared/comment，但看到 MODSEQ 似乎是如何设计的，您可以通过entry-type-req 参数，我想知道是否应该删除 /private 或 /shared 前缀以支持 entry-type-req 参数，从而为您留下 entry-name 的 /comment（根据下面的解释，这至少看起来与预期的示例相匹配）。
让我困惑的是，根据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 的作者发送电子邮件，但 2 位作者中的 1 位的电子邮件地址已返回给我，但已无法访问。
我想其他人也可能对 RFC 中的上述措辞有这个问题，这可能值得post到 Whosebug。
If/when 我收到了唯一可能收到我消息的作者的回复，我会 post 在答案部分。
与此同时，也许 Whosebug 上的本地 IMAP 专家有一些见解？
Alexey Melnikov 是最重要的作者，仍然可以通过同一地址联系到他。他有时回复很慢（他收到了堆积如山的邮件），但最终还是回复了。
据我所知，none 文档的作者或审阅者已经实现了 entry-name/entry-type-req 的东西，或者甚至计划实现它，所以如果其中遗漏了什么是可以理解的区域。 （我查看了它，但我认为我添加时还没有添加这个特定示例。）
我建议将 modseq 视为仅适用于每条消息，无需更精细地调整，并且仅按照 RFC 7162, not in either of the earlier documents. The example is correct in 7162.
中所述实施 CONDSTORE
4551（以及后来的 7162）将元数据限制为 /flags/…，因为协议中不存在其他元数据。预计如果另一个 RFC 添加元数据，它也会扩展 entry-flag-name 并引用 7162。我认为没有人这样做过。 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.
的更新
当我阅读 rfc4551, I noticed that the comment after example 15 in section 3.4（“SEARCH 中的 MODSEQ 搜索条件”）似乎是错误的。
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 completeIn 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.
SEARCH 命令似乎根本没有搜索“/comment”。
评论是否暗示 MODSEQ 搜索条件允许搜索任意元数据更改？
通常一个完整的元数据“评论”标签可以是 /private/comment 或 /shared/comment，但看到 MODSEQ 似乎是如何设计的，您可以通过entry-type-req 参数，我想知道是否应该删除 /private 或 /shared 前缀以支持 entry-type-req 参数，从而为您留下 entry-name 的 /comment（根据下面的解释，这至少看起来与预期的示例相匹配）。
让我困惑的是，根据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 的作者发送电子邮件，但 2 位作者中的 1 位的电子邮件地址已返回给我，但已无法访问。
我想其他人也可能对 RFC 中的上述措辞有这个问题，这可能值得post到 Whosebug。
If/when 我收到了唯一可能收到我消息的作者的回复，我会 post 在答案部分。
与此同时，也许 Whosebug 上的本地 IMAP 专家有一些见解？
Alexey Melnikov 是最重要的作者，仍然可以通过同一地址联系到他。他有时回复很慢（他收到了堆积如山的邮件），但最终还是回复了。
据我所知，none 文档的作者或审阅者已经实现了 entry-name/entry-type-req 的东西，或者甚至计划实现它，所以如果其中遗漏了什么是可以理解的区域。 （我查看了它，但我认为我添加时还没有添加这个特定示例。）
我建议将 modseq 视为仅适用于每条消息，无需更精细地调整，并且仅按照 RFC 7162, not in either of the earlier documents. The example is correct in 7162.
中所述实施 CONDSTORE4551（以及后来的 7162）将元数据限制为 /flags/…，因为协议中不存在其他元数据。预计如果另一个 RFC 添加元数据，它也会扩展 entry-flag-name 并引用 7162。我认为没有人这样做过。 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.