Когда я читал более rfc4551 , я заметил, что комментарий после примера 15 в разделе 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
В приведенном выше примере номера сообщений любых сообщений, содержащих строку «IMAP4» в атрибуте «value» записи «/ comment» и имеющихпоследовательность результатов, равная или больше чем 620162338 для флага «\ Draft», возвращается в результатах поиска.
Команда SEARCH вообще не отображается для поиска «/ comment».
Подразумевает ли комментарий, что критерий поиска MODSEQ позволяет искать произвольные изменения метаданных?
Обычно полный тег METADATA "comment" будет иметь значение /private/comment или /shared/comment, ноВидя, как MODSEQ выглядит так, что вы указываете private против shared через параметр entry-type-req, мне интересно, если идея заключается в том, что префикс /private или /shared должен быть удален в пользу entry-type-reqпараметр, таким образом, leavinдайте вам 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 по электронной почте, но адрес электронной почты 1 из 2 авторов уже вернулся ко мне в тупик.
Я подумал, что у других также может возникнуть этот вопрос по поводу приведенной выше формулировки в RFC, что, возможно, стоит опубликовать здесь в StackOverflow.
Если / когда я получу ответ от единственного оставшегося автора, который, возможно, получил мое сообщение, Я опубликую это в разделе ответов.
А пока, может быть, какой-то эксперт по IMAP по StackOverflow имеет некоторое представление?