W3C home > Mailing lists > Public > ietf-discuss@w3.org > December 1999

RE: HTTP Extensions Framework status?

From: Larry Masinter <lmm@acm.org>
Date: Tue, 7 Dec 1999 20:52:25 PST
To: <moore@cs.utk.edu>, "Josh Cohen (Exchange)" <joshco@exchange.microsoft.com>
Cc: "Harald Tveit Alvestrand" <Harald@alvestrand.no>, "Yaron Goland (Exchange)" <yarong@exchange.microsoft.com>, 'Patrik Fältström' <paf@swip.net>, "Scott Lawrence" <lawrence@agranat.com>, <discuss@apps.ietf.org>, "Peter Ford (Exchange)" <peterf@exchange.microsoft.com>
It seems like there are two contradictory things being requested:

a) Proposed Standard is too hard, let's have something like
   <small>temporary possible maybe proposed</small> <em>Standard</em>
   so that we can ship code based on poorly written specs
   and let our marketing department say the "temporary possible
   maybe proposed" part softly and the "standard" part loudly.

b) Proposed Standard is too easy, let's require everyone to publish
   something as Experimental first.

I don't think we need to change the IETF standards track.

I think that far more coordination is needed than we have
between APPS and other areas, since APPS protocols often
seem to reinvent things at the application layer that are
best done at other layers, and vice versa.

And I don't think we need to accomodate the marketing departments
that want to call something "standard". For decades, there
have been successful companies shipping networking systems
without the benefit of calling it "standard". The value
of the standards process is to create specifications of
lasting value.

The main thing I'd look for is not to change any of the criteria,
but to focus on process improvements that would allow IETF working
groups to reach conclusions more quickly.

Personally, I think a small amount of Internet-based collaboration
support for tracking issues in working groups, coupled with
some better group focus and management would go a long way toward
making the process more responsive.

You can't solve a deployment problem ("no one implemented
this specification, oh my") with a specification ("so here's
another specification for how to do the same thing, oh my").

And you can't solve a process implementation problem by inventing
more process.

Let's just focus on making the IETF process work.

As for HTTP extensions, I think draft-frystyk-http-extensions-03.txt
is inadequate as an extension framework for HTTP.

RFC 2324 uses the following kinds of HTTP extensions:

new method
new URL scheme(s)
new header
new value for old header
new MIME type for POST body
new return code
new interpretation for old return code

and even then, it only was exploring a limited number of
possible HTTP extensions (the most obvious being the
use of Java applets as dynamic content.)

Of these, frystyk-http-extension only covers a few,
and in a haphazard way.

# So be it. It would appear that all HTTP extensions 
# (GENA, SSDP, SOAP, etc.) will now be marked experimental...

If 10% of the effort that is going into trying to find
some way of calling these "standard" were instead applied to
actually fixing them so that they worked as documented,
they'd be a lot further along toward standards track.

Received on Tuesday, 7 December 1999 23:49:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:00 UTC