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

[Joachim Kupke <[e-mail]>]

Julian Reschke <[e-mail]> wrote:
> Joachim Kupke <[e-mail]> wrote:
>> Reading paragraph 5 of RFC 2119, I don't see
>> anything wrong with
>> ‘MAY.’  How is ‘can’ better? It's indeed not a ‘SHOULD’ since a typical
>> implementation, say in a search engine, will want to go to some length to
>> find evidence for misguided usage of the relationship and in the presence of
>> such evidence decide to ignore it.  The point of ‘MAY’ is to make clear that
>> in the absence of such evidence, the responsibility not to advertise an
>> erroneous ‘canonical’ relationship lies with the author of the context URI.”
>
> See RFC 2119, Section 6:
[...]

It's true that the imperatives of RFC 2119 (including
"MAY"/"OPTIONAL") are supposed to pertain to the format of data that
is exchanged (e.g., this and that field MAY be omitted, or this and
that proxy MAY have rewritten something), but interoperability goes
beyond that; hence the desire to give the two points where MAY is used
in the draft some more formal meaning.

Specifically, a <link rel="canonical"> supposedly gives carte blanche
to, say, an application to organize bookmarks, to rewrite a bookmarked
URI to its rel=canonical variant, if any (and non-self-referential).
Or, say, Wikipedia could crawl its external links and automatically
update those that now have a "canonical" relationship with another URI
(or, for that matter, have become an HTTP 301 redirect).  In order not
to break such applications, it is fairly important for implementations
of rel="canonical" not to designate URIs that are meaningless
substitutions for links to the context URI.

Speaking of HTTP redirects, RFC 2616 uses the wording that "[c]lients
with link editing capabilities *ought to* automatically re-link
references" to URIs that have become 301 redirects; and for a 300
"multiple choices" URI, "user agents *MAY* use the Location field
value for automatic redirection" (both emphases added).  It appears
the latter point is no more required for interoperability than what
the occurrences of "MAY" in this draft allude to.

With that said, it's closer in spirit to the provisions of 301
redirects, so I'd be happy to see the draft changed as follows:

diff before after
index 5f01f55..4ed47b8 100644
--- before
+++ after
@@ -66,10 +66,9 @@ Internet-Draft         The Canonical Link Relation
 1.  Introduction

    The canonical link relation specifies the preferred URI from a set of
-   identical or vastly similar content accessible on multiple URIs.
-   This designation MAY be used for future references to this resource,
-   and clients with link editing capabilities MAY automatically re-link
-   references to the context URI to the designated URI.
+   identical or vastly similar content accessible on multiple URIs, to
+   make it possible for references to the context URI to be updated to
+   reference the designated URI.

    The most common application of the canonical link relation includes
    specifying the preferred version of a URI from duplicate content
@@ -86,8 +85,8 @@ Internet-Draft         The Canonical Link Relation

    The canonical (target) URI MUST identify content that duplicates, is
    extremely similar, or is a superset of the content at the context
-   (referring) URI.  Presence of the canonical link relation indicates
-   to applications, such as search engines, that they MAY:
+   (referring) URI.  Authors who declare the canonical link relation
+   ought to anticipate that applications such as search engines can:

    o  Index content only from the canonical target (i.e. content from
       the context URIs will be likely disregarded as duplicative).

--Joachim