Re: HTTP Extension draft

At 09:19 AM 1/4/99 -0500, Henrik Frystyk Nielsen wrote:
>At 00:06 1/4/99 -0800, Rob Lanphier wrote:
>>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.

On second reading, I realize that "metadata" is too strong a word (I have
to admit reading it with PEP tinted glasses the first time) :), and that
you're probably right that the rest is necessary to solve the namspace
clashing problem (#3).  Now, whether #1 and #3 should be solved in the same
draft is another discussion....

>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.

I can see the benefits of trying to extend the XML model to HTTP.  However,
I'd like to see how things pan out with XML namespaces before retrofitting
that model into HTTP.

A side question:  if this becomes a proposed recommendation, what do you
think will be the first application that uses this?  I ask this because I'm
wondering if there's something waiting in the wings for the completion of
this spec, and to get a good feel for a good application of this.


Received on Wednesday, 6 January 1999 12:51:16 UTC