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

Joachim Kupke <> Sat, 09 July 2011 02:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11EF921F8AEE; Fri, 8 Jul 2011 19:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gJQVpzImNaKR; Fri, 8 Jul 2011 19:44:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2C10E21F8AEA; Fri, 8 Jul 2011 19:44:05 -0700 (PDT)
Received: by pzk5 with SMTP id 5so2501192pzk.31 for <multiple recipients>; Fri, 08 Jul 2011 19:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6+rwG4PkTHj3IKyJ2dJTgRpE027ZdlmJ7DWDySYQhAc=; b=j+FC7dj9VIhWj2bF6PZnPe7OMCrSh7DsxvxVsodtppMHIFSdn90LXVVGChSoClA72+ H9mPr5LidjCU4vzLjtfIfxaD5S/k7fY4wXGNTSLx3SzhO9lDFulX2IRot0k+ghayM2ML Mo3JyHNRItbQyXPuiDw9n0reet6IqwaGhhbvM=
MIME-Version: 1.0
Received: by with SMTP id x10mr3728454pbn.424.1310179444813; Fri, 08 Jul 2011 19:44:04 -0700 (PDT)
Received: by with HTTP; Fri, 8 Jul 2011 19:44:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <1309613470.2807.17.camel@mackerel> <> <> <>
Date: Fri, 08 Jul 2011 19:44:04 -0700
X-Google-Sender-Auth: aGVrj6uA2qd7kxyd_OPPV1IYUzU
Message-ID: <>
From: Joachim Kupke <>
To: Julian Reschke <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 09 Jul 2011 09:13:27 -0700
Cc: "" <>, IETF Apps Discuss <>, Maile Ohye <>, Bjartur Thorlacius <>
Subject: Re: [apps-discuss] [link-relations] 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: Sat, 09 Jul 2011 02:44:38 -0000

On Sun, Jul 3, 2011 at 12:55 AM, Julian Reschke <> wrote:
> On 2011-07-03 03:23, Maile Ohye wrote:
>> 2. OPEN. F. Ellermann:
> I'm not sure I understand the response. Is there a use case where an author
> would legitimately add multiple instances of the link relation?

It is quite conceivable that an author might want to designate
multiple instances of the relation with different attributes, e.g.:

<link rel="canonical" href=""
<link rel="canonical" href=""

It is recommended not to do that because it would foist additional
complexity on implementations, and---without being presumptuous---it
appears that encoding attributes such as media into the URI itself can
do more harm than good.

This recommendation might become less valid over time.  For example,
it has become rather common to encode the language (or country) of a
resource into the URI when there would have been other means of their
designation as well (such as, the Accept-Language HTTP header).

>> 5. OPEN. M. Yevstifeyev:
>>>  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).
>> --response by J. Reschke "I think this link relation is purely advisory,
>> so a better approach might be to replace "MAY" by "can"."

Reading paragraph 5 of RFC 2119, I don't see anything wrong with
"MAY."  How is "can" better?

It's indeed not a "SHOULD" since a typical implementation, say in a
search engine, will want to go to some length to find evidence for
misguided usage of the relationship and in the presence of such
evidence decide to ignore it.  The point of "MAY" is to make clear
that in the absence of such evidence, the responsibility not to
advertise an erroneous "canonical" relationship lies with the author
of the context URI.

>> 7. OPEN. M. Yevstifeyev:
> a) A non-HTML document at a non-HTTP(s) URI may not be able to specify the
> link relation, but it could be the target of a link, relation, right?


> b) Future protocols might have other means to specify a link relation, btw.

Is there terminology that reasonably unifies errors across protocols
(HTTP response code 4xx, GOPHER item type 3, FTP response code 5xx)?