This page is part of the web mail archives of SRFI discuss from before July 7th, 2015. The new archives for SRFI discuss contain all messages, not just those from before July 7th, 2015.
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