--On Thursday, September 14, 2017 15:53 +1000 Mark Nottingham
<mnot@xxxxxxxx> wrote:
>...
> I'm not a lawyer, but I would be surprised and concerned if we
> started going after sites that had copies of RFCs posted on
> them for copyright; at any rate, the IETF Trust is never the
> sole owner of copyright in specifications AIUI, so proving
> that we had the right to do so would take more work.
There is also a tradition, going back to when RFCs had
single-digit numbers, that copying, distribution, and reposting
of complete RFCs is always allowed. That was expressed in every
RFC for many years with the phrase "Distribution of this memo is
unlimited". Newer boilerplate refer to BCP 78 and the Trust
Legal Provisions, the latter of which contain (version 5.0,
Section 3(c)(i)) unlimited permission to "copy, publish, display
and distribute IETF Contributions and IETF Documents in full and
without modification" [1]. So, any attempt to "go after" such
sites would violate our rules.
> Perhaps the real problem here is that the versions of RFCs
> that we host don't get very much attention from search
> engines. While this is no doubt in part because people don't
> link to them (in my experience, people will always link to a
> "prettier" version if available), it also may be because we
> don't help ourselves; e.g., in my search engine of choice:
I don't know about that piece of the problem, but we also don't
help ourselves by creating confusion about whether the copy of
an RFC that is referenced should be the one on the RFC Editor
site or the tools site. Moving toward multiple authoritative
versions isn't going to help with that either (your comment
about "pretty" versions notwithstanding, views about what is
pretty are not consistent and, e.g., some of us prefer copies
that are easy to grep). If six people reference a given RFC,
one references the RFC Editor ASCII copy, one their PDF copy,
one references a copy on the Upper Slobbivian mirror site, and
one each references the ASCII, PDF, and HTML versions on the
Tools site, search engines that don't have special knowledge are
going to see six links, dividing what they believe is the number
of references to that document by six.
This is precisely the argument for actual persistent identifiers
or content (and maybe even format-independent content) rather
than pathnames or URLs that depend on locations. But we can't
agree to reference RFCs using URNs, DOIs, or something
equivalent and people who use references of those types just
further reduce the link frequency counts for any particular way
of referencing the the RFC.
If people think the above is a problem that needs solving, I see
much of it as being within the scope of the IESG and RFC Editor
to fix by publishing the preferred link form in each RFC (and on
the tools pages, etc.) rather than leaving it up to the user's
imagination. If they aren't interested and one still thinks it
is important, tell the IAB to think about it, possibly by
putting it on the agenda of the forthcoming identifier workshop
and/or making willingness and ability to deal with it forcefully
on the requirements list for the RFC Series Editor contract.
And, if none of that works, tell it to the Nomcom.
Whether any of that will change W3C's behavior is another
question, I think your "we don't help ourselves" comment is
important.
best,
john
[1] Whether it is wise to bury the redistribution provision that
deep in fairly complex and legalistic documents, or to handle on
a basis that the Trust, could in principle, change on a whim, is
another matter. I note, in that context, that the "Legend
Instructions" of RFC 5378 (aka BCP 79) points to
http://trustee.ietf.org/license-info, but that link redirects to
the Trust Legal Provisions main page
(https://trustee.ietf.org/trust-legal-provisions.html ) which
not only does not contain the Legend information but doesn't
point clearly to where it is. The problem goes downhill from
there; I've just filed an erratum on RFC 5378 to try to get a
stake in the ground about this.