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

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Jul 2011 15:38:44 +0200

On 2011-06-30 10:24, Frank Ellermann wrote:
>>         Title           : The Canonical Link Relation
>>         Author(s)       : Maile Ohye
>>         Filename        : draft-ohye-canonical-link-relation-00.txt
>
> A relative canonical URL can't be a good idea.  If there is more than
> one "content URL" (in the terminology of the draft) this would result
> in more than one canonical URL, defeat the purpose, and worse, this
> could make googlebot angry.
>
> The draft could s/SHOULD NOT/MUST NOT/, I don't see any good reason
> to violate a SHOULD NOT, and if that's correct MUST NOT is clearer.

I don't understand (yet).

What do you mean by "more than one "content URL""?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Jul 2011 15:47:27 +0200

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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 01 Jul 2011 18:40:39 +0300

01.07.2011 16:47, Julian Reschke wrote:
> 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.
>
So, we both agree on this.
> Why? It defines a link relation as defined by RFC 5988, so why repeat 
It should be mentioned (1) what is link relation at all and (2) that RFC 
5988 is a specification of that technology which this document depends 
on.  RFC 5988 is first mentioned in Examples.
Yes, advisory, which suits RFC 2119 definition for SHOULD:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>     may exist valid reasons in particular circumstances to ignore a
>     particular item, but the full implications must be understood and
>     carefully weighed before choosing a different course.
and natural meaning of should - advice/recommendation.
I didn't mentioned it also applies to (Section 3, last list):

>     The value of the target/canonical URI SHOULD NOT designate:

> an additional statement that the link relation isn't specific to HTTP.
Currently we have normative reference to RFC 2616 and normative 
requirements with respect to HTTP.  HTTP examples are OK; but it's 
redundant in Section 3.  I suppose in Section 3 we may replace 
HTTP-related stuff with something in the way like:

Old:
>     o  The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of
>        [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]).
New:
>     o  The source URI, which defines a resource which provides choice
>        in different represntations of a given resource, ientified by
>        the context URI, or is a link which has been permanently replaced
>        by an other one.
etc.
> 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?
RFC 5988 allows target and context URIs to be IRIs.  Current draft has 
no provisions regarding this.  However, the actual and current text 
matches encoding considerations better.

Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Jul 2011 17:49:48 +0200

On 2011-07-01 17:40, Mykyta Yevstifeyev wrote:
> RFC 5988 allows target and context URIs to be IRIs. Current draft has no
> provisions regarding this. However, the actual and current text matches
> encoding considerations better.
> ...

Actually, there's nothing special about the I18N for this link relation; 
so I believe the text should just state that there's nothing to say in 
addition to RFC 5988, Section 8.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 01 Jul 2011 18:54:22 +0300

01.07.2011 18:49, Julian Reschke wrote:
> Actually, there's nothing special about the I18N for this link 
> relation; so I believe the text should just state that there's nothing 
> to say in addition to RFC 5988, Section 8.
Probably such approach is OK.

Mykyta

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 02 Jul 2011 07:06:50 +0300

01.07.2011 21:14, Bjartur Thorlacius wrote:
> Þann fös  1.júl 2011 15:40, skrifaði Mykyta Yevstifeyev:
>> Old:
> Your wording seems overly confusing. Which is the resource that 
> "provides choice in different represntations of a given resource?" A 
> standard could be assigned the URI <http://example.org/spec>. An HTTP 
> GET /spec might be responded with an HTTP/1.1 300 choice, and an 
> entity linking to /spec.node.html, /spec.html, /spec.pdf, and 
> /spec.txt. The resource (the standard, that is) would in no way 
> provide this choice. The HTTP server simply offered multiple 
> representations.
First, this was an example only.  Next, my point was that the document 
makes HTTP/'http' scheme mandatory in context/target URIs, which I don't 
think is appropriate, since canonical URI may refer to a resource 
accessible via other protocol.  Even though HTTP is going to be the most 
often use case of canonical link relation, we shouldn't exclude other 
protocols.

Mykyta

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 02 Jul 2011 16:18:13 +0300

02.07.2011 15:34, Bjartur Thorlacius wrote:
> Þann lau  2.júl 2011 04:06, skrifaði Mykyta Yevstifeyev:
> I agree. However, I don't understand the need for forbidding canonical 
> links to resources with multiple representations. Are there not to be 
> canonical links from representations of a resource to the resource 
> (i.e. from /spec.html and /spec.txt to /spec)?
Probably such restriction is set because multiple representation choice 
may ultimately refer the user to a resource which is not canonical.  A 
_definite_ canonical resource is necessary and required.

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 02 Jul 2011 16:37:51 +0300

02.07.2011 16:31, Justin Cormack wrote:
> There does seem to not be a discussion of what is similar though in
> terms of media types - is /spec.txt similar enough that /spec.html could
> be a canonical link?
I personally think it is possible.  For example, authoritative RFC 
source is .txt file on RFC Editor's site, while we have a number of 
other sources for RFCs, not in .txt, such as 
"tools.ietf.org/html/rfcXXXX" in HTML.  Designating a "canonical" link 
to "http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems to be OK.  So I 
think we have no problem here.

Mykyta
> One could certainly have a PNG version of an SVG
> image with a canonical link I would presume.
>
> Justin
>

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 2 Jul 2011 20:58:12 +0200

