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

Mykyta Yevstifeyev <evnikita2@gmail.com> Sat, 02 July 2011 13:17 UTC

Return-Path: <evnikita2@gmail.com>
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 5058621F860F; Sat, 2 Jul 2011 06:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.55
X-Spam-Level:
X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 uYz8v4zBxSI7; Sat, 2 Jul 2011 06:17:34 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 761EE21F85E0; Sat, 2 Jul 2011 06:17:34 -0700 (PDT)
Received: by fxe4 with SMTP id 4so4945393fxe.27 for <multiple recipients>; Sat, 02 Jul 2011 06:17:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ebmIVJG1PZiNupQrVBmhMmxUszakiD7UEotJ6mfsMzs=; b=MoDYOrAk9eF1EL3CKSY7u8SsPVlT/rwMN9aHGWA6Bo6wtlESW3VF43bRQds/te6Kir /QCvE22muN74xqBTXX1mRMaKOyBs3PET9GaBMVU7qUuBbljm6J6RLLUCSdr8SWuknCFh BNXFJfiiQTyMD8rHgpko02YBYEQ/6ISmRm/Po=
Received: by 10.223.36.89 with SMTP id s25mr6502898fad.9.1309612649047; Sat, 02 Jul 2011 06:17:29 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id g12sm3080608fai.8.2011.07.02.06.17.27 (version=SSLv3 cipher=OTHER); Sat, 02 Jul 2011 06:17:27 -0700 (PDT)
Message-ID: <4E0F1A95.2030701@gmail.com>
Date: Sat, 02 Jul 2011 16:18:13 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Bjartur Thorlacius <svartman95@gmail.com>
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>
In-Reply-To: <4E0F1058.3050201@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, "link-relations@ietf.org" <link-relations@ietf.org>
Subject: Re: [apps-discuss] 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, 02 Jul 2011 13:17:35 -0000

02.07.2011 15:34, Bjartur Thorlacius wrote:
> Þann lau  2.júl 2011 04:06, skrifaði Mykyta Yevstifeyev:
>> First, this was an example only. Next, my point was that the document
>> makes HTTP/'http' scheme mandatory in context/target URIs, which I don't
>> think is appropriate, since canonical URI may refer to a resource
>> accessible via other protocol. Even though HTTP is going to be the most
>> often use case of canonical link relation, we shouldn't exclude other
>> protocols.
> I agree. However, I don't understand the need for forbidding canonical 
> links to resources with multiple representations. Are there not to be 
> canonical links from representations of a resource to the resource 
> (i.e. from /spec.html and /spec.txt to /spec)?
Probably such restriction is set because multiple representation choice 
may ultimately refer the user to a resource which is not canonical.  A 
_definite_ canonical resource is necessary and required.