- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Mon, 04 Jan 1999 09:19:59 -0500
- To: Rob Lanphier <robla@real.com>, discuss@apps.ietf.org
At 00:06 1/4/99 -0800, Rob Lanphier wrote: Hi Rob, >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 Thanks for your review - first I have a meta question: In #2 what kind of metadata do you mean? In case you mean the old feature discovery exchange mechanism defined in PEP then I fully agree with you. If you mean the extension instance parameters then I would not consider that metadata but call parameters of a particular instance. With respect to #3, is it that you consider a central registry sufficient or is it the name space prefix model you are referring to? Note, however, that as a policy neutral specification, there is nothing that prevents an extension from being open or to be the design of multiple organizations and/or commercial companies. This is fully up to the designers of that particular extension. The main purpose is to define a mechanism that allows for graceful deployment of new extensions locally as well as globally without requiring that two peers have complete knowledge about each others capabilities. >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. The HTTP extension draft in fact does separate instance data from metadata - it simply doesn't define a mechanism for handling the latter independently of instance data. Thanks! Henrik -- Henrik Frystyk Nielsen, World Wide Web Consortium http://www.w3.org/People/Frystyk
Received on Monday, 4 January 1999 09:20:45 UTC