Re: WG Review: HyperText Transport Protocol Bis (httpbis)

I would prefer that the IESG decide whether or not RFC 2616 needs
to be updated by a working group.  I would prefer that it not make
any technical decisions for that working group through the
imposition of charter constraints.

We do need a scope requirement that the resulting work products
of the WG be compatible with HTTP/1.1 as defined in RFC 2616+2617
(with allowance for the known errata).  However, I think the WG
can avoid running itself into the ground by keeping to a reasonable
discussion of what works and only specifying what is known to
be implemented in practice, letting the normal WG procedures
rein in the discussion to things HTTP/1.1.

In contrast, I think this part of the proposed charter

> The Working Group must not introduce a new version of HTTP, and
> should not introduce new features or capabilities to HTTP.

goes beyond that and makes a technical decision on what is best
for the evolution of HTTP before the WG even starts.  I don't
think that's why we have charters.  The WG can make that decision.

In any case, I have mostly completed the task of splitting
RFC 2616 into separate documents and am firmly convinced that
a complete rewrite of the document is worthwhile even if we
make no changes to the resulting protocol.

   http://labs.apache.org/webarch/http/draft-fielding-http/

Regarding RFC 2617 (HTTP Authentication), the HTTP WG (if we are
to have one) should be tasked with specifying all of HTTP.  The
previous experience of splitting HTTP security into a separate area
was an unmitigated disaster, for which we are still paying the
price of passwords in the clear, and I would prefer that the IETF
learn from that experience instead of repeating it.

HTTP access authentication needs to be specified by the people
who implement it, not by people who want to implement something
else instead.  I welcome those efforts to research, develop, and
deploy non-HTTP security mechanisms within other working groups
of the IETF without hindering the correct specification of an
update to RFC 2617 as it has been implemented by hundreds of
vendors, along with the specification of any new (Experimental)
authentication schemes that might fit within the extensible
framework defined by 2617.  I don't see any need for separate
working groups and, more importantly, believe it would be harmful
to try and progress HTTP along the standards track without
recognizing the protocol's dependency on HTTP authentication.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Tuesday, 16 October 2007 23:25:56 UTC