YADIS as an abstraction layer

[Peter Davis]

Sorry, brevity introduced ambiguity :-(

All I was pointing out, is that when an application is presented with a URI
to 'do something with', the local context assists the application what to do
next.  In this case, we think the context is 'I need some identity services
for this identifier'.

So it seems to me to make sense to have the client provide hints to the
resource about which representation it would prefer (be it
application/x-metaidentity-whatever or more simply text/rdf).  If the
resource has such a representation, that should be provided.

I guess my point relative to your mail (and this thread in general), is that
I would strongly suggest using content-negotiation, rather than overloading
the HTML/HEAD structure (and thus also potentially reduces the number of
resource requests involved in getting such capabilities data).

> I am only claiming that the Capabilities Data (the resource in my example)
> should be returned as some sort of document representation. Whether that
> representation is data embedded in HTML, or a standalone RDF (XMl or N3), or
> some sort of special XML. That is, capabilities should not be returned in a
> series of X-* headers of an HTTP response.

I completely agree with this.  And in fact, there may be several
representations. Clients express their capabilities in http-request-headers.

However, there will undoubtedly be the case where the 'server' (the identity
URI), may need to negotiate for the proper service (perhaps it requires a
mTLS connection, so the server throws a redirect to an https scheme's URI...
(BTW: what is the equivalence of these two identifiers?!?)).

So even from the server's perspective, while I'd concur that the
capabilities are not returned via http headers, negotiation for service may
occur there. 

=peterd