>> could make googlebot angry.
[...]

> What do you mean by "more than one "content URL""?

The rel="canonical" business is for in essence identical content
available at more than one URL.  Simple example, resource xyzzy.html
at http://example.com/xyzzy.hmtl and http://example.org/xyzzy.html

With a relative rel="canonical" URI in xyzzy.html I'd end up with two
different canonical URLs, but then I shouldn't use rel="canonical" in
the first place.

The idea is to get one canonical URL for all (here: both) incarnations
of xyzyy.html.  Well, that's what I meant.  But now I see that relative
can be perfectly fine if and only if all incarnations exist on the same
server, e.g., http://example/xyzzy.html?any-query could get a relative
canonical URL xyzzy.html?default or similar.  A better example in the
draft explaining when a relative canonical URL is okay could help.

-Frank

---

From: Bjartur Thorlacius <[email-masked]>
Date: Fri, 01 Jul 2011 18:14:14 +0000

Your wording seems overly confusing. Which is the resource that 
"provides choice in different represntations of a given resource?" A 
standard could be assigned the URI <http://example.org/spec>. An HTTP 
GET /spec might be responded with an HTTP/1.1 300 choice, and an entity 
linking to /spec.node.html, /spec.html, /spec.pdf, and /spec.txt. The 
resource (the standard, that is) would in no way provide this choice. 
The HTTP server simply offered multiple representations.

---

From: Bjartur Thorlacius <[email-masked]>
Date: Sat, 02 Jul 2011 12:34:32 +0000

I agree. However, I don't understand the need for forbidding canonical 
links to resources with multiple representations. Are there not to be 
canonical links from representations of a resource to the resource (i.e. 
from /spec.html and /spec.txt to /spec)?

---

From: Justin Cormack <[email-masked]>
Date: Sat, 02 Jul 2011 14:31:10 +0100

> from /spec.html and /spec.txt to /spec)?

I think this relation (which is useful) need to be called something
else, as it is performing a different function to canonical, which is
about relations between representations of resources, rather than
between representations of resources and a the resource itself
like /spec.

There does seem to not be a discussion of what is similar though in
terms of media types - is /spec.txt similar enough that /spec.html could
be a canonical link? One could certainly have a PNG version of an SVG
image with a canonical link I would presume.

Justin

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 03 Jul 2011 07:34:10 +0300

Hello Maile, all,

Let me response to my issues only.

