RFC 6203

IMAP4 Extension for Fuzzy Search 🦋

Internet Engineering Task Force (IETF) 💜 (this is the org that writes the rules for how the internet talks to itself, lol)

Request for Comments: 6203 Author: T. Sirainen Date: March 2011 Category: Standards Track ISSN: 2070-1721 Obsoletes or updates: nothing is listed in the title block, so it doesn't say it replaces or changes any other document 🫶

Abstract

okay so this doc describes an IMAP extension that lets a server run searches with inexact matching and hand out relevancy scores to the messages it finds. it's giving "smart search" energy 🔍✨

Status of This Memo

this is an Internet Standards Track document. 🎀

it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. if you want more info on Internet Standards, check Section 2 of RFC 5741 💅

for the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6203 🌸

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. ©️💖

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. please actually read these, bestie, because they explain your rights and restrictions for this document. 🙈 Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as the Simplified BSD License describes 🧚

1. Introduction ✨

when humans search in IMAP clients, they usually want the most relevant results at the top, obviously 🙄💅. IMAP servers can do this in the most efficient way when they're free to decide internally how searches match messages. this doc describes a new SEARCH=FUZZY extension that gives you exactly that 💖

2. Conventions Used in This Document 🌈

in the examples, "C:" marks lines sent by a client connected to a server, and "S:" marks lines the server sends back to the client 🧚

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. these are the capital-letter words with serious force, so keep an eye on them 👑

3. The FUZZY Search Key 🔥

the FUZZY search key takes another search key as its argument. the server is allowed to do all its matching in an implementation-defined way for this key, including ignoring the active comparator defined by [RFC5255]. this is usually used for searching strings. for example:

   C: A1 SEARCH FUZZY (SUBJECT "IMAP break")
   S: * SEARCH 1 5 10
   S: A1 OK Search completed.

so yeah, besides messages with a subject of "IMAP break", that search might also match "broken IMAP", "IMAP is broken", or literally anything else the server thinks is a good match 🤭

this one does a fuzzy SUBJECT search but a non-fuzzy FROM search:

   C: A2 SEARCH FUZZY SUBJECT work FROM user@example.com
   S: * SEARCH 1 4
   S: A2 OK Search completed.

how the server handles multiple separate FUZZY search keys is implementation-defined. your call, server, no pressure 🙃

now the real tea ☕️: fuzzy search algorithms can change, or their results can differ from one search to the next. so the same fuzzy search with the same parameters might give different results for 1) the same user at different times, 2) different users searching at the same time, or 3) different users searching at different times. a fuzzy search might even adapt to a user's habits to give more relevant results (a "learning" approach) 🧠. operational stuff like load balancing can cause differences too. so clients asking for "fuzzy" really are requesting results in a not-necessarily-deterministic way, and they need to warn the user about that. no surprises, babe 💜

4. Relevancy Scores for Search Results 💯

okay so servers SHOULD assign a search relevancy score to each matched message when the FUZZY search key is given. scores run from 1-100, where 100 is the highest relevancy. the relevancy scores SHOULD use the full 1-100 range so clients can show them to users in a meaningful way, like as a percentage 📊✨

relevancy is about how relevant the matched message is to the search, which isn't always the same as how precisely it matched 🎯. for example, a message whose subject fuzzily matches the search string might score higher than a message that had the exact string buried in the middle of a sentence in its body. when multiple search keys match fuzzily, how the score is calculated is server-dependent 🤷‍♀️

if the server also advertises the ESEARCH capability defined by [ESEARCH], you can grab the scores with the new RELEVANCY return option for SEARCH:

   C: B1 SEARCH RETURN (RELEVANCY ALL) FUZZY TEXT "Helo"
   S: * ESEARCH (TAG "B1") ALL 1,5,10 RELEVANCY (4 99 42)
   S: B1 OK Search completed.

in that example, the server would treat "hello", "help", and other similar strings as fuzzy matches for the misspelled "Helo" 💀🫶

the RELEVANCY return option MUST NOT be used unless a FUZZY search key is also given. also, SEARCH results aren't sorted by relevancy, so if you want that, you need SORT 🚫

5. Fuzzy Matching with Non-String Search Keys 🌸

fuzzy matching isn't only for strings. all search keys SHOULD be matched fuzzily, but what that means for each key is up to server implementations to decide. that includes deciding fuzzy matching is meaningless for a certain key and falling back to exact matching. a few suggestions are below 💖

Dates: a typical example is when a user wants to find a message "from Dave about a week ago". a client could do that with SEARCH FUZZY (FROM "Dave" SINCE 21-Jan-2009 BEFORE 24-Jan-2009). the server could return messages outside the date range, but the further away a message is, the lower its relevancy score 📅

Sizes: these should be handled similarly to dates 📦. if a user wants "about 1 MB attachments", the client could send SEARCH FUZZY (LARGER 900000 SMALLER 1100000). again, the further the message size is from the range, the lower the relevancy score 🦋

Flags: if the other search criteria match, the server could return messages that don't have the specified flags set, but with lower relevancy scores. SEARCH SUBJECT "xyz" FUZZY ANSWERED could be useful if the user thinks the message has the ANSWERED flag set but isn't sure 🙈

Unique Identifiers (UIDs), sequences, modification sequences: these are examples of keys where exact matching probably makes sense. alternatively, a server might choose to expand a UID range by 5% on each side, which is kinda iconic 👑

to be continued in part 2!! 💖🧚

11. Normative References ✨

Okay bestie, here's the reference list that backs up the whole spec 📚🫶

• [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 🧩
• [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008. 🎀
• [ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006. 💖
• [IMAP-ABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006. 🦋
• [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
• [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. 🌸
• [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008. 🌈
• [SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008. 💅

---

Author's Address ✨

Timo Sirainen

EMail: tss@iki.fi 💜