[Extra] IMAP4rev2 body search

[Arnt Gulbrandsen <[e-mail]>]

Hi,

a discussion the other day^Wweek jars in my mind.

I think we should underspecify the BODY search key more clearly. All it now 
says is "matches if contains", which is IMO correct (it matches the running 
code) but underspecified and vague. I think we ought to eliminate the 
vagueness, and propose the following explicit underspecification:

---

Messages that contain the specified string in the body of the message.

The server SHOULD decdode the content-transfer-encoding, so that a message 
matches independent of its content-transfer-encoding. Apart from that rule, 
this specification explicitly allows much server behaviour that has been 
common in IMAP4rev1 servers, including:

Most servers interpret "contains" on a character level, ie. "BODY range" 
matches a message that contains the word "orange", but some servers 
interpret it on a token or word level, ie. "BODY range" does not match a 
message that contains "orange", because "orange" is one token. It may 
however match a message that contains "ranges", if the server uses stemming 
(and perhaps language detection).

Some servers search only in text/plain. Others also search in other types, 
for example Microsoft Word and PDF attachments.

Some servers search HTML on a source level ("BODY range" does not match 
ra­nge), others search HTML as normally displayed ("BODY range" matches 
ra­nge).

Most servers interpret the messages and search terms independent of 
encoding, such that a message that uses charset=iso-8859-8 may match a 
search term that uses UTF-8. However, not even this is required.

Rationale: IMAP4rev1 servers vary in the kind and quality of their search 
implementation. This document chooses to avoid adding requirements on the 
business logic in such servers.

---

(I'm open to changing any of this. IMO any variant is good, and good is 
better than best. I'd prefer that quarrelsome people can't beat each other 
over the head with the RFC, that's all.)

Arnt