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

[Mykyta Yevstifeyev <[e-mail]>]

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:
>
> 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] <mailto:[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
> >>
> >
> >
>