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

[Mykyta Yevstifeyev <[e-mail]>]

31.08.2011 9:20, Julian Reschke wrote:
> 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.

It is already obvious that target URI must conform to RFC 3986 
<URI-Reference> from RFC 5988:

>    Link           = "Link" ":" #link-value
>    link-value     = "<" URI-Reference">" *( ";" link-param )

and, correspondingly, the target URI *is* (rather than *MAY be*) 
<URI-Reference>.  If the authors want to clarify that target URI may be 
relative, my proposed text is better.

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

 From Section 10.4 of RFC 2616:

>     The 4xx class of status code is intended for cases in which the
>     client seems to have erred.

So 4xx responses are used when something is wring with HTTP request.  I 
doubt there are alternatives of such definition in *all* protocols for 
which the URI scheme has been specified.  Eg., FTP doesn't alter error 
conditions caused by client or server; neither does TFTP and many others.

We aren't defining the link relation fro 'http' and 'https' URIs only; 
it is theoretically to allow any scheme, including not yet defined.

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

See above.

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

See above as well.  Why tie ourselves with HTTP only?

Mykyta

>
> > ...
>
> Best regards, Julian
>