Subject: [MORG] Fwd: Document Action: 'IMAP ANNOTATE Extension' to Experimental RFC

From: Dave Cridland <[email-masked]>
Date: Tue, 15 May 2007 10:47:05 +0100

For those not aware of the background, this is arbitrary metadata 
attached to messages.

Put another way, it's user-defined properties on messages.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Subject: Document Action: 'IMAP ANNOTATE Extension' to Experimental RFC
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, imapext mailing list <[email-masked]>, imapext chair <[email-masked]>
Date: Mon, 14 May 2007 17:35:03 -0400
List-Id: <ietf-imapext.imc.org>

The IESG has approved the following document:

- 'IMAP ANNOTATE Extension '
   <draft-ietf-imapext-annotate-16.txt> as an Experimental RFC

This document is the product of the Internet Message Access Protocol 
Extension Working Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-16.txt

Technical Summary
 
   The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "meta data" for messages, or
   individual message parts, stored in a mailbox on the server.  For
   example, this can be used to attach comments and other useful
   information to a message.  It is also possible to attach annotations
   to specific parts of a message, so that, for example, they could be
   marked as seen or important, or a comment added.

Working Group Summary
 
   The IMAPEXT WG did a lot of good and careful work on this document. 
Very responsibly, the WG considered at the end whether this was actually
going to be implemented.  Although several client developers indicated a
strong need for annotation functionality, few server developers were
willing to commit to implementation (and deployment might be even worse).
Thus, the WG reluctantly concluded to publish this as Experimental, hoping
that some implementation experience will lead to a better understanding of
what it takes to convince server implementors to do this functionality,
along with what it takes to implement it robustly and in a decently
performant fashion.
 
Protocol Quality
 
   The IMAPEXT WG did as much work for this document as would be expected
for a Proposed Standard, including Last Calls and several individual
reviews.

   Lisa Dusseault reviewed this document for the IESG.

Note to RFC Editor

   Please add the following paragraph to the abstract.

   NEW: 
   "Note that this document was the product of a WG which had good
consensus on how to approach the problem.  Nevertheless, the WG felt it
did not have enough information on implementation and deployment hurdles
to meet all the requirements of a Proposed Standard.  The IETF solicits
implementations and implementation reports in order to make further
progress."

   Please add the following sub-section to section 7.

NEW: 7.4  Capability registration

   This document registers "ANNOTATE-EXPERIMENT-1" as an IMAPEXT
capability in http://www.iana.org/assignments/imap4-capabilities.

_______________________________________________
MORG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/morg
Note Well: http://www.ietf.org/maillist.html