Protocol Action: 'IMAP4 Extension for Fuzzy Search' to Proposed Standard (draft-ietf-morg-fuzzy-search-03.txt)

The IESG <iesg-secretary@ietf.org> Fri, 07 January 2011 17:25 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@core3.amsl.com
Delivered-To: ietf-announce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04223A6935; Fri, 7 Jan 2011 09:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.149
X-Spam-Level:
X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOGF1I8XVo+0; Fri, 7 Jan 2011 09:25:35 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E078D3A6937; Fri, 7 Jan 2011 09:25:34 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'IMAP4 Extension for Fuzzy Search' to Proposed Standard (draft-ietf-morg-fuzzy-search-03.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 3.10
Message-ID: <20110107172534.27184.20699.idtracker@localhost>
Date: Fri, 07 Jan 2011 09:25:34 -0800
Cc: morg chair <morg-chairs@tools.ietf.org>, morg mailing list <morg@ietf.org>, Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2011 17:25:36 -0000

The IESG has approved the following document:
- 'IMAP4 Extension for Fuzzy Search'
  (draft-ietf-morg-fuzzy-search-03.txt) as a Proposed Standard

This document is the product of the Message Organization Working Group.

The IESG contact persons are Alexey Melnikov and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-morg-fuzzy-search/



Technical Summary

   This document describes an IMAP protocol extension enabling servers to
   perform searches with inexact matching and assigning relevancy scores
   for matched messages.  This allows more flexible searching, as well as
   optimization in server processing.

Working Group Summary 

   One working group participant thinks there are too many IMAP
   extensions already, and we don't need this one.  That view has been
   considered, but several working group participants plan to implement
   this, and some already have.  There is broad agreement in the working
   group that this extension has value.

Document Quality 

   At least two working group participants have implemented this,
   and others have said they plan to.  Many working group
   participants have reviewed and discussed it; none merit special
   mention.

Personnel

   Barry Leiba is the document shepherd. Alexey Melnikov is the 
   Responsible Area Director.

RFC Editor Note

Please add the following paragraph at the end of section 3:

  Fuzzy search algorithms might change, or the results of the algorithms
  might be different from search to search, so that fuzzy searches with
  the same parameters might give different results at different times, for
  different users, or both.  For example, a fuzzy search might adapt to a
  user's search habits in an attempt to give more relevant results (in a
  "learning" manner). Such differences can also occur because of
  operational decisions, such as load balancing.  Clients asking for
  "fuzzy" really are requesting search results in a not necessarily
  deterministic way, and need to give the user appropriate warning about that.

In Section 4, please update the 2nd line of the example to read:

OLD:

   S: * ESEARCH (TAG "B2") ALL 1,5,10 RELEVANCY (4 99 42)

NEW:
   S: * ESEARCH (TAG "B1") ALL 1,5,10 RELEVANCY (4 99 42)

(i.e. the TAG value should be "B1", not "B2")


Please rename the title of the section 6 to read:

OLD:
6.  Extensions to SORT
NEW
6.  Extensions to SORT and SEARCH


In Section 6, please replace the 6th paragraph to read:

OLD:
  To limit the number of returned messages, use the PARTIAL return
  option.  For example this returns the 10 most relevant messages:

NEW:
  Furthermore, if the server advertises the CONTEXT=SORT (or CONTEXT=SEARCH)
  capability, then the client can limit the number of returned messages to a SORT (or a
  SEARCH) by using the PARTIAL return option.  For example this returns
  the 10 most relevant messages:

In Section 8, 1st paragraph:

OLD:
   Implementation of this extension might enable a denial-of-service
   attack if the implementation isn't careful to prevent them. Fuzzy
   search engines are often complex with non-obvious disk space, memory
   and/or CPU usage patterns.  Implementors should test at least the
   behavior of large messages that contain very long words and/or unique
   random strings.  Also very long search keys might cause excessive
   memory or CPU usage.

NEW:
   Implementation of this extension might enable denial-of-service
   attacks against server resources.  Servers MAY limit the resources that
   a single search (or a single user) may use. Additionally, implementors
   should be aware of the following: Fuzzy
   search engines are often complex with non-obvious disk space, memory
   and/or CPU usage patterns.  Server implementors should at least test the
   fuzzy-search behavior with large messages that contain very long words
   and/or unique random strings. Also very long search keys might cause
   excessive memory or CPU usage.