- From: Phil Archer <parcher@icra.org>
- Date: Tue, 25 Mar 2008 14:59:50 +0000
- To: Public MWBP <public-bpwg@w3.org>
As I believe Tuesday is CT TF day, I'll just give a little update on this. There is a wiki page being maintained by Jonathan Rees on this issue at [1]. He repeated his call for use cases over the weekend [2] to which I responded [3]. There's a load more on this issue over on the TAG list (and, confusingly, on the HTTP-WG list too) but the consensus seems to be emerging around Mark Nottingham's (updated) draft at [4]. The key discussion has been around the value of the rel attribute. The way it's heading is as Mark N sets out. The value is a URI. If a relative URI is given, such as 'stylesheet', then the assumption must be that it is relative to the IANA registry's namespace which is http://www.iana.org/assignments/link-relations.html#". If you don't want to use an IANA rel type (and don't want to register it) then you give a complete URI, such as http://www.w3.org/2008/03/noTransform. Such an HTTP Link Header would be semantically equivalent to an HTML Link tag or an RDF triple of the form <resource> describedBy <description> (Indeed, describedBy may well be the term used, in which case, the POWDER WG may well choose to use this and not rel="powder" - time will tell). HTH. Phil. [1] http://esw.w3.org/topic/FindingResourceDescriptions [2] http://lists.w3.org/Archives/Public/www-tag/2008Mar/0105.html [3] http://lists.w3.org/Archives/Public/www-tag/2008Mar/0114.html [4] http://tools.ietf.org/html/draft-nottingham-http-link-header-01 Jo Rabin wrote: > Hi Phil > > Thanks for the gentle reminder of the need for action. ISSUE-238 and > ACTION-703 both have a direct relevance to this, and both are > essentially down to me to chase. I hadn't forgotten our call, or either > of these actions, it's just that I have been running around like a > headless chicken since the Seoul F2F and have only just managed to get > my head back above water (if that is not too grotesque a mixed > metaphor). > > There will definitely be input from BP on this, but there are definitely > only 24 hours in each day. > > Jo > > --- > Jo Rabin > mTLD (http://dotmobi.mobi) > > mTLD Top Level Domain Limited is a private limited company incorporated > and registered in the Republic of Ireland with registered number 398040 > and registered office at Arthur Cox Building, Earlsfort Terrace, Dublin > 2. > > >> -----Original Message----- >> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] > On >> Behalf Of Phil Archer >> Sent: 17 March 2008 09:53 >> To: Public MWBP >> Subject: HTTP Link Use cases >> >> >> Jo and I discussed this on the phone the other day so this note is >> >> a) to remind him of that conversation; >> b) alert other members of the group to the issue. >> >> We have discussed the potential usefulness of the HTTP Link Header in >> the mobile space in past meetings (I recall doing so most recently at >> TPAC last year). The issue continues to surface and resurface on the >> IETF/W3C HTTP group and has lead to some very recent and extensive >> discussion. Happy Halpin kicked things off this time [1] and this lead >> to mark Nottingham breathing new life into his draft [2]. I chimed in >> with the POWDER use case [3]. In between these are messages from the >> likes of Roy Fielding and Julian Reschke. >> >> The bulk of the discussion centred on the need for/best approach to >> providing an HTTP Profile header, i.e. an extensible and unambiguous > way >> to extend relationship types. It's not as easy as it sounds... >> >> If the MWBP in general, and the CTTF in particular, wishes to support >> the reinstatement of HTTP Link and comment on the wider discussion. > NOW >> is the time when such an input can have most effect. >> >> Cheers >> >> Phil. >> >> >> [1] > http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0444.html >> [2] > http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt >> [3] > http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0499.html >
Received on Tuesday, 25 March 2008 15:00:45 UTC