The Canonical Link Relation
RFC 6596

Note: This ballot was opened for revision 04 and is now closed.

(Peter Saint-Andre; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2012-01-02)
No email
send info
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"?

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -04)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection (2012-01-04 for -)
No email
send info
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.

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection (2012-01-02 for -)
No email
send info
I too tripped over the concept of canonical being used in the same sentence as vastly/extremely similar; therefore, I support Russ' discuss.  

(Stephen Farrell; former steering group member) No Objection

No Objection (2011-12-30 for -)
No email
send info
- A non-compromised site might also well lie about which URI
is "canonical" for various purposes.

(Stewart Bryant; former steering group member) No Objection

No Objection (2012-01-03 for -)
No email
send info
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.

(Wesley Eddy; former steering group member) No Objection

No Objection (2012-01-02 for -)
No email
send info
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.