Re: 301/302

>>>>> "LM" == Larry Masinter <masinter@parc.xerox.com> writes:

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

  If fairness and correctness were in direct conflict I would agree
  with you; early implementers do take a risk and must to some extent
  live with that.  If, for example, an earlier protocol specification
  is demonstrably not workable or causes a severe problem with future
  extensibility then it should be corrected, sacrificing backward
  compatibility if necessary.  We have no shortage of such examples.

  The IETF process is distinguished in the standards world by its
  insistence on implementation experience and interoperation as
  central approval criteria.  This is (IMHO) its greatest strength,
  and yes it gives early implementers more influence over the process
  than those who would sit and argue about the standard without
  actually implementing it until the next ice age; I think this is a
  good thing - let those people go to ISO meetings.  Personally, I'd
  rather build things and learn from the process.

  Making incompatible changes to the semantics of a protocol element
  between the Proposed and Draft Standards is a step that should be
  taken only when the reasons to do so are compelling.  Every time
  any working group does so they encourage a 'wait-and-see' attitude
  and decrease the likelyhood that new protocols will be widely
  deployed.  Look at how few vendors are shipping products based on
  2068.

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

  Adding 307 will not cause any existing implementation to
  misinterpret what it means.

  Some existing, deployed, implementations already have 303
  correctly implemented as 'See Other'.

  I think that both of the above argue for the original proposal, and
  that swapping the codes is far more confusing (bear in mind that
  none of the old documents or discussions or archived netnews advice
  on this topic will go away - it will be around forever and mess up
  people who don't find the latest spec indefinitly).

  I have heard no compelling reason to change the meaning of 303 to an
  incompatible one.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Wednesday, 3 September 1997 13:31:44 UTC