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

[Julian Reschke <[e-mail]>]

On 2011-08-31 06:34, Mykyta Yevstifeyev wrote:
> ...
> Section 3:
>
>>     The target/canonical URI MAY:
>>
>>     o  Specify a URI Reference (see [RFC3986] Section 4.1) i.e., an
>>        absolute URI or a relative reference
>
> What you mean here? If you wanted to show that canonical URI may be a
> relative one, you should better write:
>
>>     The target/canonical URI MAY:
>>
>>     o  Be a relative URI (see [RFC3986], Section 4.2);

The original text seems to be clearer to me.

> Ibid:
>
>>     o  A URI that serves a 4xx error code (Section 10.4 of [RFC2616]).
>
> Again, HTTP-centric approach. There are many other application-layer
> protocols, for which URI schemes exist, and they aren't very likely to
> even have the same req/response model as HTTP has. As this is only
> available in HTTP, I propose to exclude this bullet, unless you can
> reformulate it so that it doesn't use HTTP-only feature.

-1. This is useful information. Just because something is specific 
doesn't mean it shouldn't be mentioned.

>>     o  The first page of a multi-page article or multi-page listing of
>>        items (since the first page is not a duplicate or a superset or
>>        the context URI).  For example, page2 and page3 of an article
>>        SHOULD NOT specify page1 as the canonical.
>
> Here you may point to Section 6.12 of you reference
> [REC-html401-19991224], which specifies the 'start' relation
> (http://www.w3.org/TR/1999/REC-html401-19991224/types.html#idx-link_type),
> used for this purpose.

+-0.

> In Section 5:
>
>>     2.  Permanent HTTP redirects (Section 10.3.2 of [RFC2616]), the
>>         traditional strong indicator that a URI's content has been
>>         permanently moved, could not be implemented in place of the
>>         canonical link relation.
>
> Also too HTTP-centric approach. The same as above applies.

-1

> References:
>
> Why make RFC 2616 and HTML4 spec Normative references? Shouldn't
> Informative be OK?

For 2616 is makes sense if there are normative constrains specific for HTTP.

 > ...

Best regards, Julian