MRC@SU-SCORE.ARPA (Mark Crispin) (08/24/84)
I sure wish that people would use "invalid" instead of "illegal" when referring to syntax validity checking or other forms of user-error checking on computers. "Illegal" should be reserved for things which are against the law; e.g. theft of services, vandalism, fraudulent usage, etc. I still remember the day a few years ago when I found a newly-hired secretary at Stanford CSD crying. You see, it was her first day on the computer, and shortly after being left alone with a zillion things to enter in she made some trivial error which rewarded her with an "Illegal syntax" error message. She was terrified that the FBI was going to come and arrest her! [The fact that "syntax" itself is a horrible word to use in an error message in any program a novice might use is beside the point] I firmly believe that computers should be made more accessible to the general public, not less, and we should start by not misusing the term "illegal." I start feeling ill every time I see some message saying so-and-so's "header is ILLEGAL"! -------
ron@BRL-TGR.ARPA (Ron Natalie) (08/24/84)
Of course, if you use illegal headers the Protocol Police will come and arrest you. -Ron
don.provan@CMU-CS-A.ARPA (08/24/84)
gee, does that mean we have to stop threatening to call out the protocol police, too?
Ellis@YALE.ARPA (John R Ellis) (08/24/84)
I sure wish that people would use "invalid" instead of "illegal" when referring to syntax validity checking or other forms of user-error checking on computers. "Illegal" should be reserved for things which are against the law; e.g. theft of services, vandalism, fraudulent usage, etc. "Illegal" more accurately describes a message with bad syntax than "invalid". From my Random House College Dictionary (a mediocre dictionary): illegal: 1. not legal; contrary to existing statutes, regulations, etc.; unauthorized. invalid: 1. not valid; without force or foundation; indefensible. 2. deficient in substance or cogency; weak. 3. void or without legal force, as a contract. valid: 1. sound; just; well-founded: "a valid objection." 2. producing the desired result; effective: "a valid remedy." 3. having force, weight, or cogency; authoritative. 4. Logic. (of an argument) so constructed that if the premises are jointly asserted the conclusion cannot be denied without contradition. "Illegal" merely implies some non-conformance with a regulation or statute or rule. There is no necessary requirement that there be the force of government behind the rule. For example, it is common usage to say that a move in a game is illegal, i.e. doesn't conform to the rules. "Invalid" on the other hand is mainly used to refer to arguments and methods, especially those involving logic (thinking). For example, you might describe a possible compiler source transformation as invalid. So "illegal" accurrately describes a header that does not conform to the rules of RFC822, rules laid down by a supposedly authoritative agency, DARPA. "Invalid" wouldn't be nearly as good an adjective, since a message header is not an argument or method. It's pretty much mom and apple pie these days that error messages such as "Illegal syntax" or "Invalid header format" are pretty useless to a novice (as Mark points out in with his anecdote). On the other hand, there need be little relation between what our programs say to users and the terminology we used to describe the implementation of the program. -------
ROODE@SRI-NIC.ARPA (David Roode) (08/24/84)
Mark's explication of illegality reminds me of a solution one computer facility had. The also had a lot of novice users. One of their programs would print: UNASSIGNED JFN AT 321222, FATAL ERROR (That's not so bad.) -------
MCGREGOR@hp-labs.csnet (Scott L. McGregor) (08/29/84)
Mail-From: MCGREGOR created at 29-Aug-84 12:28:10 Date: Wed 29 Aug 84 12:28:09-PDT From: Scott L. McGregor <MCGREGOR@HP-HULK> Subject: Re: illegality To: ron%brl-tgr.arpa@csnet-relay cc: MCGREGOR@HP-HULK In-Reply-To: Message from "Ron Natalie <ron%brl-tgr.arpa@csnet-relay.csnet>" of Fri 24 Aug 84 14:19:49-PDT I will just make a few observations on "illegality","protocol police", and "shooting mail system administrators who allow illegal headers to leave their mailsystems", and then I will step out of the fray. It is ironic that a document called RFC (request for comment) is regarded as a law that some would have treated as a capital offence and to be policed by protocol police. While I don't regard the violations of the guidelines proposed in RFC822 as quite as serious as some do, I do recognize that there is much a human problem here as a machine or program problem. Here's my analysis: Many people see great benefits in reaching the Internet community by mail. This makes it desirable for them to get up a mail bridge to get into the system as quick as possible, and as is equally human, with the least amount of effort required. There are two strategies in building such a mail connection that are particularly of interest: 1) saving on building a input checking routine (assuming everyone follows the standard) and 2) saving on building an output checking routine (assuming that no one will hand you bad stuff to send out). Some sites seem to have adopted one strategy or the other. Some have even adopted both. Whenever someone who doesn't do output checking sends some garbage to someone who doesn't do input checking, the fur starts to fly in header-people. RFC733 and 822 have something to recommend about this, and there has long been a policy recommended by header-people and others that goes something like this (in various variants): 'It is good courtesy (and smart practice) to make your mail interface to the net as strict as possible about what it transmits (outbound) and as flexible as possible about what it will receive (inbound).' This is of course entirely contrary to the two strategies described above (don't input check and don't output check). For a real problem to exist there have to be two systems at fault, the one who sent the garbage and the one who received it and belched. Both sides have failed to meet the courtesy standard, and so argue about who is more at fault, and who should have to do something about it in the future. I don't find this kind of discussion very helpful. Both systems need to change. Given human organizations, the one who doesn't change is just asking for another problem in the future. Both systems should be made more error tolerant in my opinion. Of course, any changes that need to happen, won't happen overnight. Thats just how organizations and people work. But there are things that can be done to speed up these changes, and I find discussing these much more productive. In particular, there seems to be precious little discussion on how to do better error checking on output and how to do correction on input. What we mainly hear is that we should all just do a better job of it. I must admit that in my mail interface programs I have made many mistakes in the past and that these have been pointed out to me by angry mail administrators. I have tried to address them as quickly as possible, but I'll let you all in on a hint to quicker fixes. I have always responded faster to complaints that suggested how the actual repair could be accomplished (in code or pseudo code) than I have to those that just said that it needed to be fixed and that I should do it now. In the interest of more robust systems everywhere, I would like to see much more code sharing. recklessly yours, Scott McGregor ------- -------
DonWinter.pasa@XEROX.ARPA (09/04/84)
Scott, I'm pleased to see a little sanity injected into this political discussion. Of course, I expect it to have as much impact as sanity injected into any other political discussion. Sigh. Don
Jacob_Palme_QZ@QZCOM.MAILNET (09/15/84)
How many books do you want? FIVE %XYZ123 ILLEGAL NUMERIC ITEM A more suitable error message text would be Sorry, the computer does not understand this!
heiser@cca.UUCP (09/21/84)
That "crying secretary" would have loved that one about "fatal error"; Not only will she be arrested, but sentenced to death...