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

Julian Reschke <> Fri, 01 July 2011 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D8121F0C51 for <>; Fri, 1 Jul 2011 06:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XY5ob+AfMdDY for <>; Fri, 1 Jul 2011 06:47:33 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 83F3E1F0C4C for <>; Fri, 1 Jul 2011 06:47:32 -0700 (PDT)
Received: (qmail invoked by alias); 01 Jul 2011 13:47:30 -0000
Received: from (EHLO []) [] by (mp019) with SMTP; 01 Jul 2011 15:47:30 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+nBJcG+eWnhGl7Q/HXaMejGLHdJ5guNoWARtOaky cNRqktwujtEOLt
Message-ID: <>
Date: Fri, 01 Jul 2011 15:47:27 +0200
From: Julian Reschke <>
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 <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: IETF Apps Discuss <>, "" <>
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 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.


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