Al, I was starting to lean towards your argument, but your last couple
of messages have pushed me back to the status quo.

1) People working with email seem to be quite comfortable talking
   about rfc733, rfc822 and rfc2822.  And if you're not sure, google
   will happily use `rfc email' to give you appropriate references.

2) srfi numbers are for programs.  I see nothing whatsoever wrong with
   expecting anyone reading my code to go look up srfi-7 and srfi-14
   if I reference them in my program (and they're not familiar with
   them).  In the process they might even look at a bit more
   documentation than they would with srfi-config-lang and
   srfi-char-lib.  The fear as always with abbreviations is that
   people think they understand when they actually just know enough to
   confuse themselves.

   And similarly, when I'm writing some code and I want a string
   library, I'll ask google or my IDE for `srfi string library' and
   out pops srfi-13 or srfi-13 and srfi-74, and I can go and look at
   the documents to see which one does what I want.  I don't see the
   lossage here...

So I've come to be fairly strongly against the proposal, especially
with authors choosing their own keywords (the editors choosing or the
semantic clustering proposal sound *slightly* better).

../Dave