Now I think I do - it allows one to encode the search information
in the message body instead of the URL, right? This allows one to do searches
that can't be expressed in a URL either because they are too long
or because they are not textual, e.g. one could use a picture
as a query.)
Now that I understand it, I recognize that it would be VERY useful.
I have an application that requires it in fact. I want it.
But I still think it should go out of the spec until it's
well defined. It's not a judgement about the value of the idea,
only about the chaos in the document. You want proof that the
current description is confusing? Here it is: I was confused.
I could not tell what the thing was supposed to do, much less
how it was supposed to do it. A spec is supposed to tell you
how to implement a complying client or server. The current
spec does not do that. So the meta-point here, the one that
is logically prior, is "Should the HTTP spec say anything at
all about features which are neither mandatory nor fully designed?"
We have not heard from Tim on this topic - and it is he
who owns the document. If he wants it to contain such
partial designs, it is his right and priviledge. Tim, are you there?
As for SEARCH itself - I need and want this feature.
I would be grateful were you to devote
the time to bring the design to completion. I would be pleased
to help anyway I can. I will support it in my server. I am already
thinking of how to make a client to use it.
PS I will also volunteer to Tim to help edit the specification (to
remove or improve ill-defined features) if you are too busy to do that.
best wishes,
jim