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

HTTP Extension draft

From: Rob Lanphier <robla@real.com>
Date: Mon, 04 Jan 1999 00:06:36 -0800
Message-Id: <4.1.19990103232300.02dc6a30@mail.real.com>
To: discuss@apps.ietf.org
Hi folks,

I was asked to comment on Henrik's HTTP Extensions Draft as someone who's
looked at this problem in the past.  When we were working on the RTSP draft
(now RFC 2326), we contemplated baking in PEP support, but then backed down
and came up with a drastically simplified extension mechanism which you can
find in RFC 2326 by looking at the "Require:" and "Proxy-Require:" fields. 

Current experience on the RTSP extension mechanisms is still sparse, and so
I can't offer a lot of anecdotal evidence on that front.  However, we
haven't yet run into anything that suggests that we screwed up too terribly.

However, I can speak from the perspective of a vendor of an HTTP system who
may be confronted with implementing this one day.  I think it solves the
problems it tries to solve well, but that it bites off more than it should
chew.

Here's the three problems that I see this solving:
1.  Ability to add mandatory extensions
2.  Ability to send extension metadata
3.  Ability to add vendor-specific extensions free from namespace collisions

I think #1 is very interesting and useful.  #2 and #3 are of limited
utility in my opinion (I can go further on the inevitable prompting, but
I'm tired of typing right now :)

So, in the best possible of worlds, I would prefer to see proposals that
decouple the three, and solve them semi-independently (though #2 and #3
could certainly build on #1).  I'd be very supportive of a proposal that
solves #1 as simply as possible, and tests the limits of that model.  #2
and #3 could be saved for HTTP-NG, or could be added if the #1 solution was
proven insufficient.

Rob
Received on Monday, 4 January 1999 03:07:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 March 2006 20:11:25 GMT