Message-Id: <22.214.171.124.19990329134115.0342abc0@localhost> Date: Mon, 29 Mar 1999 13:41:15 -0500 To: email@example.com From: Koen Holtman <Koen.Holtman@cern.ch> (by way of Henrik Frystyk Nielsen <firstname.lastname@example.org>) Subject: Re: Last Call: HTTP Extension Framework to Proposed Standard 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. Koen.