cite-as: A Link Relation to Convey a Preferred URI for Referencing
draft-vandesompel-citeas-04

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-vandesompel-citeas-04. If any part of this review is inaccurate, please let us know.

We understand that when this document is sent to us for processing, the only action required of us will be to update the reference associated with the following existing Link Relation Type registration (https://www.iana.org/assignments/link-relations) to point to the most recent version of this document:

Relation Name: cite-as
Description: Indicates that the link target is preferred over the link context for the purpose of referencing.
Reference: [draft-vandesompel-citeas]

Thank you,

Amanda Baber
Lead IANA Services Specialist

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.

Request for posting confirmation emailed to previous authors: Simeon Warner , Herbert Van de Sompel , John Kunze , Geoffrey Bilder , rfc-ise@rfc-editor.org, Michael Nelson