Path: utzoo!utgpu!lsuc!sickkids!dptcdc!ncrcan!brian
From: brian@ncrcan.Toronto.NCR.COM (Brian Onn)
Newsgroups: tor.news
Subject: Re: attcan't?
Message-ID: <1391@ncrcan.Toronto.NCR.COM>
Date: 8 May 89 14:29:50 GMT
References: <1989May6.220422.126@telly.on.ca> <1989May7.041643.29194@utzoo.uucp> <1389@ncrcan.Toronto.NCR.COM> <1989May8.071129.19925@utstat.uucp>
Reply-To: brian@ncrcan.Toronto.NCR.COM (Brian Onn)
Organization: NCR Canada Ltd., Mississauga, Ontario
Lines: 32

In article <1989May8.071129.19925@utstat.uucp>
			geoff@utstat.uucp (Geoff Collyer) writes:
>C news generates longish Message-IDs because I didn't want to have a
>sequence-number file, which can get truncated by a crash during
>updating, and because Message-IDs are currently generated by a shell
>script.  The current date and time combined with the shell's process id
>(the last number before the "@") should keep Message-IDs unique.
>Without the date, time or process-id, Message-IDs could collide.

Ok.. I can accept the attempt to eliminate corruption in the event
of a crash.

>However, there are reasons other than aesthetics for preferring short
>Message-IDs, including limitations in dbm(3) on total key and data
>lengths per block.  Furthermore, RFC 1036 (nee 850) only requires that
>messages be unique for two years.  One could omit high-order digits of
>the year or encode the information more compactly, perhaps printing
>integers in radix 64 (e.g. <1989May7.041643.29194@utzoo.uucp> could be
>expressed as <!e9`nl()+@utzoo.uucp>, saving 12 characters).

True, but utterly gross!  I believe that andrew.cmu.edu does something
like this.  Ok, I'll retract.  Stick with the longish, yet unique, 
and still yet readable, Message-Ids.  I'll start splitting the 
"In article.." lines into two, as you subtely suggested. 

Thanks,
	Brian.
-- 
 +-------------------+--------------------------------------------------------+
 | Brian Onn         | UUCP:..!{uunet!attcan, watmath!utai}!lsuc!ncrcan!brian |
 | NCR Canada Ltd.   | INTERNET: Brian.Onn@Toronto.NCR.COM                    |
 +-------------------+--------------------------------------------------------+