Maile

1. OPEN. F. Ellermann:
A relative canonical URL can't be a good idea. =A0If th= ere is more than one &q= uot;content URL" (in the terminology of the draft) this would result in more than on= e canonical URL, defeat the purpose, and worse, this could make googlebot angry. --response by F. Ellermann: =93... But now I see that relat= ive can be per= fectly fine if and only if all incarnations exist on the same server, e.g., http://example/xyzzy.html?any-quer= y could get a relative canonical URL xyzzy.html?default or sim= ilar. =A0A better example in the draft explaining when a relative canonical URL is okay c= ould help.=94
--response by M. Ohye: =93We could add a relative URL in th= e Examples section:
Then duplicate content URIs such as:
=A0=A0=A0=A0http://www.example.com/page.php?item=3Dpurse= &category=3Dbags
=A0=A0=A0=A0http://www.example.com/page.p= hp?item=3Dpurse&category=3Dbags&sid=3D1234
may designate the canonical link relation in HTML as specif= ied in
=A0=A0[RFC5988]:
=A0=A0=A0=A0<link rel=3D"canonical" =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0href=3D"http://www.example.com/page.php?i= tem=3Dpurse" />
or <link rel=3D"canonical=94 href=3D"page.php?= item=3Dpurse" />
or alternatively, in the HTTP Header... =93

2. OPEN. F. Ellermann:
The draft could s/SHOULD NOT/MUST NOT/, I don't see any= good reason t= o violate a SHOULD NOT, and if that's correct MUST NOT is clearer.
--seconded by M. Yevstifeyev
--response by M. Ohye and J. Kupke: =93We prefer SHOULD NOT= for a few reasons. 1) If we outlawed multiple canonicals using MUST NOT, w= e would effectively call the HTML invalid. In reality, the HTML will still = be processed, though it=92s likely that search engines will ignore both/all= rel=3Dcanonicals. 2) Worse, for the cases where somebody might rel=3Dcanon= ical to a 404, etc., if we use MUST NOT, it would place a huge (and entirel= y unrealistic) burden on the site owner to ensure that search engines recra= wl pages in such an order that all rel=3Dcanonical sources are updated befo= re a page may become a 404.=94

3. CLOSED. M. Yevstifeyev:
There is the Intended Status missing in it. =A0I suppose In= formational should be fine.
--seconded by J. Reschke
--added to draft by M. Ohye

4. OPEN. M. Yevstifeyev:
> The canonical link relation spe= cifies the preferred version of a URI
I think some introductory text on linking, probably based o= n RFC 5988, should go here.
--response by J. Reschke "Why? It defines a link relat= ion 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. =A0RFC 5988 is first menti= oned in Examples."
--response by M. Ohye. =93We could modify to:
=93The canonical link relation (Link Relation Types referen= ce <xref target=3D"RFC5988"/>) specifies the preferred vers= ion of a URI...=94

5. OPEN. M. Yevstifeyev:
> Presence of the canonical link = relation indicates to applications, such as search engines, that they MAY:<= /span>
I wonder why it's MAY; in this case implementations (ex= plicitly, those apps which interpret Link: headers and corresponding constr= uction in HTML) will be free to ignore it. =A0I think normative SHOULD shou= ld be OK (sorry for pun).
--response by J. Reschke "I think this link relation i= s purely advisory, so a better approach might be to replace "MAY"= by "can"."
--response by M. Yevstifeyev "Yes, advisory, which sui= ts RFC 2119 definition for SHOULD: 'SHOULD =A0=A0This word, or the adje= ctive "RECOMMENDED", mean that there may exist valid reasons in p= articular circumstances to ignore a particular item, but the full implicati= ons must be understood and carefully weighed before choosing a different co= urse.'
and natural meaning of should - advice/recommendation."= ;
--response by M. Ohye: =93Thanks, in discussion with Joachi= m Kupke.=94

6. CLOSED. M. Yevstifeyev:
I suppose omitting "value of the" should be bette= r, since there is no such term in RFC 3986. =A0In fact, when referring the = URI, we mean its value, meaning.
--agreed by J. Reschke
--updated in draft by M. Ohye (in two instances)

7. OPEN. M. Yevstifeyev:
=A0=A0o =A0Exist on a different pro= tocol: http to https, or vice versa
You probably meant URI scheme here, since https isn't a= separate protocol. =A0As 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 "Ha= ve different scheme names" (which suits the second variant of a prefac= e to this list better).
--agreed by J. Reschke
--response by M. Ohye/J. Kupke: =93Good catch, Mykyta. We= =92re fine to change the draft to =93scheme=94:
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=94
1) Do not come with the equivalent of RFC 5988, so a non-HT= ML document available at any such URI won't be available to make use of= <link rel=3D"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=3D"canonical">.

