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

[Julian Reschke <[e-mail]>]

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