03.07.2011 4:23, Maile Ohye wrote:
> 3. CLOSED. M. Yevstifeyev:
> --seconded by J. Reschke
> --added to draft by M. Ohye
Thanks for this clarification.
> 4. OPEN. M. Yevstifeyev:
> --response by J. Reschke "Why? It defines a link relation as defined 
> by RFC 5988, so why repeat text from over there?"
> --response by M. Yevstifeyev "It should be mentioned (1) what is link 
> relation at all and (2) that RFC 5988 is a specification of that 
> technology which this document depends on.  RFC 5988 is first 
> mentioned in Examples."
> --response by M. Ohye. “We could modify to:
> “The canonical link relation (Link Relation Types reference <xref 
> target="RFC5988"/>) specifies the preferred version of a URI...”
I proposed to add something like:
/"RFC 5988 [RFC5988] specified the mechanism which is used to indicate 
relationships between the links on the Internet.  This document defined 
a new type of such relationships - canonical link relation."/
in Section 1 as 1st para; other paragraphs retain in this case.
>
> 5. OPEN. M. Yevstifeyev:
> > Presence of the canonical link relation indicates to applications, 
> such as search engines, that they MAY:
> 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"."
> --response by M. Yevstifeyev "Yes, advisory, which suits RFC 2119 
> definition for SHOULD: 'SHOULD   This word, or the adjective 
> "RECOMMENDED", mean that there may exist valid reasons in particular 
> circumstances to ignore a particular item, but the full implications 
> must be understood and carefully weighed before choosing a different 
> course.'
> and natural meaning of should - advice/recommendation."
> --response by M. Ohye: “Thanks, in discussion with Joachim Kupke.”
Please notify on the list when this issue is resolved.
>
> 6. CLOSED. M. Yevstifeyev:
> --agreed by J. Reschke
> --updated in draft by M. Ohye (in two instances)
Thanks for this.
> 7. OPEN. M. Yevstifeyev:
> 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).
> --agreed by J. Reschke
> --response by M. Ohye/J. Kupke: “Good catch, Mykyta. We’re fine to 
> change the draft to “scheme”:
... And for this correction :-)
> Have different scheme names: such as http to https, or vice versa
> Do we now need to expand the draft for ftp:// and gopher:// URIs? For 
> example, ftp:// and gopher:// URIs”
> 1) Do not come with the equivalent of RFC 5988, so a non-HTML document 
> available at any such URI won't be available to make use of <link 
> rel="canonical">.
> 2) Have corresponding GOPHER error code (item type 3) or an FTP error 
> 550, which like HTTP 404, is forbidden from being served for the 
> target of a <link rel="canonical">.
I don't think we should make such changes.  If we consider ftp and 
gopher URIs, we should also consider all other.  I proposed to add 
generic statements which would be applicable to almost all application 
protocols, not only HTTP, as in current version of the draft.
> 8. OPEN. M. Yevstifeyev:
> 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.
> --response by J. Reschke "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."
> --response by M. Yevstifeyev"Currently we have normative reference to 
> RFC 2616 and normative requirements with respect to HTTP.  HTTP 
> examples are OK; but it's redundant in Section 3.  I suppose in 
> Section 3 we may replace HTTP-related stuff with something in the way 
> like:
>
> Old:
> etc."
> --response by B. Thorlacius: “Your wording seems overly confusing. 
> Which is the resource that "provides choice in different 
> represntations of a given resource?" A standard could be assigned the 
> URI <http://example.org/spec>. An HTTP GET /spec might be responded 
> with an HTTP/1.1 300 choice, and an entity linking to /spec.node.html, 
> /spec.html, /spec.pdf, and /spec.txt. The resource (the standard, that 
> is) would in no way provide this choice. The HTTP server simply 
> offered multiple representations.”
> --response by M. Yevstifeyev: “First, this was an example only.  Next, 
> my point was that the document makes HTTP/'http' scheme mandatory in 
> context/target URIs, which I don't think is appropriate, since 
> canonical URI may refer to a resource accessible via other protocol. 
>  Even though HTTP is going to be the most often use case of canonical 
> link relation, we shouldn't exclude other protocols.”
> --response by B. Thorlacius: “I agree. However, I don't understand the 
> need for forbidding canonical links to resources with multiple 
> representations. Are there not to be canonical links from 
> representations of a resource to the resource (i.e. from /spec.html 
> and /spec.txt to /spec)?”
> --response by M. Yevstifeyev: “Probably such restriction is set 
> because multiple representation choice may ultimately refer the user 
> to a resource which is not canonical.  A _definite_ canonical resource 
> is necessary and required.”
>
> ----response by  J. Cormack: “I think this relation (which is useful) 
> need to be called something
>
> image with a canonical link I would presume.”
>
> ------response by  M. Yevstifeyev: “I personally think it is possible. 
>  For example, authoritative RFC source is .txt file on RFC Editor's 
> site, while we have a number of other sources for RFCs, not in .txt, 
> such as "tools.ietf.org/html/rfcXXXX 
> <http://tools.ietf.org/html/rfcXXXX>" in HTML.  Designating a 
> "canonical" link to "http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems 
> to be OK.  So I think we have no problem here.”
>
> --response by M. Ohye: “We can change the draft to include 
> corresponding GOPHER or FTP error codes to demonstrate non-favortism 
> to HTTP.”
I don't think it would be useful (see above).  It's better, as I've 
already mentioned in my response to (7), to provide rules which would be 
fine for almost any application protocol and which would be equivalent 
to those provided for HTTP now.  For example:
OLD: /"Be the source URI of a 302, 303, or 307 redirect (Sections 
10.3.3, 10.3.4, and 10.3.8, respectively, of [RFC2616])."/ NEW: 
/"Provide a redirect to the other resource because it is temporarily 
unavailable."/ This is what HTTP 302 and 307 responses stand for.  303 
response is used in HTTP only and here is no equivalent to it in other 
protocols.
> 9. OPEN. M. Yevstifeyev:
> 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).
> --response by J. Reschke "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?"
> --response by M. Yevstifeyev: "RFC 5988 allows target and context URIs 
> to be IRIs.  Current draft has no provisions regarding this.  However, 
> the actual and current text matches encoding considerations better."
> --response by J. Reschke: "Actually, there's nothing special about the 
> I18N for this link relation; so I believe the text should just state 
> that there's nothing to say in addition to RFC 5988, Section 8."
> --response by M. Yevstifeyev: "Probably such approach is OK."
> --response by M. Ohye, “Julian, would you like us to restate the 
> current text to explicitly mention there is nothing beyond RFC 5988, 
> or leave as-is?”
So let's wait for Julian's response.

Mykyta Yevstifeyev
>
>
> On Sat, Jul 2, 2011 at 6:37 AM, Mykyta Yevstifeyev 
> <[email-masked] <mailto:[email-masked]>> wrote:
> source is
> > .txt file on RFC Editor's site, while we have a number of other 
> sources for
> > RFCs, not in .txt, such as "tools.ietf.org/html/rfcXXXX 
> <http://tools.ietf.org/html/rfcXXXX>" in HTML.
> >  Designating a "canonical" link to
> > "http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems to be OK.  So I 
> think we
> > have no problem here.
> >
> > Mykyta
> >>
> > _______________________________________________
> > apps-discuss mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
>
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Jul 2011 09:55:56 +0200

On 2011-07-03 03:23, Maile Ohye wrote:
> 1. OPEN. F. Ellermann:
> A relative canonical URL can't be a good idea.  If there is more thanone
> "content URL" (in the terminology of the draft) this would resultin more
> than one canonical URL, defeat the purpose, and worse, thiscould make
> googlebot angry.
> --response by F. Ellermann: “... But now I see that relativecan be
> perfectly fine if and only if all incarnations exist on the sameserver,
> e.g., http://example/xyzzy.html?any-querycould get a relativecanonical
> URL xyzzy.html?default or similar.  A better example in thedraft
> explaining when a relative canonical URL is okay could help.”
> --response by M. Ohye: “We could add a relative URL in the Examples section:
> Then duplicate content URIs such as:
> http://www.example.com/page.php?item=purse&category=bags
> <http://www.example.com/page.php?item=purse&category=bags>
> http://www.example.com/page.php?item=purse&category=bags&sid=1234
> <http://www.example.com/page.php?item=purse&category=bags&sid=1234>
> may designate the canonical link relation in HTML as specified in
>    [RFC5988]:
> <link rel="canonical"
>            href="http://www.example.com/page.php?item=purse" />
> or <link rel="canonical” href="page.php?item=purse" />
> or alternatively, in the HTTP Header... “

