STATUS-IN-LIST Open issue: If server runs into unexpected trouble getting STATUS info: a)Don't return STATUS for the mailbox and return NO for LIST reply. b)Don't return STATUS for the mailbox but return OK for LIST reply. c)Return STATUS without any parameters. d)Something else? C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN)) S: * LIST () "." "INBOX S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16) S: * LIST () "." "foo S: A01 OK List completed.

Sort display Open issue: Should there be DISPLAYTO sort-key, and how should it work? a)Use first address b)Use other addresses somehow?

INTHREAD Open issue: How to encode Message-ID? a)RFC 5322 format with no encoding: SEARCH b)RFC 5322 format in IMAP string: SEARCH " c)Any format in IMAP string: SEARCH " d)Any format in IMAP string without <>: SEARCH "msgid"

Address search Set of address fields in ANY? Set of fields has changed little in last 30 years -> won't change anytime soon? a)Arnt's preferred option: Just the ones in RFC b)Fixed extension: Also the fields that have shown up and show some use in the wild: List-Unsubscribe, List-Post, List-Id, Mail-Copies-To, Mail- Followup-To, some variant of X-Abuse-To. c)Arbitrary extension I: The 5322 set now, plus whatever the WG adds later. d)Arbitrary extension II: 5322 plus whatever the server implementor wants. a UID SEARCH ADDRESS ANY a UID SEARCH DOMAIN ("From" "Sender" "Reply-To") example.com

Address search Searching non-toplevel messages? (message/rfc822 forwards, digests, etc.) a)Only search the top-level. b)MUST top-level, MAY others c)MUST all. d)New option to specify what is wanted? Make it more generic to allow searching other headers too? (new extension?)

Address search Editorial, general: Fallbacks or not? a)Not include fallbacks. b)Include fallbacks in most documents, except where obvious. c)Try it once and see what happens.

Fuzzy search C: A SEARCH RETURN (RELEVANCY ALL) FUZZY (TEXT "Helo" SMALLER 500) FROM iki.fiiki.fi S: * ESEARCH (TAG "A02") ALL 1,5,10 RELEVANCY ( ) S: A OK Search completed. What to do about non-string matching search criteria? a)MUST match exactly b)SHOULD match fuzzily, with specific recommendations given (e.g. size within 10%) c)Servers can do whatever they want

Fuzzy search Relevancy scores are meaningful only when compared to other relevancy scores from the same server. – Is this ok? Search engines don't seem to be giving very useful scores. Even comparing between two different searches might not be useful.

Fuzzy search RELEVANCY shouldn't be used unless FUZZY search key is used. – Does someone really want non-fuzzy relevancy?

Views vs multi-mailbox search (if we have time and interest) + Easy to implement by existing clients. May not even require any changes. + Reduces roundtrips when fetching messages + No special error handling code requires if mailboxes change (deleted, renamed,..) between SEARCH and SELECT+FETCH. - Difficulties in getting a design that everyone is happy about.