代码之家  ›  专栏  ›  技术社区  ›  jstedfast

IMAP MODSEQ搜索扩展能否与任意元数据标记一起使用?

  •  1
  • jstedfast  · 技术社区  · 7 年前

    当我在看书的时候 rfc4551 section 3.4 (“搜索中的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
    

    在上面的示例中,任何消息的消息编号 在属性的“value”属性中包含字符串“IMAP4” “/comment”条目,且mod序列等于或大于 搜索中返回的“\Draft”标志的值超过620162338 结果。

    SEARCH

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

    /private/comment /shared/comment 似乎是这样设计的,您可以通过 entry-type-req 参数,我想知道的是 /private /shared 前缀应该去掉,以支持 参数,从而留给您一个 entry-name 属于 /comment (根据下面的解释,这似乎至少与预期的示例相符)。

    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.
    

       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
    

    /flags/<flagname> .

    我已经给这封RFC的作者发了电子邮件,但两位作者中有一位的电子邮件地址已经作为死胡同返回给我了。

    我想其他人也可能对RFC中的上述措辞有疑问,可能值得在这里发布给StackOverflow。

    同时,也许一位关于StackOverflow的本地IMAP专家有一些见解?

    1 回复  |  直到 7 年前
        1
  •  1
  •   arnt    7 年前

    阿列克谢·梅尔尼科夫是最重要的作家,他仍然可以在同一个地址联系到。他有时回复得很慢(他收到了堆积如山的邮件),但最终还是回复了。

    据我所知,该文件的作者或审阅者中没有一人实施了 entry-name/entry-type-req 所以,如果在这方面遗漏了什么,这是可以理解的(我回顾了它,但我认为在我回顾的时候还没有添加这个特定的示例。)

    RFC 7162 is correct in 7162 .

    4551(以及后来的7162)将元数据限制为 /flags/… 因为协议中不存在其他元数据。预计如果另一个RFC添加元数据,它也将扩展 entry-flag-name 请参考7162。我认为没有人这样做过。对其中一个的更新 RFC 5257 5464 可能,但这些扩展没有引起太多兴趣,也不太可能更新。在这个大方向上的工作更有可能是基于 JMAP .