Bootstrapping discovery

Here's a draft of the proposal (in specification-like) form for review and possibly a vote by the TC at the Aug 6 meeting.
------------------------------------ The Proposal ----------------------
In order for end users or tool integrators to leverage OSLC Discovery capabilities, they must have a URI that establishes a starting point. A starting point could be a URI to a Service Provider Catalog, or a URI to a particular LDPC. Either of these URIs would allow a client to discover other URIs and capabilities that may be exploited to meet their needs.

OSLC Core Discovery specifies how to discover capabilities. But there also needs to be a standard way of determining the URIs a client would need to know in order discover the supported capabilities. By convention, some OSLC servers utilize a rootservices document at the root of the server URI that contains properties whose value is the URI for a service provider catalog. LDP specifically states that it does not define how clients discover LDPCs (see LDP 1.0, section 5.2.1). Tool integration is simplified by providing a standard way of discovering URIs that are intended to support discovery of capabilities provided by an OSLC compliant server.

A user or client application of course has to know some URI in order to access a server at all. This URI would include the supported protocol, host name, port, path and any other URI components the server requires. Often servers will have some well-known home page, often ‘/‘, that provides and entry point into hyper-linked content provided by that server. This URI may not be the root discovery URI itself, but can provide a means of discovering root discovery URIs.

1. Servers SHOULD include one or more Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot” headers on an HTTP GET, HEAD, or OPTIONS request on the server’s advertised or default home page. The discovery-URI is the URI of a ServiceProviderCatalog resources, ServiceProvider resources or LDPC that can be used for subsequent discovery of OSLC capabilities.

2. The Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot” headers SHOULD allow discovery of all OSLC resources and capabilities on that server either directly, or indirectly through referenced ServiceProviderCatalogs and/or contained LDPCs.

3. Servers MAY provide Link: <discovery-URI>; rel=“http://open-services.net/nx/core#resourceDiscoveryRoot” headers on an HTTP GET, HEAD, or OPTIONS request on other URIs that are likely to be seen to represent the OSLC server's root or the OSLC server as a whole. These different URIs could represent a partitioning of the OSLC resources and capabilities provided by the server. 

There have been a number of proposals to support URI discovery including the proposal above, using OPTIONS * to return a ServiceProviderCatalog possibly containing links to other ServiceProviderCatalogs, or using ./well-known (https://tools.ietf.org/html/rfc5785). All of these proposals suffer from the same issue. Web servers may not know the capabilities or usage of a particular application that has been registered or plugged in. In particular, a Tomcat or Apache web server wouldn't know if a plugin or WAR represented something that supported OSLC capabilities or not. So the server in general would not be able to provide information about any of the URIs supported by those plugins.

As a result, the TC voted to close this issue with no action.