> Yeah it is a thin line. But the language was introduced to keep a > current practice possible (as argued by Barry I believe). Yes, that was my concern. > I see where you are going. > > <draft Proposed rewrite> > > While commonly less mature specifications will be published as > Informational or Experimental RFCs, the IETF may, in > exceptional cases, publish a specification that still contains areas for improvement or > certain uncertainties about whether the best engineering choices are made. In those > cases that fact will be clearly communicated in the document prefereably on the front page > of the RFC e.g. in the introduction or a separate statement. > > </draft> > > I hope that removing the example of the IESG statement makes clear that this > is normally part of the development process. I think that version is just fine too, with the typo in "preferably" corrected. John, to give you the context again: I agree that we're normally requiring much more of PS documents than we used to, and that it's good that we document that and let external organizations know. At the same time, we are sometimes proposing things that we know not to be fully baked (some of these came out of the sieve, imapext, and morg working groups, for example), but we *do* want to propose them as standards, not make them Experimental. I want to be sure we have a way to continue to do that. The text Olaf proposes is, I think, acceptable for that. Barry