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

From: Maile Ohye <[email-masked]>
Date: Sun, 11 Sep 2011 23:03:05 -0700

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 <[email-masked]>
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
>>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Sep 2011 11:30:29 +0200

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

Thanks.

At this point I believe you should send a request for publication to the 
IESG ([email-masked]). If all goes well, the next step will be an 
IETF-wide Last Call, which will provide opportunity for a final round of 
feedback.

Let's get this finished!

Best regards, Julian

---

From: SM <[email-masked]>
Date: Mon, 12 Sep 2011 03:07:19 -0700

At 02:30 12-09-2011, Julian Reschke wrote:
>At this point I believe you should send a request for publication to 
>the IESG ([email-masked]). If all goes well, the next step will be an 
>IETF-wide Last Call, which

  "If you wish to seek Area Director sponsorship for an
   individual submission, the best solution is to contact the
   most relevant Area Director directly, with an explanation of
   why the draft is appropriate for IETF publication. The Area
   Director is also the best source of advice about whether an
   existing WG, or a BoF, may be applicable."

See http://tools.ietf.org/area/app/

Regards,
-sm

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 12 Sep 2011 15:55:26 +0300

Maile,

Could you please justify why do you want to constrain the requirements 
of your document with HTTP model?

Mykyta Yevstifeyev

12.09.2011 9:03, Maile Ohye wrote:
> Hi everyone,
>
> Thanks for the feedback! I'll submit draft-02 which addresses the 
> issues below:
>
> 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.
>
> Maybe you meant "target URI" instead "designated URI" (terminology 
> from RFC 5988).
>
> [ 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]).
>
> 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.”
>
> 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 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.”
>
> -- 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 
> <[email-masked] <mailto:[email-masked]>> wrote:
> > doubt there are alternatives of such definition in *all* protocols 
> for which
> > We aren't defining the link relation fro 'http' and 'https' URIs 
> only; it is

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Sep 2011 14:59:47 +0200

> of your document with HTTP model?

I believe that while the link relation itself is not restricted to 
specific protocols, it still makes sense to explain how it should be 
used with HTTP URIs.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Sep 2011 10:33:42 -0600

> See http://tools.ietf.org/area/app/

I already told authors that I would sponsor this I-D.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 12 Sep 2011 19:34:43 +0300

> specific protocols, it still makes sense to explain how it should be 

There are plenty of other URI schemes, beyond 'http' and 'https', and I 
don't see reasons we may overlook them defining semantics for these two 
only.  Otherwise, the authors should have "The 'canonical' link relation 
type for 'http' and 'https' URIs" rather than "The 'canonical' link 
relation type" in the title.

BTW, there already is a -02 version: 
http://tools.ietf.org/html/draft-ohye-canonical-link-relation-02.  
However, there are still the two places where some requirements are 

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

and

>         permanently moved, could not be implemented in place of the

And I still think this HTTP-centric approach is unacceptable.

Mykyta Yevstifeyev