W3C home > Mailing lists > Public > ietf-http-ext@w3.org > January to March 1999

Re: Last Call: HTTP Extension Framework to Proposed Standard

From: by way of Henrik Frystyk Nielsen <Koen.Holtman@cern.ch>
Date: Mon, 29 Mar 1999 13:41:15 -0500
Message-Id: <>
To: ietf-http-ext@w3.org

Dear IESG,

In my earlier last call comments to
draft-frystyk-http-extensions-02.txt I advised against the 02 draft
going to proposed.  After that there was a long private e-mail
exchange between Henrik and me in which we managed to resolve most of
my 02 last call comments.  The 03 draft has just been released so here
is a status update from my side.

The 03 draft has fixed most of my problems with the 02 draft, and I
have no objections against the 03 draft moving forward to proposed.
On the other hand, I am not actively encouraging that it moves
forward, I am neutral on the matter of moving.

I do not plan to use the http-extensions mechanism myself, my main
interest in reviewing it has been to make sure that its users would
not break caching for me as a HTTP/1.1 user.  I believe that the 03
spec has lowered the risk of bad caching interactions to an acceptable
level, so I see no reason for me to be against its deployment anymore.

Two of my 02 last call comments have not been resolved in the 03
draft, but I can live with that.  For reference I list these two
comments below.

The first comment, cut-and-pasted from my earlier message:

|- Sec 5 point 4:
|              A server MUST NOT fulfill a request without
|              understanding and obeying all mandatory extension
|              declaration(s) in a request.
|This implies that a request cannot contain two mandatory extensions
|which are to be executed by different upstream servers.  For example,
|if I want my browser to send a mandatory extension to my firewall
|proxy to enable some privacy processing, I cannot at the same time use
|a browser plugin which sends a mandatory extension to trigger some
|plugin-related functionality in the origin server.  Not being able to
|combine two extensions in this way is a rather severe restriction
|which kills the whole protocol for me.  It means that plugin vendors
|cannot use the protocol for fear of proxies getting in the way, and
|that proxy vendors cannot use the protocol for fear of plugin vendors
|getting in the way.  Result: nobody can use it.
|The Ext: mechanism should be fixed to solve this problem, e.g. the
|Ext: header should include the names of the extensions that were
|understood and obeyed by different upstream servers.

With respect to my suggestion for a fix above: I now believe that a
better way of fixing this would be to simply forbid proxies to fulfill
end-to-end mandatory requests.

The above comment is really about usability of the spec, not about its
internal correctness.  As I do not consider myself to be a likely user
of the spec, I can live with this comment not being resolved.

The second unresolved comment:

|- Sec 5.1 Fulfilling a Mandatory Request
|There is no equivalent material on how to fulfill an optional request.

This is mostly an editorial nitpick, and I don't care much that it has
not been resolved.

Received on Monday, 29 March 1999 13:41:18 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 1 July 2021 15:49:08 UTC