+1

> 2. OPEN. F. Ellermann:
> The draft could s/SHOULD NOT/MUST NOT/, I don't see any good reasonto
> violate a SHOULD NOT, and if that's correct MUST NOT is clearer.
> --seconded by M. Yevstifeyev
> --response by M. Ohye and J. Kupke: “We prefer SHOULD NOT for a few
> reasons. 1) If we outlawed multiple canonicals using MUST NOT, we would
> effectively call the HTML invalid. In reality, the HTML will still be
> processed, though it’s likely that search engines will ignore both/all
> rel=canonicals. 2) Worse, for the cases where somebody might
> rel=canonical to a 404, etc., if we use MUST NOT, it would place a huge
> (and entirely unrealistic) burden on the site owner to ensure that
> search engines recrawl pages in such an order that all rel=canonical
> sources are updated before a page may become a 404.”

I'm not sure I understand the response. Is there a use case where an 
author would legitimately add multiple instances of the link relation?

> --response by J. Reschke "Why? It defines a link relation as defined by
> RFC 5988, so why repeat text from over there?"
> technology which this document depends on.  RFC 5988 is first mentioned
> in Examples."

+1

> --response by J. Reschke "I think this link relation is purely advisory,
> so a better approach might be to replace "MAY" by "can"."

No, it's really not a SHOULD.

> 550, which like HTTP 404, is forbidden from being served for the target
> of a <link rel="canonical">.

a) A non-HTML document at a non-HTTP(s) URI may not be able to specify 
the link relation, but it could be the target of a link, relation, 
right? (that could be an example)

b) Future protocols might have other means to specify a link relation, btw.

> RFC 2616 and normative requirements with respect to HTTP.  HTTP examples
> are OK; but it's redundant in Section 3.  I suppose in Section 3 we may
> replace HTTP-related stuff with something in the way like:
>
> Old:
> --response by B. Thorlacius: “Your wording seems overly confusing. Which
> is the resource that "provides choice in different represntations of a
> given resource?" A standard could be assigned the URI
> <http://example.org/spec>. An HTTP GET /spec might be responded with an
> HTTP/1.1 300 choice, and an entity linking to /spec.node.html,
> is) would in no way provide this choice. The HTTP server simply offered
> multiple representations.”
> context/target URIs, which I don't think is appropriate, since canonical
> URI may refer to a resource accessible via other protocol.  Even though
> HTTP is going to be the most often use case of canonical link relation,
> we shouldn't exclude other protocols.”
> representations of a resource to the resource (i.e. from /spec.html and
> /spec.txt to /spec)?”
> --response by M. Yevstifeyev: “Probably such restriction is set because
> multiple representation choice may ultimately refer the user to a
> resource which is not canonical.  A _definite_ canonical resource is
> necessary and required.”
> ...

...my general feeling here is that having specific HTTP examples is 
good, as long as the spec doesn't make the reader think it's the only 
protocol that qualifies.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Jul 2011 13:29:26 +0200

Hi,

below a set of mostly editorial comments...

Best regards, Julian

Abstract

    This specification defines the canonical link relation -- an element
    which designates the preferred version of content/URI from a set of
    duplicate or near duplicate pages.

Maybe put "canonical" in double quotes? (similar in other places)

1.  Introduction

    The canonical link relation specifies the preferred version of a URI
    from a set of identical or vastly similar content that may be

maybe just "preferred URI"?

    The canonical (target URI) MUST contain content that duplicates, is

"canonical (target) URI MUST identify content" (it's not the content of 
the URI, it's the content of the identified resource)

    extremely similar, or is a superset of the content in the context

s/in/at/

    o  Be self-referential (context URI identical to target URI)

    o  Specify a relative or absolute URI

"Specify a URI Reference (see [RFC3986], Section 4.1), i.e., a full URI 
or a relative reference"

    o  Be the source URI of a 302, 303, or 307 redirect (Sections 10.3.3,
       10.3.4, and 10.3.8, respectively, of [RFC2616]).

Maybe "Be the source URI of a temporary redirect, such as..."?

Why do we cite RFC 5988 here? Should this ref HTML?

      <link rel="canonical"

    or alternatively, in the HTTP Header as specified in Section 5 of
    [RFC5988]:

s/Header/header field/

      Link: <http://www.example.com/page.php?item=purse>; rel="canonical"

5.  Recommendations

    Before implementing the canonical link relation, verification of the

Maybe s/implementing/adding/?

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 4 Jul 2011 23:58:17 +0200

On 3 July 2011 03:23, Maile Ohye wrote:

Hi, I've stripped the "link relations expert review list" from the CC:
keeping only the IETF apps list.

> In case this email displays as plain text

Sadly it didn't...  <gd&r>  About "relative canonical URLs":

> We could add a relative URL in the Examples section

Good, thanks.  About "SHOULD vs. MUST":

> We prefer SHOULD NOT for a few reasons.
> 1) If we outlawed multiple canonicals using MUST NOT, we
> would effectively call the HTML invalid. In reality, the
> HTML will still be processed, though it’s likely that
> search engines will ignore both/all rel=canonicals.

