draft-vandesompel-citeas-04 is proposed for publication as an Informational RFC
on the Independent Submissions Stream.
A web resource is routinely referenced by means of the URI with which
it is directly accessed. But cases exist where referencing a
resource by means of a URI, different than that access URI, is
preferred. This specification defines a link relation type that can
be used to convey such a preference.
This document was first brought to the ISE in April 2018 at version -02.
Expert reviews were commissioned from Mark Nottingham, Barry Leibe, Heather
Flannagan, and one reviewer who wished to remain anonymous. All provided
comments that were addressed by the authors to improve the draft.
This document requests IANA for a new link relation type. Mark Nottingham is
also one of the Designated Experts for the registry.
There remains a small format issue regarding line wraps when an example URI is
too long. We hope the RFC Editor will have some advice on this.
The reviews were as follows...
=== Barry Leibe
Comments to ISE:
0. Definitely do get a review from MNot.
1. I think there is no conflict with IETF work.
2. That said, I don't agree with the author that existing link relations
don't fit. For that matter, I don't think the proposed one does either.
The document lays out a number of different use cases that, as I see them,
need different handling. It then tries to propose a link relation that
handles all cases. More below.
3. Because of (2), I think it would be better to rethink this by separating
the use cases. It might well be that different existing link relations
take care of what's needed, even if a single one doesn't do for all. This
document could be recast as guidance about using certain link relations for
certain use cases.
4. I think there's a lot of editorial work needed here. The document seems
to go out of its way to use awkward wording to force passive voice where
active voice would not be awkward. For example:
OLD
The link relation type defined in this specification allows to convey
to user agents that the reference URI is the preferred URI for
referencing.
NEW
The link relation type defined in this specification allows the web
site to tell user agents to use the reference URI, in preference to
any other, to reference the web page.
END
This weird "allows to X" construction is all over the document.
=== Heather Flanagan
Initial impressions:
* Interesting and I can see some value.
More comments (may be shared with the author)
* Abstract will definitely need to be revised; I was unable to figure
out what he was talking about until the Introduction.
* Might be of interest to point out that the RFC Editor has Info pages
(our preferred reference point due to the extended metadata found on
those pages) whereas other entities almost always point to the TXT file
itself.
* I wonder if Herbert has seen STS
(https://www.niso.org/standards-committees/sts) and JATS
(https://www.niso.org/standards-committees/jats) and considered how
this kind of URI might fit in those schema?
=== Mark Nottingham
# Comments for Authors
Overall this is a reasonable document. A few things could bear
clarification:
* I think a reader of "3.3. Preferred Social Identifier" could be
confused about the intended usage, and walk away thinking that cite-as
is suitable for linking to profiles from *any* social page (e.g., a
tweet or facebook article). Any example would help.
* In Section 4, cite-as is defined as "A link with the "cite-as"
relation type indicates that the link target is preferred over the
link context for the purpose of referencing." The term "reference",
however, is applicable to *every* link on the Web, so read strictly,
this doesn't constrain the link relation's use at all. Some kind of
qualification on "referencing" would be helpful. I know that this is
gone into in some detail in the referenced blog entries, but many
readers will just look at this text in isolation (probably only the
first few sentences).
* The explanation in Section 5 is difficult to read, and would
benefit from a worked example (similar to the blog entry cited in
[canonical-blog]). Most readers are going to ask about the
relationship with "canonical" specifically.
=== Reviewer #4 (anonymous)
I've glanced through it. These are smart folks and thoughtful
people and papers about their ideas are almost certainly worth
publishing. However, this one lies near the nexus of a
fundamental disagreement about strategy.
One way to get/define a persistent identifier is to define
things that way (DOIs, URNs, etc.), and the other is to decide
that, despite conforming to the syntax for URLs, some strings
that look like domain names or URLs are really symbols to be
interpreted in some other way or redirected to some other place.
I have a fundamental problem with the latter because I see it as
a kludge that often involves layer violations and opens up attack
vectors. Because I have not followed the efforts and literature
associated with the link relation efforts, I'm not appropriate as
a detailed reviewer. I don't expect to get the authors from one
perspective to change their minds or their text, at least beyond
pointing out that other points of view exist.
Just a nit, but one I hope you can discuss sooner rather than
later. The "Author's Addresses" section is supposedly to contain
contact information. We used to require a real address, email
address, and usually a phone number of the theory (in the 1980s)
that those were more stable than only one. Jon's thinking was
that, if one of these became useless, at least one would have
multiple handles by which the search for someone could start.
Then we started allowing email addresses alone. This document
appears to contain only URLs pointing to biographical information
and some of those pages do not contain explicit contact information
at all. I think this is a bad idea.