Last Call2: IMAP4 to Proposed Standard

IESG Secretary <iesg-secretary@CNRI.Reston.VA.US> Tue, 01 November 1994 16:42 UTC

Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06146; 1 Nov 94 11:42 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17532; 1 Nov 94 11:42 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06119; 1 Nov 94 11:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05975; 1 Nov 94 11:38 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17215; 1 Nov 94 11:38 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05969; 1 Nov 94 11:38 EST
To: IETF-Announce:;
cc: imap@cac.washington.edu
Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary@CNRI.Reston.VA.US>
Subject: Last Call2: IMAP4 to Proposed Standard
Date: Tue, 01 Nov 1994 11:37:56 -0500
X-Orig-Sender: jstewart@CNRI.Reston.VA.US
Message-ID: <9411011138.aa05969@IETF.CNRI.Reston.VA.US>

On 9 September the IESG announced the Protocol Action "IMAP4 to
Proposed Standard."  Subsequently, the working group found a problem
with the protocol.  The new Internet-Draft, "INTERNET MESSAGE ACCESS
PROTOCOL - VERSION 4" <draft-ietf-imap-imap4-06.txt>, contains fixes
for the problem; the changes between the '05' and '06' versions are:

1) Changes in the Internet-Draft header wording to correspond to the
   latest decrees.
2) Removal of the use of the verb ``to canonicalize.''
3) Clarification that unique identifiers are unsigned, non-zero,
   32-bits, not infinite precision.
4) Addition of a unique identifier validity number, to label whether
   or not unique identifiers from the previous session are still
   valid (it was discovered that it is not always possible to have
   permanent unique identifiers, and a means was needed to tell
   clients they've been screwed).
5) Clarification of \Noselect names (non-terminal hierarchical
   names); they appear when the % wildcard is used and do not get a
   \Marked or \Unmarked.
6) Certain numbers that can never be zero are marked as such in the
   BNF.
7) Deleted security note about doing a second CAPABILITY command
   after authentication (this was the remnants of an idea that was
   rejected by the working group prior to draft 05, but wasn't fully
   removed from draft 05).

This Last Call2 is for the updated specification.

The IESG has received a request from the Internet Message Access
Protocol Working Group to consider:

  o "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4"
    <draft-ietf-imap-imap4-06.txt>

  o "IMAP4 Authentication mechanisms" <draft-ietf-imap-auth-01.txt>

for the status of Proposed Standard.  They have also asked the IESG to
consider recommending to the RFC Editor that:

  o "IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS"
    <draft-ietf-imap-compat-00.txt>
 
  o "DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4"
    <draft-ietf-imap-model-00.txt>
 
be published as Informational RFCs.
 
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by
15 November.

IESG Secretary