If you are very sure that violations of the SHOULD NOT are
only *ignored* I'm fine with it.  But search engines could
also treat violations as some kind of "link farming" and
punish authors for their intended or unintended violations.

In that case authors would be better off with a MUST NOT
clearly indicating that it is their own fault if they get
rel="canonical" wrong -- after all they are not forced to
use rel="canonical".

IOW, if you have "only" a SHOULD NOT for publishers you
might need a corresponding "MUST ignore violations" for
web crawlers.

> Worse, for the cases where somebody might rel=canonical
> to a 404, etc.

Ugh.  A typical use case is a simple site with a mirror,
in that case a 404 should be temporary:  New pages on the
mirror(s) not yet available under their canonical URL, or
old pages deleted under their canonical URL still found
on the mirror(s).

You are right, a MUST NOT does not fly for this scenario.

-Frank

---

From: Julian Reschke <[email-masked]>
Date: Sat, 09 Jul 2011 11:00:41 +0200

On 2011-07-09 04:44, Joachim Kupke wrote:
> 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...)

> 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

---

From: Joachim Kupke <[email-masked]>
Date: Fri, 8 Jul 2011 19:44:04 -0700

[...]
> I'm not sure I understand the response. Is there a use case where an author
> would legitimately add multiple instances of the link relation?

It is quite conceivable that an author might want to designate
multiple instances of the relation with different attributes, e.g.:

<link rel="canonical" href="http://en.wikipedia.org/wiki/Randomness"
media="screen"/>
<link rel="canonical" href="http://en.m.wikipedia.org/wiki/Randomness"
media="handheld"/>

It is recommended not to do that because it would foist additional
complexity on implementations, and---without being presumptuous---it
appears that encoding attributes such as media into the URI itself can
do more harm than good.

This recommendation might become less valid over time.  For example,
it has become rather common to encode the language (or country) of a
resource into the URI when there would have been other means of their
designation as well (such as, the Accept-Language HTTP header).

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.

[...]
> a) A non-HTML document at a non-HTTP(s) URI may not be able to specify the
> link relation, but it could be the target of a link, relation, right?

Correct.

--Joachim

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Jul 2011 09:46:01 +0200

On 2011-07-15 09:29, Maile Ohye wrote:
> Hi everyone, thanks again for the feedback!
>
> Julian, MAY :) we submit a new draft with the changes discussed in this
> thread?

Hi Maile,

it's your draft, so it's your decision.

Internet Draft submission in theory is closed until 10 days from now - 
in practice it still seems to work.

> 15. OPEN. J. Reschke:
> --response by M. Ohye “Changed to
> Be the source URI of a temporary redirect. Using HTTP, this refers to
> status codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8,
> respectively, of <xref target="RFC2616"/>).
> Julian, please let me know if you’d like this phased differently.
> ...

Sounds good.

> 16. OPEN. J. Reschke:
> may designate the canonical link relation in HTML as specified in [RFC5988]
> --response by M. Ohye “Changed to:
> may designate the canonical link relation in HTML as specified in <xref
> target="RFC1866"/>
> I created this reference, but I couldn’t find an organization or email
> address for Dan Connolly.
> <reference anchor="RFC1866">
> <front>
> <title>Hypertext Markup Language - 2.0</title>
> <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
> <organization>MIT/W3C</organization>
> <address><email>[email-masked] <mailto:[email-masked]></email></address>
> </author>
> <author initials="D." surname="Connolly" fullname="Dan Connolly">
> </author>
> <date month="November" year="1995"/>
> </front>
> <seriesInfo name="RFC" value="1866"/>
> </reference>
> Julian, should I have done anything differently?
> ...

No, you need to cite W3C's HTML specs nowadays.

Either

<reference anchor='REC-html401-19991224'
            target='http://www.w3.org/TR/1999/REC-html401-19991224'>
   <front>
     <title>HTML 4.01 Specification</title>
     <author fullname='Arnaud Le Hors' surname='Le Hors' initials='A.'/>
     <author fullname='David Raggett' surname='Raggett' initials='D.'/>
     <author fullname='Ian Jacobs' surname='Jacobs' initials='I.'/>
     <date year='1999' month='December' day='24'/>
   </front>
   <seriesInfo name='W3C Recommendation' value='REC-html401-19991224'/>
   <annotation>
     Latest version available at
     <eref target='http://www.w3.org/TR/html401'/>.
   </annotation>
</reference>

for HTML4 or

<reference anchor='WD-html5-20110525'
            target='http://www.w3.org/TR/2011/WD-html5-20110525/'>
   <front>
     <title>HTML5</title>
     <author fullname='Ian Hickson' surname='Hickson' initials='I.'/>
     <date year='2011' month='May' day='25'/>
   </front>
   <seriesInfo name='W3C Working Draft' value='WD-html5-20110525'/>
   <annotation>
     Latest version available at
     <eref target='http://www.w3.org/TR/html5/'/>.
   </annotation>
</reference>

for the latest HTML5 Working Draft (see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/w3c-references.html>).

(I recommend HTML 4.01 because it's stable and the differences to HTML5 
do not matter here).

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 15 Jul 2011 11:50:27 +0300

