Question

当我阅读rfc4551时，我注意到section 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” “ / comment”条目，并且mod序列等于或大于搜索中返回了比620162338更大的“ \ Draft”标志结果。

SEARCH命令似乎根本没有搜索“ / comment”。

评论是否暗示MODSEQ搜索条件允许搜索任意元数据更改？

通常，完整的METADATA“ comment”标签将是/private/comment或/shared/comment，但可以看出MODSEQ的设计方式似乎使您可以指定{ 1}}参数，我想知道是否应该删除entry-type-req或/private前缀，而推荐使用/shared参数，从而为您保留entry-type-req entry-name（根据下面的解释，它似乎至少与预期的示例相匹配）。

令我困惑的是基于3.4节中的定义：

/comment

似乎可以证实我对能够使用任意元数据标签的怀疑，但是当我阅读实际的ABNF语法时，我会看到：

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。

我已经通过电子邮件发送了该RFC的作者，但是2位作者中的1位的电子邮件地址已经作为死胡同寄给我。

我认为其他人也可能对RFC中的上述措辞有此疑问，可能值得在此处发布到StackOverflow。

如果/当我从剩下的可能收到我的消息的作者那里收到回音时，我会将其发布在答案部分。

与此同时，也许StackOverflow的本地IMAP专家有一些见识？

Answer 1

阿列克谢·梅尔尼科夫（Alexey Melnikov）是最重要的作者，应该在同一地址仍可与他联系。有时他的回复速度很慢（收到大量邮件），但最终还是会回复。

据我所知，文档的作者或审阅者还没有实现entry-name/entry-type-req东西，甚至没有计划实现它，因此，如果在该领域遗漏了某些东西，这是可以理解的。（我进行了审查，但我认为当我添加此特定示例时还没有添加。）

我建议将modseq视作仅适用于每条消息，而对其进行细微调整，并建议仅按照RFC 7162中的描述实施CONDSTORE，而在之前的两个文档中均不如此。示例is correct in 7162。

4551（及以后的7162）将元数据限制为/flags/…，因为协议中不存在其他元数据。可以预期，如果另一个RFC添加元数据，它也会扩展entry-flag-name并引用7162。我认为没有人这样做。可以对RFC 5257或5464进行更新，但是这些扩展引起了人们的极大兴趣，并且不太可能进行更新。朝这个总体方向发展的工作更有可能基于JMAP。

IMAP MODSEQ SEARCH扩展可以与任意元数据标签一起使用吗？

1 个答案: