Re: error codes

[John C Klensin <klensin@xxxxxxx>]

On Fri, 09 Apr 1999 02:38:23 -0400 David Madeo <dmadeo@ms.com> 
wrote:

> I agree with most of what Lisa (and the others) are saying on this.  However,
> the dissenting view convinced me.  To reiterate: 1) Adding text of any
> nationality makes the parsing more difficult, especially since it might include
> data as well as a return code (referrals).   2) People working with older
> protocols had found that developers had hard coded parsing based on the
> "friendly" text and were now locked into that format going forward.  Does anyone
> disagree with these two points?

I think the latter is a misreading of the experience.  There
have been two separate problems: 

(i) The original code set is inadequate, so people make up their
own.  This is rarely a "fix in version 2" problem: if
implementers discover that they _need_ something that isn't
there, they will make it up and use it, and, by "version 2", it
will be too late to get interoperability, at least without great
pain.  I suggest that the correct lesson is that, if one can't
be absolutely, 100%, positive that the set of codes provided is
sufficient and unambiguous, then the doc should specify exactly
what should be done when one of the exceptions is found (and
what conditions might constitute an exception, rather than an
excuse for overloading).

(ii) People start parsing, and interpreting, the text part
(whether to translate into a different natural language, or to
translate from geek-speak into "people", or for other purposes,
makes no difference.  This has been cited as a good reason for
banning such text entirely, but it is very handy for tracking
down problems of many varieties.  A flat ban on the practice of
parsing/ interpreting such strings is probably a good idea, but
the ban will stick iff the error code set is sufficient or
readily extensible in an orderly way.  And, of course, if there
have to be significant bits of text in those strings, it better
be *real* easy to find them and pull them out, language and
character-set independent.  

But trying to standardize the text strings and prohibit
everything else is probably a bad idea, if for no other reason
than that such requirements are almost always ignored in
practice. 

    john