- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 3 Dec 2008 13:32:09 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 02/12/2008, at 2:54 AM, Julian Reschke wrote: > > Hi Mark, > > here's some feedback on the latest draft...: > >> 1. Introduction >> This document defines typed link relations, independent of the >> context they occur in. It does so by clarifying the status of the >> link relation registry established by Atom, and registering in it >> the >> relations that are defined by HTML. > > I think it does a bit more than "clarifying", as it establishes a > new registry. Ack. > > > Furthermore, an HTTP header-field for conveying typed > links was >> defined in [RFC2068], but removed from [RFC2616], due to a lack of >> implementation experience. Since then, several use cases for doing >> so have surfaced. However, because it was removed, the status of >> the >> Link header is unclear, leading some to consider minting new >> application-specific HTTP headers instead of reusing it. This >> document addresses this by re-specifying the Link header with >> updated >> but backwards-compatible syntax. > > Would it be useful to note that some UAs already support the Link > header for linking to stylesheets (I think Opera and Firefox...)? Ack. > > >> 5. The Link Header Field >> Link = "Link" ":" #link-value >> link-value = "<" URI-Reference ">" *( ";" link-param ) ) >> link-param = ( ( "rel" "=" relation-type ) >> | ( "rev" "=" relation-type ) >> | ( "type" "=" type-name ) >> | ( "title" "=" quoted-string ) >> | ( link-extension ) ) >> link-extension = token [ "=" ( token | quoted-string ) ] >> relation-type = URI-Reference | >> <"> URI-Reference *( SP URI-Reference) <"> > > I note that we lost the "anchor" parameter defined in RFC 2068, > Section 19.6.2.4, so we are not strictly speaking backwards- > compatible... Well, in the sense that it can be a link-extension, we are... > > >> The title parameter MAY be used to label the destination of a link >> such that it can be used as identification within a human-readable >> menu. > > -> s/MAY be/may be/ or /is/ Ack. >> 6.2. Link Relation Type Registry >> New relation types can be registered by IETF Review, as outlined in >> [RFC5226]. Specifications of new values should use the following >> template: > > As far as I understand RFC5226, Section 4.1, this requires an RFC. > Is that the intent? See discussion with danc. >> Appendix A. Notes on Using the Link Header with HTML >> <html> >> <head profile="http://example.com/profile1/"> >> <link rel="foo" href="/foo"> >> </head> >> [...] >> could be represented as a header like this; >> Link: </foo>; rel="http://example.com/profile1/foo" > > Maybe use "bar" instead of one of the "foo"s... Ack. > Also: is this the proposal how to embed full URIs into HTML4? Or > should people just use the full URI in the rel value? It's not to put full URIs into HTML; rather, how to transform profiled relations into Link headers. > Other points: > > - Comparison rules: I understand we only define link comparison for > relations used in the HTTP Link header, and the rule is character-by- > character, case-sensitive? Good question. My inclination at this point is to say that's the case, and make it explicit. > - We miss a "I18N Considerations" Section. It probably should > mention IRIs in general, and how to I18Nize the title parameter (-> > RFC 2231???) Ack. > - Do we need to talk about migration issues from the old base URI to > the new base URI? Should both be treated the same when comparing > relation values? Urgh. Maybe. Many thanks, -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 3 December 2008 02:32:50 UTC