Nouns as capabilities

Mark Baker distobj@acm.org
Sun, 26 Aug 2001 11:33:54 -0400 (EDT)


Since nobody else has done it, I'll attempt an answer of my own implicit
question from my WebDAV posting, "What is the difference between inducing
a state change via POST, and using a custom HTTP method?".

While calming my teething son last night, around 04:30, it occured to
me that the fundamental difference is the way in which capability
negotiation is performed.

With a new HTTP method, negotiation for it is performed via the 405 response
code and Allow header.  But it's still a verb that is being negotiated for,
and so more complex (I'm assuming here that verbs are more expensive to deploy
than nouns, ala the Web's fixed interface).

With a POST, there's currently no standardized way of negotiating, for
example, the capacity to understand that accepting "<lock xmlns=".."/>"
as a subordinate means what the namespace defines it to mean.  But the
problem of negotiating capabilities now seems more tractable, as
each capability can be recast in terms of nouns being accepted as
subordinates of other nouns.

So how about a "Allow-Subordinates" header that could be returned as a
result of a failed POST, or a HEAD, that described which nouns can be
accepted as subordinates?

This would also avoid the problem that PEP and HTTP-EF were trying to
solve by needing to bind to a namespace, new HTTP methods derived from
their respective extension frameworks.  It would allow POST to effectively
become the PEP method, but have the meaning grounded to a noun, not a verb
(which I believe POST is suited for based only on the definition in RFC
2616, but perhaps wasn't clear that it would be used for this purpose).

Yes, I like this a lot.  Quite elegant, I believe.

Off to the cottage for a week.  I look forward to reading your responses
in September.

MB