Subject: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Jun 2011 10:20:15 +0200

(FYI)

-------- Original Message --------
Subject: I-D Action: draft-ohye-canonical-link-relation-00.txt
Date: Sun, 26 Jun 2011 22:46:52 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : The Canonical Link Relation
	Author(s)       : Maile Ohye
	Filename        : draft-ohye-canonical-link-relation-00.txt
	Pages           : 6
	Date            : 2011-06-26

    This specification defines the canonical link relation -- an element
    which designates the preferred version of content/URI from a set of
    duplicate or near duplicate pages.

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
    &lt;https://www.ietf.org/mailman/listinfo/apps-discuss&gt;).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 30 Jun 2011 10:24:17 +0200

>        Filename        : draft-ohye-canonical-link-relation-00.txt

A relative canonical URL can't be a good idea.  If there is more than
one "content URL" (in the terminology of the draft) this would result
in more than one canonical URL, defeat the purpose, and worse, this
could make googlebot angry.

The draft could s/SHOULD NOT/MUST NOT/, I don't see any good reason
to violate a SHOULD NOT, and if that's correct MUST NOT is clearer.

-Frank

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 01 Jul 2011 06:27:33 +0300

Hello Maile,

Several comments to your draft-ohye-canonical-link-relation-00.

There is the Intended Status missing in it.  I suppose Informational 
should be fine.

> 1. Introduction
>
>    The canonical link relation specifies the preferred version of a URI
I think some introductory text on linking, probably based on RFC 5988, 
should go here.

Section 2:

>     Presence of the canonical link relation indicates
>     to applications, such as search engines, that they MAY:
I wonder why it's MAY; in this case implementations (explicitly, those 
apps which interpret Link: headers and corresponding construction in 
HTML) will be free to ignore it.  I think normative SHOULD should be OK 
(sorry for pun).

I support the remark from Frank Ellermann 
(http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02870.html) about 
SHOULD NOTs in the document.

>     The value of the target/canonical URI MAY:
I suppose omitting "value of the" should be better, since there is no 
such term in RFC 3986.  In fact, when referring the URI, we mean its 
value, meaning.

>     o  Exist on a different protocol: http to https, or vice versa
You probably meant URI scheme here, since https isn't a separate 
protocol.  As before these points we had "The value of the 
target/canonical URI MAY" or, if you consider my comment above, "The 
target/canonical URI MAY", this point may be reworded as "Have different 
scheme names" (which suits the second variant of a preface to this list 
better).

Reading section 3 and 5 of the draft, it seems that is mandates use of 
HTTP when referring to canonical URIs.  And what is the situation when 
target URI is a 'ftp' or 'gopher' URI?  Section 3 allows different 
scheme names in context/target URIs, if I understand it correctly.  
Therefore, unless it is deliberately, I think any mention of HTTP should 
be replaced by more generic regulations.

> 8.  Internationalisation Considerations
>
>     In designating a canonical URI, please see [RFC3986] for information
>     on URI encoding.
URIs themselves are not internationalized, in terms of RFC 3536, which 
defined:

>     internationalization
>
>        In the IETF, "internationalization" means to add or improve the
>        handling of non-ASCII text in a protocol.<NONE>
IRIs serve for this purpose.  I recommend either to rename the section 
to Encoding considerations or skip it at all ( I personally like 2nd 
variant).

Thanks,
Mykyta Yevstifeyev