- From: Rich Salz <rsalz@osf.org>
- Date: Sat, 4 Nov 1995 09:45:02 -0500
- To: ned@sigurd.innosoft.com, rsalz@osf.org
- Cc: dl@hplyot.obspm.fr, dsr@w3.org, fielding@avron.ICS.UCI.EDU, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg-request%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Why didn't you bring it up on the IETF list or with the IESG? Because this is a revision of 1544 which is basically two years old. While I think per-protocol headers are the wrong way to do things, it makes sense to me that current practice should be standardized. >This is only partially true. The IETF has a fairly firm policy of not >duplicating work whenever it can be avoided. As such, given the existance of a >standardized, workable scheme that can already be used to perform this >function, it is going to be difficult to obtain approval for another, duplicate >mechanism. I for one would object to it in my capacity as a member of the >applications area directorate. The IETF also has a fairly strong history of accepting duplication and letting the market decide. If someone can put forward a draft for a header that shows two hash mechanisms, and running code I can't imagine the IETF rejecting it. >> Yes. Has either "side" made a strong commitment to convergence? > >Not as far as I can tell. Pity. However, this one of the reasons why we have an area directorate, an IESG, and an IAB -- these groups are supposed to check up on things and make sure that different working groups don't go off in widely differing directions. These groups collectively have the power to override working group decisions if need be in order to insure convergence where convergence is appropriate. > > My position at the present time is that the relative speed issues are more This is what I disagree with. I think it is (heck, they) both good enough, and it doesn't matter anyway since most use will be off-line. /r$
Received on Saturday, 4 November 1995 06:50:25 UTC