Re: Introducing a Directory Service rejected as BCP

Harald.T.Alvestrand@uninett.no Wed, 14 February 1996 00:07 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03037; 13 Feb 96 19:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03033; 13 Feb 96 19:07 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17702; 13 Feb 96 19:07 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03022; 13 Feb 96 19:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03017; 13 Feb 96 19:07 EST
Received: from domen.uninett.no by CNRI.Reston.VA.US id aa17696; 13 Feb 96 19:07 EST
Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03496-0@domen.uninett.no>; Wed, 14 Feb 1996 01:07:09 +0100
X-Mailer: exmh version 1.6.5 12/11/95
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald.T.Alvestrand@uninett.no
To: Russ Wright <Wright@lbl.gov>
cc: "Erik Huizer (SURFnet ExpertiseCentrum bv)" <Erik.Huizer@sec.nl>, ietf-ids@umich.edu, iesg@CNRI.Reston.VA.US
Subject: Re: Introducing a Directory Service rejected as BCP
In-reply-to: Your message of "Tue, 13 Feb 1996 10:42:03 PST." <v02140b0dad46662a20d9@[131.243.64.16]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 14 Feb 1996 01:07:07 +0100
X-Orig-Sender: Harald.T.Alvestrand@uninett.no
Message-ID: <9602131907.aa17696@CNRI.Reston.VA.US>

Russ,
quoting RFC 1602:

      2.3.2  Draft Standard

         A specification from which at least two independent and
         interoperable implementations have been developed, and for
         which sufficient successful operational experience has been
         obtained, may be elevated to the "Draft Standard" level.  This
         is a major advance in status, indicating a strong belief that
         the specification is mature and will be useful.

         A Draft Standard must be well-understood and known to be quite
         stable, both in its semantics and as a basis for developing an
         implementation.  A Draft Standard may still require additional
         or more widespread field experience, since it is possible for
         implementations based on Draft Standard specifications to
         demonstrate unforeseen behavior when subjected to large-scale
         use in production environments.

(the last paragraph sounds like it was invented for the whois++
situation, doesn't it?)

      2.3.3  Internet Standard

         A specification for which significant implementation and
         successful operational experience has been obtained may be
         elevated to the Internet Standard level.  An Internet Standard
         (which may simply be referred to as a Standard) is
         characterized by a high degree of technical maturity and by a
         generally held belief that the specified protocol or service
         provides significant benefit to the Internet community.

Something which isn't there but is common practice is that at Full
Standard level, *every single feature* of the protocol must be
implemented by at least two implementations; at Draft, the requirement
is that every feature has been implemented at least once, and that
something large enough to be an "implementation" has been developed by
two independent parties.

As you see - WHOIS++ will never be a full standard before it has
been "subjected to widespread use in production environments".
Does that satisfy you?

(it is actually MORE problematic how to get an X.500 thingummybob
to Full Standard, since we can't control what features are in the
base standard. Guess we might have to profile it again....)

              Harald A