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

Julian Reschke <julian.reschke@gmx.de> Sat, 09 July 2011 09:00 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0021F86AD for <apps-discuss@ietfa.amsl.com>; Sat, 9 Jul 2011 02:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.856
X-Spam-Level:
X-Spam-Status: No, score=-104.856 tagged_above=-999 required=5 tests=[AWL=-2.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufVnTEld8UqS for <apps-discuss@ietfa.amsl.com>; Sat, 9 Jul 2011 02:00:53 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D460721F86AA for <apps-discuss@ietf.org>; Sat, 9 Jul 2011 02:00:52 -0700 (PDT)
Received: (qmail invoked by alias); 09 Jul 2011 09:00:50 -0000
Received: from p508FA64C.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.166.76] by mail.gmx.net (mp015) with SMTP; 09 Jul 2011 11:00:50 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/2mpV9CSH2pndSylH0uvV176u0VSQiOo2Y/3FVKI QnELehDFQ10Z4x
Message-ID: <4E1818B9.8030804@gmx.de>
Date: Sat, 09 Jul 2011 11:00:41 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Joachim Kupke <joachim@kupke.za.net>
References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com> <4E0DCFEF.20206@gmx.de> <4E0DEA77.3050007@gmail.com> <4E0E0E76.2080007@gmail.com> <4E0E995A.7060800@gmail.com> <4E0F1058.3050201@gmail.com> <1309613470.2807.17.camel@mackerel> <4E0F1F2F.8020504@gmail.com> <CAGKau1GyaxpgZsZmUcqZp1iUG6wrvSG3LHM3Pq52AjXfZz900Q@mail.gmail.com> <4E10208C.6090209@gmx.de> <CAKACZovTrCEkFRvN94BW4NChko3_J=FzsAmc37jAJ6YnnjeOeg@mail.gmail.com>
In-Reply-To: <CAKACZovTrCEkFRvN94BW4NChko3_J=FzsAmc37jAJ6YnnjeOeg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "link-relations@ietf.org" <link-relations@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, Maile Ohye <maileko@gmail.com>, Bjartur Thorlacius <svartman95@gmail.com>
Subject: Re: [apps-discuss] [link-relations] Fwd: I-D Action: draft-ohye-canonical-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jul 2011 09:00:54 -0000

On 2011-07-09 04:44, Joachim Kupke wrote:
> ...
>>> 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?
> ...

See RFC 2119, Section 6:

> 6. Guidance in the use of these Imperatives
>
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.

So my recommendation is NOT to use these kinds of keywords unless when 
needed as described above (but I realize that many people disagree with 
me...)

> ...
>> 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)?
> ...

I don't think so...

Best regards, Julian