[IRC-Dev CVS] [CVS] Module ircdh: Change committed

[Toni G. <zo...@us...>]

CVSROOT    : /cvsroot/irc-dev
Module     : ircdh
Commit time: 2003-01-18 23:45:24 UTC

Added files:
     doc/en/Authors doc/en/fda.txt doc/en/features.txt
     doc/en/freebsd.txt doc/en/iauth.txt doc/en/irc.1 doc/en/ircd.8
     doc/en/iso-time.html doc/en/linux-poll.patch doc/en/p10.html
     doc/en/readme.asll doc/en/readme.chroot doc/en/readme.crules
     doc/en/readme.cvs doc/en/readme.features doc/en/readme.gline
     doc/en/readme.indent doc/en/readme.jupe doc/en/readme.log
     doc/en/readme.who doc/en/readme.www doc/en/rfc1413.txt
     doc/en/snomask.html doc/en/strings.txt

Log message:

Documentacion en ingles

---------------------- diff included ----------------------
Index: ircdh/doc/en/Authors
diff -u /dev/null ircdh/doc/en/Authors:1.1
--- /dev/null	Sat Jan 18 15:45:24 2003
+++ ircdh/doc/en/Authors	Sat Jan 18 15:45:13 2003
@@ -0,0 +1,215 @@
+/************************************************************************
+ *   IRC - Internet Relay Chat, doc/AUTHORS
+ *   Copyright (C) 1990
+ *
+ * AUTHORS FILE:
+ *   This file attempts to remember all contributors to the IRC
+ *   developement. Names can be only added this file, no name
+ *   should never be removed. This file must be included into all
+ *   distributions of IRC and derived works.
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 1, or (at your option)
+ *   any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ *
+ *   You should have received a copy of the GNU General Public License
+ *   along with this program; if not, write to the Free Software
+ *   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+IRC was conceived of and written by Jarkko Oikarinen <jt...@to...>.
+IRC was originally written in University of Oulu, Computing Center.
+Jan 1991 - IRC 2.6  jt...@to...
+	- Multiple Channels and protocol changes
+
+Contributions were made by a cast of dozens, including the following:
+
+Markku Jarvinen <mt...@tu...>: Emacs-like editing facility for the client
+
+Kimmo Suominen <ki...@ka...>: HP-UX port
+
+Jeff Trim <jt...@or...>: enhancements and advice
+
+Vijay Subramaniam <vi...@ll...>: advice and ruthless publicity
+
+Karl Kleinpaste <ka...@ci...>: user's manual
+
+Greg Lindahl <gl...@vi...>: AUTOMATON code, the Wumpus GM automaton,
+myriad bug fixes
+
+Bill Wisner <wi...@ha...>: numerous bug fixes and code
+enhancements
+
+Tom Davis <con...@ze...> and Tim Russell <ru...@ze...>:
+VMS modifications
+
+Markku Savela <ms...@te...>: advice, support, and being the
+incentive to do some of our *own* coding. :)
+
+Tom Hopkins <ho...@bu...>: bug fixes, quarantine lines,
+consolidation of various patches.
+
+Christopher Davis <ck...@cs...>: EFnet/Anet gateway coding,
+many automata ;), documentation fixing.
+
+Helen Rose <hr...@cs...>: documentation updating, and fixing.
+
+Tom Hinds <ro...@bu...>: emacs client updating.
+
+Tim Miller <ce...@bu...>: various server and client-breaking
+features.
+
+Darren Reed <av...@co...>: various bug fixes and enhancements.
+Introduced nickname and channelname hash tables into the server.
+
+The version 2.2 release was coordinated by Mike Bolotski
+<mi...@sa...>.
+
+The version 2.4 release was coordinated by Markku Savela and
+Chelsea Ashley Dyerman
+
+The version 2.5.2 release was coordinated by Christopher Davis, Helen Rose,
+and Tom Hopkins.
+
+The versions 2.6.2, 2.7 and 2.8 releases were coordinated by Darren Reed.
+
+Contributions for the 2.8 release from the following people:
+Matthew Green <ph...@co...>
+Chuck Kane <ck...@ec...>
+Matt Lyle <ma...@oc...>
+Vesa Ruokonen <ruo...@lu...>
+
+Markku Savela <Mar...@vt...> / April 1990
+Fixed various bugs in 2.2PL1 release server (2.2msa.4) and changed
+sockets to use non-blocking mode (2.2msa.9). [I have absolutely
+nothing to do with clients :-]
+
+Chelsea Ashley Dyerman <ch...@ea...> / April 1990
+Rewrote the Makefiles, restructuring of source tree. Added libIrcd.a to
+the Makefile macros, numerous reformatting of server text messages, and
+added mkversion.sh to keep track of compilation statistics. Numerous
+bug fixes and enhancements, and co-coordinator of the 2.4 release.
+
+Jarle Lyngaas (nm...@al...) added Note functions to ircd.
+
+Armin Gruner <gr...@in...> / May, June 1990:
+* Patched KILL-line feature for ircd.conf, works now.
+  Enhancement:  Time intervals can be specified in passwd-field.
+  Result: KILL-Line is only active during these intervals
+* Patched PRIVMSG handling, now OPER can specify masks for sending
+  private messages, advantage: msg to all at a specified server or host.
+* Little tests on irc 2.5 alpha, fixed some little typos in client code.
+  Change: common/debug.c has been moved to ircd/s_debug.c, and a
+  irc/c_debug.c has been created, for the benefit that wrong server msg
+  are displayed if client does not recognize them. (strange, if a server
+  sends an 'unknown command', isn't it?)
+
+Tom Hopkins <ho...@bu...> / September, October 1990:
+* Patched msa's K lines for servers (Q lines).
+* Consolidated several patches, including Stealth's logging patch. 
+* Fixed several minor bugs. 
+* Has done lots of other stuff that I can't seem to remember, but he
+  always works on code, so he has to have done alot more than three
+  lines worth. :) 
+
+Thanks go to those persons not mentioned here who have added their advice,
+opinions, and code to IRC.
+
+Various modifications, bugreports, cleanups and testing by:
+
+Hugo Calendar <hu...@uc...>
+Bo Adler <ad...@cs...>
+Michael Sandrof <ms...@an...>
+Jon Solomon <js...@cs...>
+Jan Peterson <jl...@ha...>
+Nathan Glasser <na...@br...>
+Helen Rose <hr...@ef...>
+Mike Pelletier <st...@ca...>
+Basalat Ali Raja <gw...@ta...>
+Eric P. Scott <ep...@to...>
+Dan Goodwin <fo...@wp...>
+Noah Friedman <fri...@ai...>
+
+
+UNDERNET (1991 - 1999)
+--------
+
+The Undernet versions (TSpre8, u2.9 and u2.10) are based on ircd-2.8.10 and
+contain thousands of hours of work by Carlo Wood <ca...@al...>
+(Run on IRC). The number of protocol enhancements, changes and additions
+that have been added are too many to summarize.  All patches are kept in the
+cvs repository at http://coder-com.undernet.org/.  Discussions on this
+server code are currently on the mailing list cod...@un..., or in
+#coder-com on undernet.
+
+The current maintainer is Bleep.
+
+Various additions and bugfixes have been contributed by:
+
+Aaron <agi...@sc...>
+Bleep <to...@in...>
+CaptJay <ca...@su...>
+CapVideo <ma...@pu...>
+Chaos <si...@tr...>
+Cym <cy...@ac...>
+Derrick <di...@se...>
+Ensor <dh...@ra...>
+flux <cml...@uc...>
+Ghostwolf <fo...@tr...>
+Gte- <gt...@at...>
+Isomer <is...@co...>
+Jamey <wo...@du...>
+Jarle <ja...@II...>
+Kev <kl...@mi...>
+Nemesi <co...@ti...>
+Niels <ni...@ho...>
+Run <ca...@al...>
+record <jeg...@cl...>
+smg <sm...@lm...>
+SeKs <in...@st...>
+Simon- <si...@pe...>
+Starfox <st...@qu...>
+Trio <tr...@b6...>
+WildThang <dvm...@an...>
+Xorath <vo...@wh...>
+
+UNDERNET (2000 - 2002)
+--------
+
+The UnderNet versions (P9, P10 and u2.10.11) are based on ircu2.10.07
+and contain many hours of work by the Coder Committee.
+The number of protocol enhancements, changes, and additions
+that have been added are way too many to summarize. Discussions on this
+server code are currently on the mailing list cod...@un...
+or in #coder-com on UnderNet.
+
+The current maintainer is Isomer.
+
+Various additions, testings, and bugfixes have been contributed by:
+
+Bleep <to...@in...>
+Gte- <gt...@at...>
+Isomer <is...@co...>
+Kev <kl...@mi...>
+Delete <de...@cy...>
+Ghostwolf <fo...@wt...>
+Braden <db...@ya...>
+net <ne...@as...>
+Steven <st...@do...>
+OmniDynmc <om...@dy...>
+Dianora <db...@db...>
+Sengaia <se...@un...>
+Cyberdude <Cyb...@un...>
+Maniac- <ma...@ce...>
+Vampire- <va...@p1...>
+mbuna <mb...@bu...>
+beware <ste...@to...>
+n3tguy <ne...@sp...>
+R33D33R <re...@re...>
+Math <ma...@ro...>
Index: ircdh/doc/en/fda.txt
diff -u /dev/null ircdh/doc/en/fda.txt:1.1
--- /dev/null	Sat Jan 18 15:45:24 2003
+++ ircdh/doc/en/fda.txt	Sat Jan 18 15:45:13 2003
@@ -0,0 +1,151 @@
+fdaman.txt - brief usage information for FDA (Free Debug Allocator)
+
+Copyright (C) 1998 Thomas Helvey <to...@in...>
+
+1. Base Functionality
+Basic use of the fda tools is as simple as including the header
+and source file with your source defining DEBUG and using capitalized
+versions of malloc(), calloc(), realloc(), and free().
+The fda allocation functions verify all your arguments and will call
+assert() if something is wrong. FDA trashes all allocated memory
+in a predictable manner and applies prefix and postfix bounds checking
+signatures to every allocation. When a pointer is freed it's validated,
+and checked for overflows and underflows. The fda Realloc function
+does not allow malloc or free through realloc and forces reallocation
+if the required memory is larger than the current allocation.
+
+In both the DEBUG and non-debug versions of fda, if a memory allocation
+fails once, a low memory callback function is called to allow you to
+release some memory and allow malloc to succeed, the default version
+prints a warning message to stderr. If the low memory callback returns
+the allocation is attempted again, if the second allocation fails a
+no memory callback function is called to allow you to clean up before
+terminating the application, if you allow the no memory callback to
+return the results are undefined. (a NULL ptr will be returned from the
+allocation call) The default no memory handler prints an error message
+to stderr and calls abort(). The DEBUG version will assert if you allow
+the no memory function to return.
+Both the low memory and no memory callbacks have the signature of:
+void handler(void)
+
+The debug version of fda will not allow you to do the following:
+Allocate a zero length chunk of memory.
+Free a non-allocated pointer.
+Free a pointer twice.
+Free a pointer at the wrong offset.
+Use realloc to free memory. (realloc(p, 0))
+Use realloc to malloc memory. (realloc(0, s))
+Overwrite the bounds of the memory you allocated. (checked on free)
+
+The base functions for fda are:
+void* malloc(size_t)
+void* realloc(void*, size_t)
+void* calloc(size_t, size_t)
+void  free(void*)
+char* strdup(const char*)
+void  set_lowmem_handler(void (*fn)(void))
+void  set_nomem_handler(void (*fn)(void))
+
+FDA uses a hash table to lookup pointers. The size of the hash table can
+be changed at compile time by using -DFDA_HASH_TABLE_SIZE <prime>
+where prime is a prime number somewhere around the number of allocations
+expected. The default hash table size is 16339 which should be large enough
+to hold most medium sized applications. FDA allocates memory for it's
+debugging records so if your application uses a lot of memory you
+may want to make sure you have enough memory available to use the debug
+version. FDA allocates 20 bytes to store each allocation and 20 bytes
+to store location information (file and line info). This overhead only
+applies if you have DEBUG or _DEBUG defined.
+
+2. Extended functionality
+FDA provides a few handy functions for validating pointers and
+checking for overruns before they occur when debugging.
+The first function fda_sizeof(ptr) returns the size of the buffer
+pointed to by ptr, this allows you to verify that your pointer
+is what it says it is. fda_sizeof() will call assert() if the
+pointer you pass it is not at the start of an allocation.
+
+The second function valid_ptr(ptr, size) verifies that ptr lies within
+allocated memory and there are at least size bytes available in the buffer.
+You can pass valid_ptr() a pointer to any location in allocated memory.
+valid_ptr() calls assert if the pointer points outside of allocated memory
+or the remaining size is less than the size specified.
+valid_ptr() is more efficient if the pointer argument is the value
+returned from malloc because it's a simple hash table lookup, a more
+exhaustive algorithm is used if it's not found in the hash table.
+
+FDA extended functions:
+size_t fda_sizeof(const void*)
+int    valid_ptr(const void*, size_t)
+
+Typical usage for the fda extended functions:
+Note: the assert macro compiles to nothing if NDEBUG is defined.
+Verify a foo_ptr:
+assert(sizeof(struct foo) == fda_sizeof(foo_ptr));
+assert(valid_ptr(foo_ptr, sizeof(struct foo)));
+Check for room to write:
+assert(valid_ptr(buf, len));
+
+3. Leak checking and block validation
+FDA has several functions for leak checking, and reference marking.
+fda_clear_refs() iterates through all of the allocated blocks of
+memory and clears the referenced flag.
+fda_set_ref() marks a single allocation(block) as being referenced or
+in use by somebody.
+fda_assert_refs() iterates through all the allocated blocks of
+memory and calls assert() if it finds one that's not referenced.
+
+Typical usage of the block validation functions:
+fda_clear_refs();   /* clear all block references */
+
+for each allocation do
+fda_set_ref(allocation);  /* mark allocation in use */
+done
+
+fda_assert_refs();  /* this will assert if a leak is found */
+
+4. Reporting functions:
+FDA has 4 functions for reporting various aspects of allocation
+status.
+fda_get_byte_count() tells you the current total number of bytes
+your application has allocated. (this does not include debugging records)
+This will give you an idea of how much memory your application is
+using at any given time.
+
+fda_get_block_count() returns the total count of current allocations.
+
+fda_enum_locations() calls a user supplied enumeration function with
+file, line, count information, this allows you to see your file by
+file allocation density. ;) fda_enum_locations() returns the total
+number of locations that have memory allocated.
+
+fda_enum_leaks() calls a user supplied enumeration function with
+file, line, size, and ptr for every block not marked as referenced.
+One use for fda_enum_leaks() is checking for leaks when your program
+exits:
+void enum_fn(const char* file, int line, size_t size, void* ptr)
+{
+  printf("Memory leak: %s: %d - %d bytes at (%p)\n", file, line, size, ptr);
+}
+
+int main(void)
+{
+  ...
+#if defined(DEBUG)
+  /* check for memory leaks before exiting */
+  fda_clear_refs();
+  fda_enum_leaks(enum_fn);
+#endif
+  return 0;  /* return from main */
+}
+
+The test file fdatest.c gives examples of usage for most of the functions
+available with FDA.
+
+Please let me know if you encounter any problems with FDA.
+So far FDA has been built and tested on linux and Windows NT.
+If you find that it works with or without change on other platforms
+please let me know so I can make the appropriate changes to the
+code and add it to the list of tested platforms.
+
+
Index: ircdh/doc/en/features.txt
diff -u /dev/null ircdh/doc/en/features.txt:1.1
--- /dev/null	Sat Jan 18 15:45:24 2003
+++ ircdh/doc/en/features.txt	Sat Jan 18 15:45:13 2003
@@ -0,0 +1,208 @@
+Undernet server features.
+-------------------------
+
+This document is supposed to list the features that undernet supports and
+provides to clients, and which version of ircu this was added.  Additional
+numeric replies should be added here too.
+
+Extended Who information: (WHOX)
+ Version: unknown, but at least 2.10.07+
+
+ This is described in the file 'readme.who'
+
+USERIP:
+ Version: unknown, but at least 2.10.07+
+
+ This works the same as userhost, but returns the IP instead, useful for
+ setting a ban on someones IP address instead of their nick.
+ usage:
+  USERIP nick[,nick...]
+ returns:
+  RPL_USERIP (307)
+  :server.name 307 target nick[*]=[+|-]user@host...
+
+RPL_ISUPPORT:
+ version: 2.10.08+
+  
+ This sends a numeric during client signon that lists various features that
+ ircu supports.  This allows client and script writers to know what features
+ they can use, and various parameters about the irc server.  The numeric
+ used is '005' to try and maintain some semblance of compatibility with
+ dalnet which has a similar feature.  The 005 numeric may be split across
+ multiple lines if the length exceeds 512 characters.
+
+ The format is:
+  :servername 005 target feature1 feature2... :are supported by this server.
+  :servername 005 target feature200... :are supported by this server.
+
+ features are either a word describing the feature eg: 'SILENCE', or a word
+ describing the feature and an equals and a list of parameters.  
+ eg: SILENCE=15 (says that we support silence, and we support up to 15 of
+ them per user), or FOO=12,3 (says we support FOO with parameters 12 and 3)
+ for example 2.10.08 lists:
+
+ :test.undernet.org 005 test SILENCE=15 WHOX WALLCHOPS USERIP CPRIVMSG 
+   CNOTICE MODES=6 MAXCHANNELS=10 MAXBANS=30 NICKLEN=9 TOPICLEN=160
+   KICKLEN=160
+ 
+ NOTE: Versions prior to 2.10.08+ use numeric 005 as part of 'MAP', so
+ 005 should be /not/ be used after the server registration has occured.
+ (ie: after END_OF_MOTD has arrived).
+
+MAP:
+ Version: unknown, but since 2.9.30 at least, updated in 2.10.08
+ 
+ /map shows the servers as the server percieves them, who's connected
+ to who in a pretty display.  In version 2.10.08 it also lists the
+ amount time time it takes a message to get /from/ a server to the local
+ server - this measures the one way lag only, in 2.10.08 it also lists
+ the number of clients that are currently on that server.
+ The lag estimation is very approximate and depends on people changing nick
+ and joining channels, so the less clients on a server the less reliable the
+ lag estimation is.
+
+ Map prior to 2.10.08 uses:
+  RPL_MAP     005
+  RPL_MAPMORE 006
+  RPL_MAPEND  007
+ Map changed in 2.10.08 to allow for ISUPPORT on numeric 005, the new
+  numerics are:
+  RPL_MAP     015
+  RPL_MAPMORE 016
+  RPL_MAPEND  017
+ 
+WALLCHOPS:
+ Version: unknown, but since 2.10.07
+ 
+ WALLCHOPS sends a message to all channel operators (@)'s on a channel.
+ It does /not/ require you to be op'd (@'d) to do so.  This is a feature.
+ 
+ syntax:
+  WALLCHOPS #channel :message
+ or:
+  NOTICE @#channel :message
+
+ this sends:
+  :user NOTICE @#channel :message
+ to clients that are @'d on the channel.
+
+CPRIVMSG/CNOTICE:
+ Version: unknown, but since 2.10.07
+
+ CPRIVMSG/CNOTICE are a way around target limiting in recent undernet
+ servers.  Undernet servers prevent you from sending messages to too many
+ people at once in an attempt to help cut down the amount of spam that
+ occurs on the network.  Because there are several situations where you want
+ to send messages to lots of people that are on the same channel as you
+ (autogreet's and gamebots for example) an 'escape' was made in the form
+ of CPRIVMSG/CNOTICE.  These allow you to send a privmsg/notice to a person
+ on a common channel if you are op'd (@'d) without incuring a target
+ penalty.  If you see 'Target changed too fast' messages, you should
+ probably be using these commands.
+
+ Syntax:
+  CPRIVMSG #channel nick :Message
+  CNOTICE #channel nick :Message
+ 
+ Results are the same as for 'PRIVMSG' and 'NOTICE' respectively.
+
+SILENCE:
+ Version: unknown, 2.9.32 at least.
+
+ Silence is a server side ignore.  You can /silence +hostmask or
+ /silence +nick, to add someone to your silence list, or use /silence
+ -hostmask to remove it.  /silence will list your 'silence list'.
+ you can /silence nick, to see someone elses silence list (useful for
+ helping someone).  Silence is preferably used as a last resort as it
+ tends to use server CPU time.  Undernet typically only allows 15 silences
+ per user.  in 2.10.08+ this information is available in the RPL_ISUPPORT
+ line.
+
+ Syntax:
+  SILENCE +hostmask
+  SILENCE +nick
+  SILENCE -hostmask
+  SILENCE -nick
+  SILENCE nick
+
+ reply:
+  RPL_SILELIST      217
+  RPL_ENDOFSILELIST 218
+ 
+User modes:
+ Version: various
+
+ Undernet supports these additional user modes:
+  +d: Deaf & Dumb.  This user will not get any channel traffic.  Used for
+      bots.
+  +k: This user cannot be kicked, deop'd or /kill'd.  This usermode may only
+      be set by a server, it may not be set by a user.  This is used by
+      undernet service bots (X/W/UWorld etc)
+  +g: List channel HACK:'s
+  +s: Server messages - takes a parameter of which masks to send, see
+      'snomask.html' for more details. (2.10.0+)
+
+LIST:
+ Version: Unknown
+
+ List now takes various parameters to allow you to quickly and efficiently
+ find interesting channels.  These are:
+
+ >n or <n   show channels with less than or greater than 'n' users
+            respectively
+ C>n or C<n show channels that have existed for less than or greater than
+            'n' minutes.
+ T>n or C<n show channels that have had their topic changed in less than or 
+            greater than 'n' minutes.
+
+ Additional Numerics:
+  RPL_LISTHELP 334
+
+Additional Topic Numerics:
+ Version: Since the dawn of time.
+
+ Topic also lists who set it and when they set it.
+
+ Additional Numerics:
+  RPL_TOPICWHOTIME 333
+ 
+ Straight after the topic:
+  :server.name 333 #channel Isomer 923423442
+ where the number is seconds past 00:00 1970-01-01 that the topic was set.
+
+
+INVITE list:
+ Version: 2.10.08+
+
+ /invite without any parameters lists which channels you have an outstanding
+ invite to (ie: an invite to a channel which you haven't joined)
+ 
+ Additional Numerics:
+  RPL_INVITELIST      346
+  RPL_ENDOFINVITELIST 347
+
+NICK change:
+ Version: Since the dawn of time.
+
+ Undernet prevents you from changing nick on a channel while your banned.
+ Undernet prevents you changing nicks more than once per 30 seconds, you
+ get one 'free' nick change if you haven't changed nick recently.
+
+ Additional Numerics:
+  RPL_BANNICKCHANGE 347
+  RPL_NICKTOOFAST   349
+
+Target limiting:
+ Version: Recent 2.10.07ish at least.
+
+ Undernet prevents you from changing 20 targets per 2 minutes.  A target
+ is a 'Nick' or 'channel'.  This is to prevent spam.  If you message more
+ than 20 people or join more than 20 channels in two minutes then you'll
+ start getting 'Target change too fast' and will have to wait before you
+ can start talking.  See CPRIVMSG/CNOTICE above for information on how to
+ avoid this.
+
+ Additional Numerics:
+  ERR_TARGETTOOFAST 349
+
+
Index: ircdh/doc/en/freebsd.txt
diff -u /dev/null ircdh/doc/en/freebsd.txt:1.1
--- /dev/null	Sat Jan 18 15:45:24 2003
+++ ircdh/doc/en/freebsd.txt	Sat Jan 18 15:45:13 2003
@@ -0,0 +1,28 @@
+This document pertains to kernel panics with FreeBSD involving mbufs.
+
+   This is a well documented problem with programs such as ircu, and inn that
+   involve a lot of clients, the solution is generally to set the option 'NMBCLUSTERS'
+   to a reasonably higher number the default is 1024, you should first try increasing
+   this *10 (10240) and continue checking mbuf usage with netstat -m.
+
+   It has been recommended that this be increased as far as *50 (51200) (although more
+   won't hurt, it uses more memory, so don't go too far overboard) it's been stated
+   over and over that the default is very low, but then, you're supposed to know how
+   to configure your OS for what you're doing right? =)
+
+   There is a note in the configuration for this:
+
+   # Note that you will probably want to bump up NMBCLUSTERS a lot to use
+   options NMBCLUSTERS=1024
+   Merely change the 1024 to the number that best suites your system.
+
+
+     -poptix po...@po...
+
+
+
+
+
+
+
+   April 17, 2000 Matthew S. Hallacy
Index: ircdh/doc/en/iauth.txt
diff -u /dev/null ircdh/doc/en/iauth.txt:1.1
--- /dev/null	Sat Jan 18 15:45:24 2003
+++ ircdh/doc/en/iauth.txt	Sat Jan 18 15:45:13 2003
@@ -0,0 +1,205 @@
+$Id: iauth.txt,v 1.1 2003/01/18 23:45:13 zolty Exp $
+
+Patrick Alken <wn...@un...>
+01/09/2000
+
+Ircd Authentication
+==== ==============
+
+1. Introduction
+
+  This document describes the protocol used for the IAuth server.
+IAuth performs authorization checks for all clients that connect
+to the ircd server.
+
+2. Protocol
+
+  Ircd and IAuth communicate through a TCP/IP connection. The
+Ircd server will always initiate the connection to the IAuth
+server.
+
+2.1 Server
+
+  When an Ircd server first connects to an IAuth server, it will
+send IAuth a string of the form:
+
+    Server <name>
+
+      <name>     - Ircd server name
+
+  This is used for identification purposes in case more than one
+Ircd server is using an IAuth server.
+
+2.2 Class
+
+2.2.1 Class Add
+
+  When an Ircd server first connects to an IAuth server, it will
+send IAuth it's class list in the form:
+
+    Class Add <number> <maxlinks>
+
+      <number>   - Class number
+      <maxlinks> - Maximum number of clients in this class
+
+  This is needed for the I-line check, in case the number of
+clients allowed to use a certain I-line is limited.
+
+2.2.2 Class Clear
+
+  Upon a rehash, the Ircd server will send I-line a string of the
+form:
+
+    Class Clear [number]
+
+      [number]   - optional number
+
+  In case the Ircd server's Y: lines were changed prior to the
+rehash, IAuth will clear it's old class list to make room for
+the new one Ircd will send after the rehash (via Class Add).
+
+2.3 DoAuth
+
+  When a client connects to the Ircd server, Ircd will send
+a string of the form:
+
+    DoAuth <id> <nickname> <username> <hostname> <IP> [password]
+
+      <id>       - A unique ID used to identify each client
+      <nickname> - Client's nickname
+      <username> - Client's username
+      <hostname> - Client's hostname
+      <IP>       - Client's IP Address in unsigned int format
+      [password] - *Optional* Client password
+
+  The DoAuth directive will initiate an authorization check on
+the client. The following checks are performed.
+
+2.3.1 I-line Check
+
+  This check will ensure that the client matches a valid I-line
+(as given in iauth.conf). If the client fails this check, he/she
+will not be allowed to remain connected to the Ircd server.
+The actual reason they failed authorization will be told to them.
+(See the BadAuth directive).
+  See the section on iauth.conf for more information on I-lines.
+
+2.3.2 Server Ban Check
+
+  K-lines are server-wide bans for individual (or groups of) clients.
+If a client matches a K-line, they will be disconnected from the
+Ircd server with the reason they are banned. The only exception to
+this is if they have an exemption flag in their I-line. See the
+iauth.conf section for more details on this.
+
+2.3.3 Quarantine Check
+
+  Q-lines specify nicknames which are not allowed to be used on
+the Ircd server. If a client's nickname matches that of a Q-lined
+nickname, they will be informed they have selected a quarantined
+nickname and be disconnected from the server.
+
+2.4 DoneAuth
+
+  If a client passes all of the above checks, they will pass
+authorization and be allowed to continue their connection to
+the Ircd server. IAuth will send a string back to the Ircd
+server of the form:
+
+    DoneAuth <id> <username> <hostname> <class>
+
+      <id>       - Client's unique ID
+      <username> - Client's username
+      <hostname> - Client's hostname (may be different from original
+                   if they are allowed a spoof)
+      <class>    - Client's I-line class
+
+  This will inform the Ircd server that the specified client is
+authorized to connect.
+
+2.5 BadAuth
+
+  If a client fails any of the above checks, IAuth will send a
+string to the Ircd server of the form:
+
+    BadAuth <id> :<reason>
+
+      <id>       - Client's unique ID
+      <reason>   - Reason client failed authorization
+
+  The Ircd server will then send an error back to the client
+containing <reason> and disconnect them.
+
+3. Configuration file (iauth.conf)
+
+  IAuth reads a configuration file upon startup. The name of the
+file is located in setup.h, under #define CONFFILE. The format
+of this file is identical to that of ircd.conf, except it supports
+less directives.
+
+3.1 I-lines (Server Access)
+
+  I-lines allow clients access to the Ircd server and are of the
+form:
+
+    I:<spoofhost>:[password]:[flags][user@]<host>::<class>
+
+      <spoofhost> - Hostname to give client if SPOOF_FREEFORM
+                    is defined.
+      [password]  - *Optional* password that clients will
+                    be required to supply to gain access.
+      [flags]     - *Optional* flags (see below)
+      [user]      - *Optional* username (if not given, defaults
+                    to "*")
+      <host>      - Client's hostname
+      <class>     - I-line class (see section Class Add)
+
+  Possible values to go in the [flags] section are:
+
+                = - Spoof their IP Address (requires #define
+                    SPOOF_FREEFORM)
+                ! - Limit 1 client per IP Address
+                - - Do not give them a tilde (~) character if they
+                    are not running identd
+                + - Do not allow them to connect if they are not
+                    running identd
+                ^ - Client is exempt from K/G lines
+                > - Client is also exempt from connection limits
+
+3.2 K-lines (Server Bans)
+
+  K-lines specify clients who are banned from the Ircd server and
+are of the form:
+
+    K:<username>@<hostname>:<reason>
+
+      <username>  - Client's username
+      <hostname>  - Client's hostname
+      <reason>    - Reason client is banned
+
+3.3 Q-lines (Quarantined Nicknames)
+
+  Q-lines specify illegal nicknames. A client that attempts to use
+a quarantined nickname will be exited from the Ircd server. Q-lines
+are of the form:
+
+    Q:<nickname>:<reason>:[[username@]hostname]]
+
+      <nickname>  - Quarantined nickname
+      <reason>    - Reason nickname is quarantined
+      [username]  - *Optional* exempted username
+      [hostname]  - *Optional* exempted hostname
+
+  Examples:
+
+    Q:dcc*:Dcc bots not allowed
+    Q:GoodOper:GoodOper may use this nick:goo...@op...
+
+3.4 P-lines (Ports)
+
+  P-lines specify ports on which the IAuth server will listen for
+incoming Ircd server connections. They are of the form:
+
+    P:<portnum>
+
+      <portnum>   - Port number
Index: ircdh/doc/en/irc.1
diff -u /dev/null ircdh/doc/en/irc.1:1.1
--- /dev/null	Sat Jan 18 15:45:24 2003
+++ ircdh/doc/en/irc.1	Sat Jan 18 15:45:13 2003
@@ -0,0 +1,82 @@
+.\" @(#)irc.1 2.6 7 Oct 90
+.TH IRC 1 "7 October 1990"
+.SH NAME
+irc \- User Interface to Internet Relay Chat Protocol
+.SH SYNOPSIS
+\fBirc\fP [\fB-p\fP \fIportnum\fP] [\fB-c\fP \fIchannel\fP] [ \fInickname\fP [ \fIserver\fP ]]
+.SH DESCRIPTION
+.LP
+\fBIrc\fP is a user interface to the Internet Relay Chat, a CB-like
+interactive discussion environment.  It is structured into \fIchannels\fP,
+which are public discussion forums, and also allows for private intercommunication.
+Each participant has a \fInickname\fP, which is the one specified in the command
+line or else his login name.
+.LP
+Once invoked, \fBirc\fP connects as a client to the specified server,
+\fIserver\fP or to the default one (see below).  The screen splits into a dialogue
+window (the major part
+of the screen) and a command line, from which messages can be sent and
+commands given to control irc.
+.SH COMMAND SYNTAX
+The syntax of irc commands is of the form \fB/COMMAND\fP.  The most notable
+ones are listed below.  For an uptodate list, use the \fBHELP\fP command
+of \fBirc\fP.  Case is ignored.
+.IP "\fB/ADMIN\fR [\fIserver\fP]"
+Prints administrative information about an IRC \fIserver\fP.
+.IP "\fB/AWAY\fP [\fImessage\fP]"
+Mark yourself as being away (with an automatic reply \fImessage\fP
+if specified)
+.IP "\fB/BYE\fR, \fB/EXIT\fR, \fB/QUIT\fR"
+Terminate the session
+.IP "\fB/CHANNEL\fR [\fIchannel\fP]"
+Join another \fIchannel\fP
+.IP "\fB/CLEAR\fR"
+Clear the screen
+.IP "\fB/HELP\fR [\fIcommand\fP]"
+Display a brief description of the \fIcommand\fP (or list all commands, if none
+specified).
+.IP "\fB/SUMMON\fR \fIuser\fP"
+Allows to summon a \fIuser\fP specified as a full Internet address, i.e.,
+\fI...@ho...main\fP, to an IRC dialogue session (in much the same
+way as the talk(1) command).  It is usable ONLY if the irc daemon runs on
+the target machine (host.domain).
+.IP "\fB/TOPIC\fR \fItopic\fP"
+Sets the \fItopic\fP for the current channel
+.IP "\fB/WHO\fR [\fIchannel\fP|*]"
+Lists all users of IRC if no argument, of the specified \fIchannel\fP or of the
+current channel (*).
+.SH ARGUMENTS
+.IP "\fB-p\fP \fIportnum\fP"
+TCP/IP "port number.  Default is 6667 and this option should seldom if ever"
+be used.
+.IP "\fB-c\fP \fIchannel\fP"
+\fIChannel\fP number to join upon beginning of the session.  Default is no channel.
+.IP "\fInickname\fP"
+\fINickname\fP used in the session (can be changed with the \fB/NICK\fP command).
+Default is user login name.
+.IP "\fIserver\fP"
+\fIServer\fP to connect to.  Default is specified in the irc system configuration
+file, and can be superseded with the environment variable IRCSERVER.
+.SH EXAMPLE
+.RS
+.nf
+tolmoon% \fBirc -p6667 Wizard tolsun\fP
+.fi
+.RE
+.LP
+connects you to irc server in host tolsun (port 6667) with nickname Wizard
+.SH COPYRIGHT
+Copyright (c) 1988 University of Oulu, Computing Center, Finland.
+.nf
+Copyright (c) 1988,1989,1990 Jarkko Oikarinen
+.nf
+All rights reserved.
+For full COPYRIGHT see LICENSE file with IRC package.
+.SH "SEE ALSO"
+ircd(8)
+.SH BUGS
+What bugs ?
+.SH AUTHOR
+Jarkko Oikarinen <jt...@to...>
+.nf
+Manual page updated by Michel Fingerhut <Mic...@ir...>
Index: ircdh/doc/en/ircd.8
diff -u /dev/null ircdh/doc/en/ircd.8:1.1
--- /dev/null	Sat Jan 18 15:45:24 2003
+++ ircdh/doc/en/ircd.8	Sat Jan 18 15:45:13 2003
@@ -0,0 +1,111 @@
+.\" @(#)ircd.8 2.0 (beta version) 29 Mar 1989 
+.TH IRCD 8 "10 July 2000"
+.SH NAME
+ircd \- The Undernet Internet Relay Chat Daemon
+.SH SYNOPSIS
+.hy 0
+.IP \fBircd\fP
+[-t] [-d directory] [-f configfile] [-x debuglevel] [-h hostname]
+.SH DESCRIPTION
+.LP
+\fIircd\fP is the Undernet Internet Relay Chat daemon.  
+\fIircd\fP is a server in that its function is to "serve"
+the client program \fIirc(1)\fP with messages and commands.  All commands
+and user messages are passed directly to \fIircd\fP for processing
+and relaying to other servers.  \fIirc(1)\fP depends upon
+there being an \fIircd\fP server running somewhere for it to connect to
+and thus allow the user to begin talking to other users.
+.LP
+There are many common clients including ircII, EPIC, and BitchX for UNIX,
+mIRC and pIRCh for Windows, and IRCle and Homer for the Macintosh.
+.SH OPTIONS
+.TP
+.B \-d directory
+This option tells the server to change to that directory and use
+that as a reference point when opening \fIircd.conf\fP and other startup
+files.
+.TP
+.B \-t
+Instructs the server run in the foreground and to direct debugging output to
+standard output.
+.TP
+.B \-x#
+Defines the debug level for \fIircd\fP. The higher the debug level, the more
+messages get directed to debugging file (or standard output if the -t option is
+used).
+.TP
+.B \-w interface
+This option is deprecated.  Outgoing connections are bound to the
+interface specified in the M: line, and incoming connections are accepted only on
+interfaces specified in the P: lines.
+.TP
+.B \-f filename
+Specifies the \fIircd.conf\fP file to be used for this server. The option
+is used to override the default \fIircd.conf\fP given at compile time.
+.TP
+.B \-c
+This flag must be given if you are running \fIircd\fP from \fI/dev/console\fP or
+any other situation where fd 0 isn't a TTY and you want the server to fork
+off and run in the background. This needs to be given if you are starting
+\fIircd\fP from an \fIrc\fP (such as \fI/etc/rc.local\fP) file.
+.TP
+.B \-h hostname
+Allows the user to manually set the server name at startup. The default
+name is hostname.domainname.
+.TP
+.B \-p portname
+This is deprecated in favor of specifying server ports in P: lines.
+
+.SH CONFIGURATION
+If you plan to connect your \fIircd\fP server to an existing IRC network,
+you will need to alter your local \fIircd\fP configuration file (typically named
+\fIircd.conf\fP) so that it will accept and make connections to other IRC
+servers.  This file contains the hostnames, network addresses, and
+passwords for connections to other IRC servers around the world.  Because 
+the description of the \fIircd.conf\fP file is beyond the scope of this
+document, please refer to the INSTALL file in the \fIircd\fP
+documentation directory.
+.LP
+BOOTING THE SERVER:  The \fIircd\fP server can be started as part of the
+UNIX boot procedure or just by placing the server into Unix Background.
+Keep in mind that if it is *not* part of your UNIXES Boot-up procedure 
+then you will have to manually start the \fIircd\fP server each time your
+UNIX is rebooted.  This means if your UNIX is prone to crashing
+or going for for repairs a lot it would make sense to start the \fIircd\fP
+server as part of your UNIX bootup procedure.  In some cases the \fIirc(1)\fP
+will automatically attempt to boot the \fIircd\fP server if the user is
+on the SAME UNIX that the \fIircd\fP is supposed to be running on.  If the
+\fIirc(1)\fP cannot connect to the \fIircd\fP server it will try to start
+the server on it's own and will then try to reconnect to the newly booted
+\fIircd\fP server.
+.SH EXAMPLE
+.RS
+.nf
+tolsun% \fBircd\fP
+.fi
+.RE
+.LP
+Places \fIircd\fP into UNIX Background and starts up the server for use.
+Note:  You do not have to add the "&" to this command, the program will
+automatically detach itself from tty.
+.SH COPYRIGHT
+(c) 1988,1989 University of Oulu, Computing Center, Finland,
+.LP
+(c) 1988,1989 Department of Information Processing Science,
+University of Oulu, Finland
+.LP
+(c) 1988,1989,1990,1991 Jarkko Oikarinen
+.LP
+For full COPYRIGHT see LICENSE file with IRC package.
+.LP
+.RE
+.SH FILES
+ /etc/utmp
+ "ircd.conf"
+.SH "SEE ALSO"
+irc(1)
+.SH BUGS
+See the file 'BUGS' included in the distribution.
+.SH AUTHOR
+The current authors of the undernet IRC daemon are cod...@un...,
+the original author was Jarkko Oikarinen.
\ No newline at end of file
Index: ircdh/doc/en/iso-time.html
diff -u /dev/null ircdh/doc/en/iso-time.html:1.1
--- /dev/null	Sat Jan 18 15:45:24 2003
+++ ircdh/doc/en/iso-time.html	Sat Jan 18 15:45:13 2003
@@ -0,0 +1,535 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<!-- $Id: iso-time.html,v 1.1 2003/01/18 23:45:13 zolty Exp $ -->
+<HTML>
+<HEAD>
+<TITLE>International Standard Date and Time Notation</TITLE>
+<BASE HREF="http://www.cl.cam.ac.uk/~mgk25/iso-time.html">
+<META NAME="keywords" CONTENT="ISO 8601, date format, time format,
+standard notation, calendar, clock, time zones, daylight saving time,
+summer time, international standard, file format, protocol,
+data representation">
+<META NAME="description" CONTENT="International Standard ISO 8601
+specifies numeric representations of date and time. It helps to avoid
+confusion caused by the many different national notations.">
+</HEAD>
+<BODY BGCOLOR="#EFEFEF" TEXT="#000000">
+
+<H1>A Summary of the International Standard Date and Time Notation</H1>
+
+<P>by Markus Kuhn
+
+<P><A HREF="http://www.iso.ch/markete/8601.pdf">International Standard
+ISO 8601</A> specifies numeric representations of date and time. This
+standard notation helps to avoid confusion in international
+communication caused by the many different national notations and
+increases the portability of computer user interfaces. In addition,
+these formats have several important advantages for computer usage
+compared to other traditional date and time notations. The time
+notation described here is already the de-facto standard in almost all
+countries and the date notation is becoming increasingly popular.
+
+<P><STRONG>Especially authors of Web pages and software engineers who
+design user interfaces, file formats, and communication protocols
+should be familiar with ISO 8601.</STRONG>
+
+<P>Contents: <A HREF="#date">Date</A>, <A HREF="#time">Time of Day</A>,
+<A HREF="#zone">Time Zone</A>.
+
+<H2><A NAME="date">Date</A></H2>
+
+<P>The international standard date notation is
+
+<BLOCKQUOTE><P><STRONG>YYYY-MM-DD</STRONG></BLOCKQUOTE>
+
+<P>where YYYY is the year in the usual Gregorian calendar, MM is the
+month of the year between 01 (January) and 12 (December), and DD is
+the day of the month between 01 and 31.
+
+<P>For example, the fourth day of February in the year 1995 is written
+in the standard notation as
+
+<BLOCKQUOTE><P><STRONG>1995-02-04</STRONG></BLOCKQUOTE>
+
+<P>Other commonly used notations are e.g. 2/4/95, 4/2/95, 95/2/4,
+4.2.1995, 04-FEB-1995, 4-February-1995, and many more. Especially the
+first two examples are dangerous, because as both are used quite often
+in the U.S. and in Great Britain and both can not be distinguished, it
+is unclear whether 2/4/95 means 1995-04-02 or 1995-02-04. The date
+notation 2/4/5 has at least six reasonable interpretations (assuming
+that only the twentieth and twenty-first century are reasonable
+candidates in our life time).
+
+<P>Advantages of the ISO 8601 standard date notation compared to other
+commonly used variants:
+
+<UL>
+  <LI>easily readable and writeable by software (no 'JAN', 'FEB', ...
+      table necessary)
+  <LI>easily comparable and sortable with a trivial string comparison
+  <LI>language independent
+  <LI>can not be confused with other popular date notations
+  <LI>consistency with the common 24h time notation system, where
+      the larger units (hours) are also written in front of the smaller
+      ones (minutes and seconds)
+  <LI>strings containing a date followed by a time are also
+      easily comparable and sortable (e.g. write "1995-02-04 22:45:00")
+  <LI>the notation is short and has constant length, which makes both
+      keyboard data entry and table layout easier
+  <LI>identical to the Chinese date notation, so the largest cultural
+      group (>25%) on this planet is already familiar with it :-)
+  <LI>date notations with the order "year, month, day" are in addition
+      already widely used e.g. in Japan, Korea, Hungary, Sweden, Finland,
+      Denmark, and a few other countries and people in the U.S. are already
+      used to at least the "month, day" order
+  <LI>a 4-digit year representation avoids
+      <A HREF="http://www.year2000.com/cgi-bin/clock.cgi">overflow
+      problems after 1999-12-31</A>
+</UL>
+
+<P>As dates will look a little bit strange anyway starting with
+2000-01-01 (e.g. like 1/1/0), it has been suggested that the year 2000
+is an excellent opportunity to change to the standard date notation.
+
+<P>ISO 8601 is only specifying numeric notations and does not cover
+dates and times where words are used in the representation. It is not
+intended as a replacement for language-dependent worded date notations
+such as "24. Dezember 2001" (German) or "February 4, 1995" (US
+English). ISO 8601 should however be used to replace notations such as
+"2/4/95" and "9.30 p.m.".
+
+<P>Apart from the recommended primary standard notation
+<STRONG>YYYY-MM-DD</STRONG>, ISO 8601 also specifies a number of
+alternative formats for use in applications with special requirements.
+All of these alternatives can easily and automatically be
+distinguished from each other:
+
+<P>The hyphens can be omitted if compactness of the representation is
+more important than human readability, for example as in
+
+<BLOCKQUOTE><P><STRONG>19950204</STRONG></BLOCKQUOTE>
+
+<P>For situations where information about the century is really not
+required, a 2-digit year representation is available:
+
+<BLOCKQUOTE><P><STRONG>95-02-04</STRONG> or
+<STRONG>950204</STRONG></BLOCKQUOTE>
+
+<P>If only the month or even only the year is of interest:
+
+<BLOCKQUOTE><P><STRONG>1995-02</STRONG> or
+<STRONG>1995</STRONG></BLOCKQUOTE>
+
+<P>In commercial and industrial applications (delivery times,
+production plans, etc.), especially in Europe, it is often required to
+refer to a week of a year. Week 01 of a year is per definition the
+first week that has the Thursday in this year, which is equivalent to
+the week that contains the fourth day of January. In other words, the
+first week of a new year is the week that has the majority of its
+days in the new year. Week 01 might also contain days from the
+previous year and the week before week 01 of a year is the last week
+(52 or 53) of the previous year even if it contains days from the new
+year. A week starts with Monday (day 1) and ends with Sunday (day 7).
+For example, the first week of the year 1997 lasts from 1996-12-30 to
+1997-01-05 and can be written in standard notation as
+
+<BLOCKQUOTE><P><STRONG>1997-W01</STRONG> or
+<STRONG>1997W01</STRONG></BLOCKQUOTE>
+
+<P>The week notation can also be extended by a number indicating the
+day of the week. For example, the day 1996-12-31, which is the Tuesday
+(day 2) of the first week of 1997, can also be written as
+
+<BLOCKQUOTE><P><STRONG>1997-W01-2</STRONG> or
+<STRONG>1997W012</STRONG></BLOCKQUOTE>
+
+<P>for applications like industrial planning where many things like
+shift rotations are organized per week and knowing the week number and
+the day of the week is more handy than knowing the day of the month.
+
+<P>An abbreviated version of the year and week number like
+
+<BLOCKQUOTE><P><STRONG>95W05</STRONG></BLOCKQUOTE>
+
+<P>is sometimes useful as a compact code printed on a product that
+indicates when it has been manufactured.
+
+<P>The ISO standard avoids explicitly stating the possible range of
+week numbers, but this can easily be deduced from the definition:
+
+<BLOCKQUOTE>
+
+<P><STRONG>Theorem:</STRONG> Possible ISO week numbers are in the
+range 01 to 53. A year always has a week 52. (There is one historic
+exception: the year in which the Gregorian calendar was introduced had
+less than 365 days and less than 52 weeks.)
+
+<P><STRONG>Proof:</STRONG> Per definition, the first week of a year is
+W01 and consequently days before week W01 belong to the previous year
+and so there is no week with lower numbers. Considering the highest
+possible week number, the worst case is a leap year like 1976 that
+starts with a Thursday, because this keeps the highest possible number
+of days of W01 in the previous year, i.e. 3 days. In this case, the
+Sunday of W52 of the worst case year is day number 4+51*7=361 and
+361-366=5 days of W53 belong still to this year, which guarantees that
+in the worst case year day 4 (Thursday) of W53 is not yet in the next
+year, so a week number 53 is possible. For example, the 53 weeks of
+the worst case year 1976 started with 1975-12-29 = 1976-W01-1 and
+ended with 1977-01-02 = 1976-W53-7. On the other hand, considering the
+lowest number of the last week of a year, the worst case is a non-leap
+year like 1999 that starts with a Friday, which ensures that the first
+three days of the year belong to the last week of the previous year.
+In this case, the Sunday of week 52 would be day number 3+52*7=367,
+i.e. only the last 367-365=2 days of the W52 reach into the next year
+and consequently, even a worst case year like 1999 has a week W52
+including the days 1999-12-27 to 2000-01-02. q.e.d.
+
+</BLOCKQUOTE>
+
+<P>[Unfortunately, the current version of the C programming language
+standard provides in the <CODE>strftime()</CODE> function no means to
+generate the ISO 8601 week notation. A required extension would be
+four new formatting codes: for the year of the week to which the
+specified day belongs (both 2-digit and 4-digit), for the number of
+the week between 01 and 53, and for the day of the week between 1
+(Monday) and 7 (Sunday). Another trivial mistake in the description of
+<CODE>strftime()</CODE> in the C standard is that the range of seconds
+goes from 00 to 61, because at one time only one single leap second 60
+can be inserted into UTC and consequently there will never be a leap
+second 61. Contribution <A
+HREF="http://www.gold.net/users/cdwf/c/wg14n764.txt">N764</A> to the
+<A HREF="ftp://dkuug.dk/JTC1/SC22/wg14/index.html">ISO C committee</A>
+suggests to fix some of this in the next revision of the ISO C
+standard. The author of this text has also developed a proposal for a
+<A HREF="c-time/">modernised clock and calendar API</A> for C, which
+provides full proper treatment of leap seconds and timezones and fixes
+numerous other problems in the current C timing library functions. It
+also serves as an excellent model for those who want to design clock
+library functions for other programming languages.]
+
+<P>Both day and year are useful units of structuring time, because the
+position of the sun on the sky, which influences our lives, is
+described by them. However the 12 months of a year are of some obscure
+mystic origin and have no real purpose today except that people are
+used to having them (they do not even describe the current position of
+the moon). In some applications, a date notation is preferred that
+uses only the year and the day of the year between 001 and 365 (366 in
+leap years). The standard notation for this variant representing
+the day 1995-02-04 (that is day 035 of the year 1995) is
+
+<BLOCKQUOTE><P><STRONG>1995-035</STRONG> or
+<STRONG>1995035</STRONG></BLOCKQUOTE>
+
+<P>Leap years are years with an additional day YYYY-02-29, where the
+year number is a multiple of four with the following exception: If a
+year is a multiple of 100, then it is only a leap year if it is also a
+multiple of 400. For example, 1900 was not a leap year, but 2000 is one.
+
+<H2><A NAME="time">Time of Day</A></H2>
+
+<P>The international standard notation for the time of day is
+
+<BLOCKQUOTE><P><STRONG>hh:mm:ss</STRONG></BLOCKQUOTE>
+
+<P>where hh is the number of complete hours that have passed since
+midnight (00-24), mm is the number of complete minutes that have
+passed since the start of the hour (00-59), and ss is the number of
+complete seconds since the start of the minute (00-59).  If the hour
+value is 24, then the minute and second values must be zero. [Although
+ISO 8601 does not mention this, the value 60 for ss might sometimes be
+needed during an inserted <A
+HREF="http://tycho.usno.navy.mil/leap.html">leap second</A> in an
+atomic time scale like Coordinated Universal Time (UTC). A single leap
+second 23:59:60 is inserted into the UTC time scale every few years as
+announced by the <A HREF="http://hpiers.obspm.fr/">International Earth
+Rotation Service</A> in Paris to keep UTC from wandering away more
+than 0.9&nbsp;s from the less constant astronomical time scale UT1
+that is defined by the actual rotation of the earth.]
+
+
+<P>An example time is
+
+<BLOCKQUOTE><P><STRONG>23:59:59</STRONG></BLOCKQUOTE>
+
+<P>which represents the time one second before midnight.
+
+<P>As with the date notation, the separating colons can also be
+omitted as in
+
+<BLOCKQUOTE><P><STRONG>235959</STRONG></BLOCKQUOTE>
+
+<P>and the precision can be reduced by omitting the seconds or both
+the seconds and minutes as in
+
+<BLOCKQUOTE><P><STRONG>23:59</STRONG>, <STRONG>2359</STRONG>, or
+<STRONG>23</STRONG></BLOCKQUOTE>
+
+<P>It is also possible to add fractions of a second after a decimal
+dot or comma, for instance the time 5.8&nbsp;ms before midnight can be
+written as
+
+<BLOCKQUOTE><P><STRONG>23:59:59.9942</STRONG> or
+<STRONG>235959.9942</STRONG> </BLOCKQUOTE>
+
+<P>As every day both starts and ends with midnight, the two notations
+<STRONG>00:00</STRONG> and <STRONG>24:00</STRONG> are available to
+distinguish the two midnights that can be associated with one date.
+This means that the following two notations refer to exactly the same
+point in time:
+
+<BLOCKQUOTE><P><STRONG>1995-02-04 24:00</STRONG> =
+<STRONG>1995-02-05 00:00</STRONG></BLOCKQUOTE>
+
+<P>In case an unambiguous representation of time is required, 00:00 is
+usually the preferred notation for midnight and not 24:00. Digital
+clocks display 00:00 and not 24:00.
+
+<P>ISO 8601 does not specify, whether its notations specify a point in
+time or a time period. This means for example that ISO 8601 does not
+define whether 09:00 refers to the exact end of the ninth hour of the
+day or the period from 09:00 to 09:01 or anything else. The users of
+the standard must somehow agree on the exact interpretation of the
+time notation if this should be of any concern.
+
+<P>If a date and a time are displayed on the same line, then always
+write the date in front of the time. If a date and a time value are
+stored together in a single data field, then ISO 8601 suggests that
+they should be separated by a latin capital letter T, as in
+<STRONG>19951231T235959</STRONG>.
+
+<P>A remark for readers from the U.S.:
+
+<BLOCKQUOTE><P>The 24h time notation specified here has already been
+the de-facto standard all over the world in written language for
+decades. The only exception are some English speaking countries, where
+still notations with hours between 1 and 12 and additions like "a.m."
+and "p.m." are in wide use. The common 24h international standard
+notation starts to get widely used now even in England. Most other
+languages don't even have abbreviations like "a.m." and "p.m." and the
+12h notation is certainly hardly ever used on Continental Europe to
+write or display a time. Even in the U.S., the military and computer
+programmers have been using the 24h notation for a long time.
+
+<P>The old English 12h notation has many disadvantages like:
+
+<UL>
+  <LI> It is longer than the normal 24h notation.
+  <LI> It takes somewhat more time for humans to compare two times
+       in 12h notation.
+  <LI> It is not clear, how 00:00, 12:00 and 24:00 are represented.
+       Even encyclopedias and style manuals contain contradicting
+       descriptions and a common quick fix seems to be to avoid
+       "12:00 a.m./p.m." altogether and write "noon", "midnight", or
+       "12:01 a.m./p.m." instead, although the word "midnight" still
+       does not distinguish between 00:00 and 24:00.
+  <LI> It makes people often believe that the next day starts at the
+       overflow from "12:59 a.m." to "1:00 a.m.", which is a common
+       problem not only when people try to program the timer of VCRs
+       shortly after midnight.
+  <LI> It is not easily comparable with a string compare operation.
+  <LI> It is not immediately clear for the unaware, whether the
+       time between "12:00 a.m./p.m." and "1:00 a.m./p.m." starts
+       at 00:00 or at 12:00, i.e. the English 12h notation is more
+       difficult to understand.
+</UL>
+
+<P>Please consider the 12h time to be a relic from the dark ages when
+Roman numerals were used, the number zero had not yet been invented
+and analog clocks were the only known form of displaying a
+time. Please avoid using it today, especially in technical
+applications! Even in the U.S., the widely respected <CITE>Chicago
+Manual of Style</CITE> now recommends using the international
+standard time notation in publications.
+
+</BLOCKQUOTE>
+
+<P>A remark for readers from German speaking countries:
+
+<BLOCKQUOTE><P>In May 1996, the German standard DIN 5008, which
+specifies typographical rules for German texts written on typewriters,
+has been updated. The old German numeric date notations DD.MM.YYYY and
+DD.MM.YY have been replaced by the ISO date notations YYYY-MM-DD and
+YY-MM-DD. Similarly, the old German time notations hh.mm and hh.mm.ss
+have been replaced by the ISO notations hh:mm and hh:mm:ss.  Those new
+notations are now also mentioned in the latest edition of the
+<CITE>Duden</CITE>. The German alphanumeric date notation continues to
+be for example "3. August 1994" or "3. Aug. 1994". The corresponding
+Austrian standard has already used the ISO 8601 date and time
+notations before.
+
+<P>ISO 8601 has been adopted as European Standard EN 28601 and is
+therefore now a valid standard in all EU countries and all conflicting
+national standards have been changed accordingly.
+</BLOCKQUOTE>
+
+<H2><A NAME="zone">Time Zone</A></H2>
+
+<P>Without any further additions, a date and time as written above is
+assumed to be in some local time zone. In order to indicate that a
+time is measured in <A HREF="http://aa.usno.navy.mil/AA/faq/docs/UT.html"
+>Universal Time (UTC)</A>, you can append a capital
+letter <STRONG>Z</STRONG> to a time as in
+
+<BLOCKQUOTE><P><STRONG>23:59:59Z</STRONG> or <STRONG>2359Z</STRONG>
+</BLOCKQUOTE>
+
+<P>[The Z stands for the "zero meridian", which goes through Greenwich
+in London, and it is also commonly used in radio communication where
+it is pronounced "Zulu" (the word for Z in the international radio
+alphabet).  <A HREF=
+"http://www.apparent-wind.com/gmt-explained.html">Universal
+Time</A> (sometimes also called "Zulu Time") was called Greenwich Mean
+Time (GMT) before 1972, however this term should no longer be
+used. Since the introduction of an international atomic time scale,
+almost all existing civil time zones are now related to UTC, which is
+slightly different from the old and now unused GMT.]
+
+<P>The strings
+
+<BLOCKQUOTE><P><STRONG>+hh:mm</STRONG>, <STRONG>+hhmm</STRONG>, or
+<STRONG>+hh</STRONG></BLOCKQUOTE>
+
+<P>can be added to the time to indicate that the used local time zone
+is hh hours and mm minutes ahead of UTC. For time zones west of the
+zero meridian, which are behind UTC, the notation
+
+<BLOCKQUOTE><P><STRONG>-hh:mm</STRONG>, <STRONG>-hhmm</STRONG>, or
+<STRONG>-hh</STRONG></BLOCKQUOTE>
+
+<P>is used instead. For example, Central European Time (CET) is +0100
+and U.S./Canadian Eastern Standard Time (EST) is -0500. The following
+strings all indicate the same point of time:
+
+<BLOCKQUOTE><P><STRONG>12:00Z</STRONG> = <STRONG>13:00+01:00</STRONG>
+= <STRONG>0700-0500</STRONG></BLOCKQUOTE>
+
+<P>There exists no international standard that specifies
+abbreviations for civil time zones like CET, EST, etc. and sometimes
+the same abbreviation is even used for two very different time zones.
+In addition, politicians enjoy modifying the rules for civil time
+zones, especially for daylight saving times, every few years, so the
+only really reliable way of describing a local time zone is to specify
+numerically the difference of local time to UTC. Better use directly
+UTC as your only time zone where this is possible and then you do not
+have to worry about time zones and daylight saving time changes at
+all.
+
+<H2><A NAME="tz">More Information about Time Zones</A></H2>
+
+<P><A HREF="mailto:ad...@el...">Arthur David Olson</A> and
+others maintain a <A HREF=
+"http://www.twinsun.com/tz/tz-link.htm">database of all current and
+many historic time zone changes and daylight saving time
+algorithms</A>. It is available via ftp from <A
+HREF="ftp://elsie.nci.nih.gov/pub/">elsie.nci.nih.gov</A> in the
+<SAMP>tzcode*</SAMP> and <SAMP>tzdata*</SAMP> files. Most Unix time
+zone handling implementations are based on this package. If you want
+to join the <SAMP>tz</SAMP> mailing list, which is dedicated to
+discussions about time zones and this software, please send a request
+for subscription to <A HREF="mailto:tz-...@el..."
+>tz-...@el...</A>. You can read previous discussion
+there in the <A HREF="ftp://elsie.nci.nih.gov/pub/tzarchive.gz">tz
+archive</A>.
+
+<H2><A NAME="other">Other Links about Date, Time, and Calendars</A></H2>
+
+<P>Some other interesting sources of information about date and time
+on the Internet are for example the <A
+HREF="http://www.boulder.nist.gov/timefreq/glossary.htm">Glossary of
+Frequency and Timing Terms</A> and the <A
+HREF="http://www.boulder.nist.gov/timefreq/faq/...
 
[truncated message content]