The Canonical Link Relation
draft-ohye-canonical-link-relation-05

[Ballot comment]
Please consider adding text explaining when a user might choose to go against the SHOULD NOTs in section 3.

It might help to cast the  last 4 bullets in section 3 as requirements on maintaining the link relation, rather
than just creating it. You might also make it clear whether transient errors are of concern in the 3rd bullet.

[Ballot comment]
I cleared my Discuss after an exchange with the AD.

---

Building on Brian's review in Russ's Discuss...

If URIs are identical there is surely no isse to designating one of them
as preferred. They are the same, and selecting any one is the same as
selecting any other.

I suspect this is just loose language since it is obvious from the
content (versus the Abstract) that you mean that it is the identical
nature of the content returned by URIs that is what you define as
making the URIs identical.

Maybe you could go over this with a pedant's eye?

---

Section 3 contains some examples of "SHOULD NOT". The subsequent
paragraphs got my hopes up by starting with "MAY", but actually they do
not address the exception cases of the "SHOULD NOT." Since you have
chosen "SHOULD NOT" rather than "MUST NOT", you need to explain the
option for varying the rule.

---

Section 5

  Before adding the canonical link relation, verification of the
  following is recommended:

Is that "RECOMMENDED"?

[Ballot comment]
I support Russ's discuss and wonder if "Canonical" is actually the correct term. Canonical normally implies a more precise equivalence than the author describes in the document. I think that the text is describing the preferred link relation.

[Ballot comment]
In Section 5, the first and third recommendations may be very difficult to use practically for sites where the majority of content is generated dynamically.  I don't think this document makes clear/strong enough statements on how this would/could/should be used for dynamic versus static resources, however, I defer to the judgement of the ADs closer to this topic.

[Ballot comment]
Building on Brian's review in Russ's Discuss...

If URIs are identical there is surely no isse to designating one of them
as preferred. They are the same, and selecting any one is the same as
selecting any other.

I suspect this is just loose language since it is obvious from the
content (versus the Abstract) that you mean that it is the identical
nature of the content returned by URIs that is what you define as
making the URIs identical.

Maybe you could go over this with a pedant's eye?

---

Section 3 contains some examples of "SHOULD NOT". The subsequent
paragraphs got my hopes up by starting with "MAY", but actually they do
not address the exception cases of the "SHOULD NOT." Since you have
chosen "SHOULD NOT" rather than "MUST NOT", you need to explain the
option for varying the rule.

---

Section 5

  Before adding the canonical link relation, verification of the
  following is recommended:

Is that "RECOMMENDED"?

[Ballot discuss]
AFAICS, new IANA registrations require a specification (this document)
and expert review. Have the experts looked at this request yet? I don't
see anything in the Write-up.

[Ballot discuss]
The Gen-ART Review by Brian Carpenter on 14-Dec=2011 raised one
  minor issue that deserves a response.  The review says:

  > The canonical link relation specifies the preferred URI from a set
  > of URIs that return identical or vastly similar content, ...

  I don't understand the phrase "vastly similar". I don't understand
  what algorithm tests for vast similarity.

  The same applies to "extremely similar" in section 3 and "similar to"
  in section 5.  Also, "similar to" is weaker than "vastly similar" or
  "extremely similar"; so does section 5 intend to weaken the earlier
  text? It seems that exactly the same phrase should be used in each
  case (not just a vastly similar phrase).

  This doesn't matter so much when it's a human designating the
  canonical relation.  But it can only be a matter of time before code
  starts to do this (which page is canonical among a set of generated
  pages?). A vague word like "similar" turns this into an AI problem.

Upon approval of this document, IANA will replace the current
"canonical" Link Relation Type registered at
http://www.iana.org/assignments/link-relations as follows:

OLD:

Name: canonical
Description: A "canonical" URI is the preferred version of a set of URIs
with highly similar content. It is intended to help search
engines when the same or highly similar similar content is
available at different URIs.
Reference:
[http://www.google.com/support/webmasters/bin/answer.py?answer=139394]
Notes: In http://www.mattcutts.com/blog/canonical-link-tag/ and
http://gregable.com/2009/02/relcanonical.html the authors state that
Ask, Bing, Google, and Yahoo supported canonical URIs as of February, 2009.

NEW:

Name: canonical
Description: Designates the preferred version of a resource (the URI and
its contents).
Reference: [RFCXXXX]
Notes:

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Canonical Link Relation) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The Canonical Link Relation'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-12-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  [RFC5988] specified a way to define relationships between links on
  the web.  This document describes a new type of such relationship,
  "canonical," which designates the preferred URI from a set of
  identical or vastly similar ones.

Editorial Note (To be removed by RFC Editor)

  Distribution of this document is unlimited.  Comments should be sent
  to the IETF Apps-Discuss mailing list (see
  ).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ohye-canonical-link-relation/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ohye-canonical-link-relation/


No IPR declarations have been submitted directly on this I-D.