The theory that all April 1 dates RFCs are simply jokes and nothing else is also easily refuted. Consider RFC 3092. It is an April 1st RFC produced through that process and has certainly produced some chuckles. Yet I've lost count of the number of emails I've gotten over the years from non-English speakers thanking me for the RFC and saying it was helpful to them... Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@xxxxxxxxx On Mon, Apr 8, 2013 at 3:21 AM, Måns Nilsson <mansaxel@xxxxxxxxxxxxxxxx> wrote: > Subject: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes. Date: Sun, Apr 07, 2013 at 04:58:52PM -0400 Quoting Hector Santos (hsantos@xxxxxxxx): >> This is one of those DPEP (Diversity Problem Entry Point) arising >> from globalization, April 1 HRC (Humor Recognition Culture) >> differences, IETF "stalization" and the growth of I-D submissions. >> I suggest there is a direct correlation among these factors with the >> end goal efficacy of the submission. Fortunately, there is a >> technical solution for this particular DPEP: >> >> if Date is April.1 then >> id.filename = "joke-"+id.filename. >> end if > > This solution has all the virtues of carpet-bombing. Mission accomplished > but cost and collateral damage are improportionally large. To me, both > as humour /per se/ and as sorting help when selecting vendors (cf. my > message in this thread yesterday), the value almost totally lies in the > subtle play with form and the resulting ambigousness. In other words, > if we make it possible to determine by simple logic whether a document > is a pun or dead serious, it is useless. > > I am aware that my position as stated above will be possible to interpret > as excluding. As parent of a child diagnosed with Aspergers syndrome, > I fully well know the potential consequences of failure to interpret > social hints. > > I believe that > > * transient failure to get a joke not is cause for "safing" jokes. The > failure is part of the process. > > * the speed with which we "unfail" and start to appreciate this art > form is personal and differs according to our experience, background > and intellectual skills but that the initial failure is necessary. There > are subtler ways than policy and procedure to nudge people along when > they persist in failing. > > * the Internet idea of loosely cooperating networks REQUIRES autonomous > judgement from the people operating the system. Fostering a culture > where IETF texts are seen as close to faultless holy scripture does > nothing to encourage skepticism and personal responsibility. > > * enough has been said in this that we already are risking the sweet > uncertainity. Accordingly, I'll try to not communicate further on this, > and definitely not propose any procedure work. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > I am deeply CONCERNED and I want something GOOD for BREAKFAST! > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAlFib/gACgkQ02/pMZDM1cVp0wCePKf4nLxF85ZBOACv1itL0G8s > pDwAoKPsjMy06MZRr2eMHiOegi5vCs/g > =UNMB > -----END PGP SIGNATURE----- >