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

[Mykyta Yevstifeyev <[e-mail]>]

Hello Maile, all,

Let me response to my issues only.

03.07.2011 4:23, Maile Ohye wrote:
> 3. CLOSED. M. Yevstifeyev:
> There is the Intended Status missing in it.  I suppose Informational 
> should be fine.
> --seconded by J. Reschke
> --added to draft by M. Ohye
Thanks for this clarification.
>
> 4. OPEN. M. Yevstifeyev:
> > 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.
> --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:
> 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.”
Please notify on the list when this issue is resolved.
>
> 6. CLOSED. M. Yevstifeyev:
> 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.
> --agreed by J. Reschke
> --updated in draft by M. Ohye (in two instances)
Thanks for this.
>
> 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”:
... 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:
> 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
>
> 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.”
>
> ------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:
> > 8.  Internationalisation Considerations
> In designating a canonical URI, please see [RFC3986] for information 
> on URI encoding.
>
> 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 
> <[e-mail] <mailto:[e-mail]>> 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.  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.
> >
> > Mykyta
> >>
> >> One could certainly have a PNG version of an SVG
> >> image with a canonical link I would presume.
> >>
> >> Justin
> >>
> >
> > _______________________________________________
> > apps-discuss mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
>
>