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

Julian Reschke <julian.reschke@gmx.de> Fri, 01 July 2011 13:47 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 1D8121F0C51 for <apps-discuss@ietfa.amsl.com>; Fri, 1 Jul 2011 06:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level:
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.000, 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 XY5ob+AfMdDY for <apps-discuss@ietfa.amsl.com>; Fri, 1 Jul 2011 06:47:33 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 83F3E1F0C4C for <apps-discuss@ietf.org>; Fri, 1 Jul 2011 06:47:32 -0700 (PDT)
Received: (qmail invoked by alias); 01 Jul 2011 13:47:30 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp019) with SMTP; 01 Jul 2011 15:47:30 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+nBJcG+eWnhGl7Q/HXaMejGLHdJ5guNoWARtOaky cNRqktwujtEOLt
Message-ID: <4E0DCFEF.20206@gmx.de>
Date: Fri, 01 Jul 2011 15:47:27 +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: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <4E083D3F.6030200@gmx.de> <4E0D3EA5.7010803@gmail.com>
In-Reply-To: <4E0D3EA5.7010803@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
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: Fri, 01 Jul 2011 13:47:33 -0000

On 2011-07-01 05:27, Mykyta Yevstifeyev wrote:
> 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.

We do not need to decide this now, and I expect the Area Director who's 
going to sponsor this to have an opinion on it.

That being said, "Informational" should be fine (Maile: that would be 
category="info" on the <rfc> element).

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

Why? It defines a link relation as defined by RFC 5988, so why repeat 
text from over there?

> 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 think this link relation is purely advisory, so a better approach 
might be to replace "MAY" by "can".

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

Yes.

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

Sounds good.

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

Nope; I think the HTTP examples are very useful. But maybe we can have 
an additional statement that the link relation isn't specific to HTTP.

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

I believe we'll need this section, and the contents is fine; after all, 
this is what you have to think of with respect to I18N, no?

> ...

Best regards, Julian