15.07.2011 10:29, Maile Ohye wrote:
> Julian, MAY :) we submit a new draft with the changes discussed in 
> this thread?
>
> Our comments to the open items are listed below (highlighted in 
> yellow). All comments for draft-00 are tracked in this doc:
> https://docs.google.com/document/d/1SkGEFKILZKTD6r9D2Oz76LwxuXbbqtRnWB7y2NTaDt8/edit?hl=en_US
>
> Thanks again,
> Maile
>
> [ . . . ]
>
> 4. OPEN. M. Yevstifeyev:
> [ . . . ]
> RFC 5988 [RFC5988] specified the mechanism which is used to indicate 
> relationships between the links on the Internet.  This document 
> defined a new type of such relationships - canonical link relation.
> in Section 1 as 1st para; other paragraphs retain in this case.”
> --response by M. Ohye “We researched other RFCs and it seems best to 
> start the abstract with the main subject, such as for DC1:
> ‘The Dublin Core [DC1] is a small set of metadata elements for 
> describing information resources.’
> or for HTML:
> ‘The Hypertext Markup Language (HTML) is a simple markup language used...”
> so we’d prefer to start with a mention of the canonical link relation 
> and reference RFC5988 following the initial mention.
> The canonical link relation, developed from <xref target="RFC5988"/> 
> which indicates relationships between Internet links, specifies the 
> preferred URI from a set of identical or vastly similar content 
> accessible on multiple URIs.
I don't strongly insist on any of such text, but I personally think what 
I proposed is better.  Yet, please feel free to include what you 
personally want.
>
> Then, similar to the first paragraph of Section 10.3.2 of RFC 2616:
>
> 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."
>
> 5. CLOSED. M. Yevstifeyev:
> [ . . . ]
> --response by M. Ohye “Left as ‘MAY’ in the draft, but further debate 
> welcomed.”
I'd better use non-normative "should" or "can" here rather than RFC 2119 
language, as proposed by Julian.
> [ . . . ]
> --response by M. Ohye “Changed the draft to:
> The target/canonical URI MAY:
> * Have different scheme names: such as HTTP to HTTPS, or gopher to FTP
This is an editorial comment.  RFC 3986 recommends that scheme names are 
present in lowercase.  Moreover, it would be better to enclose the 
scheme names in the quotes, to distinguish them from other text.
> target URI is a 'ftp' or 'gopher' URI?
>
> [ . . . ]
>
> --response by M. Ohye “Given Julian’s comments in #15 below, and M. 
> Yevstifeyev’s original concern of being too HTTP specific, this now reads:
> Be the source URI of a temporary redirect. For HTTP, this refers to 
This looks reasonable.
> [ . . .]
> [RFC5988]
> [ . . . ]
+1 to Julian's response to this.  RFC 1866 (and all other HTML-related 
stuff) was removed from Standards Track and is now Historic (except RFC 
2854).

Mykyta
> [ . . . ]

---

From: Maile Ohye <[email-masked]>
Date: Fri, 15 Jul 2011 00:29:49 -0700

Our comments to the open items are listed below (highlighted in yellow). All
comments for draft-00 are tracked in this doc:
https://docs.google.com/document/d/1SkGEFKILZKTD6r9D2Oz76LwxuXbbqtRnWB7y2NTaDt8/edit?hl=en_US

Thanks again,
Maile

2. OPEN. F. Ellermann:
The draft could s/SHOULD NOT/MUST NOT/, I don't see any good reason
to violate a SHOULD NOT, and if that's correct MUST NOT is clearer.
--seconded by M. Yevstifeyev
--response by M. Ohye and J. Kupke: “We prefer SHOULD NOT for a few reasons.
1) If we outlawed multiple canonicals using MUST NOT, we would effectively
call the HTML invalid. In reality, the HTML will still be processed, though
it’s likely that search engines will ignore both/all rel=canonicals. 2)
Worse, for the cases where somebody might rel=canonical to a 404, etc., if
we use MUST NOT, it would place a huge (and entirely unrealistic) burden on
the site owner to ensure that search engines recrawl pages in such an order
that all rel=canonical sources are updated before a page may become a 404.”
--response by J. Reschke “I'm not sure I understand the response. Is there a
use case where an author would legitimately add multiple instances of the
link relation?”
--response by J. Kupke “It is quite conceivable that an author might want to
designate
multiple instances of the relation with different attributes, e.g.:
<link rel="canonical" href="http://en.wikipedia.org/wiki/Randomness"
media="screen"/>
<link rel="canonical" href="http://en.m.wikipedia.org/wiki/Randomness"
media="handheld"/>
It is recommended not to do that because it would foist additional
complexity on implementations, and---without being presumptuous---it appears
that encoding attributes such as media into the URI itself can do more harm
than good.
This recommendation might become less valid over time.  For example, it has
become rather common to encode the language (or country) of a resource into
the URI when there would have been other means of their designation as well
(such as, the Accept-Language HTTP header).”
--response by F. Ellermann “If you are very sure that violations of the
SHOULD NOT are only *ignored* I'm fine with it.  But search engines could
also treat violations as some kind of "link farming" and punish authors for
their intended or unintended violations.

In that case authors would be better off with a MUST NOT clearly indicating
that it is their own fault if they get rel="canonical" wrong -- after all
they are not forced to use rel="canonical".

