RE: Issue: How CPA is used in the spec

[Rich Salz <rsalz@zolera.com>]

>Knowing how the other side behaves, forces a slow-down in the
>process and re-introduces the dependency on errors. One
>should cross his fingers hoping his software does not
>deliver something wrong since the effect would be unpredictable.

You don't have to know how the other side behaves.  *As long as you
conform,* the right things will happen.

Standards do not have to always define errors.  They can explicitly leave
things out of scope.  There are good reasons for this -- it allows future
growth ("we'll figure out what to do next version"), and it handles the
present situation, where some parties want an error, and some parties
want to legalize the behavior.

For example, ANSI C created the "#pragma" construct, but said that the
results of using it are undefined.  It's purely a local compiler issue.
Yet every compiler has #pragma and it's a very useful construct.  (In the
early days, GCC would exec "nethack" if it saw a pragma; that was cute,
but arguably not very useful.)

Finally, one last analogy.  The laws do not say "if you exceed the speed
limit, you will pay a fine."  They say, "if you are caught exceeding
the speed limit you will pay a fine."  This allows overriding local
circumstances to change things.  If I'm driving my pregnant wife to the
hospital so that she can give birth (perhaps because my life is a sitcom),
I should be allowed to speed.
	/r$