8. OPEN. M. Yevstifeyev:
Reading section 3 and 5 of the draft, it seems that is mand= ates use of HTTP when referring to canonical URIs. =A0And what is the situa= tion when target URI is a 'ftp' or 'gopher' URI? =A0Section= 3 allows different scheme names in context/target URIs, if I understand it= correctly. =A0Therefore, 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 examp= les 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 normati= ve reference to RFC 2616 and normative requirements with respect to HTTP. = =A0HTTP examples are OK; but it's redundant in Section 3. =A0I suppose = in Section 3 we may replace HTTP-related stuff with something in the way li= ke:

Old:
=A0=A0o =A0The source URI of a "300 Multiple Choices&= quot; URI (Section 10.3.1 of
=A0=A0=A0=A0=A0[RFC2616]) or a permanent redirect (Section= 10.3.2 of [RFC2616]).
New:
=A0=A0o =A0The source URI, which defines a resource which = provides choice
=A0=A0=A0=A0=A0in different represntations of a given reso= urce, ientified by
=A0=A0=A0=A0=A0the context URI, or is a link which has bee= n permanently replaced
=A0=A0=A0=A0=A0by an other one.
etc."
--response by B. Thorlacius: =93Your wording seems overly c= onfusing. Which is the resource that "provides choice in different rep= resntations of a given resource?" A standard could be assigned the URI= <http://example.org/spec>. An HTTP GET /spec might be responded with an HT= TP/1.1 300 choice, and an entity linking to /spec.node.html, /spec.html, /s= pec.pdf, and /spec.txt. The resource (the standard, that is) would in no wa= y provide this choice. The HTTP server simply offered multiple representati= ons.=94
--response by M. Yevstifeyev: =93First, this was an example= only. =A0Next, my point was that the document makes HTTP/'http' sc= heme mandatory in context/target URIs, which I don't think is appropria= te, since canonical URI may refer to a resource accessible via other protoc= ol. =A0Even though HTTP is going to be the most often use case of canonical= link relation, we shouldn't exclude other protocols.=94
--response by B. Thorlacius: =93I agree. However, I don'= ;t understand the need for forbidding canonical links to resources with mul= tiple representations. Are there not to be canonical links from representat= ions of a resource to the resource (i.e. from /spec.html and /spec.txt to /= spec)?=94
--response by M. Yevstifeyev: =93Probably such restriction = is set because multiple representation choice may ultimately refer the user= to a resource which is not canonical. =A0A _definite_ canonical resource i= s necessary and required.=94

----response = by =A0J. Cormack: =93I think this relation (which is useful) need to be cal= led something

else, as it i= s performing a different function to canonical, which is

about relatio= ns between representations of resources, rather than

between repre= sentations of resources and a the resource itself

like /spec.

There does se= em to not be a discussion of what is similar though in

terms of medi= a types - is /spec.txt similar enough that /spec.html could

be a canonica= l link? One could certainly have a PNG version of an SVG

image with a = canonical link I would presume.=94

------respons= e by =A0M. Yevstifeyev: =93I personally think it is possible. =A0For exampl= e, 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 "too= ls.ietf.org/html/rfcXXXX" in HTML. =A0Desig= nating a "canonical" link to "http://www.rfc-edito= r.org/rfc/rfcXXXX.txt" seems to be OK. =A0S= o I think we have no problem here.=94

--response by M. Ohye: =93We can change the draft to includ= e corresponding GOPHER or FTP error codes to demonstrate non-favortism to H= TTP.=94

9. OPEN. M. Yevstifeyev:
> 8. =A0Internationalisation Cons= iderations
In designating a canonical URI, please see [RFC3986] for in= formation on URI encoding.
=A0=A0
IRIs serve for this purpose. =A0I recommend either to renam= e the section to Encoding considerations or skip it at all ( I personally l= ike 2nd variant).
--response by J. Reschke "I believe we'll need thi= s section, and the contents is fine; after all, this is what you have to th= ink of with respect to I18N, no?"
--response by M. Yevstifeyev: "RFC 5988 allows target = and context URIs to be IRIs. =A0Current draft has no provisions regarding t= his. =A0However, the actual and current text matches encoding consideration= s better."
--response by J. Reschke: "Actually, there's nothi= ng special about the I18N for this link relation; so I believe the text sho= uld just state that there's nothing to say in addition to RFC 5988, Sec= tion 8."
--response by M. Yevstifeyev: "Probably such approach = is OK."
--response by M. Ohye, =93Julian, would you like us to rest= ate the current text to explicitly mention there is nothing beyond RFC 5988= , or leave as-is?=94

On Sat, Jul 2, 2011 at 6:37 AM, Mykyta Yevstifeyev <<= a href=3D"mailto:evnikita2@gmail.com">evnikita2@gmail.com> wrote:> 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. =A0For example, authoritative RFC source is
> .txt fi= le 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.
> =A0Designa= ting a "canonical" link to
> "http://www.rfc-editor.org/rfc/rfcXXXX.txt= " seems to be OK. =A0So I think we
> have no problem here.
>
> Mykyta
>>
>> O= ne could certainly have a PNG version of an SVG
>> image with a ca= nonical link I would presume.
>>
>> Justin
>> >
> _______________________________________________
> apps-d= iscuss mailing list
> apps-d= iscuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>