Re: HTTP Extensions Framework status?

> First, Im not in favor of a separate body, yet.
> I beleive that there can be progress made in IETF process
> to allow APPS what it needs..
> 
> >
> > >1) Invent a new status above ID but below RFC that let's app
> > >developers know they have a frozen draft they can develop off of but
> > >one that hasn't met all the IETF quality bars.
  > >
> > We've got one. It's called EXPERIMENTAL!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >
> Well, its no good if a standards track document cant reference it.

if you allow a document of quality 'A' to reference a document of
quality  'B', (where A is higher quality than B) you dilute the
quality of A documents to be no better than B.  because people
will just develop documents of quality B and incorporate those
by refernece into another document and claim that the second document
is of quality A. (and yes, people try to do this from time to time)

so if you want to publish documents as Experimental, you need to
content yourself with the notion that any document that makes
a normative reference to those documents can have no higher 
quality rating.

> Following that, one might say then that effort should be experimental
> as well.  This isnt a bad thing, necessarily.  I think there is
> just a stigma about experimental that prevents it from being
> appealing to the community.
> It would help if the IAB could paint a nicer picture of it,
> perhaps as "short term standard".   Whatever it is, we need
> to imply that the standard in question ( experimental) has
> the agreement of the interested vendors/parties, is likely
> to proceed to "standards track", and is something that
> the community should invest in.   

perhaps.  but I can't see how IETF should make any statement
about future direction of a protocol (i.e. its liklihood
of being on the standards track in the future) without extended
community review of that protocol - precisely because of the
tendency for groups to work at cross purposes.  

actually, it seems like Proposed Standard is really very close to
your notion of "short term standard" - in that it is likely to
advance on the standard track and eventually proceed to full standard.

> Today, the common view
> of experimental, IMHO, is "this is never going to go anywhere,
> but you can go play with this freak of nature of you want, just
> dont have any expectations of it being around in the future".

and this is precisely because Experimental documents either
a) don't have widespread community support  
b) are considered to have a high potential for being operational
disruptive.
c) have known technical problems

again, if you want some sort of statement that "things will probably
go this way" then you need at least tacit support from a lot larger
community than a single working group, and you need independent
review to overcome the tendency of editors and working groups 
(and human beings in general) to miss flaws after they've been 
working on something too long.  and that's basically what you
get with Proposed Standard.

> Maybe all APPS standards should have experimental, or an
> equivalent, as a necessary first step in getting to standards
> track proposed.

I've wondered about this - maybe groups should have to publish
as Experimental, and implement the protocol, before going to
Proposed.  It might get people focused on "running code" sooner
rather than later, and some groups need that.  I'd like to see 
a few groups try it before recommending it for everyone in APPS.  

> Maybe in the early stages it would be wise to have the IETF
> make two standards for a given area, perhaps as "quasi-experimental".
> This way the market can decide, and when it does, it wont be
> a choice of "the IETF approved standard, or the other one".

occasionally we do make two standards in a given area, call 
them both Proposed, and let the market decide.  but usually 
the conflict isn't between two different ways to do X
(working groups are fairly good at sorting those out),
the conflict is where protocol X intereferes with your ability
to use protocol Y, or vice versa.   and some of the market 
decides to use X and some of the market decides to use Y, with
the result that the ability to deploy both X and Y are diminished
even though X and Y don't directly compete with one another.
for example, NAT boxes interfere with the ability to deploy
many different kinds of protocols, but people don't realize
that when they are choosing a NAT box they are implicitly
choosing not to run those other protocols.

> People should build products, standards, and such due to
> the usefulness and market acceptability of a protocol, not
> because one is "IETF sanctioned".

agreed.  but IETF sanction is often a good indicator of the 
usefulness and deployability of a protocol.

Keith

Received on Tuesday, 7 December 1999 11:01:34 UTC