Re: 301/302

>   I strongly agree with the 307 proposal cited above.  It is most
>   unfair to those who have made the effort to read and understand the
>   specifications to change them now by swapping the codes, even if
>   there is time for them to recover (which we cannot know in any
>   case).

I don't think it is a good policy to make technical decisions on the
grounds of whether or not the decision is 'unfair' to one or another
group of implementors. We need to justify our decisions based on the
quality of the protocol we've designed and the likelihood of widespread
deployment, based on
issues such as performance, stability, and compatibility with deployed

Using those criteria, the case for "add 307, deprecate 302" has been
fairly weak ("may have some conjectured compatibility problems with some
software") while the case for "swap 302/303" has been stronger.

Received on Wednesday, 3 September 1997 11:06:09 UTC