I think Mark has got it partly wrong. I think that his Link-Template header needs to be collapsed back into the HTTP Link header, and I think that his URI templating should be collapsed back into the URI Reference. Let me explain:
It is rarely OK for a client to infer the existence of one resource from the fact that another exists. A client should only look up resources it is configured with, resources it has seen hyperlinks to, and resources that have come out of some form of server-provided forms or templating facility. At the moment, our templating facilities centre around HTML forms and XForms. Is this in need of some tweaking?
We already have a separation between a URI and a URI reference. A URI is what you send over the wire to your HTTP server. A URI reference tells you how to construct the URI, and what to do with the result returned from the server. Consider the URI reference <https://example.com/mypage#heading1>. This tells us to construct and send a request with url <https://example.com/mypage> to the server, and look for the "heading1" tag in the returned document. The exact processing of the "heading1" fragment depends on the kind of data returned from the server, and the kind of application the client is. A browser will show the whole document, but navigate to the identified tag. Another client might snip out the "heading1" tag and its descendents for further processing.
Mark Nottingham has proposed a reintroduction of and enhancement to HTTP's link header. In his draft, he suggests a templating mechanism for relationships between documents. He proposes a Link header for URI referenes, and a separate Link-Template header that allows for templating. He defers definition of how the template is expanded out to the definition of particular link types.
Danny is unsure of the use cases for link templating. I'm not sure about templating of the HTTP link header, although I'm sure Mark has some specific cases in mind. I have at least one use case for a broader definition of URI templating, and I am not sure that the link header is the right place to specify it or the link type the place to specify how it is expanded. I wrote to Mark last week commenting on how useful it would be if his hinclude effort could be coupled with a templating mechanism:
Consider a commerce website built around the shopping cart model. If I am a user of that site, I may have urls that only relate to me. I may have my shopping cart at <https://example.com/shoppingcart/benjamin>. My name would form part of the url for the purpose of context. Urls specific to me are not the only ones that need to return me personalised content, however. Consider a product url such as <https://example.com/products/toaster>. That page may contain a link to my shopping cart or even include a mini-checkout facility as part of the page, and may include useful customer-specific information for my convenience.
The server could return a static product page to the user. The client side could rewrite the HIinclude src attribute before issuing the include request. This rewrite could take into account contextual information such as a username to ensure that the static page ended up being rendered with my own customisations included.
I think that perhaps the right technical place to specify such a mechanism is as part of the URI reference. It would remain illegal to include "{" or "}" characters in a URL, however a URI reference would allow their inclusion. All substitutions must be completed as part of the transformation from a URI reference to a URI. This process would use context-specific information to be defined by individual specifications, such as HTML or HTTP. HTML would likely have a means of transferring information from javascript or directly from cookies into the templating facility. Other contexts may have other means of providing the templating. If no specification is available for a particular context on how to perform the tranformation, the use of curly braces in a URI reference would effectively be illegal.
As for actually including the curlies into a URI rfc, I understand that might be taking the bull very firmly by the horns. Perhaps the notion of a templated URI reference to eventually be merged with the general URI reference would be the right track. One thing I don't think will be ideal is the specification of a separate Link-Template header to deal with these special URI references. There may be technical reasons beyond my current comprehension, but I think it would lead to a long term maintainability problem with respect to URIs and their references.
Benjamin