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

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: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>     Reply-To: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>     To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>
>     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
>     I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>     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
>     apps-discuss@ietf.org <mailto:apps-discuss@ietf.org>
>     https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss