Team discussion - on refining Best Practice around use of canonical URLs

Team,

Please be advised that we need to work together to refine the following
statement in the Best Practices and Guidelines document:

2.11 Respond with canonical URLs and use them for identity comparison
>


> Clients can access an LDPR using multiple URLs. An LDPR server should
> respond to each of those requests using a single consistent URL, a
> canonical URL, for the LDPR. This canonical URL may be found in the
> response's Location and/or Content-Location headers, and potentially also
> in the representation of the LDPR. A common case is URLs that vary by
> protocol, one HTTP and one HTTPS, but are otherwise identical. In most
> cases those two URLs refer to the same resource, and the server should
> respond to requests on either URL with a single (canonical) URL.
>


> Clients should use the canonical URL as an LDPR's identity; for example,
> when determining if two URLs refer to the same resource clients should
> compare the canonical URLs, not the URLs used to access the resources.


Here's the issue:

Henry has suggested that we refer to a definition of "canonical URL".
However, it seems that some standard definition is not easily found (on the
Web). Here's what Henry said.

Canonical urls may need to refer to the definition in the URL spec. ( I
> think that's where the term is found ) It removes things like ../ in urls.


I thought that, perhaps, we could point to URL Normalization in RFC3986
http://tools.ietf.org/html/rfc3986#page-38, however, it seems that the team
does not agree that will be sufficient.

On the last WG call, it was determined that if we are going to use a term
like "canonical URL", we should either A) point to a definition or our
meaning or B) create a definition of our meaning.

Ashok said he had some information he would dig up (please provide, Ashok).

It was also suggested on the call that our meaning is, or is similar to el="
canonical".

Then, it will be of great help if we can all work together to refine this
Best Practice statement.



-- 
Cody Burleson