- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 15 Mar 2008 08:55:30 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Harry Halpin <hhalpin@ibiblio.org>, ietf-http-wg@w3.org
Thanks for the feedback. Responses inline... On 15/03/2008, at 12:04 AM, Julian Reschke wrote: > > Mark Nottingham wrote: >> I've submitted a draft-01 (perhaps against my best judgement; this >> discussion is rapidly consuming the mailing list...), which should >> appear shortly. In the meantime, it's available at <http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt >> >. >> It is in no way a finished product; it's just a straw-man that >> tries to cover the issues, so it's easier to appreciate what they >> are (even if we don't go in this direction). >> ... > > Mark, > > I think this absolutely heads into the right direction. > > A few comments...: > > 1. Introduction > > A means of indicating the relationships between documents on the Web > has been available for some time in HTML, and was considered as a > HTTP header in [RFC2068], but removed from [RFC2616], due to a lack > of implementation experience. > > JRE: include reference for HTML Ack > relationship = URI-Reference | > <"> URI-Reference *( SP URI-Reference) <"> ) > > > JRE: we probably should state that relationship names that include a > semicolon need to be quoted. Ack > Relationship values are URIs that identify the type of link. If the > relationship is a relative URI, its base URI MUST be considered to > be > "http://www.iana.org/assignments/link-relations.html#", and the > value > MUST be present in the link relation registry. > > JRE: why a new base URI? What's wrong with "http://www.iana.org/assignments/relation/ > " (<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section. > 4.2.7.2>)? Hmm. That's the actual URI of the registry; we should ping IANA on this, but yes. > 6.1. Normative References > > JRE: I think RFC2434 and RFC3864 could be classified as informative. Probably. > > > to map the profiled link relations to URIs. For example, in 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" > > JRE: do we need to talk about profile URIs where concatenation does > not work well, such as "http://www.w3.org/2003/g/data-view"? I'm not sure; I thought about it, but would like to see a use case where it's important. Not that there isn't one, but my limited imagination couldn't come up with one at 10pm last night. > HTML defines link relation values as case-insensitive, while the > Link > header's syntax does not. Therefore, it is important to case- > normalise relation values in HTML before comparing or converting > them > to Link headers. > > JRE: impact on registration procedure? Avoid names that only differ > in case? Nice catch. > > > Atom conveys links in the atom:link element. When serialising an > atom:link into a Link header, it is necessary to convert any IRIs to > URIs, since HTTP headers cannot directly contain UTF-8. > > JRE: that's a bit misleading. For instance, a IRI that contains non- > ASCII Latin-1 characters could be put into an HTTP header, we just > don't want to allow that and chose URIs as format. hmm. > > > Additionally, since the base URI for link relations in Link headers > is fixed, extension links (i.e,. those not in the registry) MUST be > serialised as absolute URIs. > > JRE: s/serialisized/represented/? Sure. > > > > BR, Julian > > -- Mark Nottingham http://www.mnot.net/
Received on Friday, 14 March 2008 21:56:18 UTC