Subject: [Tools-discuss] Proposal or DoS attack (?)

From: Frank Ellermann <[email-masked]>
Date: Sat, 15 Apr 2006 11:55:48 +0200

Hi, at the moment all occurences of "RFC nnnn" in Wikipedia are
automagically linked to http://www.ietf.org/rfc/rfcnnnn.txt for
numbers nnnn. 

The target URL can be set per Mediawiki project (Wikipedia,
Wiktionary, Wikisource, different languages, etc.), example:
http://en.wikipedia.org/wiki/MediaWiki:Rfcurl

I'd prefer http://tools.ietf.org/html/nnnn as target URL, not
only because it's shorter:  The simple Rfcmarkup HTML supports
links to individual sections and pages while keeping the layout
of the official plain text RFC.  Rfcmarkup links everything
that it identifies as link, allowing easy browsing.  And most
important it adds links to errata and updates where available.

It took me ages to update many RFC 1891..1894 by 3461..3464 on
Wikipedia, or 2048 by 4288+4289, with Rfcmarkup this would be
far less important, because it directly says "obsolete" where
that's clear, example: http://tools.ietf.org/html/2048

But Wikipedia might generate quite a lot of hits, can the tools
server handle this?  I'll copy that question to the talk page
http://en.wikipedia.org/wiki/MediaWiki_talk:Rfcurl when it got
a permalink on GMaNe.
                        Bye, Frank

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 15 Apr 2006 15:25:12 +0200

Hi Frank,

> automagically linked to http://www.ietf.org/rfc/rfcnnnn.txt for
...
> http://en.wikipedia.org/wiki/MediaWiki_talk:Rfcurl when it got

The tools servers are not loaded hard currently (except when
badly behaved robots generate script-invoking queries at a much
higher rate than all other traffic).  I think we'll risk it -- 
if I see that the load becomes a problem I'll arrange for the
html pages to be permanently cached and served up from disk once
they are generated.  I already do this for the generated .pdf
files, so it should be a small fix.

We'll also have an additional (third) server with oodles of disk
space coming online shortly.  Go for it.

Regards,

	Henrik