IOW, if you have "only" a SHOULD NOT for publishers you might need a
corresponding "MUST ignore violations" for web crawlers.”
--response by M. Ohye “In the new introduction, we’d like to state:
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...

As we’re using “MAY” in the introduction, to later dictate search engine
behavior with “you MUST ignore violations,” seems like it would be very
strong language.
--response by F. Ellermann with regard to M. Ohye’s [Worse, for the cases
where somebody might rel=canonical to a 404, etc., if we use MUST NOT, it
would place a huge (and entirely unrealistic) burden on the site owner to
ensure that search engines recrawl pages in such an order that all
rel=canonical sources are updated before a page may become a 404.]

“Ugh.  A typical use case is a simple site with a mirror, in that case a 404
should be temporary:  New pages on the mirror(s) not yet available under
their canonical URL, or old pages deleted under their canonical URL still
found on the mirror(s).
You are right, a MUST NOT does not fly for this scenario.”
--response by M. Ohye “We’d like to leave this as SHOULD NOT.” Please let us
know if you have further arguments.

I think some introductory text on linking, probably based on RFC 5988,
should go here.
--response by J. Reschke "Why? It defines a link relation as defined by RFC
5988, so why repeat text from over there?"
--response by M. Yevstifeyev "It should be mentioned (1) what is link
relation at all and (2) that RFC 5988 is a specification of that technology
which this document depends on.  RFC 5988 is first mentioned in Examples."
--response by M. Ohye. “We could modify to:
“The canonical link relation (Link Relation Types reference <xref
target="RFC5988"/>) specifies the preferred version of a URI...”
--response by J. Reschke “+1”
--response by M. Yevstifeyev “I proposed to add something like:
RFC 5988 [RFC5988] specified the mechanism which is used to indicate
relationships between the links on the Internet.  This document defined a
new type of such relationships - canonical link relation.
in Section 1 as 1st para; other paragraphs retain in this case.”
--response by M. Ohye “We researched other RFCs and it seems best to start
the abstract with the main subject, such as for DC1:
‘The Dublin Core [DC1] is a small set of metadata elements for describing
information resources.’
or for HTML:
‘The Hypertext Markup Language (HTML) is a simple markup language used...”
so we’d prefer to start with a mention of the canonical link relation and
reference RFC5988 following the initial mention.
The canonical link relation, developed from <xref target="RFC5988"/> which
indicates relationships between Internet links, 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."

5. CLOSED. 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"."
--response by M. Yevstifeyev "Yes, advisory, which suits RFC 2119 definition
for SHOULD: 'SHOULD   This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and carefully
weighed before choosing a different course.'
and natural meaning of should - advice/recommendation."
--response by M. Ohye “Thanks, in discussion with Joachim Kupke.”
--response by J. Reschke “No, it's really not a SHOULD.”
--response by J. Kupke “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.”
--response by J. Reschke “See RFC 2119, Section 6:

 interoperability.

7. OPEN. M. Yevstifeyev:
  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).
--agreed by J. Reschke
--response by M. Ohye/J. Kupke: “Good catch, Mykyta. We’re fine to change
the draft to “scheme”:
Have different scheme names: such as http to https, or vice versa
Do we now need to expand the draft for ftp:// and gopher:// URIs? For
example, ftp:// and gopher:// URIs”
1) Do not come with the equivalent of RFC 5988, so a non-HTML document
available at any such URI won't be available to make use of <link
rel="canonical">.
2) Have corresponding GOPHER error code (item type 3) or an FTP error 550,
which like HTTP 404, is forbidden from being served for the target of a
<link rel="canonical">.
--response by M. Yevstifeyev “I don't think we should make such changes.  If
we consider ftp and gopher URIs, we should also consider all other.  I
proposed to add generic statements which would be applicable to almost all
application protocols, not only HTTP, as in current version of the draft.”
--response by J. Reschke “a) A non-HTML document at a non-HTTP(s) URI may
not be able to specify the link relation, but it could be the target of a
link, relation, right? (that could be an example)
--response by J. Kupke “Correct.”
b) Future protocols might have other means to specify a link relation, btw.”

--response by J. Kupke “Is there terminology that reasonably unifies errors
across protocols (HTTP response code 4xx, GOPHER item type 3, FTP response
code 5xx)?”

--response by J. Reschke “I don't think so...”
--response by M. Ohye “Changed the draft to:
The target/canonical URI MAY:
* Have different scheme names: such as HTTP to HTTPS, or gopher to FTP

8. OPEN. M. Yevstifeyev:
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.
--response by J. Reschke "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."
--response by M. Yevstifeyev "Currently we have normative reference to RFC
2616 and normative requirements with respect to HTTP.  HTTP examples are OK;
but it's redundant in Section 3.  I suppose in Section 3 we may replace
HTTP-related stuff with something in the way like:

Old:
  o  The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of
     [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]).
New:
  o  The source URI, which defines a resource which provides choice
     in different represntations of a given resource, ientified by
     the context URI, or is a link which has been permanently replaced
     by an other one.
