[875] in Kerberos_V5_Development
Re: Proposed Kerberos V5 Password Changing Algorithm
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Feb 27 15:02:32 1995
Date: Mon, 27 Feb 1995 15:02:14 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Rich Salz <rsalz@osf.org>
Cc: krbdev@MIT.EDU
In-Reply-To: Rich Salz's message of Mon, 27 Feb 95 14:00:24 -0500,
<9502271900.AA20447@sulphur.osf.org>
From: Rich Salz <rsalz@osf.org>
Date: Mon, 27 Feb 95 14:00:24 -0500
Hey Ted, if you wanted a rubber-stamp approval you should have said
so at the outset.
I wanted comments; I've gotten some really good comments from some
people (for example, Bill Sommerfeld), and less than useful comments
from others (I won't name anyone specifically).
The good comments are the ones that are defined as ones that come with
technical rationales that actually make sense. Saying that "you must
use ASCII text because then you can test with telnet, when the whole
connection is encrypted", is a flawed argument that shows you didn't (a)
read the document carefully, or (b) think very carefully before you made
your statement.
Perhaps I should have just bit-bucketed those arguments instead of
actually trying to spend time responding to them. That may have been my
mistake.
Numeric command codes seem no less egregious then numeric reply codes.
Perhaps; but collisions seem historically to be lest of a problem with
reply codes. It's probably because by the time you get back a reply,
you know that you're talking in the context of a specific command, and
new error codes are generally added in response to new commands, and
much more rarely added to existing commands. Examples: SMTP, NNTP.
In any case, I expect the most important part of the error return will
not be the error code, but the error text which explains to the user
what specifically went wrong, and is designed to be printed directly to
the user's screen.
- Ted
