Comments inline, some content snipped. On Tue, Oct 5, 2010 at 5:54 AM, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Oct 4, 2010, at 4:16 PM, Barry Leiba wrote: > >> While this is true as far as it goes, I'd like to point out a good >> example of where "the common case" may be less common than we'd like >> to think. >> >> ACAP, RFC 2244, is a Proposed Standard put out in 1997. There's a >> core of us who think it's a good protocol and a useful one, but it's >> had very scanty implementation. At this point, even most of its >> champions think it might as well go to "Historic". >> > I think part of the problem is that our current "maturity" labeling scheme conflates several things: > > - quality of the protocol itself (is the design good and without significant known flaws relative to its intended/expected use?) > - quality of the specification (is it written clearly and precisely enough to encourage interoperability?) > - currency of the specification (does the written specification still reflect current and/or desirable practice?) > - applicability of the protocol (how broadly should it be used?) > - initial/continued acceptance/deployment of the protocol > I think this is a key point, both to this discussion and to the "how many grades" discussion. The current labels represent more than one axis of evaluation, and we may have to agree on which one is the most important in order to get clear labeling. This may mean that we add a second label (or potentially a third) to get full descriptions. But I don't think even that would require us to go the full "commentary document" route where the core spec was surrounded by attached commentary built up over the years. I think the "document quality" metric, assessed in relation to interoperabity is at the core of this. Can you go from this document to an implementation? We can assess that in a variety of ways, but that's my take on the most important bit to retain for the system. The "is it in use" question could be handled by an increase in statuses like "Historic" which could be applied simultaneously to the document set. So you could have ACAP be both a full standard and historic; the meaning would be "The IETF strongly believes that you could go from this document to an interoperable implementation, but that you would find few other implementations in use". Historic is probably not the right designation, given the past experience. But something like "FULL, Niche deployment" or "FULL, Wide deployment" could be useful. To my way of thinking, the "quality of the protocol" question is inevitably bound up with the "intended/expected use" issue--which means that the same protocol could have multiple different evaluations. HTTP would get one as a hypertext transport, for example, and completely different one for streaming--both uses in the wild now. The actual energy in the community to make change here actually seems to me pretty low, though, both for this and Russ's document. I'm not sure whether a proposal like either of them should "default advance" with this level of energy. regards, Ted > ...which is why, instead of "advancing in grade" from PS to DS to FS, I'd like to see a periodic re-evaluation of the last three. There are protocols today which are Full Standard for which the specifications are not being well-maintained and which don't reflect good current practice. There are also protocols which are Proposed Standard for which the specifications are reasonably current and reflective of good practice. There's a disconnect between our labeling of these standards and their "goodness" to the community, and that harms IETF's credibility. > > Keith > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf