W3C home > Mailing lists > Public > public-ldp-wg@w3.org > February 2013

ldp-ISSUE-49 (Canonical-URI): Canonical URL - how to communicate its value to clients

From: Linked Data Platform (LDP) Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Wed, 13 Feb 2013 13:25:08 +0000
Message-Id: <E1U5cKi-0005Yk-28@tibor.w3.org>
To: public-ldp-wg@w3.org
ldp-ISSUE-49 (Canonical-URI): Canonical URL - how to communicate its value to clients

http://www.w3.org/2012/ldp/track/issues/49

Raised by: John Arwe
On product: 

https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#general clause 4.1.4 states: 4.1.4 Clients can access a LDPR using multiple URLs, for example when DNS aliasing is used. A LDPR server must respond to each of those requests using a single consistent URL, a canonical URL, for the LDPR which may be found in the response's Location header and potentially also in the representation of the LDPR. Clients should use the canonical URL as an LDPR's identity; for example, when determining if two URLs refer to the same resource clients need to compare the canonical URLs not the URLs used to access the resources. 

I want to verify that the WG believes the Location header is the appropriate vehicle for communicating the canonical URI for a resource. 

[2] Location is only clearly defined in 2616 for 201 and 3xx.  [3] opens the aperture a bit, but still is only "really clear" about the same cases; the status pages for httpbis imply it's still open for comments if we want to tilt that windmill.  [3] is a lot better on relative URI values and URIs with fragments.  [3] punts to the status code definition to tell one which resource the Location refers to, so (for things like 200-OK) its use is currently undefined as I read things.

[4] Content-Location says it is representation metadata (this phrasing is clearer in bis, but bis is supposed to be compatible/clarifying 2616 not changing it).  2616 says it is undefined for PUT/POST *requests* (nothing special about put/post responses, just all-responses statements), but bis explicitly talks about its interpretation in those contexts.  Both have cache interactions.

The original use of C-L appears to have been cases where you GET a resource subject to conneg, the server offers several different representations, and each representation is ALSO a URI-addressable resource.  The original use of L appears to have been only Create and redirects.

Neither is a perfect match.  The first line of [4] is probably what led me to think C-L would be better than L for this purpose (it's a perfect fit, reading just that), but with [5]'s clarification it seems like a "definitely not right" fit.  L seems underspecified but we can look at it as we're filling in that blank.  

Looking through the link relations registry, I see "canonical" being defined in RFC 6596 [6] (Info'l though, not Standards track, but I'm unclear how much that matters in a case like this - it is in The link relation registry)

[2] http://tools.ietf.org/html/rfc2616#section-14.30     2616-Location
[3] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-8.1.2		bis-Location
[4] http://tools.ietf.org/html/rfc2616#section-14.14					2616-Content-Location
[5] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-3.1.4.2	bis-Content-Location
[6] http://tools.ietf.org/html/rfc6596
Received on Wednesday, 13 February 2013 13:25:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC