Thanks for the feedback! I'll submit draft-02 which addresses the issues below:

1. CLOSED. M. Yevstifeyev: “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.”

-- response by M. Ohye: “Updated in abstract of draft-02.”

2. CLOSED. M. Yevstifeyev: “ 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).

-- response by M. Ohye: “Updated to ‘target URI’ in draft-02.”

3. CLOSED. M. Yevstifeyev: “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);”

-- response by M. Ohye: “Added to draft-02.”

4. CLOSED. M. Yevstifeyev: “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]);”

-- response by M. Ohye: “Changed to:

[ The source URI 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 <xref target="RFC2616"/>) ]

5. CLOSED. M. Yevstifeyev: “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.”

-- response by J. Reschke: “-1. This is useful information. Just because something is specific doesn't mean it shouldn't be mentioned.”
-- response by M. Ohye: “Yes, we’d like to include restrictions, even if they are HTTP-specific. Unfortunately, it would be difficult to mention them clearly while remaining HTTP-agnostic.”

6. OPEN. M. Yevstifeyev: “

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.”

-- response by J. Reschke: “+-0.”
-- response by M. Ohye: “We’d prefer not to clutter our point with a link to the ‘start’ relation, but if we could add it in a footnote, that would be fine.”

7. CLOSED. M. Yevstifeyev: “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.”

-- response by J. Reschke: “-1.”

8. CLOSED. M. Yevstifeyev: “References:

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

-- response by J. Reschke: “For 2616 is makes sense if there are normative constrains specific for HTTP.”

Thanks again,

Maile

On Wed, Aug 31, 2011 at 12:40 AM, Mykyta Yevstifeyev <evnikita2@gmail.com> wrote:
> 31.08.2011 9:20, Julian Reschke wrote:
>>
>> On 2011-08-31 06:34, Mykyta Yevstifeyev wrote:
>>>
>>> ...
>>> 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);
>>
>> 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.
>
>>
>>> 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.
>>
>> -1. This is useful information. Just because something is specific doesn't
>> mean it shouldn't be mentioned.
>
> 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.
>
>>> 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.
>>
>> -1
>
> See above.
>
>>
>>> References:
>>>
>>> Why make RFC 2616 and HTML4 spec Normative references? Shouldn't
>>> Informative be OK?
>>
>> For 2616 is makes sense if there are normative constrains specific for
>> HTTP.
>
> See above as well. Why tie ourselves with HTTP only?
>
> Mykyta
>
>>
>> > ...
>>
>> Best regards, Julian
>>
>
>