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

Mykyta Yevstifeyev <> Fri, 01 July 2011 03:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 769761F0C4F; Thu, 30 Jun 2011 20:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l54glfAynd55; Thu, 30 Jun 2011 20:26:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7CEC61F0C4B; Thu, 30 Jun 2011 20:26:49 -0700 (PDT)
Received: by fxe4 with SMTP id 4so3627917fxe.27 for <multiple recipients>; Thu, 30 Jun 2011 20:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C68y6oF2J46LdaDar+rb31HojWC5rEEiss9m7ZYOCfc=; b=Pkmc8A8KMaCthIuQhANJK1QX7uimRbuJi9ES9xNCoyuL40JwCsQceXG6uHS35DClgm JGoQKgIotPv/zozEq/eB8Xz7PIJZn9VQnaWu2DXypYOKgrowlJAmGpGOj+DIIA4yc4LH TjziigD8KdM9IT63+cN69S4oSOjFKjLb/yrFo=
Received: by with SMTP id k28mr4056953fah.27.1309490808651; Thu, 30 Jun 2011 20:26:48 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id 21sm1902916fay.21.2011. (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 20:26:47 -0700 (PDT)
Message-ID: <>
Date: Fri, 01 Jul 2011 06:27:33 +0300
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "" <>, IETF Apps Discuss <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Jul 2011 03:26:50 -0000

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 
( 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 

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 

>     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 

Mykyta Yevstifeyev

27.06.2011 11:20, Julian Reschke wrote:
> 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