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

[Mykyta Yevstifeyev <[e-mail]>]

15.07.2011 10: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?
>
> 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:
> > The canonical link relation specifies the preferred version of a URI
> [ . . . ]
> 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:
> > Presence of the canonical link relation indicates to applications, 
> such as search engines, that they MAY:
> [ . . . ]
> --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.
>
> 7. OPEN. M. Yevstifeyev:
>   o Exist on a different protocol: http to https, or vice versa
> [ . . . ]
> --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.
>
> 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?
>
> [ . . . ]
>
> --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"/>).
This looks reasonable.
>
> [ . . .]
>
> 16. OPEN. J. Reschke:
> may designate the canonical link relation in HTML as specified in 
> [RFC5988]
> [ . . . ]
> Julian, should I have done anything differently?
+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
>
> [ . . . ]