Subject: [link-relations] 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: 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