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

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Aug 2011 17:51:06 +0200

(FYI)

-------- 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]
Reply-To: [email-masked]
To: [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;).

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]
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

---

From: Maile Ohye <[email-masked]>
Date: Tue, 30 Aug 2011 15:21:36 -0700

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
>        Filename        : draft-ohye-canonical-link-**relation-01.txt
>        Pages           : 6
>        Date            : 2011-07-30
>
>   &lt;https://www.ietf.org/**mailman/listinfo/apps-discuss&**gt;<https://www.ietf.org/mailman/listinfo/apps-discuss>>
> ).
>
>
> http://www.ietf.org/internet-**drafts/draft-ohye-canonical-**
> link-relation-01.txt<http://www.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-01.txt>
>
> ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/>
>
> ftp://ftp.ietf.org/internet-**drafts/draft-ohye-canonical-**
> link-relation-01.txt<ftp://ftp.ietf.org/internet-drafts/draft-ohye-canonical-link-relation-01.txt>
> ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/i-d-announce<https://www.ietf.org/mailman/listinfo/i-d-announce>
> Internet-Draft directories: http://www.ietf.org/shadow.**html<http://www.ietf.org/shadow.html>
> or ftp://ftp.ietf.org/ietf/**1shadow-sites.txt<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>
> ______________________________**_________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

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

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. :)
>
>     From: [email-masked] <mailto:[email-masked]>
>     Reply-To: [email-masked] <mailto:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
>
>     &lt;https://www.ietf.org/mailman/listinfo/apps-discuss&gt;
>     <https://www.ietf.org/mailman/listinfo/apps-discuss%3E>).
>
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
> 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