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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 31 Aug 2011 07:34:00 +0300

Maile and Joachim,

I did provide some comments on this draft on link-relations list; but 
I'd like you processed several new editorial issues/nits prior to 
submitting publication request.

> Abstract
>
>     The canonical link relation, developed from [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 isn't clear enough for abstract.  I propose:

> Abstract
>
>     RFC 5988 specified a way to define relationships betweeen links on
>     the Web.  This document describes a new type of such relationship,
>     'canonical', which desigantes the preferred URI from a set of identical
>     or vastly similar ones.

A similar text should go in the first paragraph of Introduction.

In Introduction:

>     making it possible for references to the context URI to be updated to
>     reference the designated URI.

Maybe you meant "target URI" instead "designated URI" (terminology from 
RFC 5988).

Section 3:

>     The target/canonical URI MAY:
>
>     o  Specify a URI Reference (see [RFC3986] Section 4.1) i.e., an
>        absolute URI or a relative reference

What you mean here?  If you wanted to show that canonical URI may be a 
relative one, you should better write:

>     The target/canonical URI MAY:
>
>     o  Be a relative URI (see [RFC3986], Section 4.2);

Ibid:

>     The target/canonical URI SHOULD NOT designate:
>
>     o  The source URI of a permanent redirect (for HTTP, this refers to
>        Section 10.3.2 of [RFC2616]) or a "300 Multiple Choices" URI
>        (Section 10.3.1 of [RFC2616])

Here probably a typo happened; so please change to:

>     The target/canonical URI SHOULD NOT designate:
>
>     o  The URI which is a source of a permanent redirect (for HTTP, this
>        refers to 300 and 301 response codes, defined in Sections
>        10.3.1 and 10.3.2 of RFC 2616 [RFC2616]);

Ibid:

>     o  A URI that serves a 4xx error code (Section 10.4 of [RFC2616]).

Again, HTTP-centric approach.  There are many other application-layer 
protocols, for which URI schemes exist, and they aren't very likely to 
even have the same req/response model as HTTP has.  As this is only 
available in HTTP, I propose to exclude this bullet, unless you can 
reformulate it so that it doesn't use HTTP-only feature.

>     o  The first page of a multi-page article or multi-page listing of
>        items (since the first page is not a duplicate or a superset or
>        the context URI).  For example, page2 and page3 of an article
>        SHOULD NOT specify page1 as the canonical.

Here you may point to Section 6.12 of you reference 
[REC-html401-19991224], which specifies the 'start' relation 
(http://www.w3.org/TR/1999/REC-html401-19991224/types.html#idx-link_type), 
used for this purpose.

In Section 5:

>     2.  Permanent HTTP redirects (Section 10.3.2 of [RFC2616]), the
>         traditional strong indicator that a URI's content has been
>         permanently moved, could not be implemented in place of the
>         canonical link relation.

Also too HTTP-centric approach.  The same as above applies.

References:

Why make RFC 2616 and HTML4 spec Normative references?  Shouldn't 
Informative be OK?

Thanks,
Mykyta Yevstifeyev

31.08.2011 1:21, Maile Ohye wrote:
> Hi everyone, please let us know if you have additional feedback. After 
> many rounds of helpful discussion, I think we're nearing submission. :)
>
> I hope to submit a publication request on Wednesday, September 7th, 2011.
>
> Thanks!
> Maile
>
>     -------- Original Message --------
>     Subject: I-D Action: draft-ohye-canonical-link-relation-01.txt
>     Date: Mon, 29 Aug 2011 07:41:45 -0700
>     From: [email-masked] <mailto:[email-masked]>
>     Reply-To: [email-masked] <mailto:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
>
>     A New Internet-Draft is available from the on-line Internet-Drafts
>     directories.
>
>            Title           : The Canonical Link Relation
>            Author(s)       : Maile Ohye
>                              Joachim Kupke
>            Filename        : draft-ohye-canonical-link-relation-01.txt
>            Pages           : 6
>            Date            : 2011-07-30
>
>       The canonical link relation, developed from [RFC5988] which
>     indicates
>       relationships between Internet links, specifies the preferred URI
>       from a set of identical or vastly similar content accessible on
>       multiple URIs.
>
>     Editorial Note (To be removed by RFC Editor)
>
>       Distribution of this document is unlimited.  Comments should be sent
>       to the IETF Apps-Discuss mailing list (see
>     &lt;https://www.ietf.org/mailman/listinfo/apps-discuss&gt;
>     <https://www.ietf.org/mailman/listinfo/apps-discuss%3E>).
>
>
>     A URL for this Internet-Draft is:
>     http://www.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-01.txt
>
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
>
>     This Internet-Draft can be retrieved at:
>     ftp://ftp.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-01.txt
>     _______________________________________________
>     I-D-Announce mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/i-d-announce
>     Internet-Draft directories: http://www.ietf.org/shadow.html
>     or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>     _______________________________________________
>     apps-discuss mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Julian Reschke <[email-masked]>
Date: Wed, 31 Aug 2011 08:20:47 +0200

On 2011-08-31 06:34, Mykyta Yevstifeyev wrote:
> ...

The original text seems to be clearer to me.

> reformulate it so that it doesn't use HTTP-only feature.

-1. This is useful information. Just because something is specific 
doesn't mean it shouldn't be mentioned.

> (http://www.w3.org/TR/1999/REC-html401-19991224/types.html#idx-link_type),

+-0.

> Also too HTTP-centric approach. The same as above applies.

-1

> Why make RFC 2616 and HTML4 spec Normative references? Shouldn't

For 2616 is makes sense if there are normative constrains specific for HTTP.

 > ...

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 31 Aug 2011 10:40:43 +0300

> The original text seems to be clearer to me.

It is already obvious that target URI must conform to RFC 3986 
<URI-Reference> from RFC 5988:

>    Link           = "Link" ":" #link-value
>    link-value     = "<" URI-Reference">" *( ";" link-param )

and, correspondingly, the target URI *is* (rather than *MAY be*) 
<URI-Reference>.  If the authors want to clarify that target URI may be 
relative, my proposed text is better.

 From Section 10.4 of RFC 2616:

>     The 4xx class of status code is intended for cases in which the
>     client seems to have erred.

So 4xx responses are used when something is wring with HTTP request.  I 
doubt there are alternatives of such definition in *all* protocols for 
which the URI scheme has been specified.  Eg., FTP doesn't alter error 
conditions caused by client or server; neither does TFTP and many others.

We aren't defining the link relation fro 'http' and 'https' URIs only; 
it is theoretically to allow any scheme, including not yet defined.

>> Also too HTTP-centric approach. The same as above applies.

See above.

> For 2616 is makes sense if there are normative constrains specific for 

See above as well.  Why tie ourselves with HTTP only?

Mykyta