Re: a different tack

John Gardiner Myers <jgm+@cmu.edu> Tue, 14 June 1994 21:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10117; 14 Jun 94 17:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10113; 14 Jun 94 17:44 EDT
Received: from ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa16614; 14 Jun 94 17:44 EDT
Received: (from postman@localhost) by andrew.cmu.edu (8.6.7/8.6.6) id RAA15864; Tue, 14 Jun 1994 17:41:27 -0400
Received: via switchmail; Tue, 14 Jun 1994 17:41:27 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.UhzWDu:00WBw8:rk5P>; Tue, 14 Jun 1994 17:41:14 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail ID </afs/andrew.cmu.edu/usr7/jm36/.Outgoing/QF.YhzWDiO00WBwE0kyEa>; Tue, 14 Jun 1994 17:41:02 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Tue, 14 Jun 1994 17:40:59 -0400 (EDT)
Message-ID: <khzWDfS00WBwE0ky4t@andrew.cmu.edu>
Date: Tue, 14 Jun 1994 17:40:59 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: John Gardiner Myers <jgm+@cmu.edu>
To: POP3 IETF Mailing List <ietf-pop3+@andrew.cmu.edu>
Subject: Re: a different tack
In-Reply-To: <2656.bill.simpson@um.cc.umich.edu>
References: <2656.bill.simpson@um.cc.umich.edu>
Beak: is Not

"William Allen Simpson" <bill.simpson@um.cc.umich.edu> writes:
> In my experience, upgrading the Standardization status of a protocol
> means we _should_ add implementation detail, but _not_ add new features.

You seem to be assuming that our purpose is to upgrade the
standardization status of the protocol.  It's not--our purpose is to
reach some sort of agreement about the loose ends that have been
identified as being tied and to make a revised document that reflects
the agreed-on changes.

What this means in terms of standardization status is up to the IESG.
I do note that between RFC's 1225 and 1460, the RPOP command was
removed and the APOP command was added, yet the protocol remained at
the "Draft Standard" state.

> So, I suggest that we add implementation history about what people have
> really done in the past, together with a "recommendation" as to what the
> "best" solution would be.  We can't force anyone, we have no protocol
> police.  Writing down the goods and bads is our best insurance.

With that argument, RFC 1123 et. al. shouldn't have used the term
"MUST".

It is within the purview of protocol documents to say what is
"correct", not just what is "best".

> BTW, I like UIDL.  I would prefer it to go in a separate extensions
> document, which everybody just implements, and it advances on its own.

I think there are people who would legitimately object to POP3 going
to "Standard" were it not to address the problems that UIDL solves.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up