YADIS as an abstraction layer

[Benjamin Yu]

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

Ok. I understand your point now. :) Not overloading the HTML/HEAD structure is
a perfectly valid point. 

Based on what I am reading, I may have to reverse my stance on embedding
Capabilities Data withing a person's HTML homepage.

In the cases of just a few capabilities, I think embedding is acceptable.

But I'm reading that we're thinking of doing thousands and thousands of
capabilities or services. In this case, it sounds like a document unto itself.

Now whether or not this is done via content-negotiation or not, I think we'll
definately have more discussion on the list about it.

As for now, I'm not taking a stance on it just yet.

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

I completely agree with you here.

--- Peter Davis <peter.davis at neustar.biz> wrote:

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