IMAP4 Extension for Fuzzy Search
Note: This ballot was opened for revision 03 and is now closed.
Alexey Melnikov Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
In reading the text there are a number of cases where "a" or "the" is missing in conjunction with "server" For example: Old IMAP protocol extension enabling server to New IMAP protocol extension enabling a server to ====== This text looks redundant: Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to email@example.com. ======= From the security section: Implementation of this extension might enable a denial-of-service attack if the implementation isn't careful to prevent them. I am not sure that the implementer can resist a DoS attack, they can only implement this feature to be resistant to one. Implementations should test at least the behavior of large messages that contain very long words and/or unique random strings. I think that the implementers need to test the feature ON large messages
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Lars Eggert) No Objection
INTRODUCTION, paragraph 5: > Note > A revised version of this draft document will be submitted to the RFC > editor as a Proposed Standard for the Internet Community. Discussion > and suggestions for improvement are requested, and should be sent to > firstname.lastname@example.org. This section should be removed. Section 4., paragraph 1: > Servers SHOULD assign a search relevancy score for each matched > message when the FUZZY search key is given. Relevancy scores are > given in range 1-100, where 100 is the highest relevancy. The > relevancy scores SHOULD use the full 1-100 range, so that clients can > show them to users in a meaningful way, such as a percentage value. Any particular reason why the range isn't 0-100? At least in my mind, a relevance of "1" still means "a tiny bit relevant", which is not "not relevant."
(Adrian Farrel) (was Discuss) No Objection
(David Harrington) No Objection
(Russ Housley) (was Discuss, No Objection, Discuss) No Objection
(Tim Polk) No Objection
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
(Robert Sparks) (was Discuss) No Objection
I've cleared based on the RFC Editor note. There is no new discuss or comment text below. Previous Discuss text: ----- The draft should be a little more clear that different servers implementations are very likely to return a different set of results for the same search. A user should net expect the results of a search to be consistent over time, even when using the same service (since the service provider may choose a new implementation, or upgrade their existing implementation, resulting in a completely different "fuzzy" algorithm being applied). Also, service load might be distributed over several server instances (using multiple SRV records perhaps) - if the different instances are not running identical algorithms, search results will be different. Should the document constrain a given instance of a server to produce the same results when given the same search? I suggest not, given the observations above. ---- Previous Comment Text ---- Consider also pointing out that a user may end up with different search results when using a dedicated imap client on their user device than when using a web interface into the same email store. Has the group considered adding way for the client to influence the level of fuzziness? Does the current mechanism make it hard to add that later if the group decided it was useful?