Protocol Action: POP3 Extension Mechanism to Proposed Standard

The IESG <iesg-secretary@ietf.org> Mon, 02 November 1998 16:55 UTC

Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA20125 for ietf-123-outbound.10@ietf.org; Mon, 2 Nov 1998 11:55:02 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA19873; Mon, 2 Nov 1998 11:43:41 -0500 (EST)
Message-Id: <199811021643.LAA19873@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ietf-pop3ext@imr.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: POP3 Extension Mechanism to Proposed Standard
Date: Mon, 02 Nov 1998 11:43:41 -0500
Sender: scoya@ns.cnri.reston.va.us


The IESG has approved the Internet-Draft 'POP3 Extension Mechanism'
<draft-gellens-pop3ext-09.txt> as a Proposed Standard.  This document
has been reviewed in the IETF but is not the product of an IETF Working
Group.

Note that version -05 was last called, and the changes to -09 represents
the results from the last call.

The IESG contact persons are Keith Moore and Patrik Faltstrom.

Technical Summary

The extension specify a new command, with which the client can detect the
behaviour of the server. I.e. in the POP standard [RFC 1939], there are
some alternatives for the server, which the client is interested in
discovering. A mechanism is also defined for extending the error codes
which makes the client able to give better responses to the end user when
the server sends an error.

Note section 7, and the IESG note (see below) which explicitely says that
this extension mechanism does not endorse future extensions to the POP
protocol. This extension is accepted just because the client in todays
implementations of different versions of POP need to know more about the
behaviour of the server.

Working Group Summary

This is not a protocol of a working group, but it has been discussed on
several mailing lists which handles POP3, SMTP and MIME.

There is a strong support from the market to make it possible for the
client to negotiate what extensions to POP3 the server can handle. It is
also interesting to see how various POP3 issues are implemented
(policy-issues). It is though the case that some people very strongly
opposes this (and all other) extensions because it moves the POP3 protocol
from being very simple, to do one purpose only, towards the complex
solution which we are supposed to use IMAP for.

It is though the descrision that this specific extension can be added, for
the purpose to make it possible for a POP3 server to express policy
descisions to a client.

Protocol Quality
This protocol has been reviewed for the IESG by Patrik Faltstrom. It makes
it possible for a POP3 server to express policy descisions for a client,
and by doing that make operations of POP3 server/client networks easier.
See the IESG note below.


Note to the RFC editor:

Please add the following IESG note:

This extension to the POP3 protocol is to be used by a server to express
policy descisions taken by the server administrator. It is not an
endorsement of implementations of further POP3 extensions generally. It is
the general view that the POP3 protocol should stay simple, and for the
simple purpose of downloading email from a mail server. If more complicated
operations is needed, the IMAP protocol [RFC 2060] should be used. First
paragraph of section 7 should be read very carefully.