From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4666794C.8040308@conducive.org>
Date: Wed,  6 Jun 2007 05:07:24 -0400
From: W B Hacker <wbh@conducive.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
	rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] my previous note on vf
References: <13426df10706022014k240d2a96h12dea0548fa6a093@mail.gmail.com>,
	<466238C4.1000600@conducive.org> <46656533.E70F1036@null.net>
In-Reply-To: <46656533.E70F1036@null.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 7a29ce80-ead2-11e9-9d60-3106f5b1d025

Douglas A. Gwyn wrote:
> W B Hacker wrote:
>> Just obtuse with different semantics.  Ones not seen as often.
>
> No, it is an actual bug.  Instead of refuse(), a different form
> of termination should be used, one that generates an accurate
> diagnostic.  Or, refuse should accept an argument for the
> reason: refuse("can't create temp file");
> Followup-To:
> Distribution:
> Organization: University of Bath Computing Services, UK
> Keywords:
> Cc:
>
>

The *cause* may very well be a bug. Not my area of expertise.

But quite separately, the form of presentation of the response is an smtp RFC
violation.

While the specific text is flexible, the code numbers at beginning of each line
are standard for each type of situation, not optional.

Decently laid-out listing here:

http://www.greenend.org.uk/rjk/2000/05/21/smtp-replies.html

The cited RFC's spell out the 'MAY', 'SHOULD', and 'MUST' rules applicable.

Nothing prevents inventing/defining some other way of messaging - smtp is far
from the only way in use.

But that 'other way' would NOT be 'smtp', nor should a proper smtp server be
expected to interoperate with a non-standard set of codes, or absence therof.

Whatever 'fixing' is to be done should take that into account as well as sorting
the proximal cause of this specific error situation.

Bill