[rfc-i] Can the web be archived?

Henning G Schulzrinne hgs at cs.columbia.edu
Wed Jan 21 04:53:34 PST 2015


A roughly similar problem is faced by some regulatory entities. A simple
remedy is to submit critical, but possibly evanescent, resources "into the
record", i.e., they are hosted at the regulatory entity itself, in what we
would recognize as "fate sharing". This only works for material with
permissive copyright (CC and similar), but I suspect this can be worked
around in many cases. I wouldn't worry about this for citations to material
published by major engineering/science societies (ACM, IEEE). Even if one
were to go under, it seems likely that somebody else would pick up the
content and maintain the DOIs.

Thus, the RFC editor could host such content locally, possibly as PDF/A
files, and created a reasonable URL scheme (maybe a DOI).

Henning

On Wed, Jan 21, 2015 at 3:58 AM, Eliot Lear <lear at cisco.com> wrote:

> Hi Heather,
>
> On 1/21/15 2:41 AM, Heather Flanagan (RFC Series Editor) wrote:
> >
> > Indeed.  This problem is extremely frustrating to STEM (scientfic,
> > technical, engineering, and medical) publishers, too.  Different
> > models try to "fix" it, but all models I'm aware of require a
> > publisher to Do Something, where something means registering their
> > documents with a service or trying to archive a copy of everything
> > they reference in their books/journals/articles.
> >
> > So far this hasn't proven to be a tractable problem, particularly not
> > when anyone and everyone can be a publisher on the web.
>
> Perhaps the relevance here is that there be sufficient identifying
> bibliographic information to provide readers the opportunity to search
> for (and hopefully find) the underlying reference.  What standards
> should we hold to for allowing URIs?  Should an author be required?  How
> about a date?  Web Site name?  Any additional meta-information?  Also,
> we assuredly need different standards for normative and informative
> references, right?
>
> Eliot
>
>
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20150121/6acde1a6/attachment.html>


More information about the rfc-interest mailing list
https://www.rfc-editor.org/pipermail/rfc-interest/2015-January/008656.html
www.rfc-editor.org
crawl=CC-MAIN-2019-47
5925
application/http; msgtype=response
sha1:TM4BLZ7Z7D3NLHERXTT7E4CNLWOPILCU
<urn:uuid:71f6360f-75c6-40ae-8152-3dd0b4dc1e70>
2019-11-18T03:29:09Z
4.31.198.49
text/html
sha1:S5DTF2ZIKWW4ZLXYTYDJ72ATW5FPPHLO
<urn:uuid:88ca0464-3ca3-4283-97b3-c6df80645259>
https://www.rfc-editor.org/pipermail/rfc-interest/2015-January/008656.html
response
<urn:uuid:10ffe200-f77f-4623-9148-a5f4dbe4ebea>
isPartOf: CC-MAIN-2019-47
publisher: Common Crawl
description: Wide crawl of the web for November 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-185.ec2.internal
software: Apache Nutch 1.16 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/