> What's the problem?
Good question. :)
People have been considering mechanisms for binding
metadata to a resource. HTTP Extensions for Resource
Metadata (HERM)  looks to be a good solution. It
calls for the use of a pair of headers, Meta-Location
We've been considering some potential refinements. I
felt that the OPTIONS method would be the natural place
to return the Meta-Location in the general case, which
is similar to the use of the Allow header. It's unclear
though if this is stretching the semantics of OPTIONS
too far. I'd like to know if it is.
Roy Fielding had mentioned in a posting to
this list that adding an extra header to each GET is not
optimal , but that might be the easiest road to
Other interesting ideas have been floated on the HERM
associated discussion list .
This topic is essentially one aspect of the TAG issue
"metadataInURI-31"  specifically with regards to
"... and more importantly there should be a "clean",
uniform way to refer to (and thus access) the metadata
of web resources..."
Another potential issue brought up by Berners-Lee in
a recent posting  to www-tag concerns a similar issue: how
can site level "metadata" such as /favicons, p3p statements
etc., be bound to a site in a standard way. It would seem
that the solution to the first issue could form the basis
of the solution to the second issue.