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

[Julian Reschke <[e-mail]>]

On 2011-07-09 04:44, Joachim Kupke wrote:
> ...
>>> 5. OPEN. M. Yevstifeyev:
>>>>
>>>>   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).
>>> --response by J. Reschke "I think this link relation is purely advisory,
>>> so a better approach might be to replace "MAY" by "can"."
>
> Reading paragraph 5 of RFC 2119, I don't see anything wrong with
> "MAY."  How is "can" better?
> ...

See RFC 2119, Section 6:

> 6. Guidance in the use of these Imperatives
>
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.

So my recommendation is NOT to use these kinds of keywords unless when 
needed as described above (but I realize that many people disagree with 
me...)

> ...
>> b) Future protocols might have other means to specify a link relation, btw.
>
> Is there terminology that reasonably unifies errors across protocols
> (HTTP response code 4xx, GOPHER item type 3, FTP response code 5xx)?
> ...

I don't think so...

Best regards, Julian