- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 12 Dec 2013 11:11:20 +1100
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: Marcos Caceres <w3c@marcosc.com>, "public-webapps@w3.org" <public-webapps@w3.org>
RFC5988 defines a model for linking (context, relation, target), as well as the Link header as *one* possible way to convey those links. There are many other possible ways to convey links; e.g., HTML <link>, <atom:link>, scribbled on the side of a shoebox, the various JSON linking proposals, etc. It usually doesn't make sense to REQUIRE someone to process all links that they come across. For example, while it's possible to put a link in HTML <link> and <a> and lots of other things, expecting HTTP proxies and other intermediaries to process it is not wise, because they generally don't like to process the bits. OTOH it makes lots of sense for a particular application of linking that needs proxies to process them to use the Link header, as <http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-04> does. So, while the Link header is generic, and indeed link relations (whether it's "stylesheet", "manifest" or something else) are also generic, a particular *application* of linking (e.g., "should my browser load a manifest?") ought to specify what link serialisations it expects to be used, to improve the chances of interop. The ones chosen have a lot to do with how they're expected to be authored and consumed. Of course, it doesn't make much sense to prohibit other serialisations, because it might be useful for some people, and anyway that's not how the Web works. Cheers, On 12 Dec 2013, at 6:21 am, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2013-12-11 19:59, Marcos Caceres wrote: >> On Wednesday, December 11, 2013, Julian Reschke wrote: >> >> On 2013-12-11 13:13, Mounir Lamouri wrote: >> >> On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote: >> >> Would any potential implementer consider supporting a HTTP >> based solution >> to loading manifests? >> >> >> It seems quite premature to discuss a HTTP based solution to >> advertise a >> manifest. Even if it happens to be something developers ask for, >> we will >> anyway need to provide a <link> solution. It seems that the best >> course >> of actions we could take here is to implement the manifest >> feature using >> <link> and gather developer feedback to evaluate that alternative. >> >> >> If you define a way using <link>, the alternative approach using the >> Link: header field essentially comes for free. >> >> >> Mark seems to imply otherwise: for example, Mark says that "[Link:] was >> never specified to be used with the "stylesheet" relation". >> >> https://github.com/w3c/manifest/issues/98#issuecomment-30293586 > > I see the comment but I have no idea what he's talking about. > > The spec is generic; and the IANA registry (<http://www.iana.org/assignments/link-relations/link-relations.xhtml>) has a "stylesheet" entry. > > Firefox implements this for CSS and XSLT, Opera (classic) did for CSS. > >> If that's the case, then neither would manifest? I also thought >> Link: was more or less generic. I should read the spec in detail. > > It's totally generic. > > Best regards, Julian > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 12 December 2013 00:11:54 UTC