Re: [Extra] IMAP4rev2 body search

[Brandon Long <[e-mail]>]

On Fri, Jan 17, 2020 at 6:56 AM Arnt Gulbrandsen <[e-mail]>
wrote:

> 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&shy;nge), others search HTML as normally displayed ("BODY range"
> matches
> ra&shy;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.)
>

This seems overly wordy, almost more like a bcp or something instead of the
spec itself.

I'm not opposed to it, but I wouldn't call myself an expert on the fine
craft of spec writing either.

Can we give intent itself?  Ie, that there's several ways to implement
search (substring, word based)
and to interpret body (raw text, extracted from formatting, or even ocr)

Brandon

Brandon