IMAP UNAUTHENTICATE Extension for Connection Reuse
draft-ietf-extra-imap-unauth-01

[Ballot comment]
This mechanism seems useful. Thanks to the author for sticking with it.

I support Martin's comment.

I also have a tiny editorial nit:

§8:

>  The original IMAP state machine was designed to allow a server
>  implementation approach where each IMAP authentication identity
>  matches an operating system identity and the server revokes all
>  administrative privilege onces authentication completes.

Typo: "once"

[Ballot comment]
§2: There are a few instances of lower case 2119 keywords. Please consider using the boilerplate from RFC 8174 instead.

§4.2, first paragraph, 2nd sentence: The two MAYs seem more like statements of fact rather than new normative permissions.

[Ballot comment]
I was surprised to see normative language in this text in 4.2 since this behavior is specified elsewhere, not here:

When a TLS [RFC5246] security layer is negotiated either via the
  STARTTLS command or use of the imaps port [RFC6186], IMAP servers MAY
  be configured to request a client certificate and IMAP clients MAY
  provide one.

[Ballot comment]
Please consider using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate; there
seems to be at least one usage of a lowercase keyword.

I do not remember seeing a response to the secdir review, which raises an issue that is probably
worth addressing (even if it is largely editorial).

I have a few other comments/questions, that happen by chance to all occur within Section 3.

  This command directs the server to reset all connection state, except
  for state at the TLS [RFC5465] layer.

5465 is IMAP NOTIFY, and a short Hamming distance from 5246 (TLS
1.2).  Though I note that TLS 1.3 is in the RFC Editor's queue...

  If a mailbox was selected, the mailbox ceases to be selected but no
  expunge event is generated.  If a SASL [RFC4422] security layer was
  active, it terminates immediately after the server sends the CRLF
  following the OK response.  For the client, it terminates immediately
  after the CRLF following the UNAUTHENTICATE command.

"terminate" applies only to outgoing messages, presumably?  (Should
this be made more explicit?)  A similar thing applies to COMPRESS as
enumerated in Section 4.1.

  Servers MAY choose to advertise the UNAUTHENTICATE capability only
  after authentication has completed.  As a result, clients need to
  issue an IMAP CAPABILITY command after authentication in order to
  determine the availability of UNAUTHENTICATE.

Is this because the ability to reset state may depend on the
authentication mechanism used?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-extra-imap-unauth-00. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Internet Message Access Protocol (IMAP) Capabilities Registry located at:

http://www.iana.org/assignments/imap-capabilities/

a single, new registration is to be made as follows:

Capability Name: UNAUTHENTICATE
Reference: [ RFC-to-be ]

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-05-21):

From: The IESG
To: IETF-Announce
CC: draft-ietf-extra-imap-unauth@ietf.org, extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IMAP UNAUTHENTICATE for Connection Reuse) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'IMAP
UNAUTHENTICATE for Connection Reuse'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This specification extends the Internet Message Access Protocol
  (IMAP) to allow an administrative client to reuse the same IMAP
  connection on behalf of multiple IMAP user identities.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for draft-extra-imap-unauth

1. This document is being requested as an Internet Standard because it
extends an existing Internet Standard (RFC3501).  The request type is
indicated in the title page header.

2.

Technical Summary

  This spec extends IMAP to add a symetrical way to return to
  UNAUTHENTICATED state from an AUTHENTICATED connection.

Working Group Summary

  This spec was accepted at the IETF101 meeting.  It has been around
  for years, but there was nowhere to submit it.

Document Quality

  The specification has been in use in at least one site for multiple
  years.  The integrations with various IMAP extensions have been very
  carefully specified.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov


3. The Document Shepherd has read the document through in detail and
is happy that it's easy to implement.

4. It would be good to see another couple of reviews for this document
during the last call period.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. There have been no IPR disclosures for this spec.

8. There have been no IPR disclosures for this spec.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool found no issues.

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The only IANA request is an additional IMAP capability.

18. There is no expert review required.

19. The formal sections are simple enough that eyeball reading
was sufficient to validate them.