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

[Mykyta Yevstifeyev <[e-mail]>]

01.07.2011 16:47, Julian Reschke wrote:
> On 2011-07-01 05:27, Mykyta Yevstifeyev wrote:
>> Hello Maile,
>>
>> Several comments to your draft-ohye-canonical-link-relation-00.
>>
>> There is the Intended Status missing in it. I suppose Informational
>> should be fine.
>
> We do not need to decide this now, and I expect the Area Director 
> who's going to sponsor this to have an opinion on it.
>
> That being said, "Informational" should be fine (Maile: that would be 
> category="info" on the <rfc> element).
So, we both agree on this.
>
>>> 1. Introduction
>>>
>>> The canonical link relation specifies the preferred version of a URI
>> I think some introductory text on linking, probably based on RFC 5988,
>> should go here.
>
> Why? It defines a link relation as defined by RFC 5988, so why repeat 
> text from over there?
It should be mentioned (1) what is link relation at all and (2) that RFC 
5988 is a specification of that technology which this document depends 
on.  RFC 5988 is first mentioned in Examples.
>
>> Section 2:
>>
>>> Presence of the canonical link relation indicates
>>> to applications, such as search engines, that they MAY:
>> I wonder why it's MAY; in this case implementations (explicitly, those
>> apps which interpret Link: headers and corresponding construction in
>> HTML) will be free to ignore it. I think normative SHOULD should be OK
>> (sorry for pun).
>
> I think this link relation is purely advisory, so a better approach 
> might be to replace "MAY" by "can".
Yes, advisory, which suits RFC 2119 definition for SHOULD:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>     may exist valid reasons in particular circumstances to ignore a
>     particular item, but the full implications must be understood and
>     carefully weighed before choosing a different course.
and natural meaning of should - advice/recommendation.
>
>> ...
>>> The value of the target/canonical URI MAY:
>> I suppose omitting "value of the" should be better, since there is no
>> such term in RFC 3986. In fact, when referring the URI, we mean its
>> value, meaning.
>
> Yes.
>
>>> o Exist on a different protocol: http to https, or vice versa
>> You probably meant URI scheme here, since https isn't a separate
>> protocol. As before these points we had "The value of the
>> target/canonical URI MAY" or, if you consider my comment above, "The
>> target/canonical URI MAY", this point may be reworded as "Have different
>> scheme names" (which suits the second variant of a preface to this list
>> better).
>
> Sounds good.
I didn't mentioned it also applies to (Section 3, last list):

>     The value of the target/canonical URI SHOULD NOT designate:

>
>> Reading section 3 and 5 of the draft, it seems that is mandates use of
>> HTTP when referring to canonical URIs. And what is the situation when
>> target URI is a 'ftp' or 'gopher' URI? Section 3 allows different scheme
>> names in context/target URIs, if I understand it correctly. Therefore,
>> unless it is deliberately, I think any mention of HTTP should be
>> replaced by more generic regulations.
>
> Nope; I think the HTTP examples are very useful. But maybe we can have 
> an additional statement that the link relation isn't specific to HTTP.
Currently we have normative reference to RFC 2616 and normative 
requirements with respect to HTTP.  HTTP examples are OK; but it's 
redundant in Section 3.  I suppose in Section 3 we may replace 
HTTP-related stuff with something in the way like:

Old:
>     o  The source URI of a "300 Multiple Choices" URI (Section 10.3.1 of
>        [RFC2616]) or a permanent redirect (Section 10.3.2 of [RFC2616]).
New:
>     o  The source URI, which defines a resource which provides choice
>        in different represntations of a given resource, ientified by
>        the context URI, or is a link which has been permanently replaced
>        by an other one.
etc.
>
>>> 8. Internationalisation Considerations
>>>
>>> In designating a canonical URI, please see [RFC3986] for information
>>> on URI encoding.
>> URIs themselves are not internationalized, in terms of RFC 3536, which
>> defined:
>>
>>> internationalization
>>>
>>> In the IETF, "internationalization" means to add or improve the
>>> handling of non-ASCII text in a protocol.<NONE>
>> IRIs serve for this purpose. I recommend either to rename the section to
>> Encoding considerations or skip it at all ( I personally like 2nd 
>> variant).
>
> I believe we'll need this section, and the contents is fine; after 
> all, this is what you have to think of with respect to I18N, no?
RFC 5988 allows target and context URIs to be IRIs.  Current draft has 
no provisions regarding this.  However, the actual and current text 
matches encoding considerations better.

Mykyta Yevstifeyev
>
>> ...
>
> Best regards, Julian
>