Skip to main content

IMAP Extension for only using and returning UIDs
draft-ietf-extra-imap-uidonly-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-extra-imap-uidonly@ietf.org, extra-chairs@ietf.org, extra@ietf.org, murch@fastmailteam.com, rfc-editor@rfc-editor.org, superuser@gmail.com
Subject: Document Action: 'IMAP Extension for only using and returning UIDs' to Experimental RFC (draft-ietf-extra-imap-uidonly-08.txt)

The IESG has approved the following document:
- 'IMAP Extension for only using and returning UIDs'
  (draft-ietf-extra-imap-uidonly-08.txt) as Experimental RFC

This document is the product of the Email mailstore and eXtensions To Revise
or Amend Working Group.

The IESG contact persons are Murray Kucherawy and Orie Steele.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-uidonly/


Ballot Text

Technical Summary

   The UIDONLY extension to the Internet Message Access Protocol (RFC
   3501/RFC 9051) allows clients to enable a mode in which information
   about mailbox changes is returned using only UIDs.  Message numbers
   are not returned in responses, and can't be used in requests once
   this extension is enabled.  This helps both clients and servers to
   reduce resource usage required to maintain a map between message
   numbers and UIDs.

Working Group Summary

   Broad agreement.

   This document went through several iterations based on feedback from
   multiple people both on the mailing list and during IETF meetings.
   The reviewers combine vast IMAP implementation and operational experience.

   The Last Call failed to identify RFC 3501 as a normative downward reference.
   That document, though Informational, has been the IMAP standard for many
   years, so I don't expect this oversight to be contentious, and it should be
   added to the downref registry.  However, I'll repeat the Last Call with
   that correction if there are any objections.


Document Quality

   There is a server implementation from a major vendor (Yahoo!) deployed and
   interoperating with client implementations from Google, Microsoft, and
   FairEmail.

   Another server implementation (Cyrus) and a client implementation
   (Isode) are being developed.

   None of the existing implementations are reported in this document but
   the source code of the Cyrus implementation is available on GitHub.

   No particular additional reviews are warranted.

Personnel

   The Document Shepherd for this document is Kenneth Murchison. The
   Responsible Area Director is Murray Kucherawy.

RFC Editor Note