Minimise HTTP traffic by returning Link only if asked for a specific profile

[rob-metalinkage]

Currently the specification does not state any constraints om when Link headers should be supplied - any resource will indicate its ConnegP compliance via Link headers. This is likely to be a HTTP and processing overhead of little value after initial communication. It has the benefit that a client will automatically be informed even if it didnt ask for this information initially.

Should link headers should only be provided if the specific conneg ALTR profile is requested - and if you only want the headers ask for HEAD, and if you want some other serialisation ask for it explicitly with a Content-type ?

Pros: less overhead for multiple resources accessed from a single ConnegP enabled URI
Cons: Client wanting to use ConnegP will need to issue a specific request to establish capabilities (2 requests to get both resource and available profiles

This is a slight narrowing of behaviour requirements I'd be happy to implement myself.

We could look for modifiers - so that the resource profile requested can be served, but also include the Link headers - this would mean changing the semantics and/or syntax of the Accept-profile list to allow additive profiles, or adding a new header to specifically trigger inclusion of Links.

We could also mitigate the overhead of two calls per resource by allowing a response to indicate a URI base, for which all resources have the same profiles available. (This wont work very well for having different profiles available for different paths - such as root paths behaving as collections supporting different profiles to collection items: http://thing.org/myCollectionWithCollectionViews/anItemWithItemSpecificViews