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

[Maile Ohye <[e-mail]>]

Hi everyone,

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 <[e-mail]>
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
>>
>
>