etc."
--response by B. Thorlacius: “Your wording seems overly confusing. Which is
the resource that "provides choice in different represntations of a given
resource?" A standard could be assigned the URI <http://example.org/spec>.
An HTTP GET /spec might be responded with an HTTP/1.1 300 choice, and an
entity linking to /spec.node.html, /spec.html, /spec.pdf, and /spec.txt. The
resource (the standard, that is) would in no way provide this choice. The
HTTP server simply offered multiple representations.”
--response by M. Yevstifeyev: “First, this was an example only.  Next, my
point was that the document makes HTTP/'http' scheme mandatory in
context/target URIs, which I don't think is appropriate, since canonical URI
may refer to a resource accessible via other protocol.  Even though HTTP is
going to be the most often use case of canonical link relation, we shouldn't
exclude other protocols.”
--response by B. Thorlacius: “I agree. However, I don't understand the need
for forbidding canonical links to resources with multiple representations.
Are there not to be canonical links from representations of a resource to
the resource (i.e. from /spec.html and /spec.txt to /spec)?”
--response by M. Yevstifeyev: “Probably such restriction is set because
multiple representation choice may ultimately refer the user to a resource
which is not canonical.  A _definite_ canonical resource is necessary and
required.”

----response by  J. Cormack: “I think this relation (which is useful) need
to be called something

like /spec.

------response by  M. Yevstifeyev: “I personally think it is possible.  For
example, authoritative RFC source is .txt file on RFC Editor's site, while
we have a number of other sources for RFCs, not in .txt, such as "
tools.ietf.org/html/rfcXXXX" in HTML.  Designating a "canonical" link to "
http://www.rfc-editor.org/rfc/rfcXXXX.txt" seems to be OK.  So I think we
have no problem here.”
--response by M. Ohye: “We can change the draft to include corresponding
GOPHER or FTP error codes to demonstrate non-favortism to HTTP.”
--response by M. Yevstifeyev “I don't think it would be useful (see above).
 It's better, as I've already mentioned in my response to (7), to provide
rules which would be fine for almost any application protocol and which
would be equivalent to those provided for HTTP now.  For example:

OLD: “Be the source URI of a 302, 303, or 307 redirect (Sections 10.3.3,
10.3.4, and 10.3.8, respectively, of [RFC2616])."
NEW: "Provide a redirect to the other resource because it is temporarily
unavailable."

This is what HTTP 302 and 307 responses stand for.  303 response is used in
HTTP only and here is no equivalent to it in other protocols.”
--response by J. Reschke “...my general feeling here is that having specific
HTTP examples is good, as long as the spec doesn't make the reader think
it's the only protocol that qualifies.”
--response by M. Ohye “Given Julian’s comments in #15 below, and M.
Yevstifeyev’s original concern of being too HTTP specific, this now reads:
Be the source URI of a temporary redirect. For HTTP, this refers to status
codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, respectively,
of <xref target="RFC2616"/>).

10. OPEN. J. Reschke:
This specification defines the canonical link relation -- an element which
designates the preferred version of content/URI from a set of duplicate or
near duplicate pages.
Maybe put "canonical" in double quotes? (similar in other places)
--response by M. Ohye “How adamant are you about double quoting “canonical”
in “canonical link relation” throughout the draft? That’s a lot of double
quotes (18 of them :). I think these double quotes would be more distracting
than helpful, but if that’s how other RFCs are written, we’ll certainly
reconsider.”

11. CLOSED. J. Reschke:
The canonical link relation specifies the preferred version of a URI from a
set of identical or vastly similar content that may be
maybe just "preferred URI"?
--response by M. Ohye “Changed. Here’s the new abstract:
The canonical link relation, developed from <xref target="RFC5988"/> which
indicates relationships between Internet links, specifies the preferred URI
from a set of identical or vastly similar content accessible on multiple
URIs.

12. CLOSED. J. Reschke:
The canonical (target URI) MUST contain content that duplicates
"canonical (target) URI MUST identify content" (it's not the content of the
URI, it's the content of the identified resource)
--response by M. Ohye “Updated in draft.”

13. CLOSED. J. Reschke
extremely similar, or is a superset of the content in the context
s/in/at/:
--response by M. Ohye “Updated in draft.”

14. OPEN. J. Reschke:

"Specify a URI Reference (see [RFC3986], Section 4.1), i.e., a full URI or a
relative reference”
--response by M. Ohye “How about the edit below?
Specify a URI Reference (see [RFC3986], Section 4.1), i.e., an absolute URI
or a relative reference

15. OPEN. J. Reschke:

Maybe "Be the source URI of a temporary redirect, such as..."?
--response by M. Ohye “Changed to
Be the source URI of a temporary redirect. Using HTTP, this refers to status
codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, respectively,
of <xref target="RFC2616"/>).
Julian, please let me know if you’d like this phased differently.

16. OPEN. J. Reschke:
     <address><email>[email-masked]</email></address>

17. CLOSED. J. Reschke:
<link rel="canonical" href="http://www.example.com/page.php?item=purse" />
 or alternatively, in the HTTP Header as specified in Section 5 of
 [RFC5988]:
s/Header/header field/
--response by M. Ohye “Updated in the draft.”

18. CLOSED. J. Reschke:
Recommendations

Maybe s/implementing/adding/?
--response by M. Ohye “Updated in the draft.”

>>>> --response by J. Reschke "I think this link relation is purely
advisory,

---

From: Joachim Kupke <[email-masked]>
Date: Wed, 20 Jul 2011 20:48:29 -0700

Julian Reschke <[email-masked]> wrote:
> Joachim Kupke <[email-masked]> wrote:
[...]

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