Re: my 2 cents worth

Steve Dorner <> Mon, 06 June 1994 16:35 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa04940; 6 Jun 94 12:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04936; 6 Jun 94 12:35 EDT
Received: from PO3.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa12771; 6 Jun 94 12:35 EDT
Received: (from postman@localhost) by (8.6.7/8.6.6) id MAA16202; Mon, 6 Jun 1994 12:32:32 -0400
Received: via switchmail for; Mon, 6 Jun 1994 12:32:31 -0400 (EDT)
Received: from via qmail ID </afs/>; Mon, 6 Jun 1994 12:30:51 -0400 (EDT)
Received: from ( []) by (8.6.7/8.6.6) with SMTP id MAA16080 for <>; Mon, 6 Jun 1994 12:30:42 -0400
Received: from by with SMTP id AA18014 (5.67b8/IDA-1.5 for <>); Mon, 6 Jun 1994 11:30:14 -0500
Received: from [] by with SMTP id AA08589 (5.67b/IDA-1.5 for <>); Mon, 6 Jun 1994 11:30:27 -0500
X-Sender: sdorner@
Message-Id: <aa18fae9270210166194@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 6 Jun 1994 11:30:09 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Dorner <>
Subject: Re: my 2 cents worth

At 10:28 AM 6/6/94, Ian Duncan wrote:
>good RFC authorship practice. I suggest words documenting the orginal
>intent for LAST to provide a checkpoint for persistent client connections
>would be good sugar.

Fine by me.

>My gut feeling is that words saying "SHOULD reset/SHOULD NOT update" with
>a nod and mumble about excepting non-standard use is reasonable.

Fine by me.  As I said, I won't argue this anymore; we'll just do what we must.

>I'm suggest we consider extending the result
>of the LIST command to support this instead of extending the commands.
>... There's fairly strong language in both of the spec's I read
>discouraging this kind of thing

Given the strength of the wording in all the previous RFC's, I don't think
the function should be piggy-backed on list.  I think another command is
the right thing to do; it's less hassle for everyone.

>Finally a couple of other items I picked up in my reading. TOP has an
>index origin of 1. Even 1081 is fairly clear about this, albeit it's read
>into the example.

It's clear that the first line of the body is line 1.  It's not at all
clear (and private mail from some time ago confirmed that Marshall didn't
believe) that asking for 0 lines of the body is supposed to be out of

However, since there are servers that barf on 0, clients should use 1, not
0, if they want headers.  Whether that means we codify 1 into the RFC, or
add a warning, or just ignore the issue, I dunno.  Like you said, no big

>reported by LIST/STAT should be accurate, particularly the size from LIST
>and # of messages from STAT.

I think requiring accuracy provides no functionality, and carries with it
not insignificant resource expense for some servers.  But I understand the
reluctance to allow cheating in the RFC.

Let's leave it the way it stands; do not put in language to allow
approximation, but neither add language that makes it seem that to-the-byte
accuracy in those numbers is a matter of life or death.

This amounts to a small wink at server authors who are challenged in this

>I'd be prepared to accept a very relaxed
>accuracy for the size of the total store reported by STAT with a
>suggestion that error an over estimation, but less than an order of

I support that.

Steve Dorner, Qualcomm Incorporated
 "There's nothing wrong with you that can't be cured
  with a little Prozac and a polo mallet